qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [PATCH v6 2/3] VFIO: Introduce EEH handler


From: Gavin Shan
Subject: Re: [Qemu-ppc] [PATCH v6 2/3] VFIO: Introduce EEH handler
Date: Sat, 24 May 2014 12:09:12 +1000
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, May 23, 2014 at 08:58:25AM +0200, Alexander Graf wrote:
>> Am 23.05.2014 um 07:00 schrieb Gavin Shan <address@hidden>:
>>> On Thu, May 22, 2014 at 09:11:07PM -0600, Alex Williamson wrote:
>>>> On Thu, 2014-05-22 at 18:26 +1000, Gavin Shan wrote:

.../...

>>>> +int vfio_eeh_handler(int32_t cmd, void *data, PCIBus *rootbus, uint32_t 
>>>> addr)
>>>> +{
>>>> +    VFIODevice *vdev;
>>>> +    struct vfio_eeh_pe_set_option *option;
>>>> +    struct vfio_eeh_pe_get_addr *get_addr;
>>>> +    int ret = 0;
>>>> +
>>>> +    switch (cmd) {
>>>> +    case VFIO_EEH_PE_SET_OPTION:
>>>> +        option = data;
>>>> +        if (option->option == 1) {
>>> 
>>> What's 1?  Define it
>> 
>> The problem is which header file should define it. If I define it
>> in sPAPR specific header file, vfio.c has to include that header
>> file. That possiblly breaks build on other platforms (e.g. x86).
>> Even though it won't block x86 build, nobody want see vfio.c to
>> include platform specific header file, right? :-)
>
>It's part of the VFIO ABI, so it should be exported by the kernel's vfio 
>headers.
>

Yeah, it makes sense. I'll fix it in next revision. However, I'm
not post next revision before the the "QOM" implementation or "callback"
is figured out :-)

Thanks,
Gavin




reply via email to

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