Re: [Xen-devel] [PATCH for-4.5 v6 00/16] Xen VMware tools support

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 09/22/2014 04:34 PM, Ian Campbell wrote:
> On Mon, 2014-09-22 at 16:19 +0100, George Dunlap wrote:
> > On 09/22/2014 02:56 PM, Ian Campbell wrote:
> > > On Sat, 2014-09-20 at 14:07 -0400, Don Slutz wrote:
> > >
> > > > I picked this subset to start with because it only has changes in
> > > > Xen.
> > > >
> > > > Some of this code is already in QEMU
> > > As I suggest in my reply to one for the rpc port patches it's not clear
> > > that any of this needs to be in Xen rather than qemu in the first place.
> > >
> > > I came to think this even more once I saw the save/restore support...
> > I don't think qemu can get notified on either cpuid or #GP faults, can it?
> I understand the need for the cpuid bits, I should have made that clear.
>
> > A big chunk of the functionality here is to allow a userspace process to
> > transparently make the "hypercalls" without the OS needing to explicitly
> > give it access to the IO space, by trapping the resulting #GP faults and
> > checking to see if they are IO instructions .  If that's functionality
> > we think is important, then it will have to be done in Xen, I think.
> Ah, the need to #GP was what I had missed, I was thinking it was just a
> regular I/O port access.
>
> Having trapped the #GP and decoded it into an IO access, is there
> anything stopping us forwarding that to qemu for consideration?
>
> (I confess I'm not sure why this is a #GP thing and not a VTd/SVM I/O
> access trap, just like if userspace mmaps /dev/ioports, but I'll trust
> that's just my lack of x86 hw virt knowledge)
I'm not 100% sure of this, but my understanding was that it *would* be a 
normal IO trap *if* the guest OS gave access to that IO range to the 
guest (via IOPL, maybe?).  But if the userspace program is not 
explicitly given access by the OS to those ports, it will generate a #GP 
instead.  The idea is to allow the "hypercall" to happen *without 
cooperation* from the guest OS.
Again, that's my understanding, someone please correct me if I'm wrong...

 -George

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