[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH RFC] xen/pci: detect when BARs overlap RAM
- To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Mon, 31 Jan 2022 11:01:30 +0100
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=EXdwXSTK37o3t9RKP4LKEQYzWlW/a22pCeDE/p+Za5Q=; b=mZQDjGcd4GUwDHQthep2WXuQjHmt0mCZzthJpgd/onOaCVBKPkMXgn+khSfzis3LcLqNM40HHGOKuzjLj9235fjSkbkTdM/D2WDS0QAl07e6ubZuz1QCVAR+OGYvxLOjKnMXjXd/y6w0Xx40eEf4H5D4iOOi2nsuEI5NL/6KozsAyf/HrfGKc924rFz/IflYFTSXbNqecMPZI75yBH0s+2r37vk5gDm1W55lIfWpVST9W86t+LRQ2LpZ1Aa2PU+A3NtyS3W/59chjEdTXOTPVcssF/iMQZyTIBRCQt4bhoc7cW8qR/rLelJT0ks5bMZ6PWZ7l0oqyGQCPvsNrr2/cQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CRv94LwMO5sLT2Vp3BeQLZsH1Wbm5k/n7ixF4FXlJcBTvclQ7iyURYdX+PkgMJTNiBmMc/khX0PAGWrvacCakAIZNdu+MSbvjPRq4+jD6L+qdHfXXCfSdD+1jLUZyB7C/8gaoMOFKf/AL2y3EuP7usXm05/X3XFGOfDSqAk5R1cOhmgSzO5dYr9uW67egf7OaoQUjQeGs/VA0l/MoBPIYhvFd5He0kmNlG9jQ4O1a3rRdvzkiFoFf+8E3rJ4nncvBj+OY2aEcvPWaibTmN6sEnGwvEUrwovUAl+LlHxJbQDzseyT2zgxS8FPwv6b7f6Ac/LjzdgBPVn4WV3NfGS/UA==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Paul Durrant <paul@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Mon, 31 Jan 2022 10:02:05 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 31.01.2022 10:57, Roger Pau Monné wrote:
> On Fri, Jan 28, 2022 at 07:48:44AM +0100, Jan Beulich wrote:
>> On 26.01.2022 16:45, Roger Pau Monné wrote:
>>> On Wed, Jan 26, 2022 at 03:08:28PM +0100, Jan Beulich wrote:
>>>> On 26.01.2022 13:26, Roger Pau Monne wrote:
>>>>> --- a/xen/arch/x86/mm.c
>>>>> +++ b/xen/arch/x86/mm.c
>>>>> @@ -479,6 +479,26 @@ unsigned int page_get_ram_type(mfn_t mfn)
>>>>> return type ?: RAM_TYPE_UNKNOWN;
>>>>> }
>>>>>
>>>>> +bool is_iomem_range(uint64_t start, uint64_t size)
>>>>
>>>> Might be nice to have this sit next it is_iomem_page(). And wouldn't
>>>> at least "start" better be paddr_t?
>>>
>>> (paddr_t, size_t) would be better, but AFAICT size_t can be an
>>> unsigned long and on Arm32 that won't be suitable for holding a 64bit
>>> BAR size.
>>
>> Talking of representing the range - a BAR occupying one part of a
>> page overlapping an E820 entry covering another part of that same
>> page is going to be equally bad, I think. The range may therefore
>> want expressing in page granularity. This may then be easier as
>> [start,end], at least on the calling side (can use PFN_DOWN()
>> twice then).
>
> Yes, indeed, would likely be better. Then I can make both parameters
> unsigned long.
>
> I also think is_memory_hole would be a suitable name given the new
> implementation?
I'd be fine with this name, fwiw.
Jan
|
