On Sun, 2012-08-12 at 12:33 +0300, Michael S. Tsirkin wrote:
> On Thu, Aug 09, 2012 at 01:26:15PM -0600, Alex Williamson wrote:
> > On Mon, 2012-08-06 at 13:40 +0300, Avi Kivity wrote:
> > > On 08/06/2012 01:38 PM, Avi Kivity wrote:
> > >
> > > > Regarding
On Sun, 2012-08-12 at 11:36 +0300, Avi Kivity wrote:
> On 08/09/2012 10:26 PM, Alex Williamson wrote:
> > On Mon, 2012-08-06 at 13:40 +0300, Avi Kivity wrote:
> >> On 08/06/2012 01:38 PM, Avi Kivity wrote:
> >>
> >> > Regarding the implementation, i
On Tue, 2012-08-14 at 00:50 +0300, Michael S. Tsirkin wrote:
> On Mon, Aug 13, 2012 at 02:48:25PM -0600, Alex Williamson wrote:
> > On Mon, 2012-08-13 at 22:50 +0300, Michael S. Tsirkin wrote:
> > > On Mon, Aug 13, 2012 at 12:17:25PM -0600, Alex Williamson wrote:
> > >
On Tue, 2012-08-14 at 01:06 +0300, Michael S. Tsirkin wrote:
> On Mon, Aug 13, 2012 at 03:34:01PM -0600, Alex Williamson wrote:
> > On Sun, 2012-08-12 at 11:36 +0300, Avi Kivity wrote:
> > > On 08/09/2012 10:26 PM, Alex Williamson wrote:
> > > > On Mon, 2012-08-06 at
On Tue, 2012-08-14 at 02:00 +0300, Michael S. Tsirkin wrote:
> On Mon, Aug 13, 2012 at 04:41:05PM -0600, Alex Williamson wrote:
> > On Tue, 2012-08-14 at 01:06 +0300, Michael S. Tsirkin wrote:
> > > On Mon, Aug 13, 2012 at 03:34:01PM -0600, Alex Williamson wrote:
> > >
On Tue, 2012-08-07 at 13:05 -0600, Alex Williamson wrote:
> Hi Linus,
>
> The following changes since commit 42a579a0f960081cd16fc945036e4780c3ad3202:
>
> Merge branches 'timers-urgent-for-linus' and 'perf-urgent-for-linus' of
> git://git.kernel.org/pub
On Tue, 2012-08-14 at 11:35 +0300, Michael S. Tsirkin wrote:
> On Mon, Aug 13, 2012 at 09:09:43PM -0600, Alex Williamson wrote:
> > On Tue, 2012-08-14 at 02:00 +0300, Michael S. Tsirkin wrote:
> > > On Mon, Aug 13, 2012 at 04:41:05PM -0600, Alex Williamson wrote:
> > >
On Tue, 2012-08-14 at 15:35 +0300, Avi Kivity wrote:
> On 08/12/2012 12:33 PM, Michael S. Tsirkin wrote:
> >>
> >> Michael, would the interface be more acceptable to you if we added
> >> separate ioctls to allocate and free some representation of an irq
> >> source ID, gsi pair? For instance, an
On Wed, 2012-08-15 at 02:04 +0300, Michael S. Tsirkin wrote:
> On Tue, Aug 14, 2012 at 04:01:15PM -0600, Alex Williamson wrote:
> > On Tue, 2012-08-14 at 15:35 +0300, Avi Kivity wrote:
> > > On 08/12/2012 12:33 PM, Michael S. Tsirkin wrote:
> > > >>
> > &g
On Wed, 2012-08-15 at 15:27 +0300, Michael S. Tsirkin wrote:
> On Fri, Aug 10, 2012 at 04:37:17PM -0600, Alex Williamson wrote:
> > Registering an kvm_irq_ack_notifier with kian.irq_source_id < 0
> > retains existing behavior, filling in the actual irq_source_id results
> &
On Wed, 2012-08-15 at 15:59 +0300, Michael S. Tsirkin wrote:
> On Fri, Aug 10, 2012 at 04:37:25PM -0600, Alex Williamson wrote:
> > Introduce KVM_IRQ_SOURCE_ID and KVM_CAP_NR_IRQ_SOURCE_ID to allow
> > user allocation of IRQ source IDs and querying both the capability
> > a
On Wed, 2012-08-15 at 16:49 +0300, Michael S. Tsirkin wrote:
> On Fri, Aug 10, 2012 at 04:37:33PM -0600, Alex Williamson wrote:
> > This allows specifying an IRQ source ID to be used when injecting an
> > interrupt. When not specified KVM_USERSPACE_IRQ_SOURCE_ID is used.
> &g
On Wed, 2012-08-15 at 17:05 +0300, Michael S. Tsirkin wrote:
> On Fri, Aug 10, 2012 at 04:37:48PM -0600, Alex Williamson wrote:
> > Enable a mechanism for IRQ ACKs to be exposed through an eventfd. The
> > user can specify the GSI and optionally an IRQ source ID and have the
>
On Wed, 2012-08-15 at 17:11 +0300, Michael S. Tsirkin wrote:
> On Fri, Aug 10, 2012 at 04:37:56PM -0600, Alex Williamson wrote:
> > It's likely (vfio) that one of the reasons to watch for an IRQ ACK
> > is to de-assert and re-enable an interrupt. As the IRQ ACK notfier
>
On Wed, 2012-08-15 at 17:28 +0300, Michael S. Tsirkin wrote:
> On Fri, Aug 10, 2012 at 04:37:08PM -0600, Alex Williamson wrote:
> > v8:
> >
> > Trying a new approach. Nobody seems to like the internal IRQ
> > source ID object and the interactions it implies between ir
On Wed, 2012-08-15 at 22:22 +0300, Michael S. Tsirkin wrote:
> On Wed, Aug 15, 2012 at 11:36:31AM -0600, Alex Williamson wrote:
> > On Wed, 2012-08-15 at 17:28 +0300, Michael S. Tsirkin wrote:
> > > On Fri, Aug 10, 2012 at 04:37:08PM -0600, Alex Williamson
On Wed, 2012-08-15 at 13:59 -0600, Alex Williamson wrote:
> On Wed, 2012-08-15 at 22:22 +0300, Michael S. Tsirkin wrote:
> > On Wed, Aug 15, 2012 at 11:36:31AM -0600, Alex Williamson wrote:
> > > On Wed, 2012-08-15 at 17:28 +0300, Michael S. Tsirkin wrote:
> > > >
On Thu, 2012-08-16 at 19:32 +0300, Avi Kivity wrote:
> On 08/11/2012 01:37 AM, Alex Williamson wrote:
> > v8:
> >
> > Trying a new approach. Nobody seems to like the internal IRQ
> > source ID object and the interactions it implies between irqfd
> > and eoifd,
On Thu, 2012-08-16 at 19:29 +0300, Avi Kivity wrote:
> On 08/15/2012 10:22 PM, Michael S. Tsirkin wrote:
> > On Wed, Aug 15, 2012 at 11:36:31AM -0600, Alex Williamson wrote:
> >> On Wed, 2012-08-15 at 17:28 +0300, Michael S. Tsirkin wrote:
> >> > On Fri, Aug 10,
excessive infrastructure
around an object for storing this irq_source_id. However, notice
that we only provide a way to assert the interrupt here. A follow-on
interface will make use of the same irq_source_id to allow de-assert.
Signed-off-by: Alex Williamson
---
Documentation/virtual/kvm/api.txt
is serviced.
Here we make use of the reference counting of the _irq_source
object allowing us to share it with an irqfd and cleanup regardless
of the release order.
Signed-off-by: Alex Williamson
---
Documentation/virtual/kvm/api.txt | 21 ++
arch/x86/kvm/x86.c|2
ut where an irqfd is de-assigned then re-assigned
now results in a new key instead of leaving the user wondering if
it re-associates back to the eoifd.
Also added workqueue flushes on assign since releasing either
object now results in a lazy release via workqueue. This ensures
we re-claim any sou
On Fri, 2012-07-20 at 10:33 -0600, Alex Williamson wrote:
> v6:
>
> So we're back to just the first two patches, unfortunately the
> diffstat got bigger though. The reason for that is that I discovered
> we don't do anything on release of an eoifd. We cleanup if the
Badness. To fix this we can move the
poll call to before the lock because we only do anything on
POLLHUP which won't occur as long as we have a reference to the
file. Thanks,
Alex
---
Alex Williamson (2):
kvm: KVM_EOIFD, an eventfd for EOIs
kvm: Extend irqfd to support level inter
excessive infrastructure
around an object for storing this irq_source_id. However, notice
that we only provide a way to assert the interrupt here. A follow-on
interface will make use of the same irq_source_id to allow de-assert.
Signed-off-by: Alex Williamson
---
Documentation/virtual/kvm/api.txt
is serviced.
Here we make use of the reference counting of the _irq_source
object allowing us to share it with an irqfd and cleanup regardless
of the release order.
Signed-off-by: Alex Williamson
---
Documentation/virtual/kvm/api.txt | 21 ++
arch/x86/kvm/x86.c|2
xt for
the last month. Thanks,
Alex
---
Alex Williamson (4):
vfio: Add PCI device driver
vfio: Type1 IOMMU implementation
vfio: Add documentation
vfio: VFIO core
Documentation/ioctl/ioctl-number.txt |1
Documentation/vfio.txt | 314 +++
M
VFIO
users are able to query and initialize the IOMMU model of their
choice.
Please see the follow-on Documentation commit for further description
and usage example.
Signed-off-by: Alex Williamson
---
Documentation/ioctl/ioctl-number.txt |1
MAINTAINERS |8
dr
Signed-off-by: Alex Williamson
---
Documentation/vfio.txt | 314
1 file changed, 314 insertions(+)
create mode 100644 Documentation/vfio.txt
diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt
new file mode 100644
index 000
the user and is optimized
for relatively static mappings. Mapped areas are pinned into system
memory.
Signed-off-by: Alex Williamson
---
drivers/vfio/Kconfig|6
drivers/vfio/Makefile |2
drivers/vfio/vfio.c |7
drivers/vfio/vfio_iommu_type1.c
t term, we can create dummy hard handlers
that return us to the previous behavior. Credit to Michael for
original patch.
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=43328
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Alex Williamson
---
Patch against kvm/master for v3.5
virt/kvm/assi
On Thu, 2012-07-05 at 18:53 +0300, Michael S. Tsirkin wrote:
> On Wed, Jul 04, 2012 at 10:24:54PM -0600, Alex Williamson wrote:
> > On Wed, 2012-07-04 at 17:00 +0300, Michael S. Tsirkin wrote:
> > > On Tue, Jul 03, 2012 at 01:21:29PM -0600, Alex Williamson wrote:
> > >
On Wed, 2012-07-11 at 14:51 +0300, Avi Kivity wrote:
> On 07/11/2012 02:23 PM, Jan Kiszka wrote:
> >>
> >> I'd appreciate a couple of examples for formality's sake.
> >
> > From the top of my head: NVIDIA FX3700 (granted, legacy by now), Atheros
> > AR9287. For others, I need to check.
>
> Thank
We've confirmed that peer-to-peer between these devices is
not possible. We can therefore claim that they support a
subset of ACS.
Signed-off-by: Alex Williamson
Cc: Joerg Roedel
---
Two things about this patch make me a little nervous. The
first is that I'd really like to have a p
On Thu, 2012-07-12 at 12:35 +0300, Avi Kivity wrote:
> On 07/11/2012 10:57 PM, Alex Williamson wrote:
> >>
> >> > We still have classic KVM device assignment to provide fast-path INTx.
> >> > But if we want to replace it midterm, I think it's necessary for
On Thu, 2012-07-12 at 10:19 -0600, Alex Williamson wrote:
> On Thu, 2012-07-12 at 12:35 +0300, Avi Kivity wrote:
> > On 07/11/2012 10:57 PM, Alex Williamson wrote:
> > >>
> > >> > We still have classic KVM device assignment to provide fast-path INTx.
> >
r v3.8-rc5
----
Alex Williamson (1):
vfio-pci: Fix buffer overfill
drivers/vfio/pci/vfio_pci_rdwr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Even PCIe 1.x had extended config space.
Signed-off-by: Alex Williamson
---
drivers/vfio/pci/vfio_pci_config.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci_config.c
b/drivers/vfio/pci/vfio_pci_config.c
index 6985149..f1dde2c 100644
PCI_EXP_FLAGS_TYPE is a mask, not an offset. Fix it.
Signed-off-by: Alex Williamson
---
drivers/pci/access.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/access.c b/drivers/pci/access.c
index 3af0478..32046c5 100644
--- a/drivers/pci/access.c
+++ b/drivers
A bus reset can trigger a presence detection change and result in a
suprise hotplug. This is generally not what we want to happen when
trying to reset a device. Disable the presence detection control on
on bridges around bus reset.
Signed-off-by: Alex Williamson
---
drivers/pci/pci.c | 29
On Thu, 2013-02-14 at 04:41 -0600, Vijay Mohan Pandarathil wrote:
> - New VFIO_SET_IRQ ioctl option to pass the eventfd that is signaled
> when
> an error occurs in the vfio_pci_device
>
> - Register pci_error_handler for the vfio_pci driver
>
> - When the device enco
On Thu, 2013-02-14 at 04:41 -0600, Vijay Mohan Pandarathil wrote:
> - Create eventfd per vfio device assigned to a guest and register an
> event handler
>
> - This fd is passed to the vfio_pci driver through the SET_IRQ ioctl
>
> - When the device encounters an error,
On Thu, 2013-02-14 at 11:37 -0700, Alex Williamson wrote:
> A bus reset can trigger a presence detection change and result in a
> suprise hotplug. This is generally not what we want to happen when
> trying to reset a device. Disable the presence detection control on
> on bridges arou
On Thu, 2013-02-14 at 16:47 -0700, Bjorn Helgaas wrote:
> On Thu, Feb 14, 2013 at 11:37 AM, Alex Williamson
> wrote:
> > A bus reset can trigger a presence detection change and result in a
> > suprise hotplug. This is generally not what we want to happen when
> >
moval.
Signed-off-by: Alex Williamson
---
drivers/vfio/vfio.c | 33 -
1 file changed, 12 insertions(+), 21 deletions(-)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 12c264d..8e6dcec 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -6
s via vfio, but we can tolerate them not being owned
by vfio-pci.
Signed-off-by: Alex Williamson
---
drivers/vfio/vfio.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 8e6dcec..28e2d5b 100644
--- a/drivers/vfio/vfio.c
+++ b/dr
oftRst-).
Signed-off-by: Alex Williamson
---
drivers/vfio/pci/vfio_pci_config.c | 25 ++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci_config.c
b/drivers/vfio/pci/vfio_pci_config.c
index f1dde2c..81567f8 100644
--- a/drivers/vf
A bus reset can trigger a presence detection change and result in a
suprise hotplug. This is generally not what we want to happen when
trying to reset a device. Disable the presence detection control on
on bridges around bus reset.
Signed-off-by: Alex Williamson
---
v2: Still hasn't res
oftRst-).
Signed-off-by: Alex Williamson
---
v2: sparse found a type error when calling pci_set_power_state. Fixed here
drivers/vfio/pci/vfio_pci_config.c | 25 ++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci_config.c
b/drivers/vf
On Mon, 2013-02-18 at 11:13 +0800, Li Zefan wrote:
> While trying to fix a race when closing cgroup eventfd, I took a look
> at how kvm deals with this problem, and I found it doesn't.
>
> I may be wrong, as I don't know kvm code, so correct me if I'm.
>
> /*
>* Race-free decouple l
On Mon, 2013-02-18 at 12:09 +0800, Li Zefan wrote:
> On 2013/2/18 12:02, Alex Williamson wrote:
> > On Mon, 2013-02-18 at 11:13 +0800, Li Zefan wrote:
> >> While trying to fix a race when closing cgroup eventfd, I took a look
> >> at how kvm deals with this prob
_domain
> *dom,
>
> devid = calc_devid(pdev->bus->number, pdev->devfn);
>
> - if (devid >= amd_iommu_last_bdf ||
> + if (devid > amd_iommu_last_bdf ||
> devid != amd_iommu_alias_table[devid])
> return -EINVAL;
&g
On Tue, 2012-10-16 at 16:50 +, Tom Mingarelli wrote:
> This patch is to prevent devices that have RMRRs associated with them
> from getting placed into the SI Domain during init. We don't put USB devices
> into this category, however. This fixes the issue where the RMRR info
> for devices bein
31 +++
> 1 files changed, 31 insertions(+), 0 deletions(-)
Looks ok to me.
Reviewed-by: Alex Williamson
>
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index d4a4cd4..8c064df 100644
> --- a/drivers/iommu/intel-iommu.c
;s no need to re-order vfio_pci_disable().
Signed-off-by: Alex Williamson
---
drivers/vfio/pci/vfio_pci.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 306b90c..b28e66c 100644
--- a/dr
On Fri, 2013-01-11 at 08:45 +, Pandarathil, Vijaymohan R wrote:
>
> > -Original Message-
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Wednesday, January 09, 2013 11:05 AM
> > To: Pandarathil, Vijaymohan R
> > C
On Fri, 2013-01-11 at 08:53 +, Pandarathil, Vijaymohan R wrote:
>
> > -Original Message-
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Wednesday, January 09, 2013 10:08 AM
> > To: Pandarathil, Vijaymohan R
> > C
A read from a range hidden from the user (ex. MSI-X vector table)
attempts to fill the user buffer up to the end of the excluded range
instead of up to the requested count. Fix it.
Signed-off-by: Alex Williamson
Cc: sta...@vger.kernel.org
---
drivers/vfio/pci/vfio_pci_rdwr.c |4 ++--
1
appreciate any feedback on the overal incorporation into vfio
given your history with the design. VGA is still a work in progress
but with this base I'm able to assign a handlful of desktop cards that
I have on hand to a qemu guest using standard builtin VGA drivers.
Thanks,
Alex
---
Alex Willia
The read and write functions are nearly identical, combine them
and convert to a switch statement. This also makes it easy to
narrow the scope of when we use the io/mem accessors in case new
regions are added.
Signed-off-by: Alex Williamson
---
drivers/vfio/pci/vfio_pci.c | 59
We can actually handle MMIO and I/O port from the same access function
since PCI already does abstraction of this. The ROM BAR only requires
a minor difference, so it gets included too. vfio_pci_config_readwrite
gets renamed for consistency.
Signed-off-by: Alex Williamson
---
drivers/vfio/pci
manage host chipset config
to route each access to the correct device.
Signed-off-by: Alex Williamson
---
drivers/vfio/pci/Kconfig| 10
drivers/vfio/pci/vfio_pci.c | 49
drivers/vfio/pci/vfio_pci_private.h |9
drivers/vfio/pci
On Wed, 2012-12-12 at 17:14 +1100, Alexey Kardashevskiy wrote:
> On 08/12/12 04:38, Alex Williamson wrote:
> >> +static int __init tce_iommu_init(void)
> >> +{
> >> + struct pci_dev *pdev = NULL;
> >> + struct iommu_table *tbl;
> >> + struct
On Wed, 2012-12-12 at 17:59 +1100, Alexey Kardashevskiy wrote:
> On 08/12/12 04:01, Alex Williamson wrote:
> >> + case VFIO_IOMMU_MAP_DMA: {
> >> + vfio_iommu_spapr_tce_dma_map param;
> >> + struct iommu_table *tbl = container->tbl;
> &
On Wed, 2012-12-12 at 23:34 +1100, Alexey Kardashevskiy wrote:
> This patch initializes IOMMU groups based on the IOMMU
> configuration discovered during the PCI scan on POWERNV
> (POWER non virtualized) platform. The IOMMU groups are
> to be used later by VFIO driver (PCI pass through).
>
> It al
On Thu, 2012-12-13 at 13:57 +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2012-12-12 at 16:30 -0700, Alex Williamson wrote:
> > Locked page accounting in this version is very, very broken. How do
> > powerpc folks feel about seemingly generic kernel iommu interfaces
> > mes
Probably a good idea to CC the iommu list and maintainer...
On Thu, 2012-12-13 at 17:28 +1100, Alexey Kardashevskiy wrote:
> The iommu_init() call initializes IOMMU internal structures and data
> required for the API to function such as iommu_group_alloc().
> It is registered as a subsys_initcall.
On Thu, 2012-12-13 at 17:50 +0800, Jason Gao wrote:
> Dear List:
>
> Description of problem:
> After installed Centos 6.3(RHEL6.3) on my Dell R710(lastest
> bios:Version: 6.3.0,Release Date: 07/24/2012) server,and updated
> lastest kernel "2.6.32-279.14.1.el6.x86_64",I want to use the Intel
> 8257
On Fri, 2012-12-14 at 00:55 +0800, Wang YanQing wrote:
> if we don't define CONFIG_IOMMU_API the
> dummy functions alway return -ENODEV
> or -EINVAL except three function, so convert
> them to the same behavior to make consistence
But if we do define CONFIG_IOMMU_API the actual functions return NU
On Fri, 2012-12-14 at 00:55 +0800, Wang YanQing wrote:
> The linux/iommu.h header uses ERR_PTR defined
> in linux/err.h but doesn't include it.
>
> Signed-off-by: Wang YanQing
> ---
> include/linux/iommu.h | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Alex W
On Fri, 2012-12-14 at 10:01 +0800, Jason Gao wrote:
> On Fri, Dec 14, 2012 at 12:23 AM, Alex Williamson
> wrote:
> >
> > Device 03:00.0 is your raid controller:
> >
> > 03:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078
> > (rev 04)
&g
On Tue, 2012-12-11 at 21:02 -0700, Alex Williamson wrote:
> Hi Linus,
>
> Take 2 using the same commits as in Stephen's next tree, please note the
> new tag below. There's a merge with v3.7 in my for-linus branch of the
> below tree, not that you should need it. Thanks
On Wed, 2012-09-26 at 10:21 -0600, Alex Williamson wrote:
> On Wed, 2012-09-26 at 17:10 +0200, Roedel, Joerg wrote:
> > On Wed, Sep 26, 2012 at 08:35:59AM -0600, Alex Williamson wrote:
> > > Hmm, that throws a kink in iommu groups. So perhaps we need to make an
> > &g
On Wed, 2012-09-26 at 13:50 -0600, Alex Williamson wrote:
> On Wed, 2012-09-26 at 10:21 -0600, Alex Williamson wrote:
> > On Wed, 2012-09-26 at 17:10 +0200, Roedel, Joerg wrote:
> > > On Wed, Sep 26, 2012 at 08:35:59AM -0600, Alex Williamson wrote:
> > > > Hmm, that
've been able to get syslinux graphics mode to
work and Windows will use it during normal bootup. I have no idea
what might be missing for VGA text mode. Thanks,
Alex
---
Alex Williamson (1):
vfio-pci: [NOT FOR COMMIT] Add support for legacy MMIO & I/O port towards
VGA support
manage host chipset config
to route each access to the correct device.
Signed-off-by: Alex Williamson
---
drivers/vfio/pci/vfio_pci.c | 74 ---
drivers/vfio/pci/vfio_pci_private.h |6 +
drivers/vfio/pci/vfio_pci_rdwr.c| 170 +++
include
On Wed, 2013-01-09 at 06:26 +, Pandarathil, Vijaymohan R wrote:
> - New ioctl which is used to pass the eventfd that is signaled when
> an error occurs in the vfio_pci_device
>
> - Register pci_error_handler for the vfio_pci driver
>
> - When the device encounters
On Wed, 2013-01-09 at 06:26 +, Pandarathil, Vijaymohan R wrote:
> - Create eventfd per vfio device assigned to a guest and register an
> event handler
>
> - This fd is passed to the vfio_pci driver through a new ioctl
>
> - When the device encounters an error, the
On Wed, 2013-01-09 at 10:52 -0700, Alex Williamson wrote:
> On Wed, 2013-01-09 at 06:26 +, Pandarathil, Vijaymohan R wrote:
> > - New ioctl which is used to pass the eventfd that is signaled when
> > an error occurs in the vfio_pci_device
> >
> > -
On Sat, 2005-07-09 at 18:06 -0700, Christoph Lameter wrote:
> On Fri, 9 Jul 2005, Andi Kleen wrote:
>
> > I think that is a really really bad idea. slab is already complex enough
> > and adding scary hacks like this will probably make it collapse
> > under its own weight at some point.
>
> Seco
ying to use the system with a 115.2k baud rate. Thanks,
Alex
--
Alex Williamson HP Linux & Open Source Lab
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo inf
On Mon, 2005-07-11 at 20:46 +0100, Russell King wrote:
> On Mon, Jul 11, 2005 at 01:00:08PM -0600, Alex Williamson wrote:
> > On Thu, 2005-07-07 at 14:20 +0100, David Vrabel wrote:
> >
> > > I've redid the patch and added a check for this. Alex, could you te
On Mon, 2005-07-11 at 21:17 +0100, Russell King wrote:
> On Mon, Jul 11, 2005 at 02:00:57PM -0600, Alex Williamson wrote:
> > On Mon, 2005-07-11 at 20:46 +0100, Russell King wrote:
> > > There was a bug in this area - does it happen with latest and greatest
> > > ke
On Mon, 2005-07-11 at 15:17 -0600, Alex Williamson wrote:
>No, I think this is a problem with the broken A2 UARTs getting
> confused in serial8250_set_sleep(). If I remove either UART_CAP_SLEEP
> or UART_CAP_EFR from the capabilities list for this UART, it behaves
> normally.
On Wed, 2005-07-13 at 11:04 -0600, Alex Williamson wrote:
> Just trying to make sure that there's not a latent bug that we enable
> a bad sleep mode when the UART is being used for the console.
Yes, this is the problem. When a UART is specified as the console
using "consol
up, this flag could be included, and
I'd be happy to test it. This would at least give us both usable UARTs
until we can work out the other kinks. Thanks,
Alex
--
Alex Williamson HP Linux & Open Source Lab
-
To unsubscribe from this list: send the li
using the "swiotlb=force" boot option. In this case, the driver is
leaking resources of the swiotlb and not causing a sync of the bounce
buffer. Thanks
Signed-off-by: Alex Williamson <[EMAIL PROTECTED]>
diff -r b9c8e9fdd6b2 drivers/block/cciss.c
--- a/drivers/block/cciss.c
by removing
> > broken_efr().
>
> I don't know - maybe Alex Williamson can try your patch out.
I can, but not till next week when I can get into the office and dig
up the box with the broken A2 rev UARTs. Let me know if you need an
answer before then. Thanks,
Alex
--
On Fri, 2005-07-29 at 16:31 -0700, Christoph Lameter wrote:
> What you are dealing with is a machine that is using ITC as a time bases.
> That is a special case.
The default time source for ia64 systems is a "special case"? 4
socket and smaller boxes typically do not have any other time sourc
Ok, here's an optimization that should help reduce contention on the
cmpxchg, has zero impact on the nojitter path, and doesn't require any
changes to fsys. When a caller already had the xtime_lock write lock
there's no need to fight with other CPUs for the cmpxchg. The other
"reader" CPUs wi
plete. We can therefore allow writers to insert a new value and exit
rather than fight with CPUs who only hold a reader lock.
Signed-off-by: Alex Williamson <[EMAIL PROTECTED]>
diff -r cff8d3633e9c kernel/timer.c
--- a/kernel/timer.cFri Jul 29 22:01:15 2005
+++ b/kernel/timer.cMon Aug
a of something around 20-50? There could be some kind of
boot/run time tunable to set this min_delta if there's no good way to
calculate it. It should be trivial to add something like this to the
fsys path as well and shouldn't disrupt the nojitter path at all.
Thanks,
Alex
--
Al
On Wed, 2005-08-03 at 09:10 -0700, Christoph Lameter wrote:
> On Wed, 3 Aug 2005, Alex Williamson wrote:
>
> > be a reasonable performance vs absolute accuracy trade-off. What
> > happens to your worst case time if you (just for a test) hard code a
> > min_delta of someth
On Thu, 2005-08-25 at 10:36 -0700, john stultz wrote:
> On Thu, 2005-08-25 at 10:44 -0600, Alex Williamson wrote:
> > How can we munge these all together to come up with a single goodness
> > factor for comparison? There's probably a thesis covering algorithms to
> > ha
e, but it seems to do what I
think it should. If I where to add another node to the system, I would
more strongly favor the HPETs time, if I removed a node I would revert
to the cycle counter. Anyway, I think it might be a good starting point
for further experimentation. Patch below.
Alex
looking into the suggestion to use logarithms to try to
normalize some of the factors such that weighting is more logical.
Hopefully that won't explode the complexity. Thanks,
Alex
--
Alex Williamson HP Linux & Open Source Lab
-
To unsubscribe from th
On Fri, 2005-08-26 at 12:16 -0700, George Anzinger wrote:
> Alex Williamson wrote:
> > On Fri, 2005-08-26 at 08:39 -0700, Christoph Lameter wrote:
> >>1. If a system boots up with a single cpu then there is no question that
> >>the ITC/TSC should be used because of th
On Sun, 2005-08-28 at 13:20 +0200, Andreas Schwab wrote:
> The last change to drivers/pci/setup-res.c (Ignore disabled ROM resources
> at setup) is breaking radeonfb on iBook G3 (with Radeon Mobility M6 LY).
> It crashes in pci_map_rom when called from radeonfb_map_ROM. This is
> probably a dorman
The HPET driver is using a parts per second drift factor instead of
the standard parts per million drift the time interpolator code expects.
This patch fixes that problem and updates the URL for the HPET spec.
Signed-off-by: Alex Williamson <[EMAIL PROTECTED]>
diff -r 38ae29531c91 d
The patch below adds IDs and setup for a new PCI Diva console port.
This device provides a single UART described by PCI Bar 1. ID already
submitted to pciids.sf.net. Please apply. Thanks,
Alex
Signed-off-by: Alex Williamson <[EMAIL PROTECTED]>
= drivers/pci/pci.ids 1
501 - 600 of 2933 matches
Mail list logo
