From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Andy Lutomirski <luto@amacapital.net>,
Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>,
"Luis R. Rodriguez" <mcgrof@kernel.org>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Borislav Petkov <bp@alien8.de>
Subject: Re: HVMlite gains
Date: Tue, 15 Mar 2016 17:50:13 -0400 [thread overview]
Message-ID: <56E88395.7090404@oracle.com> (raw)
In-Reply-To: <CALCETrW=kWZEF-xM2X3cu_YCfvQX7Ad72WCLbUDhchcqVUrKmg@mail.gmail.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
next prev parent reply other threads:[~2016-03-15 21:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-15 21:14 HVMlite gains Luis R. Rodriguez
2016-03-15 21:29 ` Andrew Cooper
2016-03-15 21:36 ` Andy Lutomirski
2016-03-15 21:50 ` Boris Ostrovsky [this message]
2016-03-15 21:50 ` Andrew Cooper
2016-03-15 21:52 ` Andy Lutomirski
2016-03-15 22:05 ` Andrew Cooper
2016-03-16 3:18 ` Andy Lutomirski
2016-03-16 10:46 ` Andrew Cooper
2016-03-15 22:39 ` Konrad Rzeszutek Wilk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56E88395.7090404@oracle.com \
--to=boris.ostrovsky@oracle.com \
--cc=andrew.cooper3@citrix.com \
--cc=bp@alien8.de \
--cc=luto@amacapital.net \
--cc=matt@codeblueprint.co.uk \
--cc=mcgrof@kernel.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).