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 --]
next prev parent 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).