RE: [PATCH] Align PCI memory regions to page size (4K) - Fix

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

 



> From: Greg KH [mailto:[email protected]]
> Sent: Sunday, October 28, 2007 10:04 PM
> To: Barak Fargoun
> Cc: [email protected];
> [email protected]; Guy Zana
> Subject: Re: [PATCH] Align PCI memory regions to page size (4K) - Fix
> 
> On Sun, Oct 28, 2007 at 03:53:20PM -0400, Barak Fargoun wrote:
> > Hi!
> > 
> > Regarding all the technical stuff (documentation, coding
> style, etc.)
> > - I thought I did it correctly :( I will fix it ASAP, and send an 
> > update when I will finish it.
> > 
> > About your question: today, some of the hypervisors are using linux 
> > kernel as their domain-0 (e.g. Xen). In order to implement direct 
> > hardware access for these native domains (e.g.  running
> windows in a
> > virtual machine above Xen), the PCI memory regions should
> be aligned
> > at-least at the page-level (so, a virtual machine - can't
> see data of
> > other devices which may not be assigned to it). So, for
> that reason,
> > we wanted a boot parameter to let us force the kernel to align PCI 
> > memory regions at-least at a PAGE_SIZE alignment. It is very useful 
> > for hypervisors which are developed at Linux environment
> (e.g.: Xen).
> 
> But doesn't aligning such regions on that alignment break some devices

> as that is not what the device is asking for in the BIOS?

No, it shouldn't break. If for example, a device request an alignment of
order 7, it will be provided if you will supply an alignment of larger
order (say 10 bits). An alignment of order that is bigger than 12 bits
is already page aligned, so we do not touch it in that case.

> 
> And if not, why would we not do this for all devices not just for 
> virtual machines, if it is such a benefit?

Since if a device asks for just 1K, the rest of the page (in mmio space)
will be empty if you'll page align it. The other resource will be in
another page and it consumes a separate page. It'll just consume
additional mmio space for nothing.

> 
> Also, how does this play with the hardware IOMMU chips that provide 
> such virtualization in hardware for you?

Actually we are not using an IOMMU, we use a 1:1 mapping that was
developed by Neocleus (for Xen right now), but that holds the same for
Intel VT-d as well.
IOMMUs are there to translate accesses to RAM from PCI devices, we are
more concerned about accesses by the host (cpu).
By using pci-mem-align, we assure that both the virtualized hardware &
the real hardware resources will be page aligned, this way we can remap
those pages so the HVM could safely access the hardware.

> 
> And, we can't accept a patch for 2.6.18, there is no development tree 
> to apply it to anymore, that is a dead kernel tree.  It needs to be 
> against
> 2.6.24-rc1 at the latest to have a chance for approval.
> 

Of course!
If you'll find it useful, we can make a progress and test it on the
latest rev and also do the changes that you asked.

> Is this a patch that distros are shipping in their Xen versions?

Actually, no one knows about it yet :-)

> 
> And how does this play with KVM?

Since we are working on Xen right now (dom0 is 2.6.18) and this feature
might be useful for other hypervisors that will implement pass-through
in the future (AFAIK KVM doesn't support PCI pass-through yet) we
thought to release it for Linux in general.

> 
> thanks,
> 
> greg k-h
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux