On 09/20/2012 05:13 PM, Alex Williamson wrote:
On Thu, 2012-09-20 at 16:36 -0400, Etienne Martineau wrote:
On 09/20/2012 03:37 PM, Alex Williamson wrote:
On Thu, 2012-09-20 at 15:08 -0400, Etienne Martineau wrote:
On 09/20/2012 02:16 PM, Alex Williamson wrote:
On Thu, 2012-09-20 at 13:27 -0400, Etienne Martineau wrote:
In hw/kvm/pci-assign.c a pread() error part of assigned_dev_pci_read()
result in a hw_error(). Similarly a pwrite() error part of
assigned_dev_pci_write() also result in a hw_error().
Would there be a way to avoid terminating the guest for those cases? How
about we deassign the device upon error?
By terminating the guest we contain the error vs allowing the guest to
continue running with invalid data. De-assigning the device is
asynchronous and relies on guest involvement, so damage is potentially
already done. Is this a theoretical problem or do you actually have
hardware that hits this? Thanks,
Alex
This problem is in the context of a Hot-pluggable device assigned to the
guest. If the guest rd/wr the config space at the same time than the
device is physically taken out then the guest will terminate with
hw_error().
Because this limits the availability of the guest I think we should try
to recover instead. I don't see what other damage can happen since
guest's MMIO access to the stale device will go nowhere?
So you're looking at implementing surprise device removal? There's not
just config space, there's slow bar access and mmap'd spaces to worry
about too. What does going nowhere mean? If it means reads return -1
and the guest is trying to read the data portion of a packet from the
network or an hba, we've now passed bad data to the guest. Thanks,
Alex
Thanks for your answer;
Yes we are doing 'surprise device removal' for assigned device. Note
that the problem also exist with standard 'attention button' device removal.
The problem is all about fault isolation. Ideally, only the
corresponding driver should be affected by this 'surprise device
removal'. I think that taking down the guest is too coarse. Think about
a 'surprise device removal' on the host. In that case the host is not
taken down so why not do the same with the guest?
It depends on the host hardware. Some x86 hardware will try to isolate
the fault with an NMI other architectures such as ia64 would pull a
machine check on a driver access to unresponsive devices.
Yes some badness will be latched into the guest but really this not any
different that having a mis-behaving device.
... which is a bad thing, but often undetectable. This is detectable.
Thanks,
Alex
Our hardware is throwing a surprise link down PCIe AER and we are acting
on it. I agree that for the generalized case NMI can be an issue.
Let me ask you that question. What would be the best way to support
device removal (surprise or not) for guest assigned device then? How
about signaling the guest from vfio_pci_remove()?
thanks,
Etienne
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
