LinuxLists.cc - [PATCH] Xen/i386 cleanups

[permalink] [raw]

Subject: Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

On Wed, Mar 16, 2005 at 11:48:29AM +0000, Keir Fraser wrote:
> This patch cleans up AGP driver treatment of bus/device memory. Every
> use of virt_to_phys/phys_to_virt should properly be converting between
> virtual and bus addresses: this distinction really matters for the Xen
> hypervisor.

It's bogus either way. You must never use virt_to_phys or virt_to_bus
for bus address. For systems with an IOMMU there's no 1:1 mapping.

2005-03-16 15:00:07

[permalink] [raw]

Subject: Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

> On Wed, Mar 16, 2005 at 11:48:29AM +0000, Keir Fraser wrote:
> > This patch cleans up AGP driver treatment of bus/device memory. Every
> > use of virt_to_phys/phys_to_virt should properly be converting between
> > virtual and bus addresses: this distinction really matters for the Xen
> > hypervisor.
>
> It's bogus either way. You must never use virt_to_phys or virt_to_bus
> for bus address. For systems with an IOMMU there's no 1:1 mapping.

Well, I'd say it's less bogus: it makes the intention clearer, and it
is a 'good enough' improvement for Xen. Indeed, it's good enough for
all the architectures that actually use the AGP drivers (all have no
IOMMU, or an IOMMU only to support legacy 32-bit I/O interfaces).

-- Keir

2005-03-16 15:05:17

[permalink] [raw]

Subject: Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

On Wed, 16 Mar 2005, Christoph Hellwig wrote:
> On Wed, Mar 16, 2005 at 11:48:29AM +0000, Keir Fraser wrote:
> > This patch cleans up AGP driver treatment of bus/device memory. Every
> > use of virt_to_phys/phys_to_virt should properly be converting between
> > virtual and bus addresses: this distinction really matters for the Xen
> > hypervisor.
>
> It's bogus either way. You must never use virt_to_phys or virt_to_bus
> for bus address. For systems with an IOMMU there's no 1:1 mapping.

In the case of AGP, the AGPGART effectively _is_ the
IOMMU. Calculating the addresses right for programming
the AGPGART is probably worth fixing.

--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

2005-03-16 17:43:50

by Alan

[permalink] [raw]

Subject: Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

On Mer, 2005-03-16 at 14:31, Christoph Hellwig wrote:
> It's bogus either way. You must never use virt_to_phys or virt_to_bus
> for bus address. For systems with an IOMMU there's no 1:1 mapping.

The AGPGART _is_ the IOMMU.

Alan

2005-03-16 17:58:59

by Jesse Barnes

[permalink] [raw]

Subject: Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

On Wednesday, March 16, 2005 3:48 am, Keir Fraser wrote:
> This patch cleans up AGP driver treatment of bus/device memory. Every
> use of virt_to_phys/phys_to_virt should properly be converting between
> virtual and bus addresses: this distinction really matters for the Xen
> hypervisor.
>
> Furthermore, when allocating the GATT, it is necessary to use
> dma_alloc_coherent rather than get_free_pages. Again, not a
> distinction that matters for i386, but very important for Xen and
> possibly for other architectures too.
>
> Signed-off-by: Keir Fraser <[email protected]>

Ugg, if we're messing with these drivers we may as well fix them properly
rather than adding in more uses of the broken virt_to_bus interface...

Jesse

2005-03-16 18:10:48

[permalink] [raw]

Subject: Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

On Wed, Mar 16, 2005 at 10:01:07AM -0500, Rik van Riel wrote:
> In the case of AGP, the AGPGART effectively _is_ the
> IOMMU. Calculating the addresses right for programming
> the AGPGART is probably worth fixing.

Well, it's a half-assed one. And some systems have a real one.

But the real problem is that virt_to_bus doesn't exist at all
on architectures like ppc64, and this patch touches files like
generic.c and backend.c that aren't PC-specific. So you
effectively break agp support for them.

2005-03-16 18:33:37

[permalink] [raw]

Subject: Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

On 16 Mar 2005, at 18:10, Christoph Hellwig wrote:

> On Wed, Mar 16, 2005 at 10:01:07AM -0500, Rik van Riel wrote:
>> In the case of AGP, the AGPGART effectively _is_ the
>> IOMMU. Calculating the addresses right for programming
>> the AGPGART is probably worth fixing.
>
> Well, it's a half-assed one. And some systems have a real one.
>
> But the real problem is that virt_to_bus doesn't exist at all
> on architectures like ppc64, and this patch touches files like
> generic.c and backend.c that aren't PC-specific. So you
> effectively break agp support for them.

The AGP driver is only configurable for ppc32, alpha, x86, x86_64 and
ia64, all of which have virt_to_bus.

-- Keir

2005-03-16 18:48:47

by Jesse Barnes

[permalink] [raw]

Subject: Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

On Wednesday, March 16, 2005 10:35 am, Keir Fraser wrote:
> On 16 Mar 2005, at 18:10, Christoph Hellwig wrote:
> > On Wed, Mar 16, 2005 at 10:01:07AM -0500, Rik van Riel wrote:
> >> In the case of AGP, the AGPGART effectively _is_ the
> >> IOMMU. Calculating the addresses right for programming
> >> the AGPGART is probably worth fixing.
> >
> > Well, it's a half-assed one. And some systems have a real one.
> >
> > But the real problem is that virt_to_bus doesn't exist at all
> > on architectures like ppc64, and this patch touches files like
> > generic.c and backend.c that aren't PC-specific. So you
> > effectively break agp support for them.
>
> The AGP driver is only configurable for ppc32, alpha, x86, x86_64 and
> ia64, all of which have virt_to_bus.

Yeah, but that doesn't mean it makes sense on all those platforms. The
biggest problem with virt_to_bus (well, depending on who you talk to) is that
it can't handle systems where the address translation must be done
differently depending on *which* bus we're getting a bus address for. Not
sure what makes sense in this case though... is the DMA mapping interface
appropriate?

Jesse

2005-03-16 19:06:02

[permalink] [raw]

Subject: Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

On 16 Mar 2005, at 18:42, Jesse Barnes wrote:

>> The AGP driver is only configurable for ppc32, alpha, x86, x86_64 and
>> ia64, all of which have virt_to_bus.
>
> Yeah, but that doesn't mean it makes sense on all those platforms. The
> biggest problem with virt_to_bus (well, depending on who you talk to)
> is that
> it can't handle systems where the address translation must be done
> differently depending on *which* bus we're getting a bus address for.
> Not
> sure what makes sense in this case though... is the DMA mapping
> interface
> appropriate?

I think that makes sense. How much code refactoring is needed to make
use of it, though?

Certainly it will work for Xen and it sounds better than
virt_to_bus/bus_to_virt, if someone will cook up the alternative patch.
Otherwise, virt_to_bus seems better than the status quo. :-)

-- Keir

2005-03-16 19:08:17

[permalink] [raw]

Subject: Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

On Wed, Mar 16, 2005 at 06:35:28PM +0000, Keir Fraser wrote:
>
> On 16 Mar 2005, at 18:10, Christoph Hellwig wrote:
>
> >On Wed, Mar 16, 2005 at 10:01:07AM -0500, Rik van Riel wrote:
> >>In the case of AGP, the AGPGART effectively _is_ the
> >>IOMMU. Calculating the addresses right for programming
> >>the AGPGART is probably worth fixing.
> >
> >Well, it's a half-assed one. And some systems have a real one.
> >
> >But the real problem is that virt_to_bus doesn't exist at all
> >on architectures like ppc64, and this patch touches files like
> >generic.c and backend.c that aren't PC-specific. So you
> >effectively break agp support for them.
>
> The AGP driver is only configurable for ppc32, alpha, x86, x86_64 and
> ia64, all of which have virt_to_bus.

and ppc64 now, which doesn't.

2005-03-16 19:12:49

[permalink] [raw]

Subject: Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

On 16 Mar 2005, at 19:06, Christoph Hellwig wrote:

>> The AGP driver is only configurable for ppc32, alpha, x86, x86_64 and
>> ia64, all of which have virt_to_bus.
>
> and ppc64 now, which doesn't.

Sounds like the new DMA-mapping interface is the way to go then.

-- Keir

2005-03-16 21:25:29

[permalink] [raw]

Subject: Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

Keir Fraser writes:

> This patch cleans up AGP driver treatment of bus/device memory. Every
> use of virt_to_phys/phys_to_virt should properly be converting between
> virtual and bus addresses: this distinction really matters for the Xen
> hypervisor.

I think you are misunderstanding the distinction between physical
addresses and bus addresses. Specifically, it seems wrong to me to be
putting bus addresses into the GATT rather than physical addresses.

For example, on my G5, physical addresses are 36 bits (in the
hardware) but bus addresses are only 32 bits. Using bus addresses in
the GATT would mean that I couldn't put any memory above the 4GB point
into the GATT.

The distinction is that physical addresses are what are used to access
physical memory, whereas bus addresses are what appears on some
external bus (usually PCI). The GATT sits between an external (AGP)
bus and memory, so while the GATT is indexed using bus addresses, its
entries contain physical addresses. So in fact virt_to_phys is the
correct thing to use to calculate values to put in GATT entries.

Paul.

2005-03-16 22:09:10

by Jesse Barnes

[permalink] [raw]

Subject: Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

On Wednesday, March 16, 2005 1:24 pm, Paul Mackerras wrote:
> Keir Fraser writes:
> > This patch cleans up AGP driver treatment of bus/device memory. Every
> > use of virt_to_phys/phys_to_virt should properly be converting between
> > virtual and bus addresses: this distinction really matters for the Xen
> > hypervisor.
>
> I think you are misunderstanding the distinction between physical
> addresses and bus addresses. Specifically, it seems wrong to me to be
> putting bus addresses into the GATT rather than physical addresses.
>
> For example, on my G5, physical addresses are 36 bits (in the
> hardware) but bus addresses are only 32 bits. Using bus addresses in
> the GATT would mean that I couldn't put any memory above the 4GB point
> into the GATT.
>
> The distinction is that physical addresses are what are used to access
> physical memory, whereas bus addresses are what appears on some
> external bus (usually PCI). The GATT sits between an external (AGP)
> bus and memory, so while the GATT is indexed using bus addresses, its
> entries contain physical addresses. So in fact virt_to_phys is the
> correct thing to use to calculate values to put in GATT entries.

Thanks for the explanation Paul, now the code actually makes sense.
Converting to the DMA mapping API doesn't make sense at all in this context
then, since we're basically programming the GATT (an IOMMU type table) with
physical addresses. Ken, are you sure you need to make these changes at all?
Does Xen break w/o them?

Jesse

2005-03-16 23:56:26

[permalink] [raw]

Subject: Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

On Wed, 16 Mar 2005, Jesse Barnes wrote:

> Thanks for the explanation Paul, now the code actually makes sense.
> Converting to the DMA mapping API doesn't make sense at all in this context
> then, since we're basically programming the GATT (an IOMMU type table) with
> physical addresses. Ken, are you sure you need to make these changes at all?
> Does Xen break w/o them?

Thing is, the rest of the kernel uses virt_to_phys for
two different things. Only one of them has to do with
the real physical address, the other is about getting
the page frame number.

On native x86, x86-64 and others, the page frame number
and physical address are directly related to each other.
Under Xen, however, the two are different - and the
AGPGART really needs to have the physical address ;)

--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

2005-03-17 00:50:05

[permalink] [raw]

Subject: Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

Rik van Riel writes:

> Thing is, the rest of the kernel uses virt_to_phys for
> two different things. Only one of them has to do with
> the real physical address, the other is about getting
> the page frame number.

So fix the places that are using virt_to_phys to get the page frame
number to use virt_to_pfn instead. :)

> On native x86, x86-64 and others, the page frame number
> and physical address are directly related to each other.
> Under Xen, however, the two are different - and the
> AGPGART really needs to have the physical address ;)

If Xen is letting the kernel program the GART, you just lost any
memory isolation between partitions you might have been trying to
enforce. :)

Paul.

2005-03-17 01:05:59

by Tupshin Harper

[permalink] [raw]

Subject: Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

Paul Mackerras wrote:

>Rik van Riel writes:
>
>
>
>>Thing is, the rest of the kernel uses virt_to_phys for
>>two different things. Only one of them has to do with
>>the real physical address, the other is about getting
>>the page frame number.
>>
>>
>
>So fix the places that are using virt_to_phys to get the page frame
>number to use virt_to_pfn instead. :)
>
>
>
>>On native x86, x86-64 and others, the page frame number
>>and physical address are directly related to each other.
>>Under Xen, however, the two are different - and the
>>AGPGART really needs to have the physical address ;)
>>
>>
>
>If Xen is letting the kernel program the GART, you just lost any
>memory isolation between partitions you might have been trying to
>enforce. :)
>
>
Since xen only lets the dom0 (privileged domain) program the GART, all
of the domU's (non-privileged domains) are still isolated from each other.

-Tupshin

2005-03-17 03:44:18

[permalink] [raw]

Subject: Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

On Thu, 17 Mar 2005, Paul Mackerras wrote:

> > Under Xen, however, the two are different - and the
> > AGPGART really needs to have the physical address ;)
>
> If Xen is letting the kernel program the GART, you just lost any
> memory isolation between partitions you might have been trying to
> enforce. :)

All the device drivers live in domain 0, so Xen doesn't
need its own set of device drivers.

--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

2005-03-17 04:42:49

[permalink] [raw]

Subject: Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

On Wed, Mar 16, 2005 at 06:55:13PM -0500, Rik van Riel wrote:
> Thing is, the rest of the kernel uses virt_to_phys for
> two different things. Only one of them has to do with
> the real physical address, the other is about getting
> the page frame number.

The latter usage has been converted to page_to_pfn(virt_to_page(v))
in the places I checked.

2005-03-17 04:58:32

[permalink] [raw]

Subject: Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

On Thu, 17 Mar 2005, Christoph Hellwig wrote:
> On Wed, Mar 16, 2005 at 06:55:13PM -0500, Rik van Riel wrote:
> > Thing is, the rest of the kernel uses virt_to_phys for
> > two different things. Only one of them has to do with
> > the real physical address, the other is about getting
> > the page frame number.
>
> The latter usage has been converted to page_to_pfn(virt_to_page(v))
> in the places I checked.

Nice. Maybe then virt_to_phys can do the right thing (for AGP)
in Xen without other stuff breaking ?

--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

2005-03-17 09:14:03

[permalink] [raw]

Subject: Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

On 16 Mar 2005, at 22:06, Jesse Barnes wrote:

>> The distinction is that physical addresses are what are used to access
>> physical memory, whereas bus addresses are what appears on some
>> external bus (usually PCI). The GATT sits between an external (AGP)
>> bus and memory, so while the GATT is indexed using bus addresses, its
>> entries contain physical addresses. So in fact virt_to_phys is the
>> correct thing to use to calculate values to put in GATT entries.
>
> Thanks for the explanation Paul, now the code actually makes sense.
> Converting to the DMA mapping API doesn't make sense at all in this
> context
> then, since we're basically programming the GATT (an IOMMU type table)
> with
> physical addresses. Ken, are you sure you need to make these changes
> at all?
> Does Xen break w/o them?

Yes, Xen will break w/o them, because physical addresses are an
illusory trick that the guest OS plays on itself to give itself the
impression of a contiguous memory map. We use _to_machine and _to_bus
macros to get 'real' physical addresses.

For allocating the GATT itself, using dma_alloc_coherent() as done in
my patch certainly seems sane -- the bus base address of that table is
poked into a chipset register, right?

As for poking entries into the GATT, I guess I'm not sure what ought to
be used. virt_to_phys() doesn't sound right to me: the GART is a bridge
between two buses, so some sort of bus mapping would still be in order
imo. Perhaps Linux should allow mapping requests to be tagged with a
bridge id, like in *BSD? :-)

So: I would very much like you to take the patches I made to generic.c
that replace __get_free_pages() calls with dma_alloc_coherent(). For
now, the patch lines that poke into the GATT I guess stay as they are.
We can maintain an out-of-tree patch for Xen, or perhaps if
virt_to_phys() is not used very much we can override its definition.

-- Keir

2005-03-17 09:33:57

[permalink] [raw]

Subject: Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

Keir Fraser writes:

> Yes, Xen will break w/o them, because physical addresses are an
> illusory trick that the guest OS plays on itself to give itself the
> impression of a contiguous memory map. We use _to_machine and _to_bus
> macros to get 'real' physical addresses.

This code needs real physical addresses, which are not the same things
as bus addresses. I thought from what Rik said that virt_to_phys
should give you real physical addresses, while virt_to_pfn would give
you the contiguous "physical" page numbers - is that the case?

> For allocating the GATT itself, using dma_alloc_coherent() as done in
> my patch certainly seems sane -- the bus base address of that table is
> poked into a chipset register, right?

Well, a northbridge register. The northbridge is in a privileged
position in that it controls the memory and can access all of it
directly using physical addresses, something which PCI or other
devices can't. The address you poke into a register to define the
base of the table is a physical address. How could it be a bus
address, when the whole point of the table is to translate bus
addresses to physical addresses? If it was a bus address you would
have to know where the table was before you could work out where the
table was.

> As for poking entries into the GATT, I guess I'm not sure what ought to
> be used. virt_to_phys() doesn't sound right to me: the GART is a bridge
> between two buses, so some sort of bus mapping would still be in order

No, the GART is a bridge between a bus and memory, and the GATT
entries are physical addresses.

> So: I would very much like you to take the patches I made to generic.c
> that replace __get_free_pages() calls with dma_alloc_coherent(). For

This is also wrong - the base address of the GATT is a physical
address not a bus address. This change will break agpgart on ppc64
systems and I won't be able to play bzflag on my G5 any more. :)
dma_alloc_coherent allocates iommu entries and returns a bus address,
but the addresses coming out of the GART don't go through a further
translation through the iommu.

> now, the patch lines that poke into the GATT I guess stay as they are.
> We can maintain an out-of-tree patch for Xen, or perhaps if
> virt_to_phys() is not used very much we can override its definition.

It sounds like xen is trying to overload the concepts of physical and
bus addresses to represent the mapping from "logical" addresses seen
by the kernel to "absolute" addresses (the "real" physical
addresses). IMHO that is a mistake and will only lead to trouble.

Regards,
Paul.

2005-03-17 11:51:30

[permalink] [raw]

Subject: Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

> > So: I would very much like you to take the patches I made to generic.c
> > that replace __get_free_pages() calls with dma_alloc_coherent(). For
>
> This is also wrong - the base address of the GATT is a physical
> address not a bus address. This change will break agpgart on ppc64
> systems and I won't be able to play bzflag on my G5 any more. :)
> dma_alloc_coherent allocates iommu entries and returns a bus address,
> but the addresses coming out of the GART don't go through a further
> translation through the iommu.

Okay, thank you for clearing up my confusion over how the GART
actually works. :-) I see you are right: my current patch is indeed
bogus, sorry about that. Unfortunately this means that some other
solution needs to be found for Xen....

> > now, the patch lines that poke into the GATT I guess stay as they are.
> > We can maintain an out-of-tree patch for Xen, or perhaps if
> > virt_to_phys() is not used very much we can override its definition.
>
> It sounds like xen is trying to overload the concepts of physical and
> bus addresses to represent the mapping from "logical" addresses seen
> by the kernel to "absolute" addresses (the "real" physical
> addresses). IMHO that is a mistake and will only lead to trouble.

Well, actually it has worked well for us so far. Our model of memory
allocation amongst Xen guests is fine-grained (page granularity). The
fact a guest can get random sparse physical pages does not fit well
with Linux's expectation (even with discontig-mem builds) of at least
getting fairly large contiguous physical chunks of RAM.

For this reason, we do rather abuse the notion of 'phys'
addresses. But we get away with it because it really doesn't matter to
the VM system that these addresses bear no relation to reality. In
most cases that it does matter it is because we are programming an I/O
device, in which case we have convenient hook points (bus-address
macros and the DMA-mapping interface). Another slightly tricky one was
block-I/O buffer merging but, again, we found a fairly clean way of
hooking that in an appropriate manner.

Even generic IOMMUs we will be able to handle -- we have control of
the DMA-mapping interface in arch/xen -- so it seems to be the case
that AGPGART is the one significant spanner in the works for us,
because it is an IOMMU in the form of a generic (arch-agnostic)
driver.

So: how about the following solution. It's a bit more distasteful
than I'd like, but I see no alternative apart from us maintaining an
out-of-tree patch to be applied only when building Linux for Xen.
What we need are four hook functions to be defined and used in place
of virt_to_phys, phys_to_virt, __get_free_pages, and
free_pages. Possible names might be:
To go into asm/io.h:
virt_to_fsb, fsb_to_virt, alloc_fsb_pages, free_fsb_pages
Or, to go into asm/agp.h:
agp_virt_to_phys, agp_phys_to_virt, agp_alloc/free_pages
The former names are an attempt to make the hooks a bit more 'generic'
by defining something applicable wherever you want an address that is
usable directly on the front-side bus. The latter are a bit hackier,
but then, maybe that is appropriate. :-)

I'd be happy to cook up a patch to do this if it isn't too offensive
for anyone.

-- Keir

2005-03-17 13:56:19

by Alan

[permalink] [raw]

Subject: Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

On Iau, 2005-03-17 at 09:34, Paul Mackerras wrote:
> This code needs real physical addresses, which are not the same things
> as bus addresses.

Not always. The code needs platform specific goodies. We've only never
been burned so far because there isn't a box with an IOMMU and AGPGART
where one maps through the other.

It's probably simplest to have phys_to_agp/agp_to_phys therefore ?

Alan

2005-03-18 00:16:38

[permalink] [raw]

Subject: Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

Alan Cox writes:

> On Iau, 2005-03-17 at 09:34, Paul Mackerras wrote:
> > This code needs real physical addresses, which are not the same things
> > as bus addresses.
>
> Not always. The code needs platform specific goodies. We've only never
> been burned so far because there isn't a box with an IOMMU and AGPGART
> where one maps through the other.

That sounds like a good way to make AGP accesses slower. :)

Seriously, given that AGP is a technology that is being superseded by
PCI Express, I think it's reasonable to look at the range of current
implementations to see what we have to cope with. So I don't think
it's worth worrying too much about the possibility of GARTs that go
through the IOMMU. However, the idea of having phys_to_agp/agp_to_phys
(or virt_to_agp/agp_to_virt) sounds like it wouldn't be too much
effort, if it would help Xen.

Paul.

2005-03-18 04:23:32

[permalink] [raw]

Subject: Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

On Fri, 18 Mar 2005, Paul Mackerras wrote:

> However, the idea of having phys_to_agp/agp_to_phys (or
> virt_to_agp/agp_to_virt) sounds like it wouldn't be too much effort, if
> it would help Xen.

It would be absolutely trivial. On most architectures you would have:

#define virt_to_agp virt_to_phys
#define agp_to_virt phys_to_virt

On Xen you would have:

#define virt_to_agp virt_to_bus
#define agp_to_virt bus_to_virt

Or, more likely, defined to arbitrary_machine_to_phys
or whatever it was called ;)

--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

2005-03-18 09:03:23

[permalink] [raw]

Subject: Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

On 18 Mar 2005, at 00:16, Paul Mackerras wrote:

> That sounds like a good way to make AGP accesses slower. :)
>
> Seriously, given that AGP is a technology that is being superseded by
> PCI Express, I think it's reasonable to look at the range of current
> implementations to see what we have to cope with. So I don't think
> it's worth worrying too much about the possibility of GARTs that go
> through the IOMMU. However, the idea of having phys_to_agp/agp_to_phys
> (or virt_to_agp/agp_to_virt) sounds like it wouldn't be too much
> effort, if it would help Xen.

I'll post a patch for this next week. Thanks for your patience so far!

-- Keir

2005-03-19 10:11:01

by Eric W. Biederman

[permalink] [raw]

Subject: Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

Keir Fraser <[email protected]> writes:

> > > now, the patch lines that poke into the GATT I guess stay as they are.
> > > We can maintain an out-of-tree patch for Xen, or perhaps if
> > > virt_to_phys() is not used very much we can override its definition.
> >
> > It sounds like xen is trying to overload the concepts of physical and
> > bus addresses to represent the mapping from "logical" addresses seen
> > by the kernel to "absolute" addresses (the "real" physical
> > addresses). IMHO that is a mistake and will only lead to trouble.
>
> Well, actually it has worked well for us so far. Our model of memory
> allocation amongst Xen guests is fine-grained (page granularity). The
> fact a guest can get random sparse physical pages does not fit well
> with Linux's expectation (even with discontig-mem builds) of at least
> getting fairly large contiguous physical chunks of RAM.

There is data excess data structure but it fits fine. You simply
allocate one region and set PG_reserved on all of the pages that
the OS does not have access too. Trivial and you don't have
to hack anything.

Larger than 4K granularity pages are important for performance reasons
in a number of contexts. The primary reason is the large pages allow
a reduction in tlb misses. But it is worth noting that DRAM pages
can be as large as 32KiB. So there are other cases where there are
benefits in dealing with contiguous memory addresses besides reducing
the tlb miss count.

> For this reason, we do rather abuse the notion of 'phys'
> addresses. But we get away with it because it really doesn't matter to
> the VM system that these addresses bear no relation to reality. In
> most cases that it does matter it is because we are programming an I/O
> device, in which case we have convenient hook points (bus-address
> macros and the DMA-mapping interface). Another slightly tricky one was
> block-I/O buffer merging but, again, we found a fairly clean way of
> hooking that in an appropriate manner.

You also have broken kexec.

And how well does hugetlbfs work under Xen?

> I'd be happy to cook up a patch to do this if it isn't too offensive
> for anyone.

For this specific case there may be another resolution but could
you please, please look at marking the missing pages PG_reserved
and not hacking phys_to_virt.

At this point anything short of explicitly introducing an intermediate
step say virt_to_logical() logical_to_virt() will be extremely
confusing and lead to very hard to spot bugs. Silently changing
the semantics of functions is bad.

Eric

2005-03-19 10:56:56

by Christian Limpach

[permalink] [raw]

Subject: Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups

On Sat, Mar 19, 2005 at 03:07:18AM -0700, Eric W. Biederman wrote:
> For this specific case there may be another resolution but could
> you please, please look at marking the missing pages PG_reserved
> and not hacking phys_to_virt.
>
> At this point anything short of explicitly introducing an intermediate
> step say virt_to_logical() logical_to_virt() will be extremely
> confusing and lead to very hard to spot bugs. Silently changing
> the semantics of functions is bad.

We also use the additional level of indirection to implement suspend/
resume and relocation of virtual machines between physical machines --
you won't get the same sparse allocation of memory on the target machine.
Also, this will make it much easier to support hot plug memory at the
hypervisor level since it will be able to substitute memory with very
little support from the OS running in the virtual machine.
I agree that adding an additional step would make this much cleaner.

christian

2005-03-19 13:02:59