Muli Ben-Yehuda <[EMAIL PROTECTED]> wrote:
>
>> And probably some similar mechanism for network drivers that limits
>> MTUs.
>
> Will that guarantee that block and net IOs will not straddle a page
> boundary?
Mostly. There is the thorny case of slab debugging that breaks
these nice assumptions.
On Wed, Jun 27, 2007 at 05:26:50PM +0200, Andi Kleen wrote:
> See the recent "quiet down swiotlb warnings" thread which uncovered
> quite some corpses in Xen's current IO setup.
>
> Xen apparently bounces for multi page IOs which get merged from block
> lists because the block layer doesn't know
Andi Kleen wrote:
On Wednesday 27 June 2007 16:15:17 Jeremy Fitzhardinge wrote:
Andi Kleen wrote:
Ok, if you can do it without ifdefs.
That should be OK. All the existing i386 mapping operations would just
have their own ops structure, right?
I just mention it because
On Wednesday 27 June 2007 16:15:17 Jeremy Fitzhardinge wrote:
> Andi Kleen wrote:
> > Ok, if you can do it without ifdefs.
> >
>
> That should be OK. All the existing i386 mapping operations would just
> have their own ops structure, right?
I just mention it because many people's ideas of m
Andi Kleen wrote:
Ok, if you can do it without ifdefs.
That should be OK. All the existing i386 mapping operations would just
have their own ops structure, right?
And no swiotlb on i386; that is something that is completely broken
in upstream Xen and needs to be fixed properly anyways.
On Tuesday 26 June 2007 21:59, Jeremy Fitzhardinge wrote:
> I'm looking at adding dom0 support to the pv-ops kernel. One of the
> obvious things we need is to support real device drivers, and the
> associated p->m translations for devices.
>
> I'm thinking the cleanest thing to do is make x86-64's
6 matches
Mail list logo
