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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 07/15/2015 12:20 PM, Chen, Tiejun wrote:
> On 2015/7/15 19:05, George Dunlap 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:
>>>> 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?
> 
> 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 :)

Do remember the context we're talking about. :-)  Jan said, *if* there
was a device that had an RMRR conflict with the "default" MMIO
placement, then the guest simply wouldn't boot.  I was saying, in that
case, we move from "silently ignore the conflict, possibly making the
device not work" to "guest refuses to boot".  Which, if it was
guaranteed that a conflict would cause the device to no longer work,
would be an improvement.

>> 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 :)

Absolutely; I was saying, if we can put in a "good enough" measure for
this release, then we can get the rest of the patch series in with our
"good enough" hvmloader fix, and then work on fixing it properly next
release.

But if you're not aiming for this release anymore, then our aims are
something different.  (See my other e-mail.)

 -George



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