Christoph Lameter wrote:
> And it seems that the hooks are not generic but bound to a particular
> hypervisor. Should the Xen specific stuff not be in the binary blob?
Xen has no "binary blob". It needs guests to cooperate with it by
making hypercalls; all that code is in the Xen implementation
Christoph Lameter wrote:
On Sat, 17 Feb 2007, Andi Kleen wrote:
That was always its intention. It's not a direct interface to a hypervisor,
but an somewhat abstracted interface to a "hypervisor driver"
I thought that hypervisor driver was some binary blob that can be directly
On Sat, 17 Feb 2007, Andi Kleen wrote:
> That was always its intention. It's not a direct interface to a hypervisor,
> but an somewhat abstracted interface to a "hypervisor driver"
I thought that hypervisor driver was some binary blob that can be directly
accessed via paravirt_ops?
> But
On Sat, 17 Feb 2007, Andi Kleen wrote:
That was always its intention. It's not a direct interface to a hypervisor,
but an somewhat abstracted interface to a hypervisor driver
I thought that hypervisor driver was some binary blob that can be directly
accessed via paravirt_ops?
But you're
Christoph Lameter wrote:
On Sat, 17 Feb 2007, Andi Kleen wrote:
That was always its intention. It's not a direct interface to a hypervisor,
but an somewhat abstracted interface to a hypervisor driver
I thought that hypervisor driver was some binary blob that can be directly
accessed
Christoph Lameter wrote:
And it seems that the hooks are not generic but bound to a particular
hypervisor. Should the Xen specific stuff not be in the binary blob?
Xen has no binary blob. It needs guests to cooperate with it by
making hypercalls; all that code is in the Xen implementation of
On Fri, Feb 16, 2007 at 01:59:44PM -0800, Christoph Lameter wrote:
> On Fri, 16 Feb 2007, Zachary Amsden wrote:
>
> > Yes, but that is just because the Xen hooks happens to be near the last part
> > of the merge. VMI required some special hooks, as do both Xen and lhype (I
> > think ... Rusty
On Fri, Feb 16, 2007 at 01:59:44PM -0800, Christoph Lameter wrote:
On Fri, 16 Feb 2007, Zachary Amsden wrote:
Yes, but that is just because the Xen hooks happens to be near the last part
of the merge. VMI required some special hooks, as do both Xen and lhype (I
think ... Rusty can
On Fri, 2007-02-16 at 13:48 -0800, Zachary Amsden wrote:
> Christoph Lameter wrote:
> > It still seems to be implemented for Xen and not to support a variety of
> > page table methods in paravirt ops.
>
> Yes, but that is just because the Xen hooks happens to be near the last
> part of the
On Fri, 2007-02-16 at 12:49 -0800, Christoph Lameter wrote:
> On Thu, 15 Feb 2007, Jeremy Fitzhardinge wrote:
>
> > This patch series implements the Linux Xen guest in terms of the
> > paravirt-ops interface. The features in implemented this patch series
>
> I am thoroughly confused. Maybe that
Christoph Lameter wrote:
> I am thoroughly confused. Maybe that is because I have not been following
> this issue closely but it seems that you are using the paravirt interface
> as an API for Xen code in the guest? I thought the idea of paravirt was to
> have an API that is generic? This
Christoph Lameter wrote:
On Fri, 16 Feb 2007, Zachary Amsden wrote:
Yes, but that is just because the Xen hooks happens to be near the last part
of the merge. VMI required some special hooks, as do both Xen and lhype (I
think ... Rusty can correct me if lhype's puppy's have precluded the
On Fri, 16 Feb 2007, Zachary Amsden wrote:
> Yes, but that is just because the Xen hooks happens to be near the last part
> of the merge. VMI required some special hooks, as do both Xen and lhype (I
> think ... Rusty can correct me if lhype's puppy's have precluded the addition
> of new hooks).
Christoph Lameter wrote:
On Fri, 16 Feb 2007, Zachary Amsden wrote:
For the most part, it doesn't disturb VMware or KVM. Xen does need some
additional functionality in paravirt-ops because they took a different design
choice - direct page tables instead of shadow page tables. This is
On Fri, 16 Feb 2007, Zachary Amsden wrote:
> For the most part, it doesn't disturb VMware or KVM. Xen does need some
> additional functionality in paravirt-ops because they took a different design
> choice - direct page tables instead of shadow page tables. This is where all
> the requirements
Christoph Lameter wrote:
On Thu, 15 Feb 2007, Jeremy Fitzhardinge wrote:
This patch series implements the Linux Xen guest in terms of the
paravirt-ops interface. The features in implemented this patch series
I am thoroughly confused. Maybe that is because I have not been following
On Thu, 15 Feb 2007, Jeremy Fitzhardinge wrote:
> This patch series implements the Linux Xen guest in terms of the
> paravirt-ops interface. The features in implemented this patch series
I am thoroughly confused. Maybe that is because I have not been following
this issue closely but it seems
On Thu, 15 Feb 2007, Jeremy Fitzhardinge wrote:
This patch series implements the Linux Xen guest in terms of the
paravirt-ops interface. The features in implemented this patch series
I am thoroughly confused. Maybe that is because I have not been following
this issue closely but it seems
Christoph Lameter wrote:
On Thu, 15 Feb 2007, Jeremy Fitzhardinge wrote:
This patch series implements the Linux Xen guest in terms of the
paravirt-ops interface. The features in implemented this patch series
I am thoroughly confused. Maybe that is because I have not been following
On Fri, 16 Feb 2007, Zachary Amsden wrote:
For the most part, it doesn't disturb VMware or KVM. Xen does need some
additional functionality in paravirt-ops because they took a different design
choice - direct page tables instead of shadow page tables. This is where all
the requirements for
Christoph Lameter wrote:
On Fri, 16 Feb 2007, Zachary Amsden wrote:
For the most part, it doesn't disturb VMware or KVM. Xen does need some
additional functionality in paravirt-ops because they took a different design
choice - direct page tables instead of shadow page tables. This is
On Fri, 16 Feb 2007, Zachary Amsden wrote:
Yes, but that is just because the Xen hooks happens to be near the last part
of the merge. VMI required some special hooks, as do both Xen and lhype (I
think ... Rusty can correct me if lhype's puppy's have precluded the addition
of new hooks). Xen
Christoph Lameter wrote:
On Fri, 16 Feb 2007, Zachary Amsden wrote:
Yes, but that is just because the Xen hooks happens to be near the last part
of the merge. VMI required some special hooks, as do both Xen and lhype (I
think ... Rusty can correct me if lhype's puppy's have precluded the
On Fri, 2007-02-16 at 12:49 -0800, Christoph Lameter wrote:
On Thu, 15 Feb 2007, Jeremy Fitzhardinge wrote:
This patch series implements the Linux Xen guest in terms of the
paravirt-ops interface. The features in implemented this patch series
I am thoroughly confused. Maybe that is
On Fri, 2007-02-16 at 13:48 -0800, Zachary Amsden wrote:
Christoph Lameter wrote:
It still seems to be implemented for Xen and not to support a variety of
page table methods in paravirt ops.
Yes, but that is just because the Xen hooks happens to be near the last
part of the merge. VMI
Andrew Morton wrote:
> On Thu, 15 Feb 2007 18:24:49 -0800 Jeremy Fitzhardinge <[EMAIL PROTECTED]>
> wrote:
>
>
>> This patch series implements the Linux Xen guest in terms of the
>> paravirt-ops interface.
>>
>
> The whole patchset exports 67 symbols to modules. How come?
>
> Are they
On Thu, 15 Feb 2007 18:24:49 -0800 Jeremy Fitzhardinge <[EMAIL PROTECTED]>
wrote:
> This patch series implements the Linux Xen guest in terms of the
> paravirt-ops interface.
The whole patchset exports 67 symbols to modules. How come?
Are they all needed?
-
To unsubscribe from this list: send
Hi Andi,
This patch series implements the Linux Xen guest in terms of the
paravirt-ops interface. The features in implemented this patch series
are:
* domU only
* UP only (most code is SMP-safe, but there's no way to create a new vcpu)
* writable pagetables, with late pinning/early unpinning
Hi Andi,
This patch series implements the Linux Xen guest in terms of the
paravirt-ops interface. The features in implemented this patch series
are:
* domU only
* UP only (most code is SMP-safe, but there's no way to create a new vcpu)
* writable pagetables, with late pinning/early unpinning
On Thu, 15 Feb 2007 18:24:49 -0800 Jeremy Fitzhardinge [EMAIL PROTECTED]
wrote:
This patch series implements the Linux Xen guest in terms of the
paravirt-ops interface.
The whole patchset exports 67 symbols to modules. How come?
Are they all needed?
-
To unsubscribe from this list: send the
Andrew Morton wrote:
On Thu, 15 Feb 2007 18:24:49 -0800 Jeremy Fitzhardinge [EMAIL PROTECTED]
wrote:
This patch series implements the Linux Xen guest in terms of the
paravirt-ops interface.
The whole patchset exports 67 symbols to modules. How come?
Are they all needed?
Yep,
31 matches
Mail list logo
