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

Re: [PATCH 1/4] x86/PVH: de-duplicate mappings for first Mb of Dom0 memory


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 31 Aug 2021 15:19:54 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • 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-SenderADCheck; bh=tUpDt3mfBHYyFfaBCdlU8s+kZ/hw79jnuiPV/6S+4w8=; b=OJelU9t0TanIfonVQ7oZkp0I9ElfTuz019ZbsNLKkfF/yr3wOVCwHIGdF5rBmoMMZd+G59T1gXb984lxeKkTKu7/C69/+LsZkH9LcLaSIqObXzFHorRAsbLYx5VQsiyrxJqhyK3eXTctsmNS/VP4rc1mbrTr8ljxQxgiW87aDFUH6baFM4LWJmb9p50jmsLCLlIWxJzqTZ9s80IIDmANpj/L/mnz13J+jK8iYatXX1iIWG0jqRZN+TCX9Eg59HZc/ddA9VbVAkbkD1aQQtO0fhLnJjukGKI4Q/FHD5oDbxt+kaZCSFxgqlsdXX6jBblRjhiGugFWP7SgqCoKKz7qkw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QiFYqZKtNbDEWhsbZLzbyzGreY6+tAWamaqytBa+VdKvs9Y6Su+jr2DAb9MP74oANP73CHTbX0jvYJzHWZGHZ4H+cocgnWb11YdxZGwnTnXVHj9iFaE6JqfHBipqA8MuLTrbF1W2KUt9xGC19qLNiuODqB9rrSjWGWprT7imIp98aKYabBeigG6xuvKIA4U5pqfn7g7YlmeGNjlqq9YwEDFQijvNY1Q+k5ZG1DFM4OVHDM5TnJ9pJSg+4823tkKRwoM4jCTq4rPGpv3IvDE7c8tsFHCxJB4Et2GhliPac3QoicgTy2m3Sg09iQY73Aiqskn/Mdr/rng7pynYQjbXsg==
  • Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
  • Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 31 Aug 2021 13:20:07 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 31.08.2021 15:14, Jan Beulich wrote:
> On 31.08.2021 15:02, Andrew Cooper wrote:
>> On 30/08/2021 14:02, Jan Beulich wrote:
>>> One of the changes comprising the fixes for XSA-378 disallows replacing
>>> MMIO mappings by unintended (for this purpose) code paths.
>>
>> I'd drop the brackets.  All it does is confuse the sentence.
>>
>>>  This means we
>>> need to be more careful about the mappings put in place in this range -
>>> mappings should be created exactly once:
>>> - iommu_hwdom_init() comes first; it should avoid the first Mb,
>>> - pvh_populate_p2m() should insert identity mappings only into ranges
>>>   not populated as RAM,
>>> - pvh_setup_acpi() should again avoid the first Mb, which was already
>>>   dealt with at that point.
>>
>> This really is a mess.  It also seems very fragile.
> 
> So it seems to me.
> 
>> Why is iommu_hwdom_init() separate in the first place?  It only does
>> mappings up to 4G in the first place, and with this change, it is now
>> [1M-4G)
> 
> I guess we'll want to wait for Roger to return to shed some light on
> this.
> 
>>> @@ -1095,6 +1101,17 @@ static int __init pvh_setup_acpi(struct
>>>          nr_pages = PFN_UP((d->arch.e820[i].addr & ~PAGE_MASK) +
>>>                            d->arch.e820[i].size);
>>>  
>>> +        /* Memory below 1MB has been dealt with by pvh_populate_p2m(). */
>>> +        if ( pfn < PFN_DOWN(MB(1)) )
>>> +        {
>>> +            if ( pfn + nr_pages <= PFN_DOWN(MB(1)) )
>>> +                continue;
>>> +
>>> +            /* This shouldn't happen, but is easy to deal with. */
>>
>> I'm not sure this comment is helpful.
>>
>> Under PVH, there is nothing special about the 1M boundary, and we can
>> reasonably have something else here or crossing the boundary.
> 
> As long as we have this special treatment of the low Mb, the boundary
> is meaningful imo. I'd see the comment go away when the handling in
> general gets streamlined.

I should have added: And as long as Dom0's E820 map gets cloned from
the host's, which will necessarily consider the 1Mb boundary special.

Jan




 


Rackspace

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