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 activation code, the software
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're welcome to test it, it is
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 create
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 able
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?
We do
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 following
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 guess,
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 Lego set containing the
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 can have a
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
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
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 containing the
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 extra logic is needed
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, for
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
16 matches
Mail list logo
