The patch adds new IOCTL commands for VFIO PCI device to support
EEH functionality for PCI devices, which have been passed through
from host to somebody else via VFIO.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
Documentation/vfio.txt | 88 ++-
The patch introduces new flags for EEH device and PE to indicate
that the device or PE has been passed through to somebody else.
In turn, we will deliver EEH errors to the device's owner for
further handling, which will be done in subsequent patches.
Signed-off-by: Gavin Shan
On 22.05.14 10:23, Gavin Shan wrote:
The patch adds new IOCTL commands for VFIO PCI device to support
EEH functionality for PCI devices, which have been passed through
from host to somebody else via VFIO.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
This already looks a *lot* more
On 22.05.14 10:23, Gavin Shan wrote:
If we detects frozen state on PE that has been passed through to somebody
else. we needn't handle it. Instead, we rely on the device's owner to
detect and recover it. The patch avoid EEH event on the frozen passed PE so
that the device's owner can have
On 21.05.14 21:47, Alexander Graf wrote:
Am 21.05.2014 um 18:33 schrieb Paul Janzen p...@pauljanzen.org:
On Wed, May 21, 2014 at 12:45 AM, Alexander Graf ag...@suse.de wrote:
Or maybe it's safer overall to just call write_IRQreg_idr() instead of
setting idr directly? That would update
When we trigger a system reset, the in-kernel openpic controller should also
get reset. This happens through a write to the GCR.RESET register which is
the same mechanism a guest would use to manually reset the device.
Signed-off-by: Alexander Graf ag...@suse.de
---
hw/intc/openpic_kvm.c | 15
When we reset the in-kernel MPIC controller, we forget to reset some hidden
state such as destmask and output. This state is usually set when the guest
writes to the IDR register for a specific IRQ line.
To make sure we stay in sync and don't forget hidden state, treat reset of
the IDR register
We worked around some nasty KVM magic page hcall breakages:
1) NX bit not honored, so ignore NX when we detect it
2) LE guests swizzle hypercall instruction
Without these fixes in place, there's no way it would make sense to expose kvm
hypercalls to a guest. Chances are immensely high it
On Thu, May 22, 2014 at 11:55:57AM +0200, Alexander Graf wrote:
On 22.05.14 10:23, Gavin Shan wrote:
If we detects frozen state on PE that has been passed through to somebody
else. we needn't handle it. Instead, we rely on the device's owner to
detect and recover it. The patch avoid EEH event on
On Thu, May 22, 2014 at 11:55:29AM +0200, Alexander Graf wrote:
On 22.05.14 10:23, Gavin Shan wrote:
The patch adds new IOCTL commands for VFIO PCI device to support
EEH functionality for PCI devices, which have been passed through
from host to somebody else via VFIO.
Signed-off-by: Gavin Shan
On Fri, May 23, 2014 at 10:17:30AM +1000, Gavin Shan wrote:
On Thu, May 22, 2014 at 11:55:29AM +0200, Alexander Graf wrote:
On 22.05.14 10:23, Gavin Shan wrote:
.../...
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index cb9023d..ef55682 100644
---
On Thu, 2014-05-22 at 18:23 +1000, Gavin Shan wrote:
The patch adds new IOCTL commands for VFIO PCI device to support
EEH functionality for PCI devices, which have been passed through
from host to somebody else via VFIO.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
On Thu, May 22, 2014 at 09:10:53PM -0600, Alex Williamson wrote:
On Thu, 2014-05-22 at 18:23 +1000, Gavin Shan wrote:
The patch adds new IOCTL commands for VFIO PCI device to support
EEH functionality for PCI devices, which have been passed through
from host to somebody else via VFIO.
On Fri, 2014-05-23 at 14:37 +1000, Gavin Shan wrote:
There's no notification, the user needs to observe the return value an
poll? Should we be enabling an eventfd to notify the user of the state
change?
Yes. The user needs to monitor the return value. we should have one
notification,
14 matches
Mail list logo
