Re: Additional virtio-mmio spec changes

Rusty wrote: Pawel Moll pawel.m...@arm.com wrote: Peter also mentioned that he didn't like the Num in QueueNum register name and would rather see it called QueueSize. I have no strong opinions either way and can provide patches to both the spec and the driver (and header) to change it. Any

Re: [PATCH RFC] virtio-spec: flexible configuration layout

On 9 November 2011 11:06, Pawel Moll pawel.m...@arm.com wrote: On Wed, 2011-11-09 at 10:55 +, Sasha Levin wrote: On Wed, 2011-11-09 at 10:47 +, Pawel Moll wrote: Yep, it's actually already in 3.2-rc1 (drivers/virtio/virtio_mmio.c) and in the spec (see Appendix X). And actually the

Re: [PATCH RFC] virtio-pci: new config layout: using memory BAR

On 29 May 2013 09:24, Michael S. Tsirkin m...@redhat.com wrote: diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c index f4db224..fd09ea7 100644 --- a/hw/virtio/virtio-pci.c +++ b/hw/virtio/virtio-pci.c @@ -467,51 +467,70 @@ static uint64_t virtio_pci_config_common_read(void

Re: [PATCH RFC] virtio-pci: new config layout: using memory BAR

On 29 May 2013 11:08, Michael S. Tsirkin m...@redhat.com wrote: On Wed, May 29, 2013 at 10:00:33AM +0100, Peter Maydell wrote: Asserting is definitely the wrong thing here, since the guest can trigger it. So? So guest should not be able to crash QEMU is a standard rule: assert() is for QEMU

Re: [PATCH RFC] virtio-pci: new config layout: using memory BAR

On 29 May 2013 14:24, Michael S. Tsirkin m...@redhat.com wrote: On Wed, May 29, 2013 at 07:52:37AM -0500, Anthony Liguori wrote: 1) C makes no guarantees about structure layout beyond the first member. Yes, if it's naturally aligned or has a packed attribute, GCC does the right thing.

Re: what should a virtio-mmio transport without a backend look like?

On 20 June 2013 13:58, Christopher Covington c...@codeaurora.org wrote: On Thu, 2013-06-20 at 11:29 +0100, Peter Maydell wrote: 1. One question I've run into is: what should a virtio-mmio transport with no backend look like to the guest OS? The spec as written seems to assume that there's

Re: what should a virtio-mmio transport without a backend look like?

On 21 June 2013 17:47, Pawel Moll pawel.m...@arm.com wrote: On Fri, 2013-06-21 at 17:41 +0100, Peter Maydell wrote: As it happens, if you use the command line to specify a virtio device it doesn't make the same complaint about bad magic number as if you specify it via dtb, but that should

Re: what should a virtio-mmio transport without a backend look like?

On 21 June 2013 19:01, Christopher Covington c...@codeaurora.org wrote: Anyhow, I just did a quick experiment with 0-size block devices, and they seem to work for me, although trying to mount the device yields the confusing message, mount: mounting /dev/vda on mount failed: Invalid argument.

Re: what should a virtio-mmio transport without a backend look like?

On 21 June 2013 19:45, Christopher Covington c...@codeaurora.org wrote: You were proposing to use a valid/existing MagicValue/Version/VendorID with a special DeviceID that does nothing. I'm saying why not use a valid/existing MagicValue/Version/VendorID/DeviceID with a special parameter

Re: what should a virtio-mmio transport without a backend look like?

On 24 June 2013 13:26, Christopher Covington c...@codeaurora.org wrote: On 06/22/2013 06:51 AM, Peter Maydell wrote: On 21 June 2013 19:45, Christopher Covington c...@codeaurora.org wrote: You were proposing to use a valid/existing MagicValue/Version/VendorID with a special DeviceID

Re: [Qemu-devel] [PATCH 1/2] virtio-gpu/2d: add hardware spec include file

On 11 September 2014 16:09, Gerd Hoffmann kra...@redhat.com wrote: This patch adds the header file with structs and defines for the virtio based gpu device. Covers 2d operations only. Signed-off-by: Gerd Hoffmann kra...@redhat.com --- include/hw/virtio/virtgpu_hw.h | 158

Re: [Qemu-devel] [PATCH 1/2] virtio-gpu/2d: add hardware spec include file

On 12 September 2014 13:48, Eric Blake ebl...@redhat.com wrote: On 09/12/2014 04:44 AM, Gerd Hoffmann wrote: +enum virtgpu_ctrl_type { +VIRTGPU_UNDEFINED = 0, + +/* 2d commands */ +VIRTGPU_CMD_GET_DISPLAY_INFO = 0x0100, Please consider also adding: #define

Re: [Qemu-devel] [PATCH 1/2] virtio-gpu/2d: add hardware spec include file

On 14 September 2014 06:46, Michael S. Tsirkin m...@redhat.com wrote: BUILD_BUG_ON in linux, QEMU_BUILD_BUG_ON in QEMU. You have to stick it in a C file though, so it won't be visible in this patch. Why do you think that? We have several header files which use QEMU_BUILD_BUG_ON and I don't see

Re: [Qemu-devel] [PATCH 1/2] virtio-gpu/2d: add hardware spec include file

On 14 September 2014 07:11, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Sep 14, 2014 at 07:04:11AM -0700, Peter Maydell wrote: On 14 September 2014 06:46, Michael S. Tsirkin m...@redhat.com wrote: BUILD_BUG_ON in linux, QEMU_BUILD_BUG_ON in QEMU. You have to stick it in a C file though

Re: [Qemu-devel] [PATCH 1/2] virtio-gpu/2d: add hardware spec include file

On 14 September 2014 08:09, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Sep 14, 2014 at 07:32:21AM -0700, Peter Maydell wrote: Who owns the master copy of the header and commits to making sure it builds on other things than Linux+gcc in that case? For most of virtio neither linux nor

Re: [Qemu-devel] [RFC PATCH 0/2] virtio-mmio: add irqfd support for vhost-net based on virtio-mmio

On 25 October 2014 09:24, john.liuli john.li...@huawei.com wrote: To get the interrupt reason to support such VIRTIO_NET_F_STATUS features I add a new register offset VIRTIO_MMIO_ISRMEM which will help to establish a shared memory region between qemu and virtio-mmio device. Then the interrupt

Re: VirtIO-MMIO on MMU-less System

On 28 October 2014 16:42, Christopher Covington c...@codeaurora.org wrote: Just out of curiosity, could VirtIO-MMIO peripherals work on an MMU-less system, such as a hypothetical M-flavor QEMU TCG virt machine? No inherent reason, I think. If you care about M profile emulation you should be

Re: [Qemu-devel] [PATCH RFC 1/7] virtio: relax feature check

On 12 May 2015 at 14:14, Cornelia Huck cornelia.h...@de.ibm.com wrote: On Wed, 06 May 2015 14:07:37 +0200 Greg Kurz gk...@linux.vnet.ibm.com wrote: @@ -233,7 +233,6 @@ static inline void virtio_clear_feature(uint32_t *features, unsigned int fbit) static inline bool

Re: [PATCH] virtio_mmio: add ACPI probing

On 28 July 2015 at 11:08, Michael S. Tsirkin m...@redhat.com wrote: On Tue, Jul 28, 2015 at 10:44:02AM +0100, Graeme Gregory wrote: Added the match table and pointers for ACPI probing to the driver. This uses the same identifier for virt devices as being used for qemu ARM64 ACPI support.

Re: [PATCH] virtio_mmio: add ACPI probing

On 28 July 2015 at 11:33, G Gregory graeme.greg...@linaro.org wrote: We assigned LNRO in ASWG to avoid collisions with our prototypes/real platforms so it makes sense to me to switch to QEMU. So just to check, if we switch virtio-mmio from an LNRO0005 ID to a QEMU ID we aren't going to

Re: [PATCH v2] arm: change vendor ID for virtio-mmio

On 29 July 2015 at 20:16, Michael S. Tsirkin m...@redhat.com wrote: ACPI spec 5.0 allows the use of PCI vendor IDs. Since we have one for virtio, it seems neater to use that rather than LNRO. For the device ID, use 103F which is a legacy ID that isn't used in virtio PCI spec - seems to make

Re: [PATCH] virtio_mmio: add ACPI probing

On 28 July 2015 at 11:27, Michael S. Tsirkin m...@redhat.com wrote: On Tue, Jul 28, 2015 at 11:12:33AM +0100, Peter Maydell wrote: On 28 July 2015 at 11:08, Michael S. Tsirkin m...@redhat.com wrote: On Tue, Jul 28, 2015 at 10:44:02AM +0100, Graeme Gregory wrote: Added the match table

Re: [PATCH] virtio_mmio: add ACPI probing

On 28 July 2015 at 21:28, G Gregory graeme.greg...@linaro.org wrote: On 28 July 2015 at 21:12, Peter Maydell peter.mayd...@linaro.org wrote: Mmm. I'm not terribly happy about stuff being in QEMU before the ACPI spec for it has been finalised. We should not be picking stuff randomly on the fly

Re: [Qemu-devel] [PATCH v2] arm: change vendor ID for virtio-mmio

On 30 July 2015 at 09:04, Michael S. Tsirkin m...@redhat.com wrote: On Thu, Jul 30, 2015 at 09:23:20AM +0800, Shannon Zhao wrote: Why do we drop the previous way using QEMU? Something I missed? So that guests that bind to this interface will work fine with non QEMU implementations of

Re: [Qemu-devel] [PATCH 3/7] linux-headers/kvm: add Hyper-V SynIC irq routing type and struct

On 26 October 2015 at 09:50, Andrey Smetanin wrote: > Signed-off-by: Andrey Smetanin > Reviewed-by: Roman Kagan > Signed-off-by: Denis V. Lunev > CC: Vitaly Kuznetsov > CC: "K. Y.

Re: [Qemu-devel] [PATCH 3/7] linux-headers/kvm: add Hyper-V SynIC irq routing type and struct

On 26 October 2015 at 10:12, Denis V. Lunev <d...@openvz.org> wrote: > On 10/26/2015 01:03 PM, Peter Maydell wrote: >> Hi. Changes to linux-headers/ should only be made as part of >> an automated update from a mainline Linux kernel tree using >> the scripts/upd

Re: [Qemu-devel] KVM Forum 2016: Call For Participation

On 10 March 2016 at 18:09, Paolo Bonzini wrote: > = > KVM Forum 2016: Call For Participation > August 24-26, 2016 - Westin Harbor Castle - Toronto, Canada > > (All submissions must be received before midnight May

Re: [PATCH v2 0/5] Add virtio-iommu driver

On 27 June 2018 at 20:59, Michael S. Tsirkin wrote: > My point was virtio mmio isn't widely used outside of ARM. > Rather than try to make everyone use it, IMHO it's better > to start with PCI. Yes. I would much rather we let virtio-mmio disappear into history as a random bit of legacy stuff.