Re: HVMlite gains

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 15/03/2016 21:14, Luis R. Rodriguez wrote:
> While discussing HVMLite with a few people a few questions have come
> up. Since I only really understand a few possible gains with the
> current design I wanted to get clarificaiton on a few which I simply
> have no clue if we stand to gain from them, or if its on the roadmap:
>
>   a) Will context switches use the actual CR3 register?

Yes.  HVMLite will use fully the full array of hardware virtualisation
extensions, so gets its own pagetables and cr3.

>   b) Will IOPL live in the actual FLAGS register?

Yes

>   c) Will guest-usable CPU features should show up in CPUID, and will
> features that shouldn't be used should *not* show up in CPUID. For
> instance currently you happen to boot Xen 4.4.0 with a new Linux dom0
> on a CPU that supports MPX what will happen? What about with HVMlite?

I am desperately trying to fix the existing broken-ness.  PV is too far
beyond repair when it comes to the OSXSAVE bit, but the rest is fine. 
See my "x86: Improvements to cpuid handling for guests" series, v3 of
which was posted today.

With that series in place, a guest should always see correct features
(give or take some "fun" with masking, but at least the xen_cpuid() path
will still be correct).

>   d)  Will acking an interrupt use the standard APIC mechanism?  Do
> any of the current Xen variants do that?

Emulated APIC will be enabled by default. The "PV event" path will be
available as an alternative.

If a user desperately wishes to avoid the emulated APIC, they have the
option to disable it in the domain config.

>   e) Can timing use RDTSC?

I don't understand this question in the context of the others.  RDTSC
has (as far as I can tell) always been advertised and available for
guest use.  RDTSCP is a different matter, and I have half-fixed that
brokenness; it should now work correctly in HVM guests.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel