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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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)

Ian.


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