xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Gleb Natapov <gleb@redhat.com>,
	Mukesh Rathor <mukesh.rathor@oracle.com>,
	Mike Rapoport <mike.rapoport@gmail.com>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Ramkumar Ramachandra <artagnon@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	xen-devel@lists.xensource.com
Subject: Re: [QUERY] lguest64
Date: Mon, 05 Aug 2013 09:59:04 -0700	[thread overview]
Message-ID: <51FFD9D8.3000704@zytor.com> (raw)
In-Reply-To: <20130805165040.GC22093@phenom.dumpdata.com>

On 08/05/2013 09:50 AM, Konrad Rzeszutek Wilk wrote:
>>>
>>> Let me iterate down what the experimental patch uses:
>>>
>>>          struct pv_init_ops pv_init_ops;                                         
>>> 		[still use xen_patch, but I think that is not needed anymore]
>>>
>>>          struct pv_time_ops pv_time_ops;                                         
>>> 		[we need that as we are using the PV clock source]
>>>
>>>          struct pv_cpu_ops pv_cpu_ops;                                           
>>> 		[only end up using cpuid. This one is a tricky one. We could
>>> 		 arguable remove it but it does do some filtering - for example
>>> 	 	 THERM is turned off, or MWAIT if a certain hypercall tells us to
>>> 		 disable that. Since this is now a trapped operation this could be
>>> 		 handled in the hypervisor - but then it would be in charge of
>>> 		 filtering certain CPUID - and this is at bootup - so there is not
>>> 		 user interaction. This needs a bit more of thinking]
>>>
>> read_msr/write_msr in this one make all msr accesses safe. IIRC there
>> are MSRs that Linux uses without checking cpuid bits.
>> IA32_PERF_CAPABILITIES for instance is used without checking PDCM bit.
> 
> Right, those are needed as well. Completly forgot about them.

CPUID is not too bad.  RDMSR/WRMSR is actually worse since there are
some MSRs which are performance-critical.  The really messy pvops are
the memory-related ones, as they don't match the hardware behavior.

Similarly, beyond pvops, what new assumptions does this code add to the
code base?

	-hpa

  reply	other threads:[~2013-08-05 16:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CALkWK0n7zedKD4tnxKh-qMuDnMJ5RXjnPJ9EUWT=cCgiokX11A@mail.gmail.com>
     [not found] ` <51E97779.3020103@zytor.com>
     [not found]   ` <87zjte9iah.fsf@rustcorp.com.au>
     [not found]     ` <CABpLfohrweJd0=0eFJDO7dv2HHxx_mbP0uySMDrsZZZXExdXug@mail.gmail.com>
     [not found]       ` <51F9005F.30501@zytor.com>
     [not found]         ` <20130731131757.GB22124@phenom.dumpdata.com>
     [not found]           ` <51F91030.9060606@zytor.com>
2013-08-02 19:09             ` [QUERY] lguest64 Konrad Rzeszutek Wilk
2013-08-04 12:37               ` Gleb Natapov
2013-08-05 16:50                 ` Konrad Rzeszutek Wilk
2013-08-05 16:59                   ` H. Peter Anvin [this message]
2013-08-05 17:16                     ` 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=51FFD9D8.3000704@zytor.com \
    --to=hpa@zytor.com \
    --cc=artagnon@gmail.com \
    --cc=gleb@redhat.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mike.rapoport@gmail.com \
    --cc=mukesh.rathor@oracle.com \
    --cc=rusty@rustcorp.com.au \
    --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).