Re: [Xen-devel] Problems when using latest git tree to boot xen on OMAP5

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 9 Oct 2013, Ian Campbell wrote:
> On Wed, 2013-10-09 at 12:29 +0100, Stefano Stabellini wrote:
> > On Wed, 9 Oct 2013, Ian Campbell wrote:
> > > On Wed, 2013-10-09 at 12:15 +0100, Julien Grall wrote:
> > > > On 10/09/2013 09:11 AM, Ian Campbell wrote:
> > > > > Rather than whitelisting and mapping disabled devices through perhaps 
> > > > > we
> > > > > should implement them as read 0xf (or 0x0) and write ignore?
> > > > 
> > > > We can't assume that these values (0x0 or 0xf) won't affect dom0 
> > > > behaviour.
> > > 
> > > 0xff is what you would typically get back if there was no actual
> > > hardware present.
> > > 
> > > > What about a new quirk to map all disabled device in dom0
> > > > (PLATFORM_QUIRK_DOM0_MAP_DISABLED_DEVICE)?
> > > 
> > > Why is this not the default behaviour?
> > 
> > I think this is not a good idea: it prevents us from assigning one
> > device directly to a domain other than dom0 from Xen at boot time
> > (without going through something like PCI passthough).
> 
> No it doesn't, it would just be a default behaviour which would be
> overrideable by some new command line option.

I see.
I would still keep it off by default and maybe enable the workaround
only where we actually need it. If we enable it by default we might not
know exactly which ones are the platforms that actually require it.


> Note that we don't even go as far as you suggest for PCI passthrough on
> x86, where dom0 still sees the device and the hide option is a dom0 one.

The main difference is that in that case we can hide a given device
using pciback (or pcistub), in this case we can't. Also on x86 we are
constrained by the PCI bus, while here we might be able to have a better
design for non-PCI devices.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel