Re: [PATCH v2] virtio-mmio: Update the device to OASIS spec version
Hi,
On 01/20/2015 01:12 PM, Pawel Moll wrote:
@@ -356,13 +346,6 @@ static struct virtqueue *vm_setup_vq(struct
virtio_device *vdev, unsigned index,
info-num /= 2;
}
- /* Activate the queue */
- writel(info-num, vm_dev-base + VIRTIO_MMIO_QUEUE_NUM);
- writel(VIRTIO_MMIO_VRING_ALIGN,
- vm_dev-base + VIRTIO_MMIO_QUEUE_ALIGN);
- writel(virt_to_phys(info-queue) PAGE_SHIFT,
- vm_dev-base + VIRTIO_MMIO_QUEUE_PFN);
-
/* Create the vring */
vq = vring_new_virtqueue(index, info-num, VIRTIO_MMIO_VRING_ALIGN,
vdev,
true, info-queue, vm_notify, callback, name);
@@ -371,6 +354,33 @@ static struct virtqueue *vm_setup_vq(struct
virtio_device *vdev, unsigned index,
goto error_new_virtqueue;
}
+ /* Activate the queue */
+ writel(info-num, vm_dev-base + VIRTIO_MMIO_QUEUE_NUM);
+ if (vm_dev-version == 1) {
+ writel(PAGE_SIZE, vm_dev-base + VIRTIO_MMIO_QUEUE_ALIGN);
+ writel(virt_to_phys(info-queue) PAGE_SHIFT,
+ vm_dev-base + VIRTIO_MMIO_QUEUE_PFN);
+ } else {
+ u64 addr;
+
+ addr = virt_to_phys(info-queue);
+ writel((u32)addr, vm_dev-base + VIRTIO_MMIO_QUEUE_DESC_LOW);
+ writel((u32)(addr 32),
+ vm_dev-base + VIRTIO_MMIO_QUEUE_DESC_HIGH);
+
+ addr = virt_to_phys(virtqueue_get_avail(vq));
+ writel((u32)addr, vm_dev-base + VIRTIO_MMIO_QUEUE_AVAIL_LOW);
+ writel((u32)(addr 32),
+ vm_dev-base + VIRTIO_MMIO_QUEUE_AVAIL_HIGH);
+
+ addr = virt_to_phys(virtqueue_get_used(vq));
+ writel((u32)addr, vm_dev-base + VIRTIO_MMIO_QUEUE_USED_LOW);
+ writel((u32)(addr 32),
+ vm_dev-base + VIRTIO_MMIO_QUEUE_USED_HIGH);
+
+ writel(1, vm_dev-base + VIRTIO_MMIO_QUEUE_READY);
+ }
+
vq-priv = info;
info-vq = vq;
This patch moved the call to vring_new_virtqueue() in the legacy code flow
before the VIRTIO_MMIO_QUEUE_NUM, VIRTIO_MMIO_QUEUE_ALIGN, and
VIRTIO_MMIO_QUEUE_PFN writes. Was this intentional? Could the old behavior be
reinstated?
We have an implementation that relies on knowing ahead of time what address
range will be used, and is blind to memory accesses that occur before
VIRTIO_MMIO_QUEUE_PFN is written to (or VIRTIO_MMIO_QUEUE_READY when we
upgrade). Is such an implementation supported by the specification? We can't
find any explicit mention that the driver is forbidden from writing to the
memory region before VIRTIO_MMIO_QUEUE_READY is set to 1 (or
VIRTIO_MMIO_QUEUE_PFN is set for legacy devices).
Thanks,
Chris
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
VirtIO-MMIO on MMU-less System
Just out of curiosity, could VirtIO-MMIO peripherals work on an MMU-less system, such as a hypothetical M-flavor QEMU TCG virt machine? Thanks, Chris -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH RFC v2 01/16] virtio: memory access APIs
Hi Michael,
On 10/22/2014 11:50 AM, Michael S. Tsirkin wrote:
virtio 1.0 makes all memory structures LE, so
we need APIs to conditionally do a byteswap on BE
architectures.
To make it easier to check code statically,
add virtio specific types for multi-byte integers
in memory.
Add low level wrappers that do a byteswap conditionally, these will be
useful e.g. for vhost. Add high level wrappers that will (in the
future) query device endian-ness and act accordingly.
At the moment, stub them out and assume native endian-ness everywhere.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
include/linux/virtio_config.h| 16 +
include/uapi/linux/virtio_ring.h | 49
include/uapi/linux/Kbuild| 1 +
3 files changed, 42 insertions(+), 24 deletions(-)
diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h
index 7f4ef66..d38d3c2 100644
--- a/include/linux/virtio_config.h
+++ b/include/linux/virtio_config.h
@@ -4,6 +4,7 @@
#include linux/err.h
#include linux/bug.h
#include linux/virtio.h
+#include linux/virtio_byteorder.h
What patch creates this file?
#include uapi/linux/virtio_config.h
/**
@@ -152,6 +153,21 @@ int virtqueue_set_affinity(struct virtqueue *vq, int cpu)
return 0;
}
+/* Memory accessors */
+#define DEFINE_VIRTIO_XX_TO_CPU(bits) \
+static inline u##bits virtio##bits##_to_cpu(struct virtio_device *vdev,
__virtio##bits val) \
+{ \
+ return __virtio##bits##_to_cpu(false, val); \
+} \
+static inline __virtio##bits cpu_to_virtio##bits(struct virtio_device *vdev,
u##bits val) \
+{ \
+ return __cpu_to_virtio##bits(false, val); \
+}
+
+DEFINE_VIRTIO_XX_TO_CPU(16)
+DEFINE_VIRTIO_XX_TO_CPU(32)
+DEFINE_VIRTIO_XX_TO_CPU(64)
+
/* Config space accessors. */
#define virtio_cread(vdev, structname, member, ptr) \
do {\
diff --git a/include/uapi/linux/virtio_ring.h
b/include/uapi/linux/virtio_ring.h
index a99f9b7..6c00632 100644
--- a/include/uapi/linux/virtio_ring.h
+++ b/include/uapi/linux/virtio_ring.h
@@ -32,6 +32,7 @@
*
* Copyright Rusty Russell IBM Corporation 2007. */
#include linux/types.h
+#include linux/virtio_types.h
/* This marks a buffer as continuing via the next field. */
#define VRING_DESC_F_NEXT1
@@ -61,32 +62,32 @@
/* Virtio ring descriptors: 16 bytes. These can chain together via next.
*/
struct vring_desc {
/* Address (guest-physical). */
- __u64 addr;
+ __virtio64 addr;
/* Length. */
- __u32 len;
+ __virtio32 len;
/* The flags as indicated above. */
- __u16 flags;
+ __virtio16 flags;
/* We chain unused descriptors via this, too */
- __u16 next;
+ __virtio16 next;
};
How does __virtio64 differ from __le64?
Thanks,
Chris
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: Standardizing an MSR or other hypercall to get an RNG seed?
On 09/19/2014 05:46 PM, H. Peter Anvin wrote: On 09/19/2014 01:46 PM, Andy Lutomirski wrote: However, it sounds to me that at least for KVM, it is very easy just to emulate the RDRAND instruction. The hypervisor would report to the guest that RDRAND is supported in CPUID and the emulate the instruction when guest executes it. KVM already traps guest #UD (which would occur if RDRAND executed while it is not supported) - so this scheme wouldn’t introduce additional overhead over RDMSR. Because then guest user code will think that rdrand is there and will try to use it, resulting in abysmal performance. Yes, the presence of RDRAND implies a cheap and inexhaustible entropy source. A guest kernel couldn't make it look like RDRAND is not present to guest userspace? Christopher -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: Standardizing an MSR or other hypercall to get an RNG seed?
On 09/19/2014 02:42 PM, Andy Lutomirski wrote: On Fri, Sep 19, 2014 at 11:30 AM, Christopher Covington c...@codeaurora.org wrote: On 09/17/2014 10:50 PM, Andy Lutomirski wrote: Hi all- I would like to standardize on a very simple protocol by which a guest OS can obtain an RNG seed early in boot. The main design requirements are: - The interface should be very easy to use. Linux, at least, will want to use it extremely early in boot as part of kernel ASLR. This means that PCI and ACPI will not work. How do non-virtual systems get entropy this early? RDRAND/Padlock? Truerand? Could hypervisors and simulators simply make sure these work? If RDRAND is available, then Linux, at least, will use it. The rest are too complicated for early use. Linux on x86 plays some vaguely clever games with rdtsc and poking at the i8254 port. I just wanted to check that it couldn't be as simple as giving one or both of the timers random initial values. Christopher -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: Standardizing an MSR or other hypercall to get an RNG seed?
On 09/17/2014 10:50 PM, Andy Lutomirski wrote: Hi all- I would like to standardize on a very simple protocol by which a guest OS can obtain an RNG seed early in boot. The main design requirements are: - The interface should be very easy to use. Linux, at least, will want to use it extremely early in boot as part of kernel ASLR. This means that PCI and ACPI will not work. How do non-virtual systems get entropy this early? RDRAND/Padlock? Truerand? Could hypervisors and simulators simply make sure these work? Christopher -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] [PATCH 1/2] virtio-gpu/2d: add hardware spec include file
On 09/11/2014 11:43 AM, Gerd Hoffmann wrote: On Do, 2014-09-11 at 16:20 +0100, Peter Maydell wrote: 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. Please don't cc subscriber only mailing lists (virtio-...@lists.oasis-open.org) on posts to qemu-devel; it just means everybody responding gets mailer bounce junkmail. I don't feel like splitting the discussion though. Suggestions how to deal with that? I think I've seen most active virtio-dev folks on the virtualization list too, is it ok to just drop virtio-dev for the next round and hope that folks see it via virtualization list? Perhaps you and other subscribers to the offending list can BCC it and announce that it's BCC'd body. Christopher -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 0/4] virtio: Clean up scatterlists and use the DMA API
On 09/04/2014 10:57 PM, Andy Lutomirski wrote: On Thu, Sep 4, 2014 at 7:31 PM, Rusty Russell ru...@rustcorp.com.au wrote: Andy Lutomirski l...@amacapital.net writes: On Sep 2, 2014 11:53 PM, Rusty Russell ru...@rustcorp.com.au wrote: Andy Lutomirski l...@amacapital.net writes: There really are virtio devices that are pieces of silicon and not figments of a hypervisor's imagination [1]. Hi Andy, As you're discovering, there's a reason no one has done the DMA API before. So the problem is that ppc64's IOMMU is a platform thing, not a bus thing. They really do carve out an exception for virtio devices, because performance (LOTS of performance). It remains to be seen if other platforms have the same performance issues, but in absence of other evidence, the answer is yes. It's a hack. But having specific virtual-only devices are an even bigger hack. Physical virtio devices have been talked about, but don't actually exist in Real Life. And someone a virtio PCI card is going to have serious performance issues: mainly because they'll want the rings in the card's MMIO region, not allocated by the driver. Being broken on PPC is really the least of their problems. So, what do we do? It'd be nice if Linux virtio Just Worked under Xen, though Xen's IOMMU is outside the virtio spec. Since virtio_pci can be a module, obvious hacks like having xen_arch_setup initialize a dma_ops pointer exposed by virtio_pci.c is out. Xen does expose dma_ops. The trick is knowing when to use it. I think the best approach is to have a new feature bit (25 is free), VIRTIO_F_USE_BUS_MAPPING which indicates that a device really wants to use the mapping for the bus it is on. A real device would set this, or it won't work behind an IOMMU. A Xen device would also set this. The devices I care about aren't actually Xen devices. They're devices supplied by QEMU/KVM, booting a Xen hypervisor, which in turn passes the virtio device (along with every other PCI device) through to dom0. So this is exactly the same virtio device that regular x86 KVM guests would see. The reason that current code fails is that Xen guest physical addresses aren't the same as the addresses seen by the outer hypervisor. These devices don't know that physical addresses != bus addresses, so they can't advertise that fact. Ah, I see. Then we will need a Xen-specific hack. Grr. This is mostly a result of the fact that virtio_pci devices aren't really PCI devices. I still think that virtio_pci shouldn't have to worry about this; ideally this would all be handled higher up in the device hierarchy. x86 already gets this right. Yes. Adding a feature to say I am a real PCI device is possible, but has other issues (particularly as Michael Tsirkin pointed out, what do you do if the driver doesn't understand the feature). Are there any hypervisors except PPC that use virtio_pci, have IOMMUs on the pci slot that virtio_pci lives in, and that use physical addressing? If not, I think that just quirking PPC will work (at least until someone wants IOMMU support in virtio_pci on PPC, in which case doing something using devicetree seems like a reasonable solution). We can either patch to make PPC weird or make Xen weird. I'm on the fence. Two questions for Paulo: 1) When QEMU support IOMMU on x86, will the virtio devices behind it respect the IOMMU (do they use the right memory access primitives?). 2) Are we really going to be able to exclude virtio devices from using the x86 IOMMU in a portable way which will always work? If it's per-bus granularity, will qemu really put them on their own PCI bus and get this right? Or will it sometimes get it wrong and users will end up using virtio devices via IOMMU by accident? If the answers are both yes, then x86 is going to be able to use virtio+IOMMU, so PPC looks like the odd one out. Otherwise it looks like we're really going to want to stick with the ignore IOMMU rule until (handwave future), and we make an exception for Xen. There's a third option: try to make virtio-mmio work everywhere (except s390), at least in the long run. This other benefits: it makes minimal hypervisors simpler, I think it'll get rid of the limits on the number of virtio devices in a system. ARM is already going this direction, and I imagine that PPC support would be straightforward (it's already using devicetree). In my opinion, a uniform virt machine for every instruction set would be very beneficial. I would guess that MMIO is more universally available than PCI, and as you point out, simpler to implement. Does virtio-mmio have any reasonable way of doing hotplug? It could also eventually make sense to have a standard for virtio on virtio. I don't think so, but it seems possible. My bystander understanding is that QEMU allocates some fixed number of VirtIO-MMIO devices, maybe a dozen, in the device tree. The ones that don't
Re: [PATCH 0/3] virtio: Clean up scatterlists and use the DMA API
On 08/27/2014 11:50 AM, Andy Lutomirski wrote: On Wed, Aug 27, 2014 at 8:45 AM, Michael S. Tsirkin m...@redhat.com wrote: On Wed, Aug 27, 2014 at 08:11:15AM -0700, Andy Lutomirski wrote: On Aug 26, 2014 11:46 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Tue, Aug 26, 2014 at 10:16 PM, Andy Lutomirski l...@amacapital.net wrote: There are two outstanding issues. virtio_net warns if DMA debugging is on because it does DMA from the stack. (The warning is correct.) This also is likely to do something unpleasant to s390. (Maintainers are cc'd -- I don't know what to do about it.) This changes the semantics of vring and breaks existing guests when bus address != physical address. Can you use a transport feature bit to indicate that bus addresses are used? That way both approaches can be supported. I can try to support both styles of addressing, but I don't think that this can be negotiated between the device (i.e. host or physical virtio-speaking device) and the guest. In the Xen case that I care about (Linux on Xen on KVM), the host doesn't know about the translation at all -- Xen is an intermediate layer that only the guest is aware of. In this case, there are effectively two layers of virtualization, and only the inner one (Xen) knows about the translation despite the fact that the the outer layer is the one providing the virtio device. I could change virtio_ring to use the DMA API only if requested by the lower driver (virtio_pci, etc) and to have only virtio_pci enable that feature. Will that work for all cases? On s390, this shouldn't work just like the current code. On x86, I think that if QEMU ever starts exposing an IOMMU attached to a virtio-pci device, then QEMU should expect that IOMMU to be used. If QEMU expects to see physical addresses, then it shouldn't advertise an IOMMU. Since QEMU doesn't currently support guest IOMMUs, this should be fine for everything that uses QEMU. At least x86's implementation of the DMA ops for devices that aren't behind an IOMMU should be very fast. Are there any other weird cases for which this might be a problem? Please also update the virtio specification: https://tools.oasis-open.org/version-control/browse/wsvn/virtio/ I'm not sure it will need an update. Perhaps a note in the PCI section indicating that, if the host expects the guest to program an IOMMU, then it should use the appropriate platform-specific mechanism to expose that IOMMU. --Andy If there's no virtio mechanism to negotate enabling/disabling translations, then specification does not need an extension. It wouldn't shock me if someone wants to negotiate this for virtio_mmio some day, but that might be more of a device tree thing. I have no idea how that works, but I think it can wait until someone wants it. At one point I wanted VirtIO-MMIO to not fail miserably on ARM LPAE systems. http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/241613.html Christopher -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/3] virtio: Clean up scatterlists and use the DMA API
On 08/27/2014 12:19 PM, Andy Lutomirski wrote: On Wed, Aug 27, 2014 at 9:13 AM, Christopher Covington c...@codeaurora.org wrote: On 08/27/2014 11:50 AM, Andy Lutomirski wrote: On Wed, Aug 27, 2014 at 8:45 AM, Michael S. Tsirkin m...@redhat.com wrote: On Wed, Aug 27, 2014 at 08:11:15AM -0700, Andy Lutomirski wrote: On Aug 26, 2014 11:46 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Tue, Aug 26, 2014 at 10:16 PM, Andy Lutomirski l...@amacapital.net wrote: There are two outstanding issues. virtio_net warns if DMA debugging is on because it does DMA from the stack. (The warning is correct.) This also is likely to do something unpleasant to s390. (Maintainers are cc'd -- I don't know what to do about it.) This changes the semantics of vring and breaks existing guests when bus address != physical address. Can you use a transport feature bit to indicate that bus addresses are used? That way both approaches can be supported. I can try to support both styles of addressing, but I don't think that this can be negotiated between the device (i.e. host or physical virtio-speaking device) and the guest. In the Xen case that I care about (Linux on Xen on KVM), the host doesn't know about the translation at all -- Xen is an intermediate layer that only the guest is aware of. In this case, there are effectively two layers of virtualization, and only the inner one (Xen) knows about the translation despite the fact that the the outer layer is the one providing the virtio device. I could change virtio_ring to use the DMA API only if requested by the lower driver (virtio_pci, etc) and to have only virtio_pci enable that feature. Will that work for all cases? On s390, this shouldn't work just like the current code. On x86, I think that if QEMU ever starts exposing an IOMMU attached to a virtio-pci device, then QEMU should expect that IOMMU to be used. If QEMU expects to see physical addresses, then it shouldn't advertise an IOMMU. Since QEMU doesn't currently support guest IOMMUs, this should be fine for everything that uses QEMU. At least x86's implementation of the DMA ops for devices that aren't behind an IOMMU should be very fast. Are there any other weird cases for which this might be a problem? Please also update the virtio specification: https://tools.oasis-open.org/version-control/browse/wsvn/virtio/ I'm not sure it will need an update. Perhaps a note in the PCI section indicating that, if the host expects the guest to program an IOMMU, then it should use the appropriate platform-specific mechanism to expose that IOMMU. --Andy If there's no virtio mechanism to negotate enabling/disabling translations, then specification does not need an extension. It wouldn't shock me if someone wants to negotiate this for virtio_mmio some day, but that might be more of a device tree thing. I have no idea how that works, but I think it can wait until someone wants it. At one point I wanted VirtIO-MMIO to not fail miserably on ARM LPAE systems. http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/241613.html Since I know nothing about LPAE, I'll leave this to you :) But I'll cc you on patch v2 soon, and please tell me whether my code makes sense on ARM. (My attempt to boot-test s390 failed because I have no clue what command-line options to pass to QEMU. If anyone wants to give me some pointers to get a working configuration with -kernel and some kind of console, I can add support to virtme. Alas, I think that no one ever bothered to implement 9p over virtio-ccw in QEMU. Why exactly does the virtio stuff in QEMU require that you instantiate virtio-9p-pci instead of just asking for an appropriate virtio dievice?) Virtme looks interesting. If it's any use, here is my modest QEMU command line collection. $dir/bin/x86_64-linux-gnu/qemu-system-x86_64 \ -m 1024 \ -kernel $dir/boot/x86_64-linux-gnu/bzImage-x86_64 \ -append 'root=/dev/root init=/sbin/x86_64-linux-gnu/init rootfstype=9p rootflags=trans=virtio,version=9p2000.L ro console=ttyS0' \ -serial stdio \ -fsdev local,id=root,path=$dir,security_model=none \ -device virtio-9p-pci,fsdev=root,mount_tag=/dev/root \ -monitor none $dir/bin/x86_64-linux-gnu/qemu-system-arm \ -M virt \ -cpu cortex-a15 \ -m 1024 \ -kernel $dir/boot/arm-linux-gnueabihf/Image \ -append 'root=/dev/root init=/sbin/arm-linux-gnueabihf/init rootfstype=9p rootflags=trans=virtio,version=9p2000.L ro console=ttyAMA0' \ -serial stdio \ -fsdev local,id=root,path=$dir,security_model=none \ -device virtio-9p-device,fsdev=root,mount_tag=/dev/root \ -monitor none $dir/bin/x86_64-linux-gnu/qemu-system-aarch64 \ -M virt \ -cpu cortex-a57 \ -m 1024 \ -kernel $dir/boot/aarch64-linux-gnu/Image \ -append 'root=/dev/root init=/sbin/aarch64-linux-gnu/init rootfstype=9p rootflags=trans=virtio,version=9p2000.L ro console=ttyAMA0' \ -serial stdio \ -fsdev local,id=root,path=$dir
Re: [V9fs-developer] [Qemu-devel] QEMU dies on any attempt to load a Linux kernel module when using a 9P rootfs
Hi Dominique, On 08/22/2014 02:27 AM, Dominique Martinet wrote: Hi, Christopher Covington wrote on Thu, Aug 21, 2014 at 03:50:58PM -0400: With my 3.15.0+ kernel, qemu-system-x86_64 substituted for qemu-kvm, and the path changed from your arguments I get: 9pnet_virtio: no channels available VFS: Cannot open root device root or unknown-block(0,0): error -2 Please append a correct root= boot option; here are the available partitions: 0b00 1048575 sr0 driver: sr Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 I'm pretty sure that's the same problem that's been reported a few times here, could you try again after cherry-picking this commit: commit f15844e0777fec936f87a87f97394f83911dacd3 Author: Dominique Martinet dominique.marti...@cea.fr Date: Wed May 21 10:02:12 2014 +0200 9P: fix return value in v9fs_fid_xattr_set v9fs_fid_xattr_set is supposed to return 0 on success. This corrects the behaviour introduced in commit bdd5c28dcb8330b9074404cc92a0b83aae5606a 9p: fix return value in case in v9fs_fid_xattr_set() (The function returns a negative error on error, as expected) Signed-off-by: Dominique Martinet dominique.marti...@cea.fr Signed-off-by: Eric Van Hensbergen eri...@gmail.com It has gotten in in v3.16-rc1, so your 3.15.0+ proably doesn't have it. Thanks for the pointer to this patch. I think I started this kernel half way through the 3.16 merge window. The last non-cherry-picked patch I have is: commit 6d87c225f5d82d29243dc124f1ffcbb0e14ec358 Merge: 338c09a 22001f6 Author: Linus Torvalds torva...@linux-foundation.org Date: Thu Jun 12 23:06:23 2014 -0700 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client So I do have the change you pointed out. Nevertheless, I'll reconfirm with the latest torvalds/master. Thanks, Christopher -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [V9fs-developer] [Qemu-devel] QEMU dies on any attempt to load a Linux kernel module when using a 9P rootfs
Hi Dominique, On 08/22/2014 08:49 AM, Dominique Martinet wrote: Hi, Christopher Covington wrote on Fri, Aug 22, 2014 at 08:37:52AM -0400: Thanks for the pointer to this patch. I think I started this kernel half way through the 3.16 merge window. The last non-cherry-picked patch I have is: commit 6d87c225f5d82d29243dc124f1ffcbb0e14ec358 So I do have the change you pointed out. Nevertheless, I'll reconfirm with the latest torvalds/master. Right, so you already do have it. I don't think there's been anything else 9P related recently, so it probably will not help much -- sorry for blindly assuming it would be this. Actually reading the error message now, no channels available is printed when virtio doesn't find any match in device name so it would look like the mount name doesn't match maybe? Could we get your exact qemu command line to confirm? (the name that needs to match is /dev/root here, used for booting as root= and for qemu as mount_tag) I re-transposed Richard's command line to my environment and it worked. Thanks for pointing me in that direction. For the record, I used: $dir/bin/x86_64-linux-gnu/qemu-system-x86_64 \ -m 1024 \ -kernel $dir/boot/x86_64-linux-gnu/bzImage-x86_64 \ -append 'root=/dev/root init=/sbin/x86_64-linux-gnu/init rootfstype=9p rootflags=trans=virtio,version=9p2000.L ro console=ttyS0' \ -serial stdio \ -fsdev local,id=root,path=$dir,security_model=none \ -device virtio-9p-pci,fsdev=root,mount_tag=/dev/root \ -monitor none $dir/bin/x86_64-linux-gnu/qemu-system-arm \ -M virt \ -cpu cortex-a15 \ -m 1024 \ -kernel $dir/boot/arm-linux-gnueabihf/Image \ -append 'root=/dev/root init=/sbin/arm-linux-gnueabihf/init rootfstype=9p rootflags=trans=virtio,version=9p2000.L ro console=ttyAMA0' \ -serial stdio \ -fsdev local,id=root,path=$dir,security_model=none \ -device virtio-9p-device,fsdev=root,mount_tag=/dev/root \ -monitor none $dir/bin/x86_64-linux-gnu/qemu-system-aarch64 \ -M virt \ -cpu cortex-a57 \ -m 1024 \ -kernel $dir/boot/aarch64-linux-gnu/Image \ -append 'root=/dev/root init=/sbin/aarch64-linux-gnu/init rootfstype=9p rootflags=trans=virtio,version=9p2000.L ro console=ttyAMA0' \ -serial stdio \ -fsdev local,id=root,path=$dir,security_model=none \ -device virtio-9p-device,fsdev=root,mount_tag=/dev/root -monitor none Christopher -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] QEMU dies on any attempt to load a Linux kernel module when using a 9P rootfs
Hi Richard, On 11/25/2013 10:49 AM, Richard Yao wrote: I booted a Gentoo Linux installation in QEMU with a 9P rootfs as follows: sudo qemu-kvm -cpu host -m 1024 -kernel /mnt/test/usr/src/linux-3.13-rc1/arch/x86/boot/bzImage -append 'root=/dev/root rootfstype=9p rootflags=trans=virtio,version=9p2000.L ro console=ttyS0' -serial stdio -fsdev local,id=root,path=/mnt/test,security_model=none -device virtio-9p-pci,fsdev=root,mount_tag=/dev/root The system boots fine, but attempting to load any module will fail: localhost ~ # modprobe crc32 qemu-system-x86_64: virtio: trying to map MMIO memory The behavior is consistent no matter what combination of things that I try. So far, I have tried Linux 3.10.7-gentoo (Gentoo patchset) and Linux 3.13-rc1. I have tried QEMU 1.4.2, QEMU 1.6.1 and QEMU HEAD. I have also tried booting without KVM, but the behavior is the same: sudo qemu-kvm --no-kvm -m 1024 -kernel /mnt/test/usr/src/linux-3.13-rc1/arch/x86/boot/bzImage -append 'root=/dev/root rootfstype=9p rootflags=trans=virtio,version=9p2000.L ro console=ttyS0' -serial stdio -fsdev local,id=root,path=/mnt/test,security_model=none -device virtio-9p-pci,fsdev=root,mount_tag=/dev/root Have you used this setup recently? With my 3.15.0+ kernel, qemu-system-x86_64 substituted for qemu-kvm, and the path changed from your arguments I get: 9pnet_virtio: no channels available VFS: Cannot open root device root or unknown-block(0,0): error -2 Please append a correct root= boot option; here are the available partitions: 0b00 1048575 sr0 driver: sr Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 Thanks, Christopher -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: QEMU dies on any attempt to load a Linux kernel module when using a 9P rootfs
Hi Richard, On 11/25/2013 04:50 PM, Richard Yao wrote: I figured out the problem. There is zerocopy IO is being done via DMA to a buffer allocated with valloc(). Right now, I am running a hack-fix locally so I can get some other stuff done first. I will propose a proper fix to the list in a few days. I've also encountered this issue on a non-QEMU simulator and have been carrying a disable-zero-copy hack for a few months. Let me know if there's anything I can help with. Christopher -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: what should a virtio-mmio transport without a backend look like?
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 that does nothing. I'm saying why not use a valid/existing MagicValue/Version/VendorID/DeviceID with a special parameter setting, size=0, that does nothing? [...] Also, it's mixing a detail of the backend layer (what a zero-sized disk happens to look like) with the transport layer, which seems a bit ugly spec-wise. I don't think that has to be the case. From what I understand of your architecture, the device layer is completely opaque to the transport layer, and the transport layer is immutable, but surely the device layer will at least know how many transports are available? As long as that's true, can't the device layer just create real devices and hook them up to transports, and then create no-op devices and hook them up to any remaining transports? (Implementation wise I'm not crazy about it either since it would be way more complicated than saying no backend? OK, RAZ/WI.) (I thought virtio block devices were already implemented.) Christopher -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: what should a virtio-mmio transport without a backend look like?
Hi Peter, On 06/21/2013 11:23 AM, Peter Maydell wrote: 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 always some backend present. (The idea is that QEMU might just always instantiate say 8 mmio transports, and then whether they actually have a blk/net/whatever backend depends on user options). Might it be reasonably easy to just not enumerate unused transports in the device tree or kernel parameters? At least for QEMU, the backend that plugs into the transport isn't created until after the machine model has created transports and put together the device tree blob. So we don't really have the information about what devices are going to appear at the point we're doing this. Would using CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES enumeration instead of device tree be any easier? How does the back end know which devices to create? Thanks, Christopher -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: what should a virtio-mmio transport without a backend look like?
On 06/21/2013 02:28 PM, Peter Maydell wrote: 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. I'm confused -- what's the significance of zero size block devices? 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 does nothing? Christopher -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: what should a virtio-mmio transport without a backend look like?
Hi Peter, On 06/20/2013 07:08 AM, Pawel Moll wrote: On Thu, 2013-06-20 at 11:29 +0100, Peter Maydell wrote: I'm (finally) trying to add virtio-mmio support properly to QEMU now Fred has put all the refactoring foundations in place. 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 always some backend present. (The idea is that QEMU might just always instantiate say 8 mmio transports, and then whether they actually have a blk/net/whatever backend depends on user options). It looks as if the current linux driver insists (if it sees a device tree node) that the MagicValue register at least is correct (otherwise it complains). So one possibility would be MagicValue/Version/VendorID must read as usual, DeviceID should read as some special nothing here value (0?), everything else can RAZ/WI. Might it be reasonably easy to just not enumerate unused transports in the device tree or kernel parameters? Regards, Christopher -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
