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

Re: [PATCH] vpci/header: cope with devices not having vpci allocated


  • To: Roger Pau Monne <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 25 May 2023 11:05:52 +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=GrUiGt6mj0LVWBMgUBMQiyi6/Kq8PjlXSx1Wp5gIW9M=; b=MMWzlJXZou04Uj1e+ijxjSzOYCIhXJZ7L8S+M0YziPn3DP504O2VuMtTvEP6xWRKuRScidnQqEM8Q8YAJ5N9To13y4V3g5QEl+wjQlPqBuijaQ7DlZJrzoZThnV5aUTwIJfOg8gI2zB/FkYEuyAGy1mWPz3OqwSFjJ71BAXEsbGStPXV7Y/YFV1tQemIlsYxUJobH5AL4RjT5tlsngMJ3LFnyXBBQpPakPd/duYvFSSprvysvQqQteWon7/MS10HSAgI+L6Jc3QRv/dWKba3kVbQY+rW+DYAvN9Yqw1gpgVHQVhjf7iKP1p3gQ6pGV6k4Ca8DrVOjBsgUuPAuvgNuQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IA4CIa+Vc+QrdzQT9pqPdopfTlREjYq5ml8y9KfgJj7fDOUzMHyKPu8jlmNY34JIqQ1qpbV/Uq/SvtgLLnnC32uMOE0eg2bqwtyN/hwCwkQtL5AFEF+qREQbjE4lHi6CdsmgLnYXxX/uW7qkSZUTpxq7P9U5XstXN7MwPn4HGopORLgS4UjZDDorTPsVnqGlDDkXshB3kX6fnJAY/ZcvvWpcKRwiuZl0CoGuc2LJUtHSoQRmFLkhkBd8EgksCrnOnI3iC23JZwIPX5IakLyyJgaXu9ZZJC7cDk3wg1Eij8MZtZrNtqib6FWC7TgT3nBM7vtYmLOToJZKHCfudQqkdA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 25 May 2023 09:06:06 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 25.05.2023 10:30, Roger Pau Monne wrote:
> When traversing the list of pci devices assigned to a domain cope with
> some of them not having the vpci struct allocated. It's possible for
> the hardware domain to have read-only devices assigned that are not
> handled by vPCI, or for unprivileged domains to have some devices
> handled by an emulator different than vPCI.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> ---
>  xen/drivers/vpci/header.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
> index ec2e978a4e6b..3c1fcfb208cf 100644
> --- a/xen/drivers/vpci/header.c
> +++ b/xen/drivers/vpci/header.c
> @@ -289,6 +289,20 @@ static int modify_bars(const struct pci_dev *pdev, 
> uint16_t cmd, bool rom_only)
>       */
>      for_each_pdev ( pdev->domain, tmp )
>      {
> +        if ( !tmp->vpci )
> +            /*
> +             * For the hardware domain it's possible to have devices assigned
> +             * to it that are not handled by vPCI, either because those are
> +             * read-only devices, or because vPCI setup has failed.

So this really is a forward looking comment, becoming true only (aiui)
when my patch also makes it in.

> +             * For unprivileged domains we should aim for passthrough devices
> +             * to be capable of being handled by different emulators, and 
> hence
> +             * a domain could have some devices handled by vPCI and others by
> +             * QEMU for example, and the later won't have pdev->vpci
> +             * allocated.

This, otoh, I don't understand: Do we really intend to have pass-through
devices handled by qemu or alike, for PVH? Or are you thinking of hybrid
HVM (some vPCI, some qemu)? Plus, when considering hybrid guests, won't
we need to take into account BARs of externally handled devices as well,
to avoid overlaps?

In any event, until the DomU side picture is more clear, I'd suggest we
avoid making statements pinning down expectations. That said, you're the
maintainer, so if you really want it like this, so be it.

Jan

> +             */
> +            continue;
> +
>          if ( tmp == pdev )
>          {
>              /*




 


Rackspace

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