From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don Slutz Subject: Re: [PATCH for-4.5 v6 00/16] Xen VMware tools support Date: Mon, 22 Sep 2014 14:32:11 -0400 Message-ID: <54206B2B.1030208@terremark.com> References: <1411236447-7435-1-git-send-email-dslutz@verizon.com> <1411394209.18331.113.camel@kazak.uk.xensource.com> <54203DE9.9040307@eu.citrix.com> <1411400048.26552.10.camel@kazak.uk.xensource.com> <54204280.2030408@eu.citrix.com> <542067EC020000780003731E@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <542067EC020000780003731E@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Ian Campbell , George Dunlap Cc: Tim Deegan , Kevin Tian , Keir Fraser , Jun Nakajima , Stefano Stabellini , Andrew Cooper , Eddie Dong , Don Slutz , xen-devel@lists.xen.org, AravindGopalakrishnan , Suravee Suthikulpanit , Boris Ostrovsky , Ian Jackson List-Id: xen-devel@lists.xenproject.org On 09/22/14 12:18, Jan Beulich wrote: >>>> On 22.09.14 at 17:38, 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... > 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 > hypercalls). 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 > Jan >