>>> On 15.03.16 at 16:35, <andrew.coop...@citrix.com> wrote:
> @@ -196,6 +197,56 @@ long arch_do_sysctl(
> ret = -EFAULT;
> break;
>
> + case XEN_SYSCTL_get_cpu_featureset:
> + {
> + static const uint32_t *featureset_table[] = {
Being static, this should imo gain a second const. With that added
Acked-by: Jan Beulich <jbeul...@suse.com>
However, there's still the not fully settled discussion on whether
the HVM feature set should be just one, or two (HAP and shadow
separately). Back then you said
>> A guest booted with hap and a guest booted with shadow will see
>> different features when booted on the same host. Hap includes 1GB
>> superpages, PCID, etc.
>>
>> The problem comes with a shadow guest booted on a hap-capable host.
>> Such a guest can safely be migrated to a non-hap capable host, but only
>> if the toolstack knows that the guest saw a reduced featureset.
>>
>> As there is still no interface to query what a guest can actually see
>> (depends on full per-domain policys and no dynamic hiding), the shadow
>> featuremask is used by the toolstack as a promise of what the Xen
>> dynamic checks will do.
As said in reply, I still don't really see why you don't use a
HAP/shadow dependent mask to take care of those
differences instead of elsewhere doing dynamic adjustments
(the more that such dynamic adjustments are easy to get out
of sync with the static annotations in the public header).
The last half sentence, btw, makes me even wonder how you
suppose the tool stack to know of the shadow mask on a HAP
capable system, and hence how it could take this as any kind
of promise.
Going through the HAP-only features, btw, revealed another
possible dependency missing from patch 10: I would think that
INVPCID depends on PCID.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
