Re: [pciutils patch v2] add virtio vendor capability support
Hi! virtio uses vendor-specific capabilities to specify the location of the virtio register ranges. The specification can be found here: http://docs.oasis-open.org/virtio/virtio/v1.0/cs01/virtio-v1.0-cs01.html#x1-690004 This patch adds support for decoding these capabilities to lspci. Thanks, applied. One more request: could you please provide a hexdump (lspci -vxxx) of a virtio device as a test case? Martin ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [pciutils patch v2] add virtio vendor capability support
Attached is a dump of a virtio-net device (both verbose=2 and hex). Thanks! I have cleaned up the code a little, could you please check that it still works for you? Martin ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 08/16] mn10300: drop dead code
On Wed, Jan 14, 2015 at 07:27:48PM +0200, Michael S. Tsirkin wrote:
pci-iomap.c was (apparently, mistakenly) reintroduced as part of
commit 83c2dc15ce824450e7044b9f90cd529c25747ae0
MN10300: Handle cacheable PCI regions in pci_iomap()
probably as side-effect of forward-porting the patch
from an old kernel.
It's not really needed: the generic pci_iomap does the right thing here.
The new file isn't compiled so it's safe to drop.
Cc: Bjorn Helgaas bhelg...@google.com
Cc: linux-...@vger.kernel.org
Cc: triv...@kernel.org
Cc: David Howells dhowe...@redhat.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Acked-by: Bjorn Helgaas bhelg...@google.com
---
Can relevant people please ack this for merging through virtio tree?
arch/mn10300/unit-asb2305/pci-iomap.c | 35
---
1 file changed, 35 deletions(-)
delete mode 100644 arch/mn10300/unit-asb2305/pci-iomap.c
diff --git a/arch/mn10300/unit-asb2305/pci-iomap.c
b/arch/mn10300/unit-asb2305/pci-iomap.c
deleted file mode 100644
index bd65dae..000
--- a/arch/mn10300/unit-asb2305/pci-iomap.c
+++ /dev/null
@@ -1,35 +0,0 @@
-/* ASB2305 PCI I/O mapping handler
- *
- * Copyright (C) 2007 Red Hat, Inc. All Rights Reserved.
- * Written by David Howells (dhowe...@redhat.com)
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public Licence
- * as published by the Free Software Foundation; either version
- * 2 of the Licence, or (at your option) any later version.
- */
-#include linux/pci.h
-#include linux/module.h
-
-/*
- * Create a virtual mapping cookie for a PCI BAR (memory or IO)
- */
-void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long maxlen)
-{
- resource_size_t start = pci_resource_start(dev, bar);
- resource_size_t len = pci_resource_len(dev, bar);
- unsigned long flags = pci_resource_flags(dev, bar);
-
- if (!len || !start)
- return NULL;
-
- if ((flags IORESOURCE_IO) || (flags IORESOURCE_MEM)) {
- if (flags IORESOURCE_CACHEABLE !(flags IORESOURCE_IO))
- return ioremap(start, len);
- else
- return ioremap_nocache(start, len);
- }
-
- return NULL;
-}
-EXPORT_SYMBOL(pci_iomap);
--
MST
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 09/16] pci: add pci_iomap_range
On Wed, Jan 14, 2015 at 07:27:54PM +0200, Michael S. Tsirkin wrote:
Virtio drivers should map the part of the BAR they need, not necessarily
all of it.
Cc: Bjorn Helgaas bhelg...@google.com
Cc: linux-...@vger.kernel.org
Acked-by: Arnd Bergmann a...@arndb.de
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
Acked-by: Bjorn Helgaas bhelg...@google.com
Sorry it took so long for me to notice these!
---
Bjorn, can you please ack this for merging through the virtio tree?
include/asm-generic/pci_iomap.h | 10 ++
lib/pci_iomap.c | 35 ++-
2 files changed, 40 insertions(+), 5 deletions(-)
diff --git a/include/asm-generic/pci_iomap.h b/include/asm-generic/pci_iomap.h
index ce37349..7389c87 100644
--- a/include/asm-generic/pci_iomap.h
+++ b/include/asm-generic/pci_iomap.h
@@ -15,6 +15,9 @@ struct pci_dev;
#ifdef CONFIG_PCI
/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */
extern void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long
max);
+extern void __iomem *pci_iomap_range(struct pci_dev *dev, int bar,
+ unsigned long offset,
+ unsigned long maxlen);
/* Create a virtual mapping cookie for a port on a given PCI device.
* Do not call this directly, it exists to make it easier for architectures
* to override */
@@ -30,6 +33,13 @@ static inline void __iomem *pci_iomap(struct pci_dev *dev,
int bar, unsigned lon
{
return NULL;
}
+
+static inline void __iomem *pci_iomap_range(struct pci_dev *dev, int bar,
+ unsigned long offset,
+ unsigned long maxlen)
+{
+ return NULL;
+}
#endif
#endif /* __ASM_GENERIC_IO_H */
diff --git a/lib/pci_iomap.c b/lib/pci_iomap.c
index 0d83ea8..bcce5f1 100644
--- a/lib/pci_iomap.c
+++ b/lib/pci_iomap.c
@@ -10,10 +10,11 @@
#ifdef CONFIG_PCI
/**
- * pci_iomap - create a virtual mapping cookie for a PCI BAR
+ * pci_iomap_range - create a virtual mapping cookie for a PCI BAR
* @dev: PCI device that owns the BAR
* @bar: BAR number
- * @maxlen: length of the memory to map
+ * @offset: map memory at the given offset in BAR
+ * @maxlen: max length of the memory to map
*
* Using this function you will get a __iomem address to your device BAR.
* You can access it using ioread*() and iowrite*(). These functions hide
@@ -21,16 +22,21 @@
* you expect from them in the correct way.
*
* @maxlen specifies the maximum length to map. If you want to get access to
- * the complete BAR without checking for its length first, pass %0 here.
+ * the complete BAR from offset to the end, pass %0 here.
* */
-void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long maxlen)
+void __iomem *pci_iomap_range(struct pci_dev *dev,
+ int bar,
+ unsigned long offset,
+ unsigned long maxlen)
{
resource_size_t start = pci_resource_start(dev, bar);
resource_size_t len = pci_resource_len(dev, bar);
unsigned long flags = pci_resource_flags(dev, bar);
- if (!len || !start)
+ if (len = offset || !start)
return NULL;
+ len -= offset;
+ start += offset;
if (maxlen len maxlen)
len = maxlen;
if (flags IORESOURCE_IO)
@@ -43,6 +49,25 @@ void __iomem *pci_iomap(struct pci_dev *dev, int bar,
unsigned long maxlen)
/* What? */
return NULL;
}
+EXPORT_SYMBOL(pci_iomap_range);
+/**
+ * pci_iomap - create a virtual mapping cookie for a PCI BAR
+ * @dev: PCI device that owns the BAR
+ * @bar: BAR number
+ * @maxlen: length of the memory to map
+ *
+ * Using this function you will get a __iomem address to your device BAR.
+ * You can access it using ioread*() and iowrite*(). These functions hide
+ * the details if this is a MMIO or PIO address space and will just do what
+ * you expect from them in the correct way.
+ *
+ * @maxlen specifies the maximum length to map. If you want to get access to
+ * the complete BAR without checking for its length first, pass %0 here.
+ * */
+void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long maxlen)
+{
+ return pci_iomap_range(dev, bar, 0, maxlen);
+}
EXPORT_SYMBOL(pci_iomap);
#endif /* CONFIG_PCI */
--
MST
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
CISTI'2015 - List of Workshops - 10th Iberian Conference on Information Systems and Technologies
CISTI'2015 10th Iberian Conference on Information Systems and Technologies 17 - 20 June 2015, Aveiro, Portugal http://www.aisti.eu/cisti2015/index.php/en List of CISTI'2015 Workshops: http://www.aisti.eu/cisti2015/index.php/en/xpto ASDACS 2015 - 2nd Workshop on Applied Statistics and Data Analysis using Computer Science SPIoY 2015 - 1st Workshop on Security and Privacy in the Internet Of You WCBIPA 2015 - 2nd Workshop on Computational Biomedical Image Processing and Analysis WCJSN 2015 - 1st Workshop on Communication and Journalism in Social Networks WGICT 2015 - 1st Workshop on Gerontechnology: ICT in the improvement of the quality of life of the elderly WISA 2015 - 7th Workshop on Intelligent Systems and Applications WICTA 2015 - 2nd International Workshop on ICT for Auditing WGSP 2015 - 1st Workshop on Gaming, Simulation and Play ICTWays 2015 - 2nd Workshop on Best Practices on ICT Ways in the classrooms URL: http://www.aisti.eu/cisti2015/index.php/en/xpto CISTI'2015 Team http://www.aisti.eu/cisti2015/index.php/en ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] [PATCH RFC v6 06/20] virtio: endianness checks for virtio 1.0 devices
On Thu, 22 Jan 2015 12:54:09 +1100
David Gibson da...@gibson.dropbear.id.au wrote:
On Thu, Dec 11, 2014 at 02:25:08PM +0100, Cornelia Huck wrote:
Add code that checks for the VERSION_1 feature bit in order to make
decisions about the device's endianness. This allows us to support
transitional devices.
Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com
---
hw/virtio/virtio.c|6 +-
include/hw/virtio/virtio-access.h |4
include/hw/virtio/virtio.h|8 ++--
3 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 7f74ae5..8f69ffa 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -881,7 +881,11 @@ static bool virtio_device_endian_needed(void *opaque)
VirtIODevice *vdev = opaque;
assert(vdev-device_endian != VIRTIO_DEVICE_ENDIAN_UNKNOWN);
-return vdev-device_endian != virtio_default_endian();
+if (!virtio_has_feature(vdev, VIRTIO_F_VERSION_1)) {
+return vdev-device_endian != virtio_default_endian();
+}
+/* Devices conforming to VIRTIO 1.0 or later are always LE. */
+return vdev-device_endian != VIRTIO_DEVICE_ENDIAN_LITTLE;
This doesn't seem quite right. Since virtio 1.0 is always LE, this
should just assert that device_endian == LE and return false,
right?
The device_endian field is ONLY used by devices when the software is
legacy.
It is set at device reset time (see virtio_reset()) since we can reasonably
assume that when the software changes endianness, it always reset the device
before using it again (aka. reboot or kexec).
In the case we would have a BE guest, device_endian would be BE, even if the
software is virtio 1.0. So, no, we shouldn't assert.
I had questioned Cornelia about why we care to migrate device_endian when in
virtio 1.0 mode. I got these answers:
https://lists.nongnu.org/archive/html/qemu-devel/2014-10/msg03979.html
https://lists.nongnu.org/archive/html/qemu-devel/2014-11/msg03888.html
My understanding is that a transitional device will necessarily be reset
if the software changes from legacy to 1.0 or vice-versa. So, yes, I still
think virtio_device_endian_needed() should return false.
}
static const VMStateDescription vmstate_virtio_device_endian = {
diff --git a/include/hw/virtio/virtio-access.h
b/include/hw/virtio/virtio-access.h
index 46456fd..ee28c21 100644
--- a/include/hw/virtio/virtio-access.h
+++ b/include/hw/virtio/virtio-access.h
@@ -19,6 +19,10 @@
static inline bool virtio_access_is_big_endian(VirtIODevice *vdev)
{
+if (virtio_has_feature(vdev, VIRTIO_F_VERSION_1)) {
+/* Devices conforming to VIRTIO 1.0 or later are always LE. */
+return false;
+}
#if defined(TARGET_IS_BIENDIAN)
return virtio_is_big_endian(vdev);
#elif defined(TARGET_WORDS_BIGENDIAN)
diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
index 08141c7..68c40db 100644
--- a/include/hw/virtio/virtio.h
+++ b/include/hw/virtio/virtio.h
@@ -297,7 +297,11 @@ static inline bool virtio_has_feature(VirtIODevice
*vdev, unsigned int fbit)
static inline bool virtio_is_big_endian(VirtIODevice *vdev)
{
-assert(vdev-device_endian != VIRTIO_DEVICE_ENDIAN_UNKNOWN);
-return vdev-device_endian == VIRTIO_DEVICE_ENDIAN_BIG;
+if (!virtio_has_feature(vdev, VIRTIO_F_VERSION_1)) {
+assert(vdev-device_endian != VIRTIO_DEVICE_ENDIAN_UNKNOWN);
+return vdev-device_endian == VIRTIO_DEVICE_ENDIAN_BIG;
+}
+/* Devices conforming to VIRTIO 1.0 or later are always LE. */
+return false;
}
#endif
AFAICT, the only real difference between virtio_is_big_endian() and
virtio_access_is_big_endian() is that the latter will become
compile-time constant on targets that don't do bi-endian.
With virtio 1.0 support, that's no longer true, so those two macros
should just be merged, I think.
pgp8Kc3xUSH86.pgp
Description: OpenPGP digital signature
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
