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

["Chen, Tiejun" <tiejun.chen@xxxxxxxxx>]

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



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