From: "Philippe Mathieu-Daudé" <philmd@linaro.org>
To: Stefan Hajnoczi <stefanha@redhat.com>, Alexander Graf <graf@amazon.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org,
qemu-arm@nongnu.org, "Cameron Esfahani" <dirty@apple.com>,
"Michael S . Tsirkin" <mst@redhat.com>,
"Kevin Wolf" <kwolf@redhat.com>,
"Hanna Reitz" <hreitz@redhat.com>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Peter Maydell" <peter.maydell@linaro.org>,
"Mads Ynddal" <mads@ynddal.dk>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Bernhard Beschow" <shentey@gmail.com>,
"Gerd Hoffmann" <kraxel@redhat.com>
Subject: Re: [PATCH v2 11/12] hw/vmapple/virtio-blk: Add support for apple virtio-blk
Date: Thu, 31 Aug 2023 22:34:39 +0200 [thread overview]
Message-ID: <9c4aa5e1-c9e7-c7eb-197a-de0c0f7c8648@linaro.org> (raw)
In-Reply-To: <20230831200342.GF532982@fedora>
On 31/8/23 22:03, Stefan Hajnoczi wrote:
> On Wed, Aug 30, 2023 at 04:14:24PM +0000, Alexander Graf wrote:
>> 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 barrier
>> command.
>>
>> This patch first creates a mechanism for virtio-blk downstream classes to
>> handle unknown commands. It then creates such a downstream class and a new
>> vmapple-virtio-blk-pci class which support the additional apple type config
>> identifier as well as the barrier command.
>>
>> It then exposes 2 subclasses from that that we can use to expose root and
>> aux virtio-blk devices: "vmapple-virtio-root" and "vmapple-virtio-aux".
>>
>> Signed-off-by: Alexander Graf <graf@amazon.com>
>
> Aside from my comments below:
>
> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
>
>>
>> ---
>>
>> v1 -> v2:
>>
>> - Rework to make all vmapple virtio-blk logic a subclass
>> ---
>> include/hw/pci/pci_ids.h | 1 +
>> include/hw/virtio/virtio-blk.h | 12 +-
>> include/hw/vmapple/virtio-blk.h | 39 ++++++
>> hw/block/virtio-blk.c | 19 ++-
>> hw/vmapple/virtio-blk.c | 212 ++++++++++++++++++++++++++++++++
>> hw/vmapple/Kconfig | 3 +
>> hw/vmapple/meson.build | 1 +
>> 7 files changed, 282 insertions(+), 5 deletions(-)
>> create mode 100644 include/hw/vmapple/virtio-blk.h
>> create mode 100644 hw/vmapple/virtio-blk.c
>> diff --git a/include/hw/vmapple/virtio-blk.h b/include/hw/vmapple/virtio-blk.h
>> new file mode 100644
>> index 0000000000..b23106a3df
>> --- /dev/null
>> +++ b/include/hw/vmapple/virtio-blk.h
>> @@ -0,0 +1,39 @@
>> +/*
>> + * VMApple specific VirtIO Block implementation
>> + *
>> + * Copyright © 2023 Amazon.com, Inc. or its affiliates. All Rights Reserved.
>> + *
>> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
>> + * See the COPYING file in the top-level directory.
>> + */
>> +
>> +#ifndef HW_VMAPPLE_CFG_H
>> +#define HW_VMAPPLE_CFG_H
>> +
>> +#include "hw/sysbus.h"
>
> I'm surprised to see this header since this isn't a SysBus device. Is it
> really needed?
>
>> +#include "qom/object.h"
>> +#include "hw/virtio/virtio-pci.h"
"virtio-pci.h" surprised me too.
>> +#include "hw/virtio/virtio-blk.h"
>> +
>> +#define TYPE_VMAPPLE_VIRTIO_BLK "vmapple-virtio-blk"
>> +#define TYPE_VMAPPLE_VIRTIO_ROOT "vmapple-virtio-root"
>> +#define TYPE_VMAPPLE_VIRTIO_AUX "vmapple-virtio-aux"
>> +
>> +OBJECT_DECLARE_TYPE(VMAppleVirtIOBlk, VMAppleVirtIOBlkClass, VMAPPLE_VIRTIO_BLK)
>> +
>> +typedef struct VMAppleVirtIOBlkClass {
>> + /*< private >*/
>> + VirtIOBlkClass parent;
>> + /*< public >*/
>> + void (*get_config)(VirtIODevice *vdev, uint8_t *config);
>> +} VMAppleVirtIOBlkClass;
>> +
>> +typedef struct VMAppleVirtIOBlk {
>> + /* <private> */
>> + VirtIOBlock parent_obj;
>> +
>> + /* <public> */
>> + uint32_t apple_type;
>> +} VMAppleVirtIOBlk;
>> +
>> +#endif /* HW_VMAPPLE_CFG_H */
next prev parent reply other threads:[~2023-08-31 20:35 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-30 16:14 [PATCH v2 00/12] Introduce new vmapple machine type Alexander Graf
2023-08-30 16:14 ` [PATCH v2 01/12] build: Only define OS_OBJECT_USE_OBJC with gcc Alexander Graf
2023-08-31 8:12 ` Philippe Mathieu-Daudé
2023-08-31 8:53 ` Akihiko Odaki
2023-08-31 8:59 ` Alexander Graf
2023-08-31 10:45 ` Akihiko Odaki
2023-08-30 16:14 ` [PATCH v2 02/12] hw/misc/pvpanic: Add MMIO interface Alexander Graf
2023-09-01 5:19 ` Mark Cave-Ayland
2023-08-30 16:14 ` [PATCH v2 03/12] hvf: Increase number of possible memory slots Alexander Graf
2023-08-30 16:14 ` [PATCH v2 04/12] hvf: arm: Ignore writes to CNTP_CTL_EL0 Alexander Graf
2023-08-31 8:13 ` Philippe Mathieu-Daudé
2023-08-30 16:14 ` [PATCH v2 05/12] hw: Add vmapple subdir Alexander Graf
2023-08-30 16:14 ` [PATCH v2 06/12] gpex: Allow more than 4 legacy IRQs Alexander Graf
2023-08-30 16:14 ` [PATCH v2 07/12] hw/vmapple/aes: Introduce aes engine Alexander Graf
2023-09-01 5:34 ` Mark Cave-Ayland
2023-08-30 16:14 ` [PATCH v2 08/12] hw/vmapple/bdif: Introduce vmapple backdoor interface Alexander Graf
2023-08-31 19:46 ` Stefan Hajnoczi
2023-09-01 5:40 ` Mark Cave-Ayland
2023-08-30 16:14 ` [PATCH v2 09/12] hw/vmapple/cfg: Introduce vmapple cfg region Alexander Graf
2023-09-01 5:46 ` Mark Cave-Ayland
2023-08-30 16:14 ` [PATCH v2 10/12] hw/vmapple/apple-gfx: Introduce ParavirtualizedGraphics.Framework support Alexander Graf
2023-09-23 21:04 ` Phil Dennis-Jordan
2023-08-30 16:14 ` [PATCH v2 11/12] hw/vmapple/virtio-blk: Add support for apple virtio-blk Alexander Graf
2023-08-31 20:03 ` Stefan Hajnoczi
2023-08-31 20:34 ` Philippe Mathieu-Daudé [this message]
2023-09-01 6:53 ` Mark Cave-Ayland
2023-08-30 16:14 ` [PATCH v2 12/12] hw/vmapple/vmapple: Add vmapple machine type Alexander Graf
2023-09-01 7:07 ` Mark Cave-Ayland
2023-10-12 11:46 ` Francesco Cagnin
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=9c4aa5e1-c9e7-c7eb-197a-de0c0f7c8648@linaro.org \
--to=philmd@linaro.org \
--cc=berrange@redhat.com \
--cc=dirty@apple.com \
--cc=graf@amazon.com \
--cc=hreitz@redhat.com \
--cc=kraxel@redhat.com \
--cc=kwolf@redhat.com \
--cc=mads@ynddal.dk \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.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=shentey@gmail.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 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).