Re: [v7][PATCH 06/16] hvmloader/pci: skip reserved ranges

["Chen, Tiejun" <tiejun.chen@intel.com>]

On 2015/7/15 19:05, George Dunlap wrote:
> On Wed, Jul 15, 2015 at 10:27 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 15.07.15 at 10:59, <tiejun.chen@intel.com> wrote:
>>> On 2015/7/15 16:34, Jan Beulich wrote:
>>>>>>> On 15.07.15 at 06:27, <tiejun.chen@intel.com> wrote:
>>>>> Furthermore, could we have this solution as follows?
>>>>
>>>> Yet more special casing code you want to add. I said no to this
>>>> model, and unless you can address the issue _without_ adding
>>>> a lot of special casing code, the answer will remain no (subject
>>>
>>> What about this?
>>>
>>> @@ -301,6 +301,19 @@ void pci_setup(void)
>>>                pci_mem_start <<= 1;
>>>        }
>>>
>>> +    for ( i = 0; i < memory_map.nr_map ; i++ )
>>> +    {
>>> +        uint64_t reserved_start, reserved_size;
>>> +        reserved_start = memory_map.map[i].addr;
>>> +        reserved_size = memory_map.map[i].size;
>>> +        if ( check_overlap(pci_mem_start, pci_mem_end - pci_mem_start,
>>> +                           reserved_start, reserved_size) )
>>> +        {
>>> +            printf("Reserved device memory conflicts current PCI memory.\n");
>>> +            BUG();
>>> +        }
>>> +    }
>>
>> So what would the cure be if someone ran into this BUG() (other
>> than removing the device associated with the conflicting RMRR)?
>> Afaics such a guest would remain permanently unbootable, which
>> of course is not an option.
>
> Is not booting worse than what we have now -- which is, booting
> successfully but (probably) having issues due to MMIO ranges
> overlapping RMRRs?

Its really so rare possibility here since in the real world we didn't 
see any RMRR regions >= 0xF0000000 (the default pci memory start.) And I 
already sent out a little better revision in that ensuing email so also 
please take a review if possible :)

>
> This patch series as a whole represents a lot of work and a lot of
> tangible improvements to the situation; and (unless the situation has
> changed) it's almost entirely acked apart from the MMIO placement
> part.  If there is a simple way that we can change hvmloader so that
> most (or even many) VM/device combinations work properly for the 4.6
> release, then I think it's worth considering.
>

Current MMIO allocation mechanism is not good. So we really need to 
reshape that, but we'd better do this with some further discussion in 
next release :)

Thanks
Tiejun