[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/14 11:55, George Dunlap wrote:
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

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.

Yes, this is why the port in question is (via vmport_register and register_portio_handler) is added
to the hypervisor ports that get handled by hypervisor code.

Again, that's my understanding, someone please correct me if I'm wrong...

Looks like a good statement, should I add it to a commit message?

It sounds plausible, for sure.

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

This is not simple in that QEMU does not have access to the VCPU registers. Unlike a normal
I/O request, vmware_port (aka vmport) both reads and writes VCPU registers.

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.

Clearly it is possible to pass the VCPU registers to QEMU, but that is currently not done. So a new version of QEMU would also be needed to go this way. None the the proposed features need
any data from QEMU, so I do not think this make sense.

   -Don Slutz


Xen-devel mailing list



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