--- a/src/udev/ata_id/ata_id.c
+++ b/src/udev/ata_id/ata_id.c
@@ -485,6 +485,10 @@ int main(int argc, char *argv[])
disk_identify_fixup_uint16(identify.byte, 90); /*
time required for enhanced SECURITY ERASE UNIT */
disk_identify_fixup_uint16(identify.byte,
Virtiio_mmio attempts to mimic the layout of some control registers from
virtio_pci. These registers, in particular VIRTIO_MMIO_QUEUE_SEL and
VIRTIO_PCI_QUEUE_SEL,
are active in nature, and not just passive like a normal memory
location. Thus, the host side must react immediately upon write
On 05/01/2013 10:25 PM, Michael S. Tsirkin wrote:
On Wed, May 01, 2013 at 08:40:54PM -0700, Tom Lyon wrote:
Virtiio_mmio attempts to mimic the layout of some control registers
from virtio_pci. These registers, in particular
VIRTIO_MMIO_QUEUE_SEL and VIRTIO_PCI_QUEUE_SEL,
are active in nature
On 05/02/2013 04:37 AM, Pawel Moll wrote:
Hi Tom,
On Thu, 2013-05-02 at 04:40 +0100, Tom Lyon wrote:
Virtiio_mmio attempts to mimic the layout of some control registers from
virtio_pci. These registers, in particular VIRTIO_MMIO_QUEUE_SEL and
VIRTIO_PCI_QUEUE_SEL,
are active in nature
On 05/01/2013 10:25 PM, Michael S. Tsirkin wrote:
On Wed, May 01, 2013 at 08:40:54PM -0700, Tom Lyon wrote:
Virtiio_mmio attempts to mimic the layout of some control registers
from virtio_pci. These registers, in particular
VIRTIO_MMIO_QUEUE_SEL and VIRTIO_PCI_QUEUE_SEL,
are active in nature
On 05/02/2013 04:37 AM, Pawel Moll wrote:
Hi Tom,
On Thu, 2013-05-02 at 04:40 +0100, Tom Lyon wrote:
Virtiio_mmio attempts to mimic the layout of some control registers from
virtio_pci. These registers, in particular VIRTIO_MMIO_QUEUE_SEL and
VIRTIO_PCI_QUEUE_SEL,
are active in nature
Virtiio_mmio attempts to mimic the layout of some control registers from
virtio_pci. These registers, in particular VIRTIO_MMIO_QUEUE_SEL and
VIRTIO_PCI_QUEUE_SEL,
are active in nature, and not just passive like a normal memory
location. Thus, the host side must react immediately upon write
On Friday, April 29, 2011 03:05:54 pm Alex Williamson wrote:
This is allocated via vmalloc, so needs vfree, not kfree.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
drivers/vfio/vfio_dma.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
On Tuesday, April 19, 2011 01:32:59 pm Alex Williamson wrote:
When using VFIO to assign a device to a guest, we want to make sure
the device is quiesced on VM reset to stop all DMA within the guest
mapped memory. Add an ioctl which just calls pci_reset_function()
and returns whether it
, 2010-12-21 at 16:29 +1100, Benjamin Herrenschmidt wrote:
On Mon, 2010-11-22 at 15:21 -0800, Tom Lyon wrote:
VFIO driver development has moved to a publicly accessible
respository
on github:
git://github.com/pugs/vfio-linux-2.6.git
This is a clone of the Linux-2.6 tree
eom
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
VFIO driver development has moved to a publicly accessible respository
on github:
git://github.com/pugs/vfio-linux-2.6.git
This is a clone of the Linux-2.6 tree with all VFIO changes on the vfio
branch (which is the default). There is a tag 'vfio-v6' marking the latest
release of VFIO.
Applied.
On Tuesday, November 16, 2010 10:57:27 am Alex Williamson wrote:
On Tue, 2010-11-16 at 10:54 -0700, Alex Williamson wrote:
On Tue, 2010-11-09 at 17:09 -0800, Tom Lyon wrote:
Cleans up config space virtualization, especialy handling of bytes
which have some virtual and some real
Alex - I am rejecting these 2 patches.
For patch 1/2, I started with yours and found a couple of problems, but then I
got into the spirit and did a buinch more cleaning up. My patch to follow.
For patch 2/2, the INTX stuff, I don't really see the problem. If the user
turns on the bit, it'll
Cleans up config space virtualization, especialy handling of bytes
which have some virtual and some real bits, like PCI_COMMAND.
Alex, I hope you can test this with your setups.
Signed-off-by: Tom Lyon p...@cisco.com
---
drivers/vfio/vfio_pci_config.c | 166
Applied.
On Wednesday, November 03, 2010 01:17:33 pm Alex Williamson wrote:
Trying to be too clever with setting the irq_disabled flag. PCI 2.3
disabled devices can still share IRQs, which can lead to clearing
the irq_disabled flag, preventing the EOI from registering, and leaving
the device
Applied. Thanks!
On Monday, November 01, 2010 10:08:35 pm Alex Williamson wrote:
- Virtual channel position gets truncated as a u8
- Print the ecap that's unknown, not the last cap we saw
- Print actual config offset, which provides enough info to make
some sense of the error.
I've applied all your patches. Thanks!
On Saturday, October 30, 2010 09:58:55 am Alex Williamson wrote:
Hi Tom,
I've updated some patches I've been working on to v5 and wanted to
see what you think. I also found a couple minor bugs, fixed in this
series.
The main idea is that since the
- but that will take time.
Tom Lyon (4):
VFIO V5: export pci_user_{read,write}_config
VFIO V5: additions to include/linux/pci_regs.h
VFIO V5: uiommu driver - allow user progs to manipulate iommu domains
VFIO V5: Non-privileged user level PCI drivers
Documentation/ioctl/ioctl-number.txt |1
Acked-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Tom Lyon p...@cisco.com
---
drivers/pci/access.c |6 --
drivers/pci/pci.h|7 ---
include/linux/pci.h |8
3 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/pci/access.c b
Signed-off-by: Tom Lyon p...@cisco.com
---
drivers/Kconfig|2 +
drivers/Makefile |1 +
drivers/vfio/Kconfig |8 +++
drivers/vfio/Makefile |1 +
drivers/vfio/uiommu.c | 126
include/linux/uiommu.h | 76
Signed-off-by: Tom Lyon p...@cisco.com
---
include/linux/pci_regs.h | 107 ++
1 files changed, 98 insertions(+), 9 deletions(-)
diff --git a/include/linux/pci_regs.h b/include/linux/pci_regs.h
index 455b9cc..70addc9 100644
--- a/include/linux
Michael Alex et al -
Sorry for going quiet; I've been digesting the comments and researching
a
lot more stuff. I plan to release V5 shortly after 2.6.36 is out, highlights
will be:
1. Re-written pci config tables - using approach suggested by MST to clean
things up. Looking much
On Monday, September 27, 2010 04:54:21 am Michael S. Tsirkin wrote:
On Wed, Sep 22, 2010 at 02:18:24PM -0700, Tom Lyon wrote:
Signed-off-by: Tom Lyon p...@cisco.com
Some comments on the pci bits:
After going over them for the Nth time - something needs to be done
with the rvirt/write
- but that will take time.
Tom Lyon (3):
VFIO V4: export pci_user_{read,write}_config
VFIO V4: uiommu driver - allow user progs to manipulate iommu domains
VFIO V4: VFIO driver: Non-privileged user level PCI drivers
Documentation/ioctl/ioctl-number.txt |1 +
Documentation/vfio.txt
Signed-off-by: Tom Lyon p...@cisco.com
---
drivers/pci/access.c |6 --
drivers/pci/pci.h|7 ---
include/linux/pci.h |8
3 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/pci/access.c b/drivers/pci/access.c
index 531bc69..96ed449 100644
Signed-off-by: Tom Lyon p...@cisco.com
---
drivers/Kconfig|2 +
drivers/Makefile |1 +
drivers/vfio/Kconfig |8 +++
drivers/vfio/Makefile |1 +
drivers/vfio/uiommu.c | 126
include/linux/uiommu.h | 76
On Tuesday, July 27, 2010 04:53:22 pm Michael S. Tsirkin wrote:
On Tue, Jul 27, 2010 at 03:13:14PM -0700, Tom Lyon wrote:
[ Sorry for the long hiatus, I've been wrapped up in other issues.]
I think the fundamental issue to resolve is to decide on the model which
the VFIO driver presents
[ Sorry for the long hiatus, I've been wrapped up in other issues.]
I think the fundamental issue to resolve is to decide on the model which the
VFIO driver presents to its users.
Fundamentally, VFIO as part of the OS must protect the system from its users
and also protect the users from each
On Friday 02 July 2010 02:26:46 am Roedel, Joerg wrote:
On Thu, Jul 01, 2010 at 05:24:32PM -0400, Tom Lyon wrote:
This patch allows IOMMU users to determine whether the hardware and software
support safe, isolated interrupt remapping. Not all Intel IOMMUs have the
hardware
This patch allows IOMMU users to determine whether the hardware and software
support safe, isolated interrupt remapping. Not all Intel IOMMUs have the
hardware, and the software for AMD is not there yet.
Signed-off-by: Tom Lyon p...@cisco.com
---
Version 3: shorter name requested by Joerg
On Thursday 01 July 2010 08:48:41 am Alex Williamson wrote:
On Thu, 2010-07-01 at 18:31 +0300, Michael S. Tsirkin wrote:
On Thu, Jul 01, 2010 at 09:29:04AM -0600, Alex Williamson wrote:
On Tue, 2010-06-08 at 14:21 -0700, Tom Lyon wrote:
+The VFIO_DMA_MASK ioctl is used to set the maximum
This patch allows IOMMU users to determine whether the hardware and software
support safe, isolated interrupt remapping. Not all Intel IOMMUs have the
hardware, and the software for AMD is not there yet.
Signed-off-by: Tom Lyon p...@cisco.com
---
Version 2: previous ifdefs not needed
Thanks, Alex!
Am incorporating...
On Tuesday 29 June 2010 11:14:12 pm Alex Williamson wrote:
On Tue, 2010-06-08 at 14:21 -0700, Tom Lyon wrote:
The VFIO driver is used to allow privileged AND non-privileged processes
to
implement user-level device drivers for any well-behaved PCI, PCI-X
On Wednesday 30 June 2010 03:32:56 pm Michael S. Tsirkin wrote:
On Wed, Jun 30, 2010 at 03:17:55PM -0700, Tom Lyon wrote:
Thanks, Alex!
Am incorporating...
I get it there's no chance you'll drop the virtualization
from the driver then?
I think it'll get a whole lot simpler by depending
This patch allows IOMMU users to determine whether the hardware and software
support safe, isolated interrupt remapping. Not all Intel IOMMUs have the
hardware, and the software for AMD is not there yet.
Signed-off-by: Tom Lyon p...@cisco.com
---
MST has convinced me that any user level
On Wednesday 30 June 2010 09:16:23 pm Alex Williamson wrote:
On Tue, 2010-06-08 at 14:21 -0700, Tom Lyon wrote:
+int vfio_dma_unmap_dm(struct vfio_listener *listener, struct vfio_dma_map
*dmp)
+{
+ unsigned long start, npage;
+ struct dma_map_page *mlp;
+ struct list_head *pos
On Sunday 13 June 2010 03:23:39 am Michael S. Tsirkin wrote:
On Fri, Jun 11, 2010 at 03:15:53PM -0700, Tom Lyon wrote:
[ bunch of stuff about MSI-X checking and IOMMUs and config registers...]
OK, here's the thing. The IOMMU API today does not do squat about
dealing with interrupts
The inline comments are getting pretty hard to wade through, so I'm deleting
some
of the lesser stuff - but I am incorporating into the code.
On Tuesday 08 June 2010 10:45:57 pm Michael S. Tsirkin wrote:
On Tue, Jun 08, 2010 at 04:54:43PM -0700, Tom Lyon wrote:
On Tuesday 08 June 2010 03:38
On Thursday 10 June 2010 10:27:36 am Konrad Rzeszutek Wilk wrote:
+EXPORT_SYMBOL(uiommu_fdget);
EXPORT_SYMBOL_GPL
.. snip
+EXPORT_SYMBOL(uiommu_put);
ditto.
Is there a definitive explanation somewhere of when to use each?
--
To unsubscribe from this list: send the line unsubscribe
On Tuesday 08 June 2010 03:38:44 pm Michael S. Tsirkin wrote:
On Tue, Jun 08, 2010 at 02:21:52PM -0700, Tom Lyon wrote:
The VFIO driver is used to allow privileged AND non-privileged processes
to
implement user-level device drivers for any well-behaved PCI, PCI-X, and
PCIe
devices
On Sunday 06 June 2010 02:54:51 am Michael S. Tsirkin wrote:
On Thu, Jun 03, 2010 at 02:41:38PM -0700, Tom Lyon wrote:
OK, in the interest of making progress, I am about to embark on the
following:
1. Create a user-iommu-domain driver - opening it will give a new empty
domain
OK, in the interest of making progress, I am about to embark on the following:
1. Create a user-iommu-domain driver - opening it will give a new empty domain.
Ultimately this can also populate sysfs with the state of its world, which
would
also be a good addition to the base iommu stuff.
On Wednesday 02 June 2010 10:46:15 am Chris Wright wrote:
* Joerg Roedel (j...@8bytes.org) wrote:
On Wed, Jun 02, 2010 at 02:21:00PM +0300, Michael S. Tsirkin wrote:
On Wed, Jun 02, 2010 at 01:12:25PM +0200, Joerg Roedel wrote:
Even if it is bound to a domain the userspace driver
On Tuesday 01 June 2010 03:46:51 am Michael S. Tsirkin wrote:
On Tue, Jun 01, 2010 at 01:28:48PM +0300, Avi Kivity wrote:
On 06/01/2010 12:55 PM, Michael S. Tsirkin wrote:
It can't program the iommu.
What
the patch proposes is that userspace tells vfio about the needed
mappings, and
On Monday 31 May 2010 10:17:35 am Alan Cox wrote:
Does look like it needs a locking audit, some memory and error checks
reviewing and some further review of the ioctl security and
overflows/trusted values.
Yes. Thanks for the detailed look.
Rather a nice way of attacking the user space PCI
On Tuesday 01 June 2010 09:29:47 pm Alex Williamson wrote:
On Tue, 2010-06-01 at 13:28 +0300, Avi Kivity wrote:
On 06/01/2010 12:55 PM, Michael S. Tsirkin wrote:
It can't program the iommu.
What
the patch proposes is that userspace tells vfio about the needed
mappings, and vfio
- but see my inline comments below.
On Wednesday 21 April 2010 02:38:49 am Michael S. Tsirkin wrote:
On Mon, Apr 19, 2010 at 03:05:35PM -0700, Tom Lyon wrote:
These are changes to uio_pci_generic.c to allow better use of the driver by
non-privileged processes.
1. Add back old code which
, but not IRQ.
Signed-off-by: Tom Lyon p...@cisco.com
---
checkpatch.pl is happy with this one.
--- linux-2.6.33/drivers/uio/uio_pci_generic.c 2010-02-24 10:52:17.0
-0800
+++ mylinux-2.6.33/drivers/uio/uio_pci_generic.c2010-04-19
14:57:21.0 -0700
@@ -14,9 +14,10
The current uio and uio_pci_generic allow multiple opens; I was just preserving
that behavior.
On Saturday 17 April 2010 03:43:09 am Joerg Roedel wrote:
On Thu, Apr 15, 2010 at 01:55:29PM -0700, Tom Lyon wrote:
+ down(idev-gate);
+ if (idev-listeners == 0) { /* first open
This is the firt of 2 related, but independent, patches. This is for
uio_pci_generic.c, the next is for uio.c.
The 2 patches were previously one large patch. Changes for this version:
- uio_pci_generic.c just gets extensions so that a single fd can be used
by non-privileged processes for
This is the second of 2 related, but independent, patches. This is for
uio.c, the previous is for uio_pci_generic.c.
The 2 patches were previously one large patch. Changes for this version:
- uio_pci_generic.c just gets extensions so that a single fd can be used
by non-privileged processes for
On Friday 09 April 2010 02:58:19 am Avi Kivity wrote:
On 04/02/2010 08:05 PM, Greg KH wrote:
Currently kvm does device assignment with its own code, I'd like to unify
it with uio, not split it off.
Separate notifications for msi-x interrupts are just as useful for uio as
they are for
Mea culpa.
On Friday 09 April 2010 02:08:55 am Joerg Roedel wrote:
Btw. This patch posting is broken. It suffers from line-wraps which make
it impossible to apply as-is. I was able to fix it but please consider
this in your next posting.
On Wed, Mar 31, 2010 at 05:12:35PM -0700, Tom Lyon
On Thursday 01 April 2010 02:09:09 am Avi Kivity wrote:
On 04/01/2010 03:08 AM, Tom Lyon wrote:
uio_pci_generic has previously been discussed on the KVM list, but this
patch has nothing to do with KVM, so it is also going to LKML.
(needs to go to lkml even if it was for kvm)
The point
On Thursday 01 April 2010 05:52:18 am Joerg Roedel wrote:
On Wed, Mar 31, 2010 at 05:08:38PM -0700, Tom Lyon wrote:
uio_pci_generic has previously been discussed on the KVM list, but this
patch has nothing to do with KVM, so it is also going to LKML.
But since you send it to the KVM list
On Thursday 01 April 2010 07:25:04 am Michael S. Tsirkin wrote:
On Wed, Mar 31, 2010 at 05:08:38PM -0700, Tom Lyon wrote:
uio_pci_generic has previously been discussed on the KVM list, but this
patch has nothing to do with KVM, so it is also going to LKML.
The point of this patch
On Thursday 01 April 2010 08:54:14 am Avi Kivity wrote:
On 04/01/2010 06:39 PM, Tom Lyon wrote:
- support for MSI and MSI-X interrupts (the intel 82599 VFs support
only MSI-X)
How does a userspace program receive those interrupts?
Same as other UIO drivers - by read()ing an event
On Thursday 01 April 2010 09:07:47 am Joerg Roedel wrote:
On Thu, Apr 01, 2010 at 08:40:34AM -0700, Tom Lyon wrote:
On Thursday 01 April 2010 05:52:18 am Joerg Roedel wrote:
The point of this patch is to beef up the uio_pci_generic driver so
that a non-privileged user process can run
On Thursday 01 April 2010 09:10:57 am Avi Kivity wrote:
On 04/01/2010 07:06 PM, Tom Lyon wrote:
On Thursday 01 April 2010 08:54:14 am Avi Kivity wrote:
On 04/01/2010 06:39 PM, Tom Lyon wrote:
- support for MSI and MSI-X interrupts (the intel 82599 VFs support
only MSI-X)
How does
On Thursday 01 April 2010 08:54:14 am Avi Kivity wrote:
On 04/01/2010 06:39 PM, Tom Lyon wrote:
- support for MSI and MSI-X interrupts (the intel 82599 VFs support
only MSI-X)
How does a userspace program receive those interrupts?
Same as other UIO drivers - by read()ing an event
devices
+ *
+ * Copyright (C) 2010 Cisco Systems, Inc.
+ * Extensions by Tom Lyon p...@cisco.com
*
* Copyright (C) 2009 Red Hat, Inc.
* Author: Michael S. Tsirkin m...@redhat.com
@@ -14,25 +17,35 @@
* # ls -l /sys/bus/pci/devices/:00:19.0/driver
* .../:00:19.0/driver - ../../../bus/pci
T-Mobile aka VoiceStream is sharing the Cingular network, so coverage
will be the same.
At 07:29 PM 7/22/2002 -0700, Matt Peterson wrote:
T-Mobile (Deutsche Telekom) has made its west coast attack on Market St
in San Francisco recently. I briefly poked into the shop (previously a
computer shop
Hi, I've just been through the process of booting e-smith on
a small DELL server with a 3ware 6200 controller with mirrored
drives. It has been painful.
The server was totally clean, no OS, no IDE drives. e-smith
seems to really want to see /dev/hda since there were several
timeout/error
64 matches
Mail list logo
