--- 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, 9
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, and
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
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 of
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, and
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
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 of
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
> ---
>
> drivers/vfio/vfio_dma.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/vfio/vfio_dma.c b
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 suc
> Cheers,
> Ben.
>
> On Tue, 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
> > >
> > >
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 VFI
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
> > >
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
---
drivers/vfio/vfio_pci_config.c | 166 +---
1 files
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 re
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 dev
On Tuesday, November 02, 2010 12:11:08 pm Michael S. Tsirkin wrote:
> On Mon, Nov 01, 2010 at 11:08:35PM -0600, 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 pr
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.
>
> Si
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 sinc
Acked-by: Jesse Barnes
Signed-off-by: Tom Lyon
---
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
Signed-off-by: Tom Lyon
---
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
---
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/pci_regs.h
+++ b
written just to give user
access to certain devices - 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
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 bet
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
>
> Some comments on the pci bits:
>
> After going over them for the Nth time - something needs to be done
> with t
Signed-off-by: Tom Lyon
---
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
---
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
--- a/drivers/pci
ten just to give user
access to certain devices - 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
Documentati
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
[ 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 o
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
---
Version 3: shorter name requested by Joerg.
Version 2
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
> &
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
---
Version 2: previous ifdefs not needed.
MST has
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
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
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
---
MST has convinced me that any user level driver for PCI
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?
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 devi
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 sq
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 0
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 "unsu
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-be
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 - openi
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
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
> >
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 spac
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 neede
and effectively the same
iommu handling - 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 dr
, but not IRQ.
Signed-off-by: Tom Lyon
---
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 @@
* # ls -l
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);
> > +
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
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 interr
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:
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
>
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
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
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
> > > > t
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
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.
> >
> &
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 y
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 e
O driver for PCI 2.3 and PCIe devices
+ *
+ * Copyright (C) 2010 Cisco Systems, Inc.
+ * Extensions by Tom Lyon
*
* Copyright (C) 2009 Red Hat, Inc.
* Author: Michael S. Tsirkin
@@ -14,25 +17,35 @@
* # ls -l /sys/bus/pci/devices/:00:19.0/driver
* .../:00:19.0/driver -&g
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 is to beef up the uio_pci_generic driver so that a
non-privileged user process can run a user level driver for most PCIe
devices. This c
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 s
The Verizon Express Network is not CDPD, it's CDMA 1xRTT.
I've used it for a few months now, and I really get the 40-60K throughput
everywhere in the
country - EXCEPT the Bay Area (Aaarrrgh). I usually get 10-20K around here.
At 01:08 PM 7/22/2002 -0700, Dave Hartzell wrote:
>Hello-
>
>I was won
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 message
67 matches
Mail list logo
