qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] Re: [PATCH V6 17/32] pci: 64bit bar support.
Date: Tue, 3 Nov 2009 15:21:00 +0200
User-agent: Mutt/1.5.19 (2009-01-05)

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.
> >>
> >>    
> >
> > 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.
> 
> 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.

BTW, the right way to do this is probably to move mapping device memory
out of devices proper and into pci.


> > -- 
> > error compiling committee.c: too many arguments to function




reply via email to

[Prev in Thread] Current Thread [Next in Thread]