Re: HVMlite gains

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

On 03/15/2016 05:36 PM, Andy Lutomirski wrote:
> On Tue, Mar 15, 2016 at 2:29 PM, Andrew Cooper
> <andrew.cooper3@citrix.com> wrote:
>> 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.
>>
> These questions mostly came from me, and they weren't necessarily
> intended to make sense as a coherent whole :)  They were more of a
> random collection of things I was wondering about to varying extents.
>
> What I mean is:  if we point sched_clock at RDTSC and try to use the
> regular TSC timesource in a guest, will it work reasonably well,
> assuming that the underlying hardware supports it?  And, if the
> underlying hardware doesn't support it (e.g. not constant / invariant
> or no TSC offsetting available or similar), will the hypervisor tell
> the guest this fact via CPUID so that the standard guest clocksource
> code doesn't try to use a non-working TSC?

Hypervisor typically clears TSC Invariant bit because the guest can 
migrate to a system with a different clock

http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/domain.c;h=a6d721bd48176f51c0d9dfb57099c8b7f52220c2;hb=HEAD#l2612

There are options (in guest config file) to have hypervisor set this flag.

-boris


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