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

Re: [Xen-devel] [PATCH] ns16550: limit mapped MMIO size



>>> On 16.11.15 at 17:52, <ian.campbell@xxxxxxxxxx> wrote:
> On Thu, 2015-11-12 at 08:52 -0700, Jan Beulich wrote:
>> There's no point in mapping more than the memory we actually may need
>> to touch, and in fact the too large region could actually extend into
>> another device's one (which currently is benign on x86 since only a
>> single page gets mapped anyway, but which is a latent bug on ARM
>> whenever PCI support gets enabled there).
>> 
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> 
>> --- a/xen/drivers/char/ns16550.c
>> +++ b/xen/drivers/char/ns16550.c
>> @@ -931,6 +931,8 @@ pci_uart_config (struct ns16550 *uart, i
>>                          uart->io_base += bar_idx *
>> uart_param[p].uart_offset;
>>                          if ( uart_param[p].base_baud )
>>                              uart->clock_hz = uart_param[p].base_baud *
>> 16;
>> +                        size = max(8U << uart_param[p].reg_shift,
>> +                                   uart_param[p].uart_offset);
> 
> I assume 8 bytes (suitably shifted as above) corresponds to the "need to
> touch" set of registers, but I can't fathom the link to uart_offset, rather
> than uart_offset + those 8 bytes or something like that.

uart_offset represents the range of I/O-ports or MMIO that individual
ports are apart. Since advanced functionality may require access to
more than the legacy 8 registers range, and since everything is part of
a single BAR, it seems appropriate to use the maximum of the two
values.

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