[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 09/22/2014 04:50 PM, Ian Campbell wrote:
On Mon, 2014-09-22 at 16:38 +0100, George Dunlap wrote:
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...
It sounds plausible, for sure.

Even so, why can't the result of that #GP be a calldown into qemu for
further processing?

I was only responding to the part of your comment in parentheses. :-)

I suppose in large part it would depend on what the hypercalls were actually doing; I'd have to go back and look at them to say if they need to be in Xen or whether they could be passed on to qemu.

 -George

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.