qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 2/2] Adding BAR0 for e500 PCI controller


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 2/2] Adding BAR0 for e500 PCI controller
Date: Sun, 07 Oct 2012 11:48:50 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1

On 10/05/2012 01:59 PM, Alexander Graf wrote:
>>>> Do you mean that we add the "MemoryRegion bar0" in PCIDevice struct. Do the
>>> same thing that I was doing in e500_pcihost_initfn() in the k->init() (will 
>>> add
>>> this) function of "e500-host-bridge"
>>> 
>>> No, he means that you create a new struct like this:
>>> 
>>>  struct foo {
>>>    PCIDevice p;
>>>    MemoryRegion bar0;
>>>  };
>>> 
>>> Please check out any other random PCI device in QEMU. Almost all of them do 
>>> this
>>> to store more information than their parent class can hold.
>> 
>> Just want to be sure I understood you correctly: Do you mean something like 
>> this : ( I know I have to switch to QOM mechanism to share parameters)
>> 
>> diff --git a/hw/ppce500_pci.c b/hw/ppce500_pci.c
>> index 92b1dc0..a948bc6 100644
>> --- a/hw/ppce500_pci.c
>> +++ b/hw/ppce500_pci.c
>> @@ -89,6 +89,12 @@ struct PPCE500PCIState {
>>     MemoryRegion iomem;
>> };
>> 
>> +struct BHARAT {
>> +    PCIDevice p;
>> +    void *bar0;
> 
> MemoryRegion *bar0

MemoryRegion bar0;

> 
>> +};
>> +
>> +typedef struct BHARAT bharat;
>> typedef struct PPCE500PCIState PPCE500PCIState;
>> 
>> static uint64_t pci_reg_read4(void *opaque, target_phys_addr_t addr,
>> @@ -307,6 +313,16 @@ static const VMStateDescription vmstate_ppce500_pci = {
>> 
>> #include "exec-memory.h"
>> 
>> +static int e500_pcihost_bridge_initfn(PCIDevice *d)
>> +{
>> +    bharat *b = DO_UPCAST(bharat, p, d);
>> +
>> +    printf("Addr = %llx, size = %llx\n", ((MemoryRegion *)b->bar0)->addr, 
>> (unsigned long long)int128_get64(((Me

memory_region_init_io(&d->bar0, ...);

>> +    pci_register_bar(d, 0, PCI_BASE_ADDRESS_SPACE_MEMORY, (MemoryRegion 
>> *)b->bar0);
> 
> That one still has to call its parent initfn, no?
> 

yes

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



reply via email to

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