From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH v14 00/20] Introduce PVH domU support Date: Fri, 8 Nov 2013 17:06:26 +0000 Message-ID: <527D1A12.6090702@eu.citrix.com> References: <1383567306-6636-1-git-send-email-george.dunlap@eu.citrix.com> <20131104165905.GA6979@phenom.dumpdata.com> <5277D7FB.30208@eu.citrix.com> <20131104173452.GB45309@deinos.phlegethon.org> <527D0623.4000504@eu.citrix.com> <527D08F4.8030609@eu.citrix.com> <20131108170126.GE12621@deinos.phlegethon.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20131108170126.GE12621@deinos.phlegethon.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tim Deegan Cc: Keir Fraser , Ian Campbell , Jan Beulich , xen-devel@lists.xen.org, Ian Jackson List-Id: xen-devel@lists.xenproject.org On 08/11/13 17:01, Tim Deegan wrote: > At 15:53 +0000 on 08 Nov (1383922404), George Dunlap wrote: >> On 08/11/13 15:41, George Dunlap wrote: >>> On 04/11/13 17:34, Tim Deegan wrote: >>>> At 17:23 +0000 on 04 Nov (1383582187), George Dunlap wrote: >>>>> On 04/11/13 16:59, Konrad Rzeszutek Wilk wrote: >>>>>>> This also means no support for "legacy" forced invalid ops -- only >>>>>>> native >>>>>>> cpuid is supported in this series. >>>>>> OK. >>>>> (FWIW, support for legacy forced invalid ops was requested by Tim.) >>>> I was worried about existing PV kernel code that used the fake-CPUID, >>>> which would break if the 'core' kernel code went from PV to PVH. But >>>> I guess I could be convinced that such kernel code is buggy? Really, >>>> the high-order bit was consistency. The version I commented on >>>> supported them for user-space but not for kernel, which seemed like >>>> risking trouble for no benefit. >>> Oh right -- I think Mukesh we do need to support forced invalid ops >>> for user space so that we can use the same xen tools binaries on PV >>> and PVH kernels. >>> >>> Hmm, Mukesh / Konrad, what tools are you actually thinking about >>> here? Are these Oracle-specific tools? I can't seem to find >>> XEN_CPUID or XEN_EMULATE_PREFIX anywhere in the tools/ directory of >>> the xen repo... >> It's misc/xen-detect.c, for the curious (which helpfully does not use >> the macros above). >> >> Handling forced invalid ops it is, then. > The xen-detect code tries real CPUID first, so not supporting the fake > CPUID doesn't actually affect it at all. That's why I could be > convinced that detection failures were a guest-side bug. > > It would affect older code that _only_ tired the fake CPUID, or code > that for some reason needed to behave differently on PV vs HVM (though > it's not at all clear that on PVH such code should use the 'PV' > behaviour. Yes, taking a closer look, xen-detect in a PVH domain will behave the same as in an HVM domain: # ./xen-detect Running in HVM context on Xen v4.4. I don't think this is a big deal; to be robust your system should be able to operate properly in an HVM (or PVHVM) domU. I'll leave this out for now, but I'll put a note in the cover letter and in the doc file so we don't forget about it. -George