From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH v6 1/2] xen/pvh: use a custom IO bitmap for PVH hardware domains Date: Mon, 18 May 2015 08:12:07 +0100 Message-ID: <5559ACE7020000780007AE7E@mail.emea.novell.com> References: <1431356258-31269-1-git-send-email-roger.pau@citrix.com> <1431356258-31269-2-git-send-email-roger.pau@citrix.com> <55533B220200007800079F0A@mail.emea.novell.com> <5554BEFA.1020500@citrix.com> <5555AFFD020000780007A5E1@mail.emea.novell.com> <5555A168.9050108@citrix.com> <5555BF74020000780007A697@mail.emea.novell.com> <55565284.4070606@tycho.nsa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YuFDh-0002LL-1T for xen-devel@lists.xenproject.org; Mon, 18 May 2015 07:12:13 +0000 In-Reply-To: <55565284.4070606@tycho.nsa.gov> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Daniel De Graaf Cc: Kevin Tian , SuraveeSuthikulpanit , Andrew Cooper , Eddie Dong , Aravind Gopalakrishnan , Jun Nakajima , xen-devel@lists.xenproject.org, Boris Ostrovsky , roger.pau@citrix.com List-Id: xen-devel@lists.xenproject.org >>> On 15.05.15 at 22:09, wrote: > On 05/15/2015 03:42 AM, Jan Beulich wrote: >>>>> On 15.05.15 at 09:34, wrote: >>> El 15/05/15 a les 8.36, Jan Beulich ha escrit: >>>>>>> On 14.05.15 at 17:27, wrote: >>>>> El 13/05/15 a les 11.53, Jan Beulich ha escrit: >>>>>>>>> On 11.05.15 at 16:57, wrote: >>>>>>> --- a/xen/common/domain.c >>>>>>> +++ b/xen/common/domain.c >>>>>>> @@ -42,6 +42,7 @@ >>>>>>> #include >>>>>>> #include >>>>>>> #include >>>>>>> +#include >>>>>>> >>>>>>> /* Linux config option: propageted to domain0 */ >>>>>>> /* xen_processor_pmbits: xen control Cx, Px, ... */ >>>>>>> @@ -219,6 +220,7 @@ static int late_hwdom_init(struct domain *d) >>>>>>> rangeset_swap(d->iomem_caps, dom0->iomem_caps); >>>>>>> #ifdef CONFIG_X86 >>>>>>> rangeset_swap(d->arch.ioport_caps, dom0->arch.ioport_caps); >>>>>>> + setup_io_bitmap(d); >>>>>>> #endif >>>>>> >>>>>> Considering that rangesets are getting swapped rather than >>>>>> copied, I think you also need to reset Dom0's I/O bitmap here >>>>>> to the ordinary, non-hardware domain one. >>>>> >>>>> Yes. Would it be fine to memset it and just call setup_io_bitmap on it >>>>> again, or would you prefer to exchange it with the static one and free it? >>>> >>>> Following how the rangesets are being treated, simply swapping >>>> the two I/O bitmaps would seem to be the right approach here. >>> >>> AFAICT this requires adding a new hook in hvm_function_table in order to >>> implement setting the io bitmap for SVM and VMX. I don't have a problem >>> with that, but it's going to need a separate patch. >> >> Right - if there is nothing like that currently, it'll need to be added. >> Of course you may want to get Daniel de Graaf's (who originally >> added this non-Dom0 hardware domain code, now Cc-ed) input on >> the above outline approach before going that route... > > Currently, the only user of this code that I know of is a domain builder > which is a PV stub domain, which may impact a trivial swapping operation > because dom0->arch.hvm_domain will not be valid. The primary reason why > the rangeset_swap calls are not rangeset_dup is because this stub domain > does not need access to the hardware after the creation of the hardware > domain. > > I think it seems cleaner for the IO bitmap of domain 0 to also be cleared > after the hardware domain is created, but it's not really a requirement to > make things work. Hmm - I think the rangeset handling and the I/O bitmap handling ought to be in sync (even if only to avoid future confusion/questions). And yes, considering the case of one of the two being PV and the other PVH is going to be necessary (even if right now only a PV stub domain builder may exist). Jan