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

Re: [PATCH v3 01/10] drivers/char: Add support for USB3 DbC debugger


  • To: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 5 Aug 2022 08:14:56 +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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=bGH1TWAhCev18qr25KY0QCoCiXKkcHEAoVKC2XCVGQo=; b=eLyOnbLP6lXyXKU3t9bBdaPUaBtwL7ytsR/1uze4tmKFyz/ZGhUeBAWcJJu4fCjSoVbZ+fkf+HuTarZpx0/e3E6t45njqfdn293tA+5E79uYO5uFJycXHaYWFVEov1RYk/2ZclSVEA28dFoA9mzRDuRallnOwri5fShA6LLNdFddHfO7X2BI6f87hfQFL0QLGTrqogMM6n9/96tIbVud3/VMwfK8cdXBCyw5+O4VUyP6IM7VBlmT//wOkmMEscLDWyICeYbJk2jguVHIlSvQ3NYamd+Jc1ujb3Mcctvj/9FKrh3vaLY4eu7HDsoYQ0jlc0Y33VHqRgUUdC6yKwLbgQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iREtbcRzU1AonluszoaraA7NqE6J1XtTCtxcUE+X19pwVmgvEIbaTs/yad68QOaZyBqskIKJ454YaEIsBN8YJGwok0GqzH3TgDRAncbY765dwo6nUueCAmMakV4ClekFUzZVvt9ozS3o5mnc0f/g15Fsn19uUqSdbODyc2p7+5FI035YjDZNORAefa0R4yAiMa3Lp+0OFQDRCjvTYloRv4jSMa7d3hkICvqlUsQWc5zw4pzSG/QFnQcHyEygMq6OqnPtJ2uryAklZQfTM42iyrpr9RogROxM6PkgYGKp8syU2BanqMOJmkrIs3RctZ4G7GzIdqlNX4b5qJX2W2KWgg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 05 Aug 2022 06:15:13 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 04.08.2022 16:34, Jan Beulich wrote:
> On 04.08.2022 16:21, Jan Beulich wrote:
>> On 04.08.2022 15:43, Marek Marczykowski-Górecki wrote:
>>> On Thu, Aug 04, 2022 at 02:57:49PM +0200, Jan Beulich wrote:
>>>> On 26.07.2022 05:23, Marek Marczykowski-Górecki wrote:
>>>>> +struct dbc {
>>>>> +    struct dbc_reg __iomem *dbc_reg;
>>>>> +    struct xhci_dbc_ctx *dbc_ctx;
>>>>> +    struct xhci_erst_segment *dbc_erst;
>>>>> +    struct xhci_trb_ring dbc_ering;
>>>>> +    struct xhci_trb_ring dbc_oring;
>>>>> +    struct xhci_trb_ring dbc_iring;
>>>>> +    struct dbc_work_ring dbc_owork;
>>>>> +    struct xhci_string_descriptor *dbc_str;
>>>>
>>>> I'm afraid I still don't see why the static page this field is being
>>>> initialized with is necessary. Can't you have a static variable (of
>>>> some struct type) all pre-filled at build time, which you then apply
>>>> virt_to_maddr() to in order to fill the respective dbc_ctx fields?
>>>
>>> I need to keep this structure somewhere DMA-reachable for the device (as
>>> in - included in appropriate IOMMU context). Patch 8/10 is doing it. And
>>> also, patch 8/10 is putting it together with other DMA-reachable
>>> structures (not a separate page on its own). If I'd make it a separate
>>> static variable (not part of that later struct), I'd need to reserve the
>>> whole page for it - to guarantee no unrelated data lives on the same
>>> (DMA-reachable) page.
>>>
>>> As for statically initializing it, if would require the whole
>>> (multi-page DMA-reachable) thing living in .data, not .bss, so a bigger
>>> binary (not a huge concern due to compression, but still). But more
>>> importantly, I don't know how to do it in a readable way, and you have
>>> complained about readability of initializer of this structure in v2.
>>>
>>>> That struct will be quite a bit less than a page's worth in size.
>>>
>>> See above - it cannot share page with unrelated Xen data.
>>
>> I have to admit that I'd see no issue if these lived side by side with
>> e.g. other string literals. The more that the device is supposed to be
>> exposed to Dom0 only anyway, and hence that'll be the only domain able
>> to get at that data.
> 
> Actually: With your plan to expose the device to a DomU, how is that
> going to work without tool stack adjustments? Wouldn't you need to
> prevent in particular HVM/PVH guests from using the GFNs corresponding
> to the MFNs where this Xen data is? The minimal requirement then would
> seem to be an E820 reserved range for the area.

I guess this was rubbish - by mimic-ing RMRRs or their AMD equivalents,
the tool stack ought to be taking care of this already.

Jan



 


Rackspace

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