>>> On 15.07.15 at 12:34, <tiejun.c...@intel.com> wrote:
>>>> 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)?
> 
> Maybe I  can move this chunk of codes downward those actual allocation 
> to check if RDM conflicts with the final allocation, and then just 
> disable those associated devices by writing PCI_COMMAND without BUG() 
> like this draft code,

And what would keep the guest from re-enabling the device?

Jan


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

Reply via email to