From: "Michael S. Tsirkin" <mst@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Alexander Graf <graf@amazon.com>,
qemu-devel@nongnu.org, qemu-block@nongnu.org,
qemu-arm@nongnu.org, Cameron Esfahani <dirty@apple.com>,
Roman Bolshakov <r.bolshakov@yadro.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
Hanna Reitz <hreitz@redhat.com>,
Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>
Subject: Re: [PATCH 05/12] hw/virtio: Add support for apple virtio-blk
Date: Fri, 16 Jun 2023 10:45:01 -0400 [thread overview]
Message-ID: <20230616104401-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <ZIxMIyi1KY7Ku9Xm@redhat.com>
On Fri, Jun 16, 2023 at 01:48:51PM +0200, Kevin Wolf wrote:
> Am 15.06.2023 um 00:56 hat Alexander Graf geschrieben:
> > Apple has its own virtio-blk PCI device ID where it deviates from the
> > official virtio-pci spec slightly: It puts a new "apple type"
> > field at a static offset in config space and introduces a new discard
> > command.
>
> In other words, it's a different device. We shouldn't try to
> differentiate only with a property, but actually model it as a separate
> device.
>
> > This patch adds a new qdev property called "apple-type" to virtio-blk-pci.
> > When that property is set, we assume the virtio-blk device is an Apple one
> > of the specific type and act accordingly.
>
> Do we have any information on what the number in "apple-type" actually
> means or do we have to treat it as a black box?
>
> > Signed-off-by: Alexander Graf <graf@amazon.com>
> > ---
> > hw/block/virtio-blk.c | 23 +++++++++++++++++++++
> > hw/virtio/virtio-blk-pci.c | 7 +++++++
> > include/hw/pci/pci_ids.h | 1 +
> > include/hw/virtio/virtio-blk.h | 1 +
> > include/standard-headers/linux/virtio_blk.h | 3 +++
> > 5 files changed, 35 insertions(+)
> >
> > diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
> > index 39e7f23fab..76b85bb3cb 100644
> > --- a/hw/block/virtio-blk.c
> > +++ b/hw/block/virtio-blk.c
> > @@ -1120,6 +1120,20 @@ static int virtio_blk_handle_request(VirtIOBlockReq *req, MultiReqBuffer *mrb)
> >
> > break;
> > }
> > + case VIRTIO_BLK_T_APPLE1:
>
> Can we have a more descriptive name?
>
> > + {
> > + if (s->conf.x_apple_type) {
> > + /* Only valid on Apple Virtio */
> > + char buf[iov_size(in_iov, in_num)];
> > + memset(buf, 0, sizeof(buf));
> > + iov_from_buf(in_iov, in_num, 0, buf, sizeof(buf));
> > + virtio_blk_req_complete(req, VIRTIO_BLK_S_OK);
>
> So this is a command that simply fills the guest buffer with zeros
> without accessing the disk content? Weird, but ok, if that's what they
> are doing...
>
> The commit message talks about a discard command. I would have expected
> a command that discards/unmaps data from the disk. I think it would be
> good to call it something else in the commit message if it has nothing
> to do with this.
>
> > + } else {
> > + virtio_blk_req_complete(req, VIRTIO_BLK_S_UNSUPP);
> > + }
> > + virtio_blk_free_request(req);
> > + break;
> > + }
> > default:
> > virtio_blk_req_complete(req, VIRTIO_BLK_S_UNSUPP);
> > virtio_blk_free_request(req);
> > @@ -1351,6 +1365,10 @@ static void virtio_blk_update_config(VirtIODevice *vdev, uint8_t *config)
> > } else {
> > blkcfg.zoned.model = VIRTIO_BLK_Z_NONE;
> > }
> > + if (s->conf.x_apple_type) {
> > + /* Apple abuses the same location for its type id */
> > + blkcfg.max_secure_erase_sectors = s->conf.x_apple_type;
>
> Ideally, blkcfg would contain a union there. Since this is a type
> imported from the kernel, we can't change it inside of QEMU only. Works
> for me with this comment.
>
> > + }
> > memcpy(config, &blkcfg, s->config_size);
> > }
> >
> > @@ -1625,6 +1643,10 @@ static void virtio_blk_device_realize(DeviceState *dev, Error **errp)
> >
> > s->config_size = virtio_get_config_size(&virtio_blk_cfg_size_params,
> > s->host_features);
> > + if (s->conf.x_apple_type) {
> > + /* Apple Virtio puts the blk type at 0x3c, make sure we have space. */
> > + s->config_size = MAX(s->config_size, 0x3d);
> > + }
> > virtio_init(vdev, VIRTIO_ID_BLOCK, s->config_size);
> >
> > s->blk = conf->conf.blk;
> > @@ -1734,6 +1756,7 @@ static Property virtio_blk_properties[] = {
> > conf.max_write_zeroes_sectors, BDRV_REQUEST_MAX_SECTORS),
> > DEFINE_PROP_BOOL("x-enable-wce-if-config-wce", VirtIOBlock,
> > conf.x_enable_wce_if_config_wce, true),
> > + DEFINE_PROP_UINT32("x-apple-type", VirtIOBlock, conf.x_apple_type, 0),
>
> In a separate device, this would probably be called "apple-type"
> (without "x-") like promised in the commit message?
>
> If not, what is the reason for having an "x-" prefix?
>
> > DEFINE_PROP_END_OF_LIST(),
> > };
> >
> > diff --git a/hw/virtio/virtio-blk-pci.c b/hw/virtio/virtio-blk-pci.c
> > index 9743bee965..5fbf98f750 100644
> > --- a/hw/virtio/virtio-blk-pci.c
> > +++ b/hw/virtio/virtio-blk-pci.c
> > @@ -62,6 +62,13 @@ static void virtio_blk_pci_realize(VirtIOPCIProxy *vpci_dev, Error **errp)
> > }
> >
> > qdev_realize(vdev, BUS(&vpci_dev->bus), errp);
> > +
> > + if (conf->x_apple_type) {
> > + /* Apple virtio-blk uses a different vendor/device id */
> > + pci_config_set_vendor_id(vpci_dev->pci_dev.config, PCI_VENDOR_ID_APPLE);
> > + pci_config_set_device_id(vpci_dev->pci_dev.config,
> > + PCI_DEVICE_ID_APPLE_VIRTIO_BLK);
> > + }
> > }
> >
> > static void virtio_blk_pci_class_init(ObjectClass *klass, void *data)
> > diff --git a/include/hw/pci/pci_ids.h b/include/hw/pci/pci_ids.h
> > index e4386ebb20..74e589a298 100644
> > --- a/include/hw/pci/pci_ids.h
> > +++ b/include/hw/pci/pci_ids.h
> > @@ -188,6 +188,7 @@
> > #define PCI_DEVICE_ID_APPLE_UNI_N_AGP 0x0020
> > #define PCI_DEVICE_ID_APPLE_U3_AGP 0x004b
> > #define PCI_DEVICE_ID_APPLE_UNI_N_GMAC 0x0021
> > +#define PCI_DEVICE_ID_APPLE_VIRTIO_BLK 0x1a00
> >
> > #define PCI_VENDOR_ID_SUN 0x108e
> > #define PCI_DEVICE_ID_SUN_EBUS 0x1000
> > diff --git a/include/hw/virtio/virtio-blk.h b/include/hw/virtio/virtio-blk.h
> > index dafec432ce..7117ce754c 100644
> > --- a/include/hw/virtio/virtio-blk.h
> > +++ b/include/hw/virtio/virtio-blk.h
> > @@ -46,6 +46,7 @@ struct VirtIOBlkConf
> > uint32_t max_discard_sectors;
> > uint32_t max_write_zeroes_sectors;
> > bool x_enable_wce_if_config_wce;
> > + uint32_t x_apple_type;
> > };
> >
> > struct VirtIOBlockDataPlane;
> > diff --git a/include/standard-headers/linux/virtio_blk.h b/include/standard-headers/linux/virtio_blk.h
> > index 7155b1a470..bbea5d50b9 100644
> > --- a/include/standard-headers/linux/virtio_blk.h
> > +++ b/include/standard-headers/linux/virtio_blk.h
> > @@ -204,6 +204,9 @@ struct virtio_blk_config {
> > /* Reset All zones command */
> > #define VIRTIO_BLK_T_ZONE_RESET_ALL 26
> >
> > +/* Write zeroes command */
> > +#define VIRTIO_BLK_T_APPLE1 0x10000
>
> Hm... The commit message says discard, this says write zeroes, and the
> implementation seems to be read zeroes? I'm confused.
You can't add it here, this is from Linux.
> > +
> > #ifndef VIRTIO_BLK_NO_LEGACY
> > /* Barrier before this op. */
> > #define VIRTIO_BLK_T_BARRIER 0x80000000
>
> Kevin
next prev parent reply other threads:[~2023-06-16 14:45 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20230614224038.86148-1-graf>
2023-06-14 22:54 ` [PATCH 04/12] hvf: arm: Ignore writes to CNTP_CTL_EL0 Alexander Graf
2023-06-16 10:31 ` Philippe Mathieu-Daudé
2023-06-14 22:56 ` [PATCH 05/12] hw/virtio: Add support for apple virtio-blk Alexander Graf
2023-06-14 22:56 ` [PATCH 06/12] hw: Add vmapple subdir Alexander Graf
2023-06-14 22:56 ` [PATCH 07/12] gpex: Allow more than 4 legacy IRQs Alexander Graf
2023-06-14 22:56 ` [PATCH 08/12] hw/vmapple/aes: Introduce aes engine Alexander Graf
2023-06-14 22:56 ` [PATCH 09/12] hw/vmapple/bdif: Introduce vmapple backdoor interface Alexander Graf
2023-06-16 10:39 ` Philippe Mathieu-Daudé
2023-08-22 13:07 ` Alexander Graf
2023-06-16 11:48 ` [PATCH 05/12] hw/virtio: Add support for apple virtio-blk Kevin Wolf
2023-06-16 14:22 ` Philippe Mathieu-Daudé
2023-06-16 14:45 ` Michael S. Tsirkin [this message]
2023-08-24 14:30 ` Alexander Graf
2023-08-24 14:49 ` Gerd Hoffmann
2023-06-19 17:47 ` Daniel P. Berrangé
2023-06-20 14:35 ` Stefan Hajnoczi
2023-06-20 18:32 ` Kevin Wolf
2023-06-14 22:57 ` [PATCH 10/12] hw/vmapple/cfg: Introduce vmapple cfg region Alexander Graf
2023-06-14 22:57 ` [PATCH 11/12] hw/vmapple/apple-gfx: Introduce ParavirtualizedGraphics.Framework support Alexander Graf
2023-06-14 22:57 ` [PATCH 12/12] hw/vmapple/vmapple: Add vmapple machine type Alexander Graf
2023-06-20 17:35 ` Bernhard Beschow
2023-08-30 14:58 ` Alexander Graf
2023-06-16 10:47 ` [PATCH 10/12] hw/vmapple/cfg: Introduce vmapple cfg region Philippe Mathieu-Daudé
2023-08-22 13:17 ` Alexander Graf
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=20230616104401-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=dirty@apple.com \
--cc=graf@amazon.com \
--cc=hreitz@redhat.com \
--cc=kwolf@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=r.bolshakov@yadro.com \
--cc=stefanha@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.