Re: [PATCH 2/2]: kvm-s390: add KVM_S390_GET/SET_SREGS2 call for additional hw regs

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

 



On 20/12/11 17:28, Alexander Graf wrote:
>>> Would it make sense to instead use the GET_ONE_REG and SET_ONE_REG interfaces?
>>>
>>>  http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/80854

What is the status of these patches?

> 
>> - Is the interface limited to 56 registers? (see the ID)
> 
> Uh. It's limited to 0x0fffffffffffffff registers per architecture :).

Yes, I see.



> Do you expect the prefix register to be synced often? If so, then you should maybe put it into kvm_struct
> and always have it shared between kernel and user space, always updating it on every user space exit
> and entry (you can optimize by checking if it changed).
> 
> I don't think user space should worry about prefix too often though. Unless you expect anyone to DMA
> into the CPU prefix area :).

In theory:
To be architecture compliant we actually must check for _every_ memory access to the guest 
if it is 0 < address < 8192  or prefix < address < prefix+8192 and swap that. Usually this
should not not happen very often, but you dont know until you check.
As of today:
Only a small part of the guest OS actually touches the lowcore and current KVM guests never
cause exits to qemu that have to deal with such an case - it was handled by SIE or by the
host kernel - so not a problem.
Future:
Additional components and non-para-virtualized I/O will pass addresses in the prefix pages
to some  instructions that qemu might have to handle, so we might need that more often.

To play safe, we might want to do the prefix translation for all handled intercepts.
Then we would need the prefix value almost always.


Christian

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux