|
xen-devel
RE: [Xen-devel] Configuration of nestedhvm
Keir Fraser wrote:
> On 08/10/2010 08:56, "Dong, Eddie" <eddie.dong@xxxxxxxxx> wrote:
>
>>> What's the point when a per-domain config option is going to be
>>> implemented? You can then simply not configure nestedhvm for a
>>> domain you want to test without that capability? I suppose it makes
>>> your second patch make a bit more sense than it would in total
>>> isolation.
>>
>> I want double-lock (AND) like other components such as IOMMU.
>> If the global switch is off, even per domain configuration is turned
>> on, the final effect is "OFF".
>>
>> The point here is to avoid manual mistake when the nested code is
>> built in as formal release but targeting for pilot. Relying on HVM
>> guest configuration only may cause the host crash or performance
>> impact if the code has a bug and a guest enables nested
>> virtualization feature.
>>
>> This switch is mainly for developer only at least for now.
>
> Well, at least it should only be disallowing toolstack to set the
> per-domain config option. Then it won't need to be accessed on every
The tools side patch will hypercall to try to set, but it is hypervisor's
decision to allow the setting or not.
The userland CPUID emulation will rely on the VMM returned setting.
> use of is_nestedhvm(). So again it depends on that, mainly tool-side,
> patch.
It is chicken and egg then :) emulation of per domain setting hypercall relies
on the global setting. is_nestedhvm relies on the per domain setting :)
But it is fine too, as if you want the global control, and Chris may merge the
patch into his if he needs to repost..
>
> -- Keir
So can Ian have a look at the previous Chris patch again? What is the reason to
block that patch?
Thx, Eddie
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home