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

[Yuji Shimada <shimada-yxb@xxxxxxxxxxxxxxx>]

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.

Thanks,

--
Yuji Shimada

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel