From: "Jan Beulich" <JBeulich@suse.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v4 6/6] x86/HVM: report the set of enabled emulated devices through CPUID
Date: Fri, 22 Jan 2016 03:57:38 -0700 [thread overview]
Message-ID: <56A2193202000078000C9FC1@prv-mh.provo.novell.com> (raw)
In-Reply-To: <1453395092-88090-7-git-send-email-roger.pau@citrix.com>
>>> On 21.01.16 at 17:51, <roger.pau@citrix.com> wrote:
> Add a new HVM-specific feature flag that signals the presence of a bitmap
> that contains the current set of enabled emulated devices. The bitmap is
> placed in the ecx register. The bit fields used in the bitmap are the same
> as the ones used in the xen_arch_domainconfig emulation_flags field, and
> their meaning can be found at arch-x86/xen.h.
>
> This will allow Xen to enable emulated devices for HVMlite guests in the
> future, by having a proper ABI for reporting which devices are enabled.
The idea is certainly nice and appreciated, but ...
> --- a/xen/include/public/arch-x86/cpuid.h
> +++ b/xen/include/public/arch-x86/cpuid.h
> @@ -78,12 +78,17 @@
> * HVM-specific features
> * EAX: Features
> * EBX: vcpu id (iff EAX has XEN_HVM_CPUID_VCPU_ID_PRESENT flag)
> + * ECX: bitmap of enabled devices, according to the bit fields defined in
> + * arch-x86/xen.h.
... this set of definitions is not currently a stable ABI (limited to
hypervisor and tool stack), and if we wanted to make it stable
we'd first need to think a little about the complications that may
arise if the granularity chosen (think about the PM bit and the
discussion around it before your changes went in) turns out to
be a problem later on.
Also at least some of the features can be determined by other
means (CPUID, ACPI tables), so I'm not even sure we need all
of this, and I'd really prefer to avoid multiple distinct ways to
learn of a certain feature, as it's too easy for the two (or more)
mechanisms to get out of sync.
> All unused bits have undefined values.
Nor is this an option, but maybe this is just a wording issue:
Perhaps you mean to say that they're reserved for future use?
Since truly unused bits have are guaranteed to have the value
zero, just that the set of bits varies.
Jan
next prev parent reply other threads:[~2016-01-22 10:57 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-21 16:51 [PATCH v4 0/6] HVMlite: DomU fixes and a Dom0 preparatory patch Roger Pau Monne
2016-01-21 16:51 ` [PATCH v4 1/6] libelf: rewrite symtab/strtab loading for Dom0 Roger Pau Monne
2016-01-21 17:29 ` Ian Jackson
2016-01-21 17:55 ` Roger Pau Monné
2016-01-21 18:44 ` Ian Jackson
2016-01-22 8:11 ` Jan Beulich
2016-01-22 9:58 ` Roger Pau Monné
2016-01-21 16:51 ` [PATCH v4 2/6] libxl: introduce LIBXL_VGA_INTERFACE_TYPE_UNKNOWN Roger Pau Monne
2016-01-22 10:59 ` Ian Campbell
2016-01-21 16:51 ` [PATCH v4 3/6] libxl: initialise the build info before calling prepare_config Roger Pau Monne
2016-01-22 11:00 ` Ian Campbell
2016-01-21 16:51 ` [PATCH v4 4/6] x86/PV: allow PV guests to have an emulated PIT Roger Pau Monne
2016-01-22 10:48 ` Jan Beulich
2016-01-22 11:03 ` Ian Campbell
2016-01-21 16:51 ` [PATCH v4 5/6] libxl: add options to enable/disable emulated devices Roger Pau Monne
2016-01-22 17:04 ` Roger Pau Monné
2016-01-25 9:33 ` Ian Campbell
2016-01-21 16:51 ` [PATCH v4 6/6] x86/HVM: report the set of enabled emulated devices through CPUID Roger Pau Monne
2016-01-22 10:57 ` Jan Beulich [this message]
2016-01-22 12:43 ` Roger Pau Monné
2016-01-22 13:24 ` Jan Beulich
2016-01-22 14:41 ` Roger Pau Monné
2016-01-22 15:02 ` Jan Beulich
2016-01-22 15:41 ` Roger Pau Monné
2016-01-22 13:34 ` Andrew Cooper
2016-01-22 14:59 ` Roger Pau Monné
2016-01-22 15:31 ` Jan Beulich
2016-01-22 15:51 ` Roger Pau Monné
2016-01-25 11:23 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56A2193202000078000C9FC1@prv-mh.provo.novell.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=roger.pau@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.