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.
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
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.
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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.
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
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
28 matches
Mail list logo