This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [Q] Is qemu used when we use VTd?

On Fri, 26 Sep 2008 12:36:21 +0800
"Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote:

> What I considered is, for PV domain, the pciback can act as a
> stub/proxy, pass the callback from AER to guest side and wait
> guest's return, like PCI_ERS_RESULT_NEED_RESET etc. I didn;t find
> much issue to this method, except some guard on pciback to make sure
> no timeout and the feedback is valid. Also some mechanism needed
> from pciback to notify pcifront (currently only request from
> pcifront to pciback per my understanding).
> But for HVM domain, maybe we can't support it unless we have virtual
> AER support in virtual HVM platform. Even if we have virtual HVM
> platform, it is much complex to translat the physical AER to guest
> side, and parse guest side's action to decide how to act on host
> side. We are still consider this. Do you have any idea on it?
> Also another point is, have you consider how to handle
> multi-function device that assigned to multple domain, and one
> function has error? Or devices under the same switch assigned to
> different domain??

We have to solve many difficulties to keep guest domain running.

How about following idea for first step?

    Non-fatal error on I/O device:
        - kill the domain with error source function.
        - reset the function.

    Non-fatal error on PCI-PCI bridge.
        - kill all domains with the functions under the PCI-PCI bridge.
        - reset PCI-PCI bridge and secondary bus.

    Fatal error:
        - kill all domains with the functions under the same root port.
        - reset the link (secondary bus reset on root port).

Note: we have to consider to prevent device from destroying other
domain's memory.

> >>> in guest side is required in the long term, because guest OS will be
> >>> able to handle AER and recover error condition.
> >>
> >> Yes, agree that if guest can do AER, it will enahnce reliability and
> >> availability. But more elegant design is needed. For example, if
> >> guest decide that the AER need root port reset link (switch link
> >> reset should be ok unless SR-IOV), what shall host do?  If host act
> >> according to guest's suggestion, that may not be safe, I suspect.
> >
> > I agree with you.  Host should NOT act according to guest's
> > suggestion. I think host should recover error condition with dom0
> > linux's AER driver. AER emulation for guest is needed to make guest survive.
> Have you considered implement just a virtual root port in qemu, not
> the whoel RC? Not sure if any effort/function difference between
> these two method.

I think it is good to implement just a virtual root port in qemu. The
reasons are followings.

- OS does not control chipset-specific device in RC much. We don't
  need to provide chipset-specific device to guest OS.

- Firmware control chipset-specific device in RC. But guest firmware
  is xen-specific. We don't need to provide chipset-specific device to
  guest firmware.

Note: for first step, we don't need to implement virtual root port in
qemu, because we kill guest domain.


Yuji Shimada

Xen-devel mailing list