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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Wed, Jul 15, 2015 at 10:27 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 15.07.15 at 10:59, <tiejun.chen@xxxxxxxxx> wrote:
>> On 2015/7/15 16:34, Jan Beulich wrote:
>>>>>> On 15.07.15 at 06:27, <tiejun.chen@xxxxxxxxx> 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?

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.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel