Hello!
> So: sorry for the noise, you can just go ahead with that native 64-bit
> sysregs encoding for [SG]ET_ONE_REG as you had before.
Ok, good. Take v4 then. Some issues you've commented on were fixed, some other
things were left as
they are (i replied to your comments, why). Let's move
On 24/09/15 13:08, Pavel Fedin wrote:
> Hello!
>
>> The only thing that is pure 64-bit is the MRS/MSR _instruction_ in
>> Aarch64, which always takes a x register.
>> So can you model the register size according to the spec and allow
>> 32-bit accesses from userland?
>
> I would like to
On 25 September 2015 at 15:27, Andre Przywara wrote:
> On 24/09/15 13:08, Pavel Fedin wrote:
>> Hello!
>>
>>> The only thing that is pure 64-bit is the MRS/MSR _instruction_ in
>>> Aarch64, which always takes a x register.
>>> So can you model the register size according
On Fri, 25 Sep 2015 15:33:44 -0700
Peter Maydell wrote:
> On 25 September 2015 at 15:27, Andre Przywara wrote:
> > On 24/09/15 13:08, Pavel Fedin wrote:
> >> Hello!
> >>
> >>> The only thing that is pure 64-bit is the MRS/MSR _instruction_ in
>
Hello!
> The only thing that is pure 64-bit is the MRS/MSR _instruction_ in
> Aarch64, which always takes a x register.
> So can you model the register size according to the spec and allow
> 32-bit accesses from userland?
I would like to complete the rework and respin v4, but this is, i guess,
The access is done similar to GICv2, using KVM_DEV_ARM_VGIC_GRP_CPU_REGS
group, however attribute ID encodes corresponding system register. Access
size is always 64 bits.
Since CPU interface state actually affects only a single vCPU, no vGIC
locking is done. Just made sure that the vCPU is not
Hello!
> So can you model the register size according to the spec and allow
> 32-bit accesses from userland?
I can. But i'll have to invent my own macro for encoding register IDs into the
attribute, as well
as drop reusing index_to_params(). Will it be OK?
Upside: i can further extend "cpu