>> >I want to try the balloon driver. Do we have it in any git tree?
>> >
>> >The git tree I am having now only has master branch, and nothing
else.
>> >
>> >(Maybe the balloon driver is not working yet, but I am curious when
>> >see the userspace code in user/)
>> >
>> >Thanks,
>> >Jun
>>
>> You'r
On 6/6/07, Dor Laor <[EMAIL PROTECTED]> wrote:
> >> >I want to try the balloon driver. Do we have it in any git tree?
> >> >
> >> >The git tree I am having now only has master branch, and nothing
> else.
> >> >
> >> >(Maybe the balloon driver is not working yet, but I am curious when
> >> >see the
Avi Kivity wrote:
> Wayde Milas wrote:
>
>> This is a weird one. Using kvm27. I am able to install and run winxp 32
>> bit perfectly. The problem arises when I try and run my Vista Ultimate
>> upgrade. You cannot cold boot the upgrade and install on a blank drive
>> because when you enter the
Jun Koi wrote:
> So the PCI interface is definetely better IMO. Please put it online,
> so we can test it.
Why would we want a PCI interface to do balooning? All we need is a
simple interface. It _is_ a mess for platforms that don't have PCI.
And it is a mess for paravirtulaization - will we crea
Wayde Milas wrote:
>
>>
>> This is probably some kind of copy protection device, it's making sure
>> you're upgrading to the same machine and not to a different one. So
>> most likely this is by design.
>>
> Maybe... but define "different one". The ultimate upgrade comes with
> its own unique
>Jun Koi wrote:
>> So the PCI interface is definetely better IMO. Please put it online,
>> so we can test it.
>Why would we want a PCI interface to do balooning? All we need is a
>simple interface. It _is_ a mess for platforms that don't have PCI.
>And it is a mess for paravirtulaization - will we
Dor Laor wrote:
> I agree that pci interface isn't ideal, the advantage is that platforms
> that do support pci don't have to implement a virtualized bus, and pci
> is PnP device. This was the motivation behind using it, especially for
> Windows.
In understand that requirement, and I think being ab
Carsten Otte wrote:
> The best approach into this direction I have seen so far is not our
> own vdev thing but Rusty's virtio infrastructure. That's what I think
> I would start with.
>
>
I agree. We need a Lego set containing the following bricks:
- bus interfaces: pci bus, hypercall-based
On Wednesday 06 June 2007, Carsten Otte wrote:
> Dor Laor wrote:
>
> > Now that more platforms are joining the KVM wagon, we should define a
> > common bus. PCI was a overkill anyway - its irq are shared and we don't
> > have to use its io/mmio areas.
> > Do you guys have something to start with?
>
On 6/7/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
> Carsten Otte wrote:
> > The best approach into this direction I have seen so far is not our
> > own vdev thing but Rusty's virtio infrastructure. That's what I think
> > I would start with.
> >
> >
>
> I agree. We need a Lego set containing the fo
Arnd Bergmann wrote:
> On Wednesday 06 June 2007, Carsten Otte wrote:
>> We do have something basic, our vdev bus. The bad thing is, it is
>> platform specific. I really prefer to aim for an idea that Arnd came
>> up with when discussing this issue:
>> We could define a virtual device bus.
>
> I
Jun Koi wrote:
> On 6/7/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
>> Carsten Otte wrote:
>> > The best approach into this direction I have seen so far is not our
>> > own vdev thing but Rusty's virtio infrastructure. That's what I think
>> > I would start with.
>> >
>> >
>>
>> I agree. We need a L
Carsten Otte wrote:
>
>> So you suggest having a PCI driver that exports a virtio device for
>> each PCI device it matches? Sounds fine to me, though it goes beyond
>> what I think Rusty had in mind with his latest set of virtio
>> patches.
>>
> We don't need a PCI device per virtio device. We
The long return value of rmode_tss_base is truncated by its declared
return type of int.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
drivers/kvm/vmx.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: kvm/drivers/kvm/vmx.c
===
On Wednesday 06 June 2007, Jun Koi wrote:
> About the balloon driver, I looked at the current code, and what I
> dont like is its approach: it needs to be operated from inside the
> guest, which is not the way we usually want to do. So something like
> Xen balloon driver is certainly better.
There
Hi,
I just tried kvm-27 with the following result when starting a vm.
-no-kvm works, as does kvm-26. No other changes to my set up:
BUG: unable to handle kernel NULL pointer dereference at virtual address
0024
printing eip:
f8d16ee7
*pde =
Oops: 0002 [#1]
PREEMPT SMP
Modules link
On Wed, 2007-06-06 at 19:17 +0300, Avi Kivity wrote:
> Carsten Otte wrote:
> > The best approach into this direction I have seen so far is not our
> > own vdev thing but Rusty's virtio infrastructure. That's what I think
> > I would start with.
> >
> >
>
> I agree. We need a Lego set contain
>
>The long return value of rmode_tss_base is truncated by its declared
>return type of int.
>
>Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
>--
> drivers/kvm/vmx.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>Index: kvm/drivers/kvm/vmx.c
>===
On Thu, Jun 07, 2007 at 10:13:42AM +0800, Li, Xin B wrote:
> >-static int rmode_tss_base(struct kvm* kvm)
> >+static unsigned long rmode_tss_base(struct kvm* kvm)
>
> Should use gpa_t instead.
Right you are, I didn't notice that type.
Will fix.
Jeff
--
Work ema
Jeff Dike wrote:
> On Thu, Jun 07, 2007 at 10:13:42AM +0800, Li, Xin B wrote:
>
>>> -static int rmode_tss_base(struct kvm* kvm)
>>> +static unsigned long rmode_tss_base(struct kvm* kvm)
>>>
>> Should use gpa_t instead.
>>
>
> Right you are, I didn't notice that type.
>
>
Some ext
Jon wrote:
> Hi,
>
> I just tried kvm-27 with the following result when starting a vm.
> -no-kvm works, as does kvm-26. No other changes to my set up:
>
>
This was fixed in kvm.git, use the attached patch (cd kernel/, and apply
with patch -p3).
--
Do not meddle in the internals of kernels, f
Hi Avi,
On Thu, Jun 07, 2007 at 08:15:29AM +0300, Avi Kivity wrote:
> This was fixed in kvm.git, use the attached patch (cd kernel/, and apply
> with patch -p3).
Applied, but no go. Managed to save this before things started dying:
BUG: unable to handle kernel paging request at virtual address 3
22 matches
Mail list logo
