On 09.07.2010, at 11:11, MJ embd wrote:
> On Thu, Jul 1, 2010 at 4:13 PM, Alexander Graf 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.
>>
On Thu, Jul 1, 2010 at 4:13 PM, Alexander Graf 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
>
> ---
>
> v1
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 diffe
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 t
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 fir
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 do
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 partic
On 04.07.2010, at 00:42, Benjamin Herrenschmidt wrote:
> 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 sp
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,
On 02.07.2010, at 21:10, Scott Wood wrote:
> On Fri, 2 Jul 2010 20:47:44 +0200
> Alexander Graf 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
>>>
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 aligne
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 th
On Fri, 2 Jul 2010 20:47:44 +0200
Alexander Graf 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 embedd
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 alr
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
[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,
+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 cal
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
---
v1 -> v2:
- clarify guest implementation
- clarify that privileged i
18 matches
Mail list logo
