Re: [Xen-devel] [PATCH][RFC] Support more Capability Structures andDevice Specific

[Yuji Shimada <shimada-yxb@xxxxxxxxxxxxxxx>]

I think it is better to emulate registers related to error reporting
at least.

We can consider two patterns of error handling as following.

PATTERN-1: AER is enabled on host but will not be notified to guest domain.

Actual AER is enable, but guest software is not allowed to enable AER
by _OSC in guest firmware. When error occurs, dom0 will kill guest
domain and reset the device or bus. Registers related to error
reporting should be emulated to prevent guest software turning off
actual error reporting.

PATTERN-2: AER is enabled on host and will also be notified to guest domain.

Actual AER is always enable, but guest can enable/disable its virtual
AER. When error occurs, dom0 check guest emulated AER is enabled or not.
If guest emulated AER is enabled, dom0 will notify error to guest
software. Then guest software will reset I/O device or bus.
If guest emulated AER is disabled, dom0 will not notify error to
guest software. Dom0 will kill guest domain, and reset I/O device or
bus. To do this, registers related to error reporting should be
emulated. And Root Port emulation is also required.


I've taken a look at "Xen - VT-D Enhance.pdf".

Is Dexuan implementing Memory Mapped Configuration Access Mechanism to
support offset 256-4095? Are following interfaces not changed ?

    pci_dev->config_read
    pci_dev->config_write

If they are not changed, I think Dexuan's Memory Mapped Configuration
Access Mechanism and my code can be merged easily.

Thanks a lot.

--
Yuji Shimada

> Keir Fraser wrote:
> > What do you think of Yuji's patch? One thing to consider
> > is that perhaps the patch should be against the upstream
> > qemu merge now. But I'm not sure that PCI passthrough is
> > even supported yet in that tree (Ian?). 
> > 
> 
> If we agree the basic policy is pass through except the ones with known
> behavior, I think we don't need that many case to case handle. Dexuan is
> working on the implementation base on the summit talk and close to end,
> maybe Yuji and Dexuan can coordinate first to see if the proposed policy
> can server yuji's purpose.
> 
> Thx, eddie
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel


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