Re: [Qemu-devel] Re: [PATCH V6 17/32] pci: 64bit bar support.

[Michael S. Tsirkin]

On Tue, Nov 03, 2009 at 11:01:00PM +0900, Isaku Yamahata wrote:
> On Tue, Nov 03, 2009 at 02:39:06PM +0200, Michael S. Tsirkin wrote:
> > On Tue, Nov 03, 2009 at 02:22:07PM +0200, Avi Kivity wrote:
> > > On 11/03/2009 01:47 PM, Michael S. Tsirkin wrote:
> > >>
> > >> If qemu is compiled with target phys address size 32 bit, emulated
> > >> devices can not support a 64 bit BAR.  Therefore, according to PCI spec,
> > >> such devices should declare all BARs as 32 bit.
> 
> Here is the point.
>   > "emulated devices can not support a 64 bit BAR"
> If target_phy_addr_t = uint32_t, the emulation of 64 bit BAR which
> is set to >4GB is cpu can't access it. So just not-mapping it
> is correct behavior.
> 
> 
> > > What happens if you take a PCI card that supports 64-bit BARs and stick  
> > > it into a machine that has a 32-bit physical address space?
> > > The firmware/OS will configure the BARs to below 4G.
> > > 
> > >> I think you are right that guests on such systems really do not have a
> > >> way to address PCI devices if BAR is set beyond 4G. But pci emulation is
> > >> better off not relying on this, IMO. Makes sense?
> > >>    
> > >
> > > No.  Device emulation shouldn't change with the machine type.
> > 
> > I agree. Issue is, we recompile the *devices* as well.
> > It's the device emulation that is broken when compiled
> > with target phys addr set to 32 bit, because all devices
> > take pcibus_t and cast it to target_phys_addr_t
> > and then do stuff with it.
> > So such emulation should not claim to support 64 bit.
> 
> Such case is checked by "last_addr >= TARGET_PHYS_ADDR_MAX",
> so the device emulation works well.
> 
> Generally device drivers know their devices. For example they know
> that BAR0 is 64bit memory and so on. So if BAR type were changed
> by forcing 64 bit BAR into 32 bit BAR, the device driver wouldn't be
> confused.
> 
> > Long term, we should fix all devices and *then* they can claim 64 bit
> > support always.  As a nice side effect, we'll be able to avoid
> > rebuilding devices.
> 
> Are you claiming that (PCI) devices emulation shouldn't depend on
> target_phys_addr_t? That sounds a good idea.

Yes. Maybe we can stop devices from mapping memory, have pci
core do it for them.

> However I don't agree on "*then*".
> The conversions would take place step by step as it's long term object.
> I don't see any reason to penalize correct device emulations just
> because there are incomplete device emulations left.

Hmm. Okay ... but which device emulations are correct?
It seems that none of them are.
I don't see the rush .

> thanks,
> -- 
> yamahata