Re: handling cp15 state which isn't trivially exposed as a single register

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 20, 2012 at 5:55 AM, Peter Maydell <peter.maydell@xxxxxxxxxx> wrote:
> As I've been working through trying to drive kvm cp15 save/load
> via qemu's cpreg hashtable, I ran into an interesting question.
>
> Some bits of cp15 don't trivially expose their state as a single
> register. For example, the cache status registers have a number
> of different values which are accessed via writing to a 'select'
> register to pick which of them is visible in the 'value' register.
> Some of the perf registers come in "write 1 to set, 0 is ignored"
> and "write 1 to clear, 0 is ignored" pairs.
>
> The current kernel ABI just exposes these as registers the same
> way the hardware does. Userspace can use this to read/write
> the state, but it would have to do it via a sequence of "write
> select reg; read value reg; write select reg; read value reg..."
> which defeats the intention of the 'many regs' ABI slightly.
>
> I guess fundamentally somebody has to do the mapping from the
> register interface the hw provides to "slurp the state in
> and out", so the question is whether it should be userspace
> (as now) or the kernel...
>
> I don't have a concrete suggestion for this yet, I just thought
> I'd raise the issue in case somebody else had a good idea.
>
Is there a current need (or reasonably foreseeable future one) to read
these registers from user space? If so, I think the multi-kernel
crossing approach sounds awful, but an interface for this sounds on
the other hand complicated and annoying. I guess to me awful trumps
complicated and annoying and the kernel should do the work, but I sure
hope it's not a priority.

-Christoffer
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm


[Index of Archives]     [Linux KVM]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux