On Thu, Jul 1, 2010 at 4:13 PM, Alexander Graf ag...@suse.de wrote:
We just introduced a new PV interface that screams for documentation. So here
it is - a shiny new and awesome text file describing the internal works of
the PPC KVM paravirtual interface.
Signed-off-by: Alexander Graf
On 09.07.2010, at 11:11, MJ embd wrote:
On Thu, Jul 1, 2010 at 4:13 PM, Alexander Graf ag...@suse.de wrote:
We just introduced a new PV interface that screams for documentation. So here
it is - a shiny new and awesome text file describing the internal works of
the PPC KVM paravirtual
On 09.07.2010, at 11:11, MJ embd wrote:
On Thu, Jul 1, 2010 at 4:13 PM, Alexander Graf ag...@suse.de wrote:
We just introduced a new PV interface that screams for documentation. So here
it is - a shiny new and awesome text file describing the internal works of
the PPC KVM paravirtual
On 02.07.2010, at 21:10, Scott Wood wrote:
On Fri, 2 Jul 2010 20:47:44 +0200
Alexander Graf ag...@suse.de wrote:
On 02.07.2010, at 19:59, Hollis Blanchard wrote:
[Resending...]
Please reconcile this with
http://www.linux-kvm.org/page/PowerPC_Hypercall_ABI, which has been
discussed
On 04.07.2010, at 00:41, Benjamin Herrenschmidt wrote:
On Fri, 2010-07-02 at 18:27 +0200, Segher Boessenkool wrote:
+To find out if we're running on KVM or not, we overlay the PVR
register. Usually
+the PVR register contains an id that identifies your CPU type. If,
however, you
+pass
On 07/04/2010 12:04 PM, Alexander Graf wrote:
My biggest concern about putting things in the device-tree is that I was trying
to keep things as separate as possible. Why does the firmware have to know that
it's running in KVM?
It doesn't need to know about kvm, it needs to know that a
On 04.07.2010, at 11:10, Avi Kivity wrote:
On 07/04/2010 12:04 PM, Alexander Graf wrote:
My biggest concern about putting things in the device-tree is that I was
trying to keep things as separate as possible. Why does the firmware have to
know that it's running in KVM?
It doesn't need
On 04.07.2010, at 11:17, Alexander Graf wrote:
On 04.07.2010, at 11:10, Avi Kivity wrote:
On 07/04/2010 12:04 PM, Alexander Graf wrote:
My biggest concern about putting things in the device-tree is that I was
trying to keep things as separate as possible. Why does the firmware have
On 07/04/2010 12:17 PM, Alexander Graf wrote:
On 04.07.2010, at 11:10, Avi Kivity wrote:
On 07/04/2010 12:04 PM, Alexander Graf wrote:
My biggest concern about putting things in the device-tree is that I was trying
to keep things as separate as possible. Why does the firmware have
On 07/04/2010 12:30 PM, Alexander Graf wrote:
Considering how the parts of the draft that I read about sound like, that's not
the inventor's idea. PPC people love to see the BIOS be part of the
virtualization solution. I don't. That's the biggest difference here and reason
for us going
On 02.07.2010, at 21:10, Scott Wood wrote:
On Fri, 2 Jul 2010 20:47:44 +0200
Alexander Graf ag...@suse.de wrote:
On 02.07.2010, at 19:59, Hollis Blanchard wrote:
[Resending...]
Please reconcile this with
http://www.linux-kvm.org/page/PowerPC_Hypercall_ABI, which has been
discussed
On 04.07.2010, at 00:41, Benjamin Herrenschmidt wrote:
On Fri, 2010-07-02 at 18:27 +0200, Segher Boessenkool wrote:
+To find out if we're running on KVM or not, we overlay the PVR
register. Usually
+the PVR register contains an id that identifies your CPU type. If,
however, you
+pass
On 04.07.2010, at 11:17, Alexander Graf wrote:
On 04.07.2010, at 11:10, Avi Kivity wrote:
On 07/04/2010 12:04 PM, Alexander Graf wrote:
My biggest concern about putting things in the device-tree is that I was
trying to keep things as separate as possible. Why does the firmware have
On 07/04/2010 12:17 PM, Alexander Graf wrote:
On 04.07.2010, at 11:10, Avi Kivity wrote:
On 07/04/2010 12:04 PM, Alexander Graf wrote:
My biggest concern about putting things in the device-tree is that I was trying
to keep things as separate as possible. Why does the firmware have
On 07/04/2010 12:30 PM, Alexander Graf wrote:
Considering how the parts of the draft that I read about sound like, that's not
the inventor's idea. PPC people love to see the BIOS be part of the
virtualization solution. I don't. That's the biggest difference here and reason
for us going
On Fri, 2010-07-02 at 18:27 +0200, Segher Boessenkool wrote:
+To find out if we're running on KVM or not, we overlay the PVR
register. Usually
+the PVR register contains an id that identifies your CPU type. If,
however, you
+pass KVM_PVR_PARA in the register that you want the PVR
On Fri, 2010-07-02 at 20:41 +0200, Alexander Graf wrote:
The u64s are 64-bit aligned, should they always be?
That's obvious, isn't it? And the ABI only specifies u64s to be 32 bit
aligned, no? At least that's what ld and std specify.
No, the PowerPC ABI specifies u64's to be 64-bit aligned,
On Fri, 2010-07-02 at 18:27 +0200, Segher Boessenkool wrote:
+To find out if we're running on KVM or not, we overlay the PVR
register. Usually
+the PVR register contains an id that identifies your CPU type. If,
however, you
+pass KVM_PVR_PARA in the register that you want the PVR
On Fri, 2010-07-02 at 20:41 +0200, Alexander Graf wrote:
The u64s are 64-bit aligned, should they always be?
That's obvious, isn't it? And the ABI only specifies u64s to be 32 bit
aligned, no? At least that's what ld and std specify.
No, the PowerPC ABI specifies u64's to be 64-bit aligned,
+To find out if we're running on KVM or not, we overlay the PVR
register. Usually
+the PVR register contains an id that identifies your CPU type. If,
however, you
+pass KVM_PVR_PARA in the register that you want the PVR result in,
the register
+still contains KVM_PVR_PARA after the mfpvr
[Resending...]
Please reconcile this with
http://www.linux-kvm.org/page/PowerPC_Hypercall_ABI, which has been
discussed in the (admittedly closed) Power.org embedded hypervisor
working group. Bear in mind that other hypervisors are already
implementing the documented ABI, so if you have concerns,
On 02.07.2010, at 18:27, Segher Boessenkool wrote:
+To find out if we're running on KVM or not, we overlay the PVR register.
Usually
+the PVR register contains an id that identifies your CPU type. If, however,
you
+pass KVM_PVR_PARA in the register that you want the PVR result in, the
On 02.07.2010, at 19:59, Hollis Blanchard wrote:
[Resending...]
Please reconcile this with
http://www.linux-kvm.org/page/PowerPC_Hypercall_ABI, which has been
discussed in the (admittedly closed) Power.org embedded hypervisor
working group. Bear in mind that other hypervisors are already
On Fri, 2 Jul 2010 20:47:44 +0200
Alexander Graf ag...@suse.de wrote:
On 02.07.2010, at 19:59, Hollis Blanchard wrote:
[Resending...]
Please reconcile this with
http://www.linux-kvm.org/page/PowerPC_Hypercall_ABI, which has been
discussed in the (admittedly closed) Power.org
+To find out if we're running on KVM or not, we overlay the PVR
register. Usually
+the PVR register contains an id that identifies your CPU type. If,
however, you
+pass KVM_PVR_PARA in the register that you want the PVR result in,
the register
+still contains KVM_PVR_PARA after the mfpvr
On 02.07.2010, at 18:27, Segher Boessenkool wrote:
+To find out if we're running on KVM or not, we overlay the PVR register.
Usually
+the PVR register contains an id that identifies your CPU type. If, however,
you
+pass KVM_PVR_PARA in the register that you want the PVR result in, the
On 02.07.2010, at 19:59, Hollis Blanchard wrote:
[Resending...]
Please reconcile this with
http://www.linux-kvm.org/page/PowerPC_Hypercall_ABI, which has been
discussed in the (admittedly closed) Power.org embedded hypervisor
working group. Bear in mind that other hypervisors are already
On Fri, 2 Jul 2010 20:47:44 +0200
Alexander Graf ag...@suse.de wrote:
On 02.07.2010, at 19:59, Hollis Blanchard wrote:
[Resending...]
Please reconcile this with
http://www.linux-kvm.org/page/PowerPC_Hypercall_ABI, which has been
discussed in the (admittedly closed) Power.org
We just introduced a new PV interface that screams for documentation. So here
it is - a shiny new and awesome text file describing the internal works of
the PPC KVM paravirtual interface.
Signed-off-by: Alexander Graf ag...@suse.de
---
v1 - v2:
- clarify guest implementation
- clarify that
29 matches
Mail list logo