On Mon, Apr 25, 2011 at 7:48 PM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
It seems that Solaris doesn't set up a DMA mapping for the LANCE DMA buffers and hence must inherit this from OpenBIOS. To make things more complicated, Solaris appears to assume that the buffers are fixed at 0xff000000 rather than detecting this information from the OpenBIOS IOMMU pagetable before switching. Mimicking this behaviour with a fixed location allows Solaris 8 to correctly use the network card under QEMU.
Signed-off-by: Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk
Would it make any difference if IOMMU region were 16M so that the base would start at 0xff000000?
Otherwise the patch looks OK.
On 25/04/11 19:11, Blue Swirl wrote:
Would it make any difference if IOMMU region were 16M so that the base would start at 0xff000000?
Otherwise the patch looks OK.
Maybe, but there are still difficulties with that. For example, ESP claims its IOMMU memory first, so I was seeing that ESP would get 0xfe000000 while LANCE would get 0xfe001000 - so even changing the base is no guarantee this will work. And of course, as soon as the kernel takes over the IOMMU page table then the existing mappings disappear - unless there is some weird kernel logic that only preserves mappings above a certain limit such as 0xff000000?
So in short, given the amount of effort involved for a similar result I don't see many advantages over the fixed address mapping implemented in the patch.
ATB,
Mark.
On Mon, Apr 25, 2011 at 10:05 PM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
On 25/04/11 19:11, Blue Swirl wrote:
Would it make any difference if IOMMU region were 16M so that the base would start at 0xff000000?
Otherwise the patch looks OK.
Maybe, but there are still difficulties with that. For example, ESP claims its IOMMU memory first, so I was seeing that ESP would get 0xfe000000 while LANCE would get 0xfe001000 - so even changing the base is no guarantee this will work. And of course, as soon as the kernel takes over the IOMMU page table then the existing mappings disappear - unless there is some weird kernel logic that only preserves mappings above a certain limit such as 0xff000000?
So in short, given the amount of effort involved for a similar result I don't see many advantages over the fixed address mapping implemented in the patch.
It's fine then. It's just good to know that this is a bit of a hack.
On 25/04/11 21:51, Blue Swirl wrote:
So in short, given the amount of effort involved for a similar result I don't see many advantages over the fixed address mapping implemented in the patch.
It's fine then. It's just good to know that this is a bit of a hack.
That's what it feels like, although I would say it's a workaround for a Solaris kernel bug. Hopefully the commit message and the comment are verbose enough so that if/when someone does work out what the right behaviour should be, they can change it with a reasonable degree of confidence.
Are you happy for me to commit this, with just a minor change to add the CONFIG_DEBUG_SBUS variable into sparc32_config.xml?
ATB,
Mark.
On Tue, Apr 26, 2011 at 12:59 AM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
On 25/04/11 21:51, Blue Swirl wrote:
So in short, given the amount of effort involved for a similar result I don't see many advantages over the fixed address mapping implemented in the patch.
It's fine then. It's just good to know that this is a bit of a hack.
That's what it feels like, although I would say it's a workaround for a Solaris kernel bug. Hopefully the commit message and the comment are verbose enough so that if/when someone does work out what the right behaviour should be, they can change it with a reasonable degree of confidence.
Are you happy for me to commit this, with just a minor change to add the CONFIG_DEBUG_SBUS variable into sparc32_config.xml?
Yes, it's OK.
Maybe we should also have tracepoints like QEMU or Linux kernel. Something that can be enabled at run time.
-
Blue Swirl -
Mark Cave-Ayland