From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don Slutz Subject: Re: [PATCH v3 04/16] hypervisor part of add vmware_port to xl.cfg Date: Mon, 08 Sep 2014 13:56:46 -0400 Message-ID: <540DEDDE.8060704@terremark.com> References: <1410182158-8542-1-git-send-email-dslutz@verizon.com> <1410182158-8542-5-git-send-email-dslutz@verizon.com> <540DC4B6.1000707@oracle.com> <540DE5D3020000780003222A@mail.emea.novell.com> <540DCBF2.40209@citrix.com> <540DCE93.40303@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <540DCE93.40303@oracle.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: Boris Ostrovsky , Andrew Cooper , Jan Beulich , xen-devel@lists.xen.org, Don Slutz Cc: Kevin Tian , Keir Fraser , Ian Campbell , Stefano Stabellini , Jun Nakajima , Eddie Dong , Ian Jackson , Tim Deegan , Aravind Gopalakrishnan , Suravee Suthikulpanit List-Id: xen-devel@lists.xenproject.org On 09/08/14 11:43, Boris Ostrovsky wrote: > On 09/08/2014 11:32 AM, Andrew Cooper wrote: >> On 08/09/14 16:22, Jan Beulich wrote: >>>>>> On 08.09.14 at 17:01, wrote: >>>> I wonder whether we should enable #GP intercepts only when we know >>>> that >>>> the guest is VMware-aware (which we do as far as I can tell since we >>>> have a config option). >>> I didn't look at the patches themselves yes, but I very much expected >>> this to now be the case considering discussion on the earlier version. >>> If it's not, I'm not even sure looking at the new version is going >>> to be >>> of much use... >>> Getting the adjustment of #GP exits at the time of setting of hvm param vmware_port to 1 is more complex. But I do think that the allowing it to be deferred until the next #VMEXIT would work just fine. I will see how well that works. >>> Jan >>> >> I find it incredibly hard to believe that VMWare do unconditional #GP >> exits, and looking at the Intel manual, you do not actually need to >> intercept #GP faults. >> >> The "unconditional I/O exiting" control can be used to cherry-pick >> specific IO ports in combination with the IO port bitmap, ahead of the >> #GP fault due to a failure of IOPL. I would expect AMD has a similar >> option. > > Yes, it does. However, I believe #GP intercept has been added so that > IO access can be made from guest's ring 3 as well, not to handle IO > access in general. > > Having said that, I don't remember seeing updates to IO permissions > map in the patch. > There are no updates to IO permissions map. My understanding that it controls access to real hardware, not that it changes the IOPL checking in the in instruction. Here is what I am looking at: This control determines whether executions of I/O instructions (IN, INS/INSB/INSW/INSD, OUT, and OUTS/OUTSB/OUTSW/OUTSD) cause VM exits. Which to me is about #VMEXIT or access host hardware, not "Change a #GP into a #VMEXIT for this port." The goal is to get #VMEXITs when needed, not to allow domU to access a VMware running Xen under it. For the non-#GP case (domU ring 0 access to the port), it is handled by register_portio_handler() which would adjust the IO permissions map as needed. -Don Slutz > -boris >