qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] pci: add standard bridge device


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH] pci: add standard bridge device
Date: Sun, 4 Sep 2011 17:54:26 +0300
User-agent: Mutt/1.5.21 (2010-09-15)

On Sun, Sep 04, 2011 at 05:36:56PM +0300, Avi Kivity wrote:
> On 09/04/2011 05:21 PM, Michael S. Tsirkin wrote:
> >>  >
> >>  >+static pcibus_t pci_bridge_get_size(const PCIDevice *bridge, uint8_t 
> >> type)
> >>  >+{
> >>  >+    return pci_bridge_get_limit(bridge, type)>=
> >>  >+        pci_bridge_get_base(bridge, type) ?
> >>  >+        pci_bridge_get_limit(bridge, type) -
> >>  >+        pci_bridge_get_base(bridge, type)  + 1 : 0;
> >>  >+}
> >>
> >>  Correct
> >
> >To make sure: 0 size is ok?
> 
> Yes.
> 
> >
> >>  but unreadable.
> >
> >variables will make it clearer.
> >
> >base = pci_bridge_get_base(bridge, type);
> >limit = pci_bridge_get_limit(bridge, type);
> >return limit>= bridge ? limit - base + 1 : 0;
> 
> So long as we're nitpicking, limit + 1 - base.

If this makes you happier, OK :)

> >
> >
> >>   Doesn't work for limit == 2^64-1, is this a
> >>  possible value?
> >
> >You mean when base == 0?  Yes, but what can I do?
> >This seems to be an API limitation of the memory API:
> >memory_region_init(sec_bus->address_space_mem, "pci_pridge_pci", INT64_MAX);
> >and the same for aliases: max size seems to be INT64_MAX,
> >the last byte isn't covered.
> 
> Right.
> 
> >The only way to fix this would be to pass first/last instead
> >of offset/size. Too late for such an API change?
> 
> Way too late.  And also won't work, since often the offset is
> determined by one party and the size by another.

For things like BARs, yes - but these don't need to be
that big normally. We could add an additinal API
that gets first/last parameters. last < first means 0 size.
Feasible?

> >VGA I/O addresses (including ISA aliases address - AD[15::10] are not
> >decoded):
> >AD[9::0] = 3B0h through 3BBh and 3C0h through 3DFh
> 
> These "not decoded" bits mean you need to instantiate tons of
> aliases to implement correctly.
> I plan to add core support for that eventually.

There's a flag to enable 16-bit decode actually:
bit 4 in bridge control register.
How does VGA work at the moment without a bridge? Ignores the ISA aliases?
then we can do that too I think.

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



reply via email to

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