Re: [Xen-devel] HVMlite gains

[Andy Lutomirski <luto@xxxxxxxxxxxxxx>]

On Tue, Mar 15, 2016 at 2:29 PM, Andrew Cooper
<andrew.cooper3@xxxxxxxxxx> 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?

--Andy

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