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

Re: [PATCH v2 9/9] xue: allow driving the rest of XHCI by a domain while Xen uses DbC


  • To: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 18 Jul 2022 17:07:30 +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=Cm6ZZa/2Qcsr1jyZkJxTATwz0x7fHthxNCI/xgs+aRQ=; b=anAALyRXXYOTBYx86eSWxfwV3wh45icw6PNTjm4qSE1PNZCePG9nsZ84NymHz+oc5SpqiUlTrjd/HaLLusnNR4ITz84MkzYlPEaTb+G0cuCNz4WQWf1L+uZAplzUe0NYe4GxOUOyibi9sQv3R6E3hBLzCgO1q/Ohkcdn+9ACSEjudC7Z5H8r4SzBKm8AfyjPlBVbbrvep2S/Ad7xGC77HIq3GF8TRcHNNnq8Cd29icoN5wq4Q0qg/EtCx6H5bGV+Ro7pNT7tdp1Iz8Oc1HPAE1VnQQwp41aQ++1mc87tdAmzgCjEBRQoknpGydOAOjxhdKLkVEi4WXKvBRq+qitrCg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VUNYLuKVtvPAx2NY3HT7yAKY5y29cooOgoOr5y6Wk/bCHzVEpubaOKcYYVf8djSMhqDX858H38hYNrSdc0PJyWPAIFIRiK842mDkSUFw3NDpK8oriJULsWxopjTVzdpGFlfCJQtaS7zdAPq5iH2AOmeOpAijPMgELoyymPrGWdBsHzezWJ+4mFZUSE1dB5hkvJljE00/3fJorhQCWuIcJG5yU9srR7YaHHY8NktYfTsSjw6jVLxEyIBhakQ6CJ34SxVQlx0Hy2tqbNbsPXV6LKpEEzPSVIVMzsYII9Eii6F8dGhAqJs9rHlM9Pt4mo/NQxxoWQ0M1cJ3eII0OQqcxw==
  • 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>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 18 Jul 2022 15:07:51 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 18.07.2022 14:54, Marek Marczykowski-Górecki wrote:
> On Thu, Jul 14, 2022 at 02:06:07PM +0200, Jan Beulich wrote:
>> On 06.07.2022 17:32, Marek Marczykowski-Górecki wrote:
>>> That's possible, because the capability was designed specifically to
>>> allow separate driver handle it, in parallel to unmodified xhci driver
>>> (separate set of registers, pretending the port is "disconnected" for
>>> the main xhci driver etc). It works with Linux dom0, although requires
>>> an awful hack - re-enabling bus mastering behind dom0's backs.
>>> Linux driver does similar thing - see
>>> drivers/usb/early/xhci-dbc.c:xdbc_handle_events().
>>
>> Isn't there a risk that intermediately data was lost?
> 
> Yes, there is such risk (although minimal in practice - it happens just
> once during dom0 boot). You can avoid it by instructing dom0 to not use
> that USB controller.
> Having this capability is really helpful (compared with the alternative
> of using the whole USB controller by either Xen or Linux), as many
> (most) systems have only a single USB controller.

No question about the usefulness. But this aspect wants spelling out,
and it is one of the arguments against allowing use of the device by
other than hwdom.

>>> To avoid Linux messing with the DbC, mark this MMIO area as read-only.
>>
>> In principle this would want to happen quite a bit earlier in the
>> series. I'm okay with it being kept here as long as it is made
>> very obvious to and easily noticeable by committers that this series
>> should only be committed all in one go.
>>
>> Also along with this is where I'd see the pci_hide_device() go.
> 
> Earlier version of the patch set had pci_ro_device() before this patch.
> I can add pci_ro_device() in the initial patch, and drop it in this one.

Having pci_ro_device() up to here sounds reasonable, but then you still
want to flip to using pci_hide_device() rather than just dropping the
call.

Jan



 


Rackspace

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