[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3] qapi: introduce 'query-cpu-model-cpuid' action
From: |
Daniel P . Berrangé |
Subject: |
Re: [PATCH v3] qapi: introduce 'query-cpu-model-cpuid' action |
Date: |
Mon, 29 Mar 2021 12:48:35 +0100 |
User-agent: |
Mutt/2.0.5 (2021-01-21) |
On Mon, Mar 29, 2021 at 02:21:53PM +0300, Valeriy Vdovin wrote:
> On Mon, Mar 29, 2021 at 10:20:54AM +0100, Daniel P. Berrang?? wrote:
> > On Fri, Mar 26, 2021 at 08:30:00PM +0300, Valeriy Vdovin wrote:
> > > Other than debug, the method is useful in cases when we would like to
> > > utilize QEMU's virtual cpu initialization routines and put the retrieved
> > > values into kernel CPUID overriding mechanics for more precise control
> > > over how various processes perceive its underlying hardware with
> > > container processes as a good example.
> >
> > When I read this, my impression is that QEMU's CPU handling doesn't do
> > what you need, and you're trying to work around it outside of QEMU.
> > Can you give more detailed information about what situations QEMU's
> > CPUID handling doesn't work, and why we can't simply enhance QEMU
> > to do what you need ?
> >
> We want to override CPUID for container processes to support live
> migration. For that we want to base on a reliable cpu model, which is
> present in libvirt and QEMU. We will communicate cpu models information
> between physical nodes to decide the baseline cpu model and then we could
> use the new method to get all CPUID value leaves that we would return to
> containers during CPUID override. In our case the QAPI-way of getting the
> values is a clean solution, because we can just query it from the outside
> (not as guest system).
IIUC, you seem to be saying that you're not actually going to run a
real QEMU VM at all ? You're just using QEMU / QMP as a convenient
way expand a named CPI model into CPUID leaves, so you can then use
this data in a completely separate container based mgmt application.
Essentially treating QMP as a general purpose API for handling CPU
models.
> > > virsh qemu-monitor-command VM --pretty '{ "execute":
> > > "query-cpu-model-cpuid" }'
> > > {
> > > "return": {
> > > "cpuid": {
> > > "leafs": [
> > > {
> > > "leaf": 0,
> > > "subleafs": [
> > > {
> > > "eax": 13,
> > > "edx": 1231384169,
> > > "ecx": 1818588270,
> > > "ebx": 1970169159,
> > > "subleaf": 0
> > > }
> > > ]
> > > },
> > > {
> > > "leaf": 1,
> > > "subleafs": [
> > > {
> > > "eax": 329443,
> > > "edx": 529267711,
> > > "ecx": 4160369187,
> > > "ebx": 133120,
> > > "subleaf": 0
> > > }
> > > ]
> > > },
> > > {
> > > "leaf": 2,
> > > "subleafs": [
> > > {
> > > "eax": 1,
> > > "edx": 2895997,
> > > "ecx": 0,
> > > "ebx": 0,
> > > "subleaf": 0
> > > }
> > > ]
> > > },
> > > ]
> > > },
> > > "vendor": "GenuineIntel",
> > > "class-name": "Skylake-Client-IBRS-x86_64-cpu",
> > > "model-id": "Intel Core Processor (Skylake, IBRS)"
> > > },
> > > "id": "libvirt-40"
> > > }
> >
> > There's feels like there's a lot of conceptual overlap with the
> > query-cpu-model-expansion command. That reports in a arch independant
> > format, but IIUC the property data it returns can be mapped into
> > CPUID leaf values. Is it not possible for you to use this existing
> > command and maintain a mapping of property names -> CPUID leaves ?
> As already stated in the use-case description above, having this method
> around, helps us in a way that we can just take values and return them
> to containers. QEMU code already does a great job, generating CPUID
> responses, we don't want to do the same in our own code.
This is asking QEMU to maintain a new QAPI command which does not appear
to have a use case / benefit for QEMU mgmt. It isn't clear to me that
this should be considered in scope for QMP.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|