qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: "Stefano Stabellini" <sstabellini@kernel.org>,
	"Julien Grall" <julien@xen.org>,
	"Paul Durrant" <xadimgnik@gmail.com>,
	"Oleksandr Tyshchenko" <Oleksandr_Tyshchenko@epam.com>,
	"Anthony Perard" <anthony.perard@citrix.com>,
	"Paul Durrant" <paul@xen.org>, "Kevin Wolf" <kwolf@redhat.com>,
	"Hanna Reitz" <hreitz@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Jason Wang" <jasowang@redhat.com>,
	"open list:X86 Xen CPUs" <xen-devel@lists.xenproject.org>,
	"open list:Block layer core" <qemu-block@nongnu.org>
Subject: Re: [EXTERNAL] [PATCH v3 2/5] xen: backends: don't overwrite XenStore nodes created by toolstack
Date: Mon, 27 Nov 2023 08:35:42 +0000	[thread overview]
Message-ID: <51fd9b1f4407b92352c109cbef5acf16c91351d4.camel@infradead.org> (raw)
In-Reply-To: <20231124232400.943580-3-volodymyr_babchuk@epam.com>

[-- Attachment #1: Type: text/plain, Size: 4738 bytes --]

On Fri, 2023-11-24 at 23:24 +0000, Volodymyr Babchuk wrote:
> Xen PV devices in QEMU can be created in two ways: either by QEMU
> itself, if they were passed via command line, or by Xen toolstack. In
> the latter case, QEMU scans XenStore entries and configures devices
> accordingly.
> 
> In the second case we don't want QEMU to write/delete front-end
> entries for two reasons: it might have no access to those entries if
> it is running in un-privileged domain and it is just incorrect to
> overwrite entries already provided by Xen toolstack, because
> toolstack
> manages those nodes. For example, it might read backend- or frontend-
> state to be sure that they are both disconnected and it is safe to
> destroy a domain.
> 
> This patch checks presence of xendev->backend to check if Xen PV
> device was configured by Xen toolstack to decide if it should touch
> frontend entries in XenStore. Also, when we need to remove XenStore
> entries during device teardown only if they weren't created by Xen
> toolstack. If they were created by toolstack, then it is toolstack's
> job to do proper clean-up.
> 
> Suggested-by: Paul Durrant <xadimgnik@gmail.com>
> Suggested-by: David Woodhouse <dwmw@amazon.co.uk>
> Co-Authored-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>

... albeit with a couple of suggestions... 

> diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
> index bef8a3a621..b52ddddabf 100644
> --- a/hw/char/xen_console.c
> +++ b/hw/char/xen_console.c
> @@ -450,7 +450,7 @@ static void xen_console_realize(XenDevice *xendev, Error **errp)
> 
>      trace_xen_console_realize(con->dev, object_get_typename(OBJECT(cs)));
> 
> -    if (CHARDEV_IS_PTY(cs)) {
> +    if (CHARDEV_IS_PTY(cs) && !xendev->backend) {
>          /* Strip the leading 'pty:' */
>          xen_device_frontend_printf(xendev, "tty", "%s", cs->filename + 4);
>      }


It's kind of weird that that one is a frontend node at all; surely it
should have been a backend node? But it is known only to QEMU once it
actually opens /dev/ptmx and creates a new pty. It can't be populated
by the toolstack in advance.

So shouldn't the toolstack have made it writable by the driver domain? 

I think we should attempt to write this and just gracefully handle the
failure if we can't. (In fact, xen_device_frontend_printf() will just
use error_report_err() which is probably OK unless you feel strongly
about silencing it).

> diff --git a/hw/net/xen_nic.c b/hw/net/xen_nic.c
> index afa10c96e8..27442bef38 100644
> --- a/hw/net/xen_nic.c
> +++ b/hw/net/xen_nic.c
> @@ -315,14 +315,16 @@ static void xen_netdev_realize(XenDevice *xendev, Error **errp)
> 
>      qemu_macaddr_default_if_unset(&netdev->conf.macaddr);
> 
> -    xen_device_frontend_printf(xendev, "mac", "%02x:%02x:%02x:%02x:%02x:%02x",
> -                               netdev->conf.macaddr.a[0],
> -                               netdev->conf.macaddr.a[1],
> -                               netdev->conf.macaddr.a[2],
> -                               netdev->conf.macaddr.a[3],
> -                               netdev->conf.macaddr.a[4],
> -                               netdev->conf.macaddr.a[5]);
> -
> +    if (!xendev->backend) {
> +        xen_device_frontend_printf(xendev, "mac",
> +                                   "%02x:%02x:%02x:%02x:%02x:%02x",
> +                                   netdev->conf.macaddr.a[0],
> +                                   netdev->conf.macaddr.a[1],
> +                                   netdev->conf.macaddr.a[2],
> +                                   netdev->conf.macaddr.a[3],
> +                                   netdev->conf.macaddr.a[4],
> +                                   netdev->conf.macaddr.a[5]);
> +    }
>      netdev->nic = qemu_new_nic(&net_xen_info, &netdev->conf,
>                                 object_get_typename(OBJECT(xendev)),
>                                 DEVICE(xendev)->id, netdev);


Perhaps here you should create the "mac" node if it doesn't exist (or
is that "if it doesn't match netdev->conf.macaddr"?) and just
gracefully accept failure too?




[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5965 bytes --]

  reply	other threads:[~2023-11-27  8:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-24 23:24 [PATCH v3 0/5] xen-arm: add support for virtio-pci Volodymyr Babchuk
2023-11-24 23:24 ` [PATCH v3 1/5] hw/xen: Set XenBackendInstance in the XenDevice before realizing it Volodymyr Babchuk
2023-11-24 23:24 ` [RFC PATCH v3 3/5] xen: add option to disable legacy backends Volodymyr Babchuk
2023-11-27  8:46   ` Woodhouse, David via
2023-11-27  9:15     ` Volodymyr Babchuk
2023-11-24 23:24 ` [PATCH v3 2/5] xen: backends: don't overwrite XenStore nodes created by toolstack Volodymyr Babchuk
2023-11-27  8:35   ` David Woodhouse [this message]
2023-11-28  1:20     ` [EXTERNAL] " Volodymyr Babchuk
2023-11-28 14:11       ` David Woodhouse
2023-11-24 23:24 ` [PATCH v3 4/5] xen_arm: set mc->max_cpus to GUEST_MAX_VCPUS Volodymyr Babchuk
2023-11-24 23:24 ` [PATCH v3 5/5] xen_arm: Add virtual PCIe host bridge support Volodymyr Babchuk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51fd9b1f4407b92352c109cbef5acf16c91351d4.camel@infradead.org \
    --to=dwmw2@infradead.org \
    --cc=Oleksandr_Tyshchenko@epam.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=anthony.perard@citrix.com \
    --cc=hreitz@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=julien@xen.org \
    --cc=kwolf@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=paul@xen.org \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=sstabellini@kernel.org \
    --cc=xadimgnik@gmail.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).