* Avi Kivity wrote:
> Amit Shah wrote:
> > * Anthony Liguori wrote:
> >
> >
> >> Amit Shah wrote:
> >>
> >>
> >> What are you using to issue the hypercall?
> >>
> >
> > + r = kvm_hypercall1(KVM_PV_PCI_DEVICE, page_gfn);
> >
> > Setup is done by:
> >
> > + if (!kvm_para_availab
Amit Shah wrote:
> * Anthony Liguori wrote:
>
>> Amit Shah wrote:
>>
>>> * Anthony Liguori wrote:
>>>
>>>
>>>
This patch refactors the current hypercall infrastructure to better
support live migration and SMP. It eliminates the hypercall page by
trapping the UD exce
* Anthony Liguori wrote:
> Amit Shah wrote:
> > * Anthony Liguori wrote:
> >
> >
> >> This patch refactors the current hypercall infrastructure to better
> >> support live migration and SMP. It eliminates the hypercall page by
> >> trapping the UD exception that would occur if you used the wrong
Amit Shah wrote:
> * Anthony Liguori wrote:
>
>> This patch refactors the current hypercall infrastructure to better support
>> live migration and SMP. It eliminates the hypercall page by trapping the
>> UD exception that would occur if you used the wrong hypercall instruction
>> for the underl
Amit Shah wrote:
> * Anthony Liguori wrote:
>
>> This patch refactors the current hypercall infrastructure to better support
>> live migration and SMP. It eliminates the hypercall page by trapping the
>> UD exception that would occur if you used the wrong hypercall instruction
>> for the underl
* Anthony Liguori wrote:
> This patch refactors the current hypercall infrastructure to better support
> live migration and SMP. It eliminates the hypercall page by trapping the
> UD exception that would occur if you used the wrong hypercall instruction
> for the underlying architecture and replac
Anthony Liguori wrote:
> Nakajima, Jun wrote:
>>> I don't understand the purpose of returning the max leaf. Who is that
>>> information useful for?
>>>
>>
>> Well, this is the key info to the user of CPUID. It tells which leaves
>> are valid to use. Otherwise, the user cannot tell whether the
Nakajima, Jun wrote:
> Using CPUID.0x400N (N > 2) does not prevent Xen from doing that,
> either. If you use 0x40001000, 1) you need to say the leaves from
> 0x4000 through 0x40001000 are all valid, OR 2) you create/fork a
> new/odd leaf (with 0x1000 offset) repeating the detection redundan
Jeremy Fitzhardinge wrote:
> Nakajima, Jun wrote:
>
> > Again, 0x4000 is not Xen specific. If the leaf 0x4000 is
used
> > for any guest to detect any hypervisor, that would be compelling
> > benefit. For future Xen-specific features, it's safe for Xen to use
> > other bigger leaves (like 0
Jeremy Fitzhardinge wrote:
>> I'm starting to lean toward just using . If for no other reason
>> than the hypercall space is unsharable.
>>
>
> Well, it could be, but it would take affirmative action on the guest's
> part. If there's feature bits for each supported hypercall interface,
>
Nakajima, Jun wrote:
>> I don't understand the purpose of returning the max leaf. Who is that
>> information useful for?
>>
>
> Well, this is the key info to the user of CPUID. It tells which leaves
> are valid to use. Otherwise, the user cannot tell whether the results of
> CPUID.0x400N
Anthony Liguori wrote:
> Nakajima, Jun wrote:
> >
> > I'm suggesting that we use CPUID.0x400Y (Y: TBD, e.g. 6) for
Linux
> > paravirtualization. The ebx, ecx and edx return the Linux
> > paravirtualization features available on that hypervisor. Those
features
> > are defined architecturally
Anthony Liguori wrote:
> This patch refactors the current hypercall infrastructure to better support
> live
> migration and SMP. It eliminates the hypercall page by trapping the UD
> exception that would occur if you used the wrong hypercall instruction for the
> underlying architecture and repla
Nakajima, Jun wrote:
> Jeremy Fitzhardinge wrote:
>
>> Nakajima, Jun wrote:
>>
>>> The hypervisor detection machanism is generic, and the signature
>>> returned is implentation specific. Having a list of all hypervisor
>>> signatures sounds fine to me as we are detecting vendor-specific
>>>
Zachary Amsden wrote:
> On Fri, 2007-09-14 at 16:44 -0500, Anthony Liguori wrote:
>
>
>> So then each module creates a hypercall page using this magic MSR and
>> the hypervisor has to keep track of it so that it can appropriately
>> change the page on migration. The page can only contain a si
Zachary Amsden wrote:
> On Fri, 2007-09-14 at 16:44 -0500, Anthony Liguori wrote:
>
>
>> So then each module creates a hypercall page using this magic MSR and
>> the hypervisor has to keep track of it so that it can appropriately
>> change the page on migration. The page can only contain a si
Nakajima, Jun wrote:
> To me this is the beginning of fragmentation. Why do we need different
> and VMM-specific Linux paravirtualization for hardware-assisted
> virtualization? That would not be good for Linux.
>
>
The only way to have a single interface is if a central authority
defines and d
Anthony Liguori wrote:
> Jeremy Fitzhardinge wrote:
>
>> Anthony Liguori wrote:
>>
>>
>>> This patch refactors the current hypercall infrastructure to better support
>>> live
>>> migration and SMP. It eliminates the hypercall page by trapping the UD
>>> exception that would occur if yo
Jeremy Fitzhardinge wrote:
> Nakajima, Jun wrote:
> > The hypervisor detection machanism is generic, and the signature
> > returned is implentation specific. Having a list of all hypervisor
> > signatures sounds fine to me as we are detecting vendor-specific
> > processor(s) in the native. And I do
Nakajima, Jun wrote:
> The hypervisor detection machanism is generic, and the signature
> returned is implentation specific. Having a list of all hypervisor
> signatures sounds fine to me as we are detecting vendor-specific
> processor(s) in the native. And I don't expect the list is large.
>
>
On Fri, 2007-09-14 at 16:44 -0500, Anthony Liguori wrote:
> So then each module creates a hypercall page using this magic MSR and
> the hypervisor has to keep track of it so that it can appropriately
> change the page on migration. The page can only contain a single
> instruction or else it ca
On Fri, 2007-09-14 at 13:53 -0700, Jeremy Fitzhardinge wrote:
> Anthony Liguori wrote:
> > This patch refactors the current hypercall infrastructure to better support
> > live
> > migration and SMP. It eliminates the hypercall page by trapping the UD
> > exception that would occur if you used the
Jeremy Fitzhardinge wrote:
> Nakajima, Jun wrote:
> > Today, 3 CPUID leaves starting from 0x4000_ are defined in a
generic
> > fashion (hypervisor detection, version, and hypercall page), and
those
> > are the ones used by Xen today. We should extend those leaves (e.g.
> > starting from 0x4000_
Nakajima, Jun wrote:
> Today, 3 CPUID leaves starting from 0x4000_ are defined in a generic
> fashion (hypervisor detection, version, and hypercall page), and those
> are the ones used by Xen today. We should extend those leaves (e.g.
> starting from 0x4000_0003) for the vmm-independent feature
Jeremy Fitzhardinge wrote:
> Nakajima, Jun wrote:
> > > > one. Start the kvm leaves at 0x40001000 or something?
> > > >
> > > >
> > > Yeah, that works with me.
> > >
> >
> > To me this is the beginning of fragmentation. Why do we need
different
> > and VMM-specific Linux paravirtualization for
Nakajima, Jun wrote:
>>> one. Start the kvm leaves at 0x40001000 or something?
>>>
>>>
>> Yeah, that works with me.
>>
>
> To me this is the beginning of fragmentation. Why do we need different
> and VMM-specific Linux paravirtualization for hardware-assisted
> virtualization? That wou
Anthony Liguori wrote:
> Jeremy Fitzhardinge wrote:
> > Anthony Liguori wrote:
> >
> > > Yeah, see, the initial goal was to make it possible to use the KVM
> > > paravirtualizations on other hypervisors. However, I don't think
this
> > > is really going to be possible in general so maybe it's bet
Jeremy Fitzhardinge wrote:
> Anthony Liguori wrote:
>
>> Yeah, see, the initial goal was to make it possible to use the KVM
>> paravirtualizations on other hypervisors. However, I don't think this
>> is really going to be possible in general so maybe it's better to just
>> use leaf 0. I'll let
Anthony Liguori wrote:
> Yeah, see, the initial goal was to make it possible to use the KVM
> paravirtualizations on other hypervisors. However, I don't think this
> is really going to be possible in general so maybe it's better to just
> use leaf 0. I'll let others chime in before sending a new
Jeremy Fitzhardinge wrote:
> Anthony Liguori wrote:
>
>> The whole point of using the instruction is to allow hypercalls to be
>> used in many locations. This has the nice side effect of not
>> requiring a central hypercall initialization routine in the guest to
>> fetch the hypercall page. A
Zachary Amsden wrote:
> On Fri, 2007-09-14 at 16:02 -0500, Anthony Liguori wrote:
>
>> Jeremy Fitzhardinge wrote:
>>
>>> Anthony Liguori wrote:
>>>
>>>
This patch refactors the current hypercall infrastructure to better
support live
migration and SMP. It eliminate
Anthony Liguori wrote:
> The whole point of using the instruction is to allow hypercalls to be
> used in many locations. This has the nice side effect of not
> requiring a central hypercall initialization routine in the guest to
> fetch the hypercall page. A PV driver can be completely independen
On Fri, 2007-09-14 at 16:02 -0500, Anthony Liguori wrote:
> Jeremy Fitzhardinge wrote:
> > Anthony Liguori wrote:
> >
> >> This patch refactors the current hypercall infrastructure to better
> >> support live
> >> migration and SMP. It eliminates the hypercall page by trapping the UD
> >> exce
Jeremy Fitzhardinge wrote:
> Anthony Liguori wrote:
>
>> This patch refactors the current hypercall infrastructure to better support
>> live
>> migration and SMP. It eliminates the hypercall page by trapping the UD
>> exception that would occur if you used the wrong hypercall instruction for
Anthony Liguori wrote:
> This patch refactors the current hypercall infrastructure to better support
> live
> migration and SMP. It eliminates the hypercall page by trapping the UD
> exception that would occur if you used the wrong hypercall instruction for the
> underlying architecture and repla
Attached is the patch I'm using to test it. I'm going to take a look at
Rusty's pv_ops implementation for kvm-lite so that we can submit a
single common one instead of introducing mine and having unnecessary churn.
Regards,
Anthony Liguori
Subject: [PATCH 2/3] KVM paravirt-ops implementation
36 matches
Mail list logo
