Re: [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

["Jan Beulich" <JBeulich@suse.com>]

>>> On 30.05.18 at 06:32, <x1917x@gmail.com> wrote:
>> On Wed, 30 May 2018 03:56:07 +1000
>>Alexey G <x1917x@gmail.com> wrote:
>>
>>>On Tue, 29 May 2018 08:23:51 -0600
>>>"Jan Beulich" <JBeulich@suse.com> wrote:
>>>  
>>>>>>> On 12.03.18 at 19:33, <x1917x@gmail.com> wrote:      
>>>>> --- a/tools/firmware/hvmloader/config.h
>>>>> +++ b/tools/firmware/hvmloader/config.h
>>>>> @@ -53,10 +53,14 @@ extern uint8_t ioapic_version;
>>>>>  #define PCI_ISA_DEVFN       0x08    /* dev 1, fn 0 */
>>>>>  #define PCI_ISA_IRQ_MASK    0x0c20U /* ISA IRQs 5,10,11 are PCI connected */
>>>>>  #define PCI_ICH9_LPC_DEVFN  0xf8    /* dev 31, fn 0 */
>>>>> +#define PCI_MCH_DEVFN       0       /* bus 0, dev 0, func 0 */      
>>>>
>>>>Just MCH is liable to become ambiguous in the future. Perhaps PCI_Q35_MCH_DEVFN?    
>>>
>>>Agree, PCI_Q35_MCH_DEVFN is more explicit.
> 
> On the other thought, we can reuse one MCH BDF #define for multiple
> emulated chipsets, not just for something completely distinct to Q35
> but even for those which mostly require merely changing PCI DIDs (like
> P35 etc.) So in this case producing multiple #defines like
> PCI_{Q|P|G}35_MCH_DEVFN for the same BDF 0:0.0 might be excessive.
> 
> PCI_ICH9_LPC_DEVFN can be actually reused too, its BDF location
> survived many chipset generations so its #define can be shared as well
> (though renamed to something like PCI_LPC_BRIDGE_DEVFN).

PCI_x35_MCH_DEVFN then, with a brief comment explaining the x?

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel