On 07/31/2012 01:29 AM, Alex Williamson wrote:
If the region size is zero, then both memory_region_del_subregion()
(assuming the region is parented) and munmap() do nothing. So you could
call this unconditionally.
I suppose parenting them is the key. I'm counting on memory_region_size
On Tue, 2012-07-31 at 15:34 +0300, Avi Kivity wrote:
On 07/31/2012 01:29 AM, Alex Williamson wrote:
If the region size is zero, then both memory_region_del_subregion()
(assuming the region is parented) and munmap() do nothing. So you could
call this unconditionally.
I suppose
On Sun, 2012-07-29 at 16:47 +0300, Avi Kivity wrote:
On 07/26/2012 08:40 PM, Alex Williamson wrote:
On Thu, 2012-07-26 at 19:34 +0300, Avi Kivity wrote:
On 07/25/2012 08:03 PM, Alex Williamson wrote:
+/*
+ * Resource setup
+ */
+static void vfio_unmap_bar(VFIODevice *vdev, int
On 07/26/2012 08:40 PM, Alex Williamson wrote:
On Thu, 2012-07-26 at 19:34 +0300, Avi Kivity wrote:
On 07/25/2012 08:03 PM, Alex Williamson wrote:
+/*
+ * Resource setup
+ */
+static void vfio_unmap_bar(VFIODevice *vdev, int nr)
+{
+VFIOBAR *bar = vdev-bars[nr];
+uint64_t
On Fri, 2012-07-27 at 19:22 +, Blue Swirl wrote:
On Wed, Jul 25, 2012 at 5:03 PM, Alex Williamson
diff --git a/hw/vfio_pci.c b/hw/vfio_pci.c
new file mode 100644
index 000..e9ae421
--- /dev/null
+++ b/hw/vfio_pci.c
@@ -0,0 +1,2030 @@
+/*
+ * vfio based device assignment
On 28/07/12 05:22, Blue Swirl wrote:
On Wed, Jul 25, 2012 at 5:03 PM, Alex Williamson
+
+static void vfio_enable_intx_kvm(VFIODevice *vdev)
+{
+#ifdef CONFIG_KVM
These shouldn't be needed. The device will not be useful without KVM,
so the file shouldn't be compiled for non-KVM case at all.
On 07/25/2012 10:53 PM, Alex Williamson wrote:
On Wed, 2012-07-25 at 22:30 +0300, Avi Kivity wrote:
On 07/25/2012 08:03 PM, Alex Williamson wrote:
This adds PCI based device assignment to Qemu using the Linux VFIO
userspace driver interface. After setting up VFIO device access,
devices
On Thu, 2012-07-26 at 11:35 +0300, Avi Kivity wrote:
On 07/25/2012 10:53 PM, Alex Williamson wrote:
On Wed, 2012-07-25 at 22:30 +0300, Avi Kivity wrote:
On 07/25/2012 08:03 PM, Alex Williamson wrote:
This adds PCI based device assignment to Qemu using the Linux VFIO
userspace driver
On Wed, 2012-07-25 at 11:03 -0600, Alex Williamson wrote:
This adds PCI based device assignment to Qemu using the Linux VFIO
userspace driver interface. After setting up VFIO device access,
devices can be added to Qemu guests using the vfio-pci device
option:
-device
On 07/26/2012 05:56 PM, Alex Williamson wrote:
Let's use the same syntax as for kvm device assignment. Then we can
fall back on kvm when vfio is not available. We can also have an
optional parameter kernel-driver to explicitly select vfio or kvm.
This seems confusing to me, pci-assign
On 07/26/2012 05:56 PM, Alex Williamson wrote:
Both KVM and VFIO do strive to make the device in the guest look as much
like it does on bare metal as possible, but we don't guarantee they're
identical and we don't guarantee to match each other.
btw, this is somewhat problematic, conceivably
On 07/25/2012 08:03 PM, Alex Williamson wrote:
+/*
+ * Resource setup
+ */
+static void vfio_unmap_bar(VFIODevice *vdev, int nr)
+{
+VFIOBAR *bar = vdev-bars[nr];
+uint64_t size;
+
+if (!memory_region_size(bar-mem)) {
+return;
+}
+
+size =
On Thu, 2012-07-26 at 18:59 +0300, Avi Kivity wrote:
On 07/26/2012 05:56 PM, Alex Williamson wrote:
Let's use the same syntax as for kvm device assignment. Then we can
fall back on kvm when vfio is not available. We can also have an
optional parameter kernel-driver to explicitly select
On Thu, 2012-07-26 at 19:34 +0300, Avi Kivity wrote:
On 07/25/2012 08:03 PM, Alex Williamson wrote:
+/*
+ * Resource setup
+ */
+static void vfio_unmap_bar(VFIODevice *vdev, int nr)
+{
+VFIOBAR *bar = vdev-bars[nr];
+uint64_t size;
+
+if
On 07/26/2012 07:40 PM, Alex Williamson wrote:
On Thu, 2012-07-26 at 19:06 +0300, Avi Kivity wrote:
On 07/26/2012 05:56 PM, Alex Williamson wrote:
Both KVM and VFIO do strive to make the device in the guest look as much
like it does on bare metal as possible, but we don't guarantee
On Thu, 2012-07-26 at 19:06 +0300, Avi Kivity wrote:
On 07/26/2012 05:56 PM, Alex Williamson wrote:
Both KVM and VFIO do strive to make the device in the guest look as much
like it does on bare metal as possible, but we don't guarantee they're
identical and we don't guarantee to match
On 07/26/2012 07:33 PM, Alex Williamson wrote:
In the common case, on x86 (but I'm repeating myself), the iommu group
includes just one device, yes? Could we make pci-stub an alias for the
corresponding vfio steps?
PCI bridges masking devices is not as uncommon as you'd like, that's
On Thu, 2012-07-26 at 19:40 +0300, Avi Kivity wrote:
On 07/26/2012 07:33 PM, Alex Williamson wrote:
In the common case, on x86 (but I'm repeating myself), the iommu group
includes just one device, yes? Could we make pci-stub an alias for the
corresponding vfio steps?
PCI bridges
On 07/25/2012 08:03 PM, Alex Williamson wrote:
This adds PCI based device assignment to Qemu using the Linux VFIO
userspace driver interface. After setting up VFIO device access,
devices can be added to Qemu guests using the vfio-pci device
option:
-device vfio-pci,host=1:10.1,id=net0
On Wed, 2012-07-25 at 22:30 +0300, Avi Kivity wrote:
On 07/25/2012 08:03 PM, Alex Williamson wrote:
This adds PCI based device assignment to Qemu using the Linux VFIO
userspace driver interface. After setting up VFIO device access,
devices can be added to Qemu guests using the vfio-pci
20 matches
Mail list logo
