[Q] Guest mode in HVM

[Q] Guest mode in HVM

[cotulla]

Hello,


I have a question:
Did I understand right that "HVM Guest mode" is actually native hexagon user mode?
And native hexagon super mode is only used inside HVM during trap1 and exception handlers?


We continued to develop our native hexagon Linux port.
Progress is good so far, we are able to run busybox from intird, but it doesn't work stable with forks

After debugging we found root case of that.

At the current moment we realize that one thing in kernel is totally wrong, out of our concept:
It's not possible to specify access mode for user/super mode in TLB.
Access mode works only for user mode, while super mode ignores it.
That a really bad thing, Linux needs that kind of feature to run.
For example during write access to usermode memory from kernel to be able to clone RW page after fork() call. fork() sets it as RO and waits page fault to make a clone of it.

Now we are redesigning it to run linux kernel also in hexagon user mode and use hexagon super mode only for small operations which are accessed by trap1calls. Actually it's simular to HVM now, thought we are not following HVM strict.

We are going to emulate separate memory access attributes (RWX) for linux kernel and linux user modes by using two different ASIDs for user and kernel mode per hw thread.  


-Cotulla

Re: [Q] Guest mode in HVM

[rkuo]

On Tue, Mar 5, 2013 at 11:45 AM, <cotulla@yandex.ru> wrote:
> I have a question:
> Did I understand right that "HVM Guest mode" is actually native hexagon
> user mode?
> And native hexagon super mode is only used inside HVM during trap1 and
> exception handlers?

On certain versions of the architecture, yes, it effectively is pushed
into user mode.

> It's not possible to specify access mode for user/super mode in TLB.
> ...
> We are going to emulate separate memory access attributes (RWX) for linux
> kernel and linux user modes by using two different ASIDs for user and
> kernel mode per hw thread.

Right, the supervisor isn't subject to RWX bits, but it is still subject
to ASIDs.  I think there was some other nuance to the fault handling, but
that was the gist of it.

This brings us to hypervisors which we've sort of skirted in other emails.
 There will be changes in the Hexagon architecture from one version to
another, some of which will affect the guest operation and compatibility. 
Long term, "we" would like to have Linux just deal with the hypervisor
interface.

Of course, that isn't useful to anybody without the actual hypervisor.  We
recognize this and are working hard to try to release some version of a
functioning hypervisor for the community to continue tinkering with.  If
we get that out, perhaps that will be more preferable for you to work
on...

That said, I think it's great that you all are motivated enough to go for
a bare metal port in the first place (and it looks like you've made great
progress).  I see no reason to reject bare metal patches, but we would
need to keep things clean with ifdefs/config switches...


Thanks,
Richard Kuo


--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

Re: [Q] Guest mode in HVM

[Rob Landley]

On 03/05/2013 05:53:09 PM, rkuo@codeaurora.org wrote:
> On Tue, Mar 5, 2013 at 11:45 AM, <cotulla@yandex.ru> wrote:
> > I have a question:
> > Did I understand right that "HVM Guest mode" is actually native  
> hexagon
> > user mode?
> > And native hexagon super mode is only used inside HVM during trap1  
> and
> > exception handlers?
> 
> On certain versions of the architecture, yes, it effectively is pushed
> into user mode.
> 
> > It's not possible to specify access mode for user/super mode in TLB.
> > ...
> > We are going to emulate separate memory access attributes (RWX) for  
> linux
> > kernel and linux user modes by using two different ASIDs for user  
> and
> > kernel mode per hw thread.
> 
> Right, the supervisor isn't subject to RWX bits, but it is still  
> subject
> to ASIDs.  I think there was some other nuance to the fault handling,  
> but
> that was the gist of it.
> 
> This brings us to hypervisors which we've sort of skirted in other  
> emails.
>  There will be changes in the Hexagon architecture from one version to
> another, some of which will affect the guest operation and  
> compatibility.
> Long term, "we" would like to have Linux just deal with the hypervisor
> interface.
> 
> Of course, that isn't useful to anybody without the actual  
> hypervisor.  We
> recognize this and are working hard to try to release some version of  
> a
> functioning hypervisor for the community to continue tinkering with.   
> If
> we get that out, perhaps that will be more preferable for you to work
> on...
> 
> That said, I think it's great that you all are motivated enough to go  
> for
> a bare metal port in the first place (and it looks like you've made  
> great
> progress).  I see no reason to reject bare metal patches, but we would
> need to keep things clean with ifdefs/config switches...
> 
> Thanks,
> Richard Kuo

I would very much like to test this once you can boot a shell prompt on  
it. Is there some kind of README about what hardware to try to snag off  
ebay or prospects for getting support in qemu? (If there's a prebuilt  
toolchain an actual URL to that would be great too.)

Rob

Re: [Q] Guest mode in HVM

[Jon Pry]

> I would very much like to test this once you can boot a shell prompt on it.
> Is there some kind of README about what hardware to try to snag off ebay or
> prospects for getting support in qemu? (If there's a prebuilt toolchain an
> actual URL to that would be great too.)
>
> Rob

In theory we can run a shell prompt now. However the only console
driver is a ram console type thing, so output only. Cotulla also has
some kind of screen driver working which has the same problem.
The big issue with these devices is getting access to the registers
required to cause the processor to boot. This is not only dependent on
the processor model, but the specific version of the baseband software
installed. Really more so on the latter since any processor could at
least in theory provide access. My HP touchpad just happens to use
unsigned firmware for the Hexagon. Not many people have tried, so
there is no data on other devices with support. At this moment. the
touchpad is the only device known to have unlocked access to the DSP
boot registers.

If your really inspired it is possible to figure out if a given
android device can run unsigned firmware by examining the
/lib/firmware/Q6.mdt file on the device. Location kind of varies, but
it's somewhere. That file is an ELF header, and if you open it up in a
hex editor it will either have a couple thousand bytes of certificate
stuff at the end or not.  The NSA would be proud to see how well these
Hexagons are protected from their owners.

There may be some devices that have firmware signatures but still
allow access to the registers. Some modification to the arm side
kernel is probably required to prevent it from trying to use the DSP
for audio stuff.  I have patches for doing that on the touchpad.

There is a toolchain here:
https://www.codeaurora.org/patches/quic/hexagon/4.0/

That toolchain is horrible, and it can't compile anything except the
kernel. However it is the only one that can compile the kernel for >V2

Mentor graphics makes one that can actually build programs, what a
concept. LD is kind of messed up for greater than > V2 so whatever
your building must use gcc to do the linking.

https://sourcery.mentor.com/GNUToolchain/release2194

I used that for making userland stuff like busybox.

Cheers,

Jon

Re: [Q] Guest mode in HVM

[cotulla]

Hello,


> šRight, the supervisor isn't subject to RWX bits, but it is still subject
> što ASIDs. šI think there was some other nuance to the fault handling, but
> šthat was the gist of it.
That's sadly :(

>
> šThis brings us to hypervisors which we've sort of skirted in other emails.
> ššThere will be changes in the Hexagon architecture from one version to
> šanother, some of which will affect the guest operation and compatibility.
> šLong term, "we" would like to have Linux just deal with the hypervisor
> šinterface.
>
> šOf course, that isn't useful to anybody without the actual hypervisor. šWe
> šrecognize this and are working hard to try to release some version of a
> šfunctioning hypervisor for the community to continue tinkering with. š
Will it be releases as binary or as source code?

> If šwe get that out, perhaps that will be more preferable for you to work
> šon...
Well, we already [i]somehow[/i] almost got full working ;-)
But can be useful for another hobby developers.


> šThat said, I think it's great that you all are motivated enough to go for
> ša bare metal port in the first place (and it looks like you've made great
> šprogress). šI see no reason to reject bare metal patches, but we would
> šneed to keep things clean with ifdefs/config switches...
>
Yes, we got busybox to run rather good as well. Most tests are passed.
Under "we" I mean me and Jonpry. I am working with QDSP6v2 (QSD8250B) and he is working with QDSP6v3 (APQ8060).

Another question which I want to know - QDSP6 has PIPT cache or VIPT?


Best regards,
-Cotulla

Re: [Q] Guest mode in HVM

[rkuo]

On Wed, Mar 6, 2013 at 5:27 PM, <cotulla@ya.ru> wrote:
> Will it be releases as binary or as source code?

We're hoping to release it as source; currently still working things out.


> Yes, we got busybox to run rather good as well. Most tests are passed.
> Under "we" I mean me and Jonpry. I am working with QDSP6v2 (QSD8250B) and
> he is working with QDSP6v3 (APQ8060).

I see you guys already found the last version of the Linux tools; that's
good.  I was in fact wondering what hardware you were using as well.


> Another question which I want to know - QDSP6 has PIPT cache or VIPT?

It's VIPT; you shouldn't have to worry about the extra cache flushing or
whatever when translations change.



Regards,
Richard Kuo



--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation