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

2018-06-28 Thread Peter Maydell
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. One

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

2016-04-26 Thread Peter Maydell
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 1, 2016) > ==

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

2015-10-26 Thread Peter Maydell
On 26 October 2015 at 10:12, Denis V. Lunev 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/update-linux-headers.sh script. Thi

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

2015-10-26 Thread Peter Maydell
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. Srinivasan" > CC: Gleb Natapov > CC: Paolo Bonzini > CC: Roman Kagan > CC: Denis V. Lunev > CC: k...@vger.ker

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

2015-07-31 Thread Peter Maydell
On 29 July 2015 at 20:16, Michael S. Tsirkin 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 sense since

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

2015-07-30 Thread Peter Maydell
On 30 July 2015 at 09:04, Michael S. Tsirkin 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 virtio-mm

Re: [PATCH] virtio_mmio: add ACPI probing

2015-07-29 Thread Peter Maydell
On 28 July 2015 at 11:33, G Gregory 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 break any existing widel

Re: [PATCH] virtio_mmio: add ACPI probing

2015-07-28 Thread Peter Maydell
On 28 July 2015 at 21:28, G Gregory wrote: > On 28 July 2015 at 21:12, Peter Maydell 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: [PATCH] virtio_mmio: add ACPI probing

2015-07-28 Thread Peter Maydell
On 28 July 2015 at 11:27, Michael S. Tsirkin wrote: > On Tue, Jul 28, 2015 at 11:12:33AM +0100, Peter Maydell wrote: >> On 28 July 2015 at 11:08, Michael S. Tsirkin wrote: >> > On Tue, Jul 28, 2015 at 10:44:02AM +0100, Graeme Gregory wrote: >> >> Added the mat

Re: [PATCH] virtio_mmio: add ACPI probing

2015-07-28 Thread Peter Maydell
On 28 July 2015 at 11:08, Michael S. Tsirkin 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. >> >> http:

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

2015-05-12 Thread Peter Maydell
On 12 May 2015 at 14:14, Cornelia Huck wrote: > On Wed, 06 May 2015 14:07:37 +0200 > Greg Kurz wrote: >> @@ -233,7 +233,6 @@ static inline void virtio_clear_feature(uint32_t >> *features, unsigned int fbit) >> >> static inline bool __virtio_has_feature(uint32_t features, unsigned int >> fbit)

Re: VirtIO-MMIO on MMU-less System

2014-10-28 Thread Peter Maydell
On 28 October 2014 16:42, Christopher Covington 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 aware that it's not c

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

2014-10-27 Thread Peter Maydell
On 27 October 2014 11:23, Li Liu wrote: > So you mean virtio-mmio will be replaced by PCI/PCIe on ARM at last? That is the plan, yes. I can't make any promises on timescales at the moment, though... -- PMM ___ Virtualization mailing list Virtualization

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

2014-10-27 Thread Peter Maydell
On 25 October 2014 09:24, john.liuli 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 reason can be acce

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

2014-09-14 Thread Peter Maydell
On 14 September 2014 08:09, Michael S. Tsirkin 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 mos

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

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

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

2014-09-14 Thread Peter Maydell
On 14 September 2014 06:46, Michael S. Tsirkin 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 any reason w

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

2014-09-12 Thread Peter Maydell
On 12 September 2014 13:48, Eric Blake 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: >>> >>

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

2014-09-11 Thread Peter Maydell
On 11 September 2014 16:09, Gerd Hoffmann wrote: > This patch adds the header file with structs and defines for > the virtio based gpu device. Covers 2d operations only. Please don't cc subscriber only mailing lists (virtio-...@lists.oasis-open.org) on posts to qemu-devel; it just means everybod

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

2014-09-11 Thread Peter Maydell
On 11 September 2014 16:09, Gerd Hoffmann 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 > --- > include/hw/virtio/virtgpu_hw.h | 158 > + >

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

2013-06-24 Thread Peter Maydell
On 24 June 2013 13:26, Christopher Covington wrote: > On 06/22/2013 06:51 AM, Peter Maydell wrote: >> On 21 June 2013 19:45, Christopher Covington wrote: >>> You were proposing to use a valid/existing MagicValue/Version/VendorID with >>> a >>> special Device

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

2013-06-22 Thread Peter Maydell
On 21 June 2013 19:45, Christopher Covington 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 setting, size=0, > that

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

2013-06-21 Thread Peter Maydell
On 21 June 2013 19:01, Christopher Covington 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". I'm confused --

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

2013-06-21 Thread Peter Maydell
On 21 June 2013 17:47, Pawel Moll 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

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

2013-06-21 Thread Peter Maydell
On 21 June 2013 17:02, Christopher Covington wrote: > Would using CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES enumeration > instead of device tree be any easier? My general view is that the kernel command line is the user's to manipulate, and that QEMU shouldn't touch it at all (just pass it through). (Co

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

2013-06-21 Thread Peter Maydell
On 20 June 2013 13:58, Christopher Covington 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 >>> se

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

2013-05-29 Thread Peter Maydell
On 29 May 2013 14:24, Michael S. Tsirkin 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. But this

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

2013-05-29 Thread Peter Maydell
On 29 May 2013 11:08, Michael S. Tsirkin 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

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

2013-05-29 Thread Peter Maydell
On 29 May 2013 09:24, Michael S. Tsirkin 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 > *opaque, hwaddr

Re: [RFC] kvm tools: Add support for virtio-mmio

2011-11-15 Thread Peter Maydell
On 15 November 2011 16:47, Sasha Levin wrote: > +       vmmio->hdr = (struct virtio_mmio_hdr) { > +               .magic          = {'v', 'i', 'r', 't'}, > +               .version        = 1, > +               .device_id      = device_id - 0x1000 + 1, > +               .vendor_id      = PCI_VENDO

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

2011-11-14 Thread Peter Maydell
On 9 November 2011 11:06, Pawel Moll 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 control regi

Re: Additional virtio-mmio spec changes

2011-11-14 Thread Peter Maydell
Rusty wrote: >Pawel Moll 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 thought