[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 12:18, Jan Beulich wrote:
On 22.09.14 at 17:38, <george.dunlap@xxxxxxxxxxxxx> 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.

Again, that's my understanding, someone please correct me if I'm wrong...
That's indeed what was said so far. I wonder though whether opening
this up without guest OS consent isn't gong to introduce a security
issue inside the guest (depending on the exact functionality of these

Since this is only opened when vmware_port=1, there is no change when vmware_port=0.

I do not know of any security issue inside the guest with the subset that is supported (and there
has been more then 1 set of eyes looking for them).

    -Don Slutz


Xen-devel mailing list



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