From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel De Graaf Subject: Re: [PATCH v6 1/2] xen/pvh: use a custom IO bitmap for PVH hardware domains Date: Fri, 15 May 2015 16:09:40 -0400 Message-ID: <55565284.4070606@tycho.nsa.gov> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YtLvq-0003uz-A2 for xen-devel@lists.xenproject.org; Fri, 15 May 2015 20:10:06 +0000 In-Reply-To: <5555BF74020000780007A697@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 , =?windows-1252?Q?Roger_Pau_Monn=E9?= Cc: Kevin Tian , SuraveeSuthikulpanit , Andrew Cooper , Eddie Dong , Aravind Gopalakrishnan , Jun Nakajima , xen-devel@lists.xenproject.org, Boris Ostrovsky List-Id: xen-devel@lists.xenproject.org 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. -- Daniel De Graaf National Security Agency