Re: [Xen-devel] HVMlite gains

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 03/15/2016 05:36 PM, Andy Lutomirski wrote:
> 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?
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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel