On 04.07.2011, at 13:37, Avi Kivity wrote:
> On 07/04/2011 02:36 PM, Alexander Graf wrote:
>> >
>> > What intermediate steps? We can't add fields to the structure before we
>> > get the extensibility infrastructure, but that's all.
>>
>> If we add it now without extensibility code, we will ha
On 07/04/2011 02:36 PM, Alexander Graf wrote:
>
> What intermediate steps? We can't add fields to the structure before we get
the extensibility infrastructure, but that's all.
If we add it now without extensibility code, we will have a kernel that only knows the
ioctl with the size as it is
On 04.07.2011, at 13:22, Avi Kivity wrote:
> On 07/04/2011 01:59 PM, Alexander Graf wrote:
>> On 03.07.2011, at 11:12, Avi Kivity wrote:
>>
>> > On 07/03/2011 12:09 PM, Alexander Graf wrote:
>> >> >
>> >> > Right. The idea is that if KVM_FLAG_BLAH implies a field
>> >> kvm_struct::blah, t
On 07/04/2011 01:59 PM, Alexander Graf wrote:
On 03.07.2011, at 11:12, Avi Kivity wrote:
> On 07/03/2011 12:09 PM, Alexander Graf wrote:
>> >
>> > Right. The idea is that if KVM_FLAG_BLAH implies a field
kvm_struct::blah, then either both are present in the headers, or none of them.
>>
>
On 03.07.2011, at 11:12, Avi Kivity wrote:
> On 07/03/2011 12:09 PM, Alexander Graf wrote:
>> >
>> > Right. The idea is that if KVM_FLAG_BLAH implies a field
>> > kvm_struct::blah, then either both are present in the headers, or none of
>> > them.
>>
>> Yup, makes sense. I like the idea :).
On 07/03/2011 12:09 PM, Alexander Graf wrote:
>
> Right. The idea is that if KVM_FLAG_BLAH implies a field kvm_struct::blah,
then either both are present in the headers, or none of them.
Yup, makes sense. I like the idea :). Gets rid of all the useless paddings and
reserved fields. We could
On 03.07.2011, at 11:05, Avi Kivity wrote:
> On 07/03/2011 12:00 PM, Alexander Graf wrote:
>> >> }
>> >>
>> >> Otherwise we might write over data the user expected. And that logic
>> >> that tells to copy_to_user how much data it actually takes to put all the
>> >> information in is n
On 07/03/2011 12:00 PM, Alexander Graf wrote:
>> }
>>
>> Otherwise we might write over data the user expected. And that logic that
tells to copy_to_user how much data it actually takes to put all the information in
is not there today and would have to be added. You can even verify tha
On 03.07.2011, at 10:56, Avi Kivity wrote:
> On 07/03/2011 11:34 AM, Alexander Graf wrote:
>> >>
>> >> Yup, which requires knowledge in the code on what actually fits :).
>> >> Logic we don't have today.
>> >
>> > I don't follow. What knowledge is required? Please give an example.
>>
>> Sur
On 07/03/2011 11:34 AM, Alexander Graf wrote:
>>
>> Yup, which requires knowledge in the code on what actually fits :). Logic
we don't have today.
>
> I don't follow. What knowledge is required? Please give an example.
Sure. Let's take an easy example Currently we have for get_pvinfo:
On 03.07.2011, at 10:15, Avi Kivity wrote:
> On 06/30/2011 07:33 PM, Alexander Graf wrote:
>> On 30.06.2011, at 18:00, Avi Kivity wrote:
>>
>> > On 06/30/2011 06:22 PM, Alexander Graf wrote:
>> >>> Regarding that. There's another option - the ioctl code embeds the
>> >>> structure size. So
On 06/30/2011 07:33 PM, Alexander Graf wrote:
On 30.06.2011, at 18:00, Avi Kivity wrote:
> On 06/30/2011 06:22 PM, Alexander Graf wrote:
>>> Regarding that. There's another option - the ioctl code embeds the
structure size. So if we extend the ioctl parsing to pad up (or truncate down) fro
On 01.07.2011, at 12:09, Paul Mackerras wrote:
> On Thu, Jun 30, 2011 at 05:04:23PM +0200, Alexander Graf wrote:
>> On 06/29/2011 12:41 PM, Paul Mackerras wrote:
>>> +struct kvm_ppc_set_platform {
>>> + __u16 platform; /* defines the OS/hypervisor ABI */
>>> + __u16 guest_arch;
On Thu, Jun 30, 2011 at 05:04:23PM +0200, Alexander Graf wrote:
> On 06/29/2011 12:41 PM, Paul Mackerras wrote:
> >+struct kvm_ppc_set_platform {
> >+__u16 platform; /* defines the OS/hypervisor ABI */
> >+__u16 guest_arch; /* e.g. decimal 206 for v2.06 */
> >+__u32 flags;
> Regarding that. There's another option - the ioctl code embeds the
> structure size. So if we extend the ioctl parsing to pad up (or
> truncate down) from the user's size to our size, and similarly in the
> other direction, we can get away from this ugliness.
I don't like relying on that m
On 30.06.2011, at 18:00, Avi Kivity wrote:
> On 06/30/2011 06:22 PM, Alexander Graf wrote:
>>> Regarding that. There's another option - the ioctl code embeds the
>>> structure size. So if we extend the ioctl parsing to pad up (or truncate
>>> down) from the user's size to our size, and simil
On 06/30/2011 06:22 PM, Alexander Graf wrote:
Regarding that. There's another option - the ioctl code embeds the
structure size. So if we extend the ioctl parsing to pad up (or
truncate down) from the user's size to our size, and similarly in the
other direction, we can get away from this ugl
On 06/30/2011 05:16 PM, Avi Kivity wrote:
On 06/30/2011 06:04 PM, Alexander Graf wrote:
+4.64 KVM_PPC_SET_PLATFORM
+
+Capability: none
+Architectures: powerpc
+Type: vm ioctl
+Parameters: struct kvm_ppc_set_platform (in)
+Returns: 0, or -1 on error
+
+This is used by userspace to tell KVM what s
On 06/30/2011 06:04 PM, Alexander Graf wrote:
+4.64 KVM_PPC_SET_PLATFORM
+
+Capability: none
+Architectures: powerpc
+Type: vm ioctl
+Parameters: struct kvm_ppc_set_platform (in)
+Returns: 0, or -1 on error
+
+This is used by userspace to tell KVM what sort of platform it should
+emulate. The re
On 06/29/2011 12:41 PM, Paul Mackerras wrote:
This new ioctl allows userspace to specify what paravirtualization
interface (if any) KVM should implement, what architecture version
the guest virtual processors should conform to, and whether the guest
can be permitted to use a real supervisor mode.
On 06/29/2011 02:58 PM, Josh Boyer wrote:
>> This makes me wonder if a similar thing might eventually be usable for
>> running an i686 or x32 guest on an x86_64 KVM host. I have no idea if
>> that is even theoretically possible, but if it is it might be better to
>> rename the ioctl to be ar
On Wed, Jun 29, 2011 at 01:56:16PM +0200, Alexander Graf wrote:
>
>On 29.06.2011, at 13:53, Josh Boyer wrote:
>
>> On Wed, Jun 29, 2011 at 08:41:03PM +1000, Paul Mackerras wrote:
>>> Documentation/virtual/kvm/api.txt | 35
>>> +++
>>> arch/powerpc/include/asm/kvm
On 29.06.2011, at 13:53, Josh Boyer wrote:
> On Wed, Jun 29, 2011 at 08:41:03PM +1000, Paul Mackerras wrote:
>> Documentation/virtual/kvm/api.txt | 35
>> +++
>> arch/powerpc/include/asm/kvm.h | 15 +++
>> arch/powerpc/include/asm/kvm_host.h |
On Wed, Jun 29, 2011 at 08:41:03PM +1000, Paul Mackerras wrote:
> Documentation/virtual/kvm/api.txt | 35 +++
> arch/powerpc/include/asm/kvm.h | 15 +++
> arch/powerpc/include/asm/kvm_host.h |1 +
> arch/powerpc/kvm/powerpc.c | 28 +
This new ioctl allows userspace to specify what paravirtualization
interface (if any) KVM should implement, what architecture version
the guest virtual processors should conform to, and whether the guest
can be permitted to use a real supervisor mode.
At present the only effect of the ioctl is to
25 matches
Mail list logo
