* 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
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
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
hypercall
* 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_available()) {
+
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
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
* 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
* 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
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
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
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
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
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
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
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:
Nakajima, Jun wrote:
snip
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 (not
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
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 redundantly.
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 results of
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
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
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
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
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
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
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
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 don't
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 you used the wrong
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> >>
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
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
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
exception that would
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 independent
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
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
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:
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
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 better to
just
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 would not be good
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 hardware-assisted
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 features
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_0003)
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
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.
I'm
63 matches
Mail list logo
