[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [PATCH v2] xen/arm: p2m: Populate pages for GICv2 mapping in arch_domain_create()


  • To: Julien Grall <julien@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Henry Wang <Henry.Wang@xxxxxxx>
  • Date: Sat, 15 Oct 2022 13:14:44 +0000
  • Accept-language: zh-CN, en-US
  • Arc-authentication-results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com])
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=l7XP1jibOmnC8B6gmAGNYfyQ+uFUyvyw7XPGM2uHVS8=; b=Qap7oucwy//SlzzjdVKFUU1V6OdlUZpqeMy7HSsd1b2tDBGOujSkk7J8obSs2o/rc/T0k0mIrsoakk0uxLTigyyHCuhm+wiqstXm8PMGrujm5Ue5HASGt/kkHgGgHz7+4y0cvkUXl2pskdcr5ADCLrGHKX1xDnX4ooQkkhkyRh7rEw72J8czev7X1mJMShu4n+kbPJfaM++fTMt8JoLnKSDs/Y6KthQUHeM8CLTC+3p5l/jYABdS8x+Ytdx85oTdbkm5/PpvJlDJMUwgcDG1ur9JqHhWwg8IUKuMUbmrKUaH5eEcIllmzQzUKqsBzid8zgeM7OtnEa1lDnXLwSM5qw==
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=l7XP1jibOmnC8B6gmAGNYfyQ+uFUyvyw7XPGM2uHVS8=; b=gSsD52Xm1ZJ8FBVtybV7pebVfJoIHsiw68U7Hmc4Qo34XVzS25Zr0y1Qn7ELueb7PuprMHmXINQT6cadRqYvWQz3VJN3TXCm2GQjnVDpCFrKbNmqWgeBQ1A3MnsMlb0I9jgD6wgidAjTDNYRJn/Fg+JJOS0dV9T5ODtxiTtA+9ijtn9SPlYpA6CSs/KQPVg/5mqT1ksRC9AYvc/j1HSTnWBP8atnOM8JyrAprBZph7wGxOL+U+MVqeigGUkFVYcDJMicVJ/vaTPblx+l2H4LqkRoBRq2FuhBk1h/ZTW4VKYXJ9OlAHFgIUGaoYrhJra1fcpRpnGmvHezfDoIR8lFeA==
  • Arc-seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=BzyDuTdNRoSHLffTEzqb6KVzzHvngJwjj2JMBENGN79ENuVG+ejhHI8Oh0kQzbzQ8agZqh+eJMNrZtumpRZRMmmvAeuGS83AXfK822jF1RWSiC8CbOh5NwuZBOi8eBe66lShIeXymacjQhHlZo37cRm1ESn2Qymd6hyvI9QpsQtO20SA9s/Mr2Jhw8YiImM0HEDZWiNpk7KdvVMvqgf10/ftxgoEgn8IxhkqB3LTycuwwCvFxjFblACf6AJymRfCSVWx0wA8To4SgBqRWQOXpW0CYxsEGBVSYoxDYZnzN/Kuyd3E24WrcDBFoS9akERW7vWaK3MijU3mGRxU3+Gm+w==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Bt6suVxt8G5cbDOE3qXshTkDuk6mZCfM+uokwC9WA57K0Z0cCiUmWRLJsCRvV/4n8hlTRiTCXaTRAewTfHYrSBzrkErd7Tyj19vukQOHTlNt7uIuoMpdPqwawYKEsPuq82JlQ8jOHSGHQd8DbrQpnXdL7m3IWG4QBwVbNJGiUbtSb0/x4DC1keyZnbf1O2uvKpN8EMW6SiP2m6PbDfsRcNVxesZgUODbKcomY6R3/cl8CiB+CMyi48bsfI8NEcEtCbZF+7xr3oz+rqghYlTIDuxa2SmkCiyQooPT1P4BihGJOGtgzZdulU5i2qmuunaeBPOwNq8SA0oGw4GESo7Hrg==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Wei Chen <Wei.Chen@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Delivery-date: Sat, 15 Oct 2022 13:15:19 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHY36RSrOIThkYtnEq9RrtWc+uYX64NsO2AgAACdYCAAZeJAIAAAyvQ
  • Thread-topic: [PATCH v2] xen/arm: p2m: Populate pages for GICv2 mapping in arch_domain_create()

Hi Julien,

Thanks for reply and sharing your opinions!

> -----Original Message-----
> From: Julien Grall <julien@xxxxxxx>
> Subject: Re: [PATCH v2] xen/arm: p2m: Populate pages for GICv2 mapping in
> arch_domain_create()
> On 14/10/2022 12:19, Henry Wang wrote:
> > Hi Julien,
> 
> Hi Henry,
> 
> >> -----Original Message-----
> >> From: Julien Grall <julien@xxxxxxx>
> >>>        struct p2m_domain *p2m = p2m_get_hostp2m(d);
> >>>        unsigned long count = 0;
> >>> @@ -1716,7 +1716,7 @@ int p2m_teardown(struct domain *d)
> >>>            p2m_free_page(p2m->domain, pg);
> >>>            count++;
> >>>            /* Arbitrarily preempt every 512 iterations */
> >>> -        if ( !(count % 512) && hypercall_preempt_check() )
> >>> +        if ( allow_preemption && !(count % 512) &&
> >> hypercall_preempt_check() )
> >>>            {
> >>>                rc = -ERESTART;
> >>>                break;
> >>> @@ -1736,6 +1736,17 @@ void p2m_final_teardown(struct domain *d)
> >>>        if ( !p2m->domain )
> >>>            return;
> >>>
> >>> +    if ( !page_list_empty(&p2m->pages) )
> >>
> >> Did you add this check to avoid the clean & invalidate if the list is 
> >> empty?
> >
> > Yep. I think we only need the p2m_teardown() if we actually have
> something
> > in p2m->pages list.
> 
> How about adding the check in p2m_teardown()? So it will be easier to
> remember that the check can be dropped if we move the zeroing outside of
> the function.

Yes, I will turn above if check to a

if ( page_list_empty(&p2m->pages) )
    return 0;

in the beginning of the p2m_teardown(), and do the clean & invalidate
follow-up after the release.

> 
> >
> >>
> >>> +        p2m_teardown(d, false);
> >>
> >> Today, it should be fine to ignore p2m_teardown(). But I would prefer if
> >> we add an ASSERT()/BUG_ON() (or else) to make confirm this is the case.
> >
> > Sorry I do not really understand why we can ignore the p2m_teardown()
> > probably because of my English.
> 
> No, I forgot a word in my sentence. I was meant to say that the return
> of p2m_teardown() can be ignored in our situation because it only return
> 0 or -ERESTART. The latter cannnot happen when the preemption is not
> enabled.
> 
> But I would like to add some code (either ASSERT() or BUG_ON()) to
> confirm that p2m_teardown() will always return 0.

I added the doc asked in your previous email. Also, I will use a

ASSERT(p2m_teardown(d, false) == 0);

in p2m_final_teardown() here.

> 
> > Let's talk a bit more in C if you don't mind :))
> > Do you mean p2m_teardown() should be called here unconditionally
> without
> > the if ( !page_list_empty(&p2m->pages) ) check?
> 
> See above.

Thanks.

> 
> >
> >>
> >> This also wants to be documented on top of p2m_teardown() as it would
> be
> >> easier to know that the function should always return 0 when
> >> !allow_preemption is not set.
> >
> > Ok, will do.
> >
> >>
> >> I also noticed that relinquish_p2m_mapping() is not called. This should
> >> be fine for us because arch_domain_create() should never create a
> >> mapping that requires p2m_put_l3_page() to be called.
> >>
> >> I think it would be good to check it in __p2m_set_entry(). So we don't
> >> end up to add such mappings by mistake.
> >
> > I thought for a while but failed to translate the above requirements
> > to proper if conditions in __p2m_set_entry()...
> 
> For checking the mapping, we can do:
> 
> if ( !removing_mapping && (p2m_is_foreign(t) || (p2m_is_ram(t) &&
> is_xenheap_mfn(mfn) )
>      return -EINVAL;

Thanks for this, I guess without your hint it will take ages for me to
think of this.... 

> 
> We also need a way to check whether we are called from
> arch_domain_create(). I think we would need a field in the domain
> structure to indicate whether it is still initializating.
> 
> This is a bit ugly though. Any other suggestions?

My first thought is checking the implementation of domain_create()
and arch_domain_create() (as both will call arch_domain_destroy()
when fail) to see if there are some fields in struct domain or
struct arch_domain that are set/changed in this stage so probably we
can reuse. Otherwise I think adding a new field sounds a good idea.

> 
> >
> >>
> >> I would have suggested to add a comment only for version and send a
> >> follow-up patch. But I don't exactly know where to put it.
> >
> > ...how about p2m_final_teardown(), we can use a TODO to explain why
> > we don't need to call relinquish_p2m_mapping() and a following patch
> > can fix this?
> 
> To me the TODO would make more sense on top of p2m_set_entry()
> because
> this is where the issue should be fixed. This is also where most of the
> reader will likely look if they want to understand how p2m_set_entry()
> can be used.

Good idea, thanks for the suggestion!

> 
> We could also have a comment in p2m_final_teardown() stating that the
> relinquish function is not called because the P2M should not contain any
> mapping that requires specific operation when removed. This could point
> to the comment in p2m_set_entry().

Yes, my current wording for this would be:
+    /*
+     * No need to call relinquish_p2m_mapping() here because
+     * p2m_final_teardown() is called either after 
domain_relinquish_resources()
+     * where relinquish_p2m_mapping() has been called, or from failure path of
+     * domain_create()/arch_domain_create() where mappings that require
+     * p2m_put_l3_page() should never be created.
+     */

I will add the words pointing to p2m_set_entry().

Kind regards,
Henry


> 
> Cheers,
> 
> --
> Julien Grall

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.