On 9/24/08, Blue Swirl <blauwirbel@xxxxxxxxx> wrote: > On 9/23/08, David Miller <davem@xxxxxxxxxxxxx> wrote: > > From: "Blue Swirl" <blauwirbel@xxxxxxxxx> > > > > Date: Tue, 23 Sep 2008 18:28:06 +0300 > > > > > > > On 9/22/08, David Miller <davem@xxxxxxxxxxxxx> wrote: > > > > > > As he mentioned, the V8 rett instruction causes problems on V9 chips. > > > > > > > > An opcode which was a V8 privileged instruction, "rett", got reused as > > > > a non-privileged instruction in V9, for "return". > > > > > > There are others: rdtbr/flushw and stdfq/stqf. Also any ASI >0x80 > > > accesses are unprivileged on V9, though that shouldn't be a problem > > > since all ASIs used on V8 were <0x80. And of course MMUs are > > > incompatible. > > > > > > Thanks for the list. I sent a message to someone who I think might > > have been responsible for these architectual design decisions, letting > > them know what problems it is causing :-) > > > > > > > > So booting a 32-bit kernel on a 64-bit cpu is going to be challenging, > > > > at best. > > > > > > Maybe it would be possible to run V8 userspace with full speed > > > acceleration on V9 and use translation only for kernel code? > > > > > > Yes, that should work. > > > > BTW, there is another area related the ASIs. Trap numbers. > > > > Even through V9, traps only up to 0x7f are valid. But sun4v extended > > V9 to allow trap numbers >= 0x80, mostly these are used for hypervisor > > calls. > > > > The trap number field of the instruction is just extended one more > > bit higher to accomodate this. > > > I see, also Qemu needs to use one more bit then. Does this mean that > even V8 code written specially may use these traps to call hypervisor? > Then we would need to catch these, maybe with the some assistance from > the hypervisor. Now I found the relevant part in the manuals. The extra sun4v bit is not taken into account from user mode, so we can't catch privileged to hyperprivileged mode traps easily. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
