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

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



>>> On 15.07.15 at 13:05, <George.Dunlap@xxxxxxxxxxxxx> wrote:
> 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:
>>> 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?

Again a matter of perspective: For devices (USB!) where the RMRR
exists solely for boot time (or outdated OS) use, this would be a
plain regression. For the graphics device Tiejun needs this for, it of
course would make little difference, I agree.

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.