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