* 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 exception that would occur if you used
* 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 underlying architec
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 underlying architec
* 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
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,
then you cou
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
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:
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 are valid or
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 replacing it w
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
processor(s) in the n
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 replacing it with the right one lazily.
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 single
instru
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 others chime
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 PV driver can
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 eliminates the hypercall page by trapping
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 the
underlying
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
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 replacing it with the right one lazily.
37 matches
Mail list logo
