Zhang, Xiantao wrote:
>Christian Ehrhardt wrote:
<[...]
>> @@ -2600,8 +2601,8 @@ void cpu_physical_memory_rw(target_phys_addr_t
>> addr, uint8_t *buf, phys_ram_dirty[addr1 >>
>> TARGET_PAGE_BITS] |= (0xff &
>> ~CODE_DIRTY_FLAG); }
>> -#
Hi,
This is today's KVM test result against kvm.git
864b17cab371ec5fc3b8560b640d8b8a867c5228 and kvm-userspace.git
8778f7f9c1c96cbe671815afb54cac5b47fa28eb.
Save/restore IA32e guest passed today, but on PAE host it still fails with the
error:
prints:kvm_get_mem_map failed: Unknown error 4294967
Carsten Otte wrote:
> Zhang, Xiantao wrote:
>> diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
>> index 530c391..2d2ff55 100644
>> --- a/drivers/kvm/kvm_main.c
>> +++ b/drivers/kvm/kvm_main.c
>> @@ -670,7 +670,7 @@ static int kvm_vcpu_fault(struct vm_area_struct
>> *vma, struct vm_faul
Christian Ehrhardt wrote:
> Zhang, Xiantao wrote:
>> Christian Ehrhardt wrote:
> <[...]
>>> @@ -2600,8 +2601,8 @@ void cpu_physical_memory_rw(target_phys_addr_t
>>> addr, uint8_t *buf, phys_ram_dirty[addr1 >>
>>> TARGET_PAGE_BITS] |= (0xff &
>>>
Zhang, Xiantao wrote:
> diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
> index 530c391..2d2ff55 100644
> --- a/drivers/kvm/kvm_main.c
> +++ b/drivers/kvm/kvm_main.c
> @@ -670,7 +670,7 @@ static int kvm_vcpu_fault(struct vm_area_struct
> *vma, struct vm_fault *vmf)
> if (vmf->pgo
Zhang, Xiantao wrote:
> As you know, we have to change to kvm_vcpu_arch concept since meet
> various issues about #includes.
> This patches enables it. I also prepared a series of patches to split
> kvm with similar idea.
> Now, kvm.h includes x86.h by default. X86.c needs includes kvm.h, and
> v
Avi Kivity wrote:
> kvm_vcpu_fault() isn't for mapping guest pages, but for mapping the
> kernel/userspace vcpu communication area. Moving that snippet to an
> arch hook should be enough.
Oh thanks for clearing my confusion. Indeed, hm... but we won't have a
PIO_PAGE at all. On the other hand, we
Rusty, Anthony, Dor,
I need your brain power :-)
On smp guests I have seen a problem with virtio (the version in curent Avi's
git) which do not occur on single processor guests:
kernel BUG at /space/kvm/drivers/virtio/virtio_ring.c:228!
illegal operation: 0001 [#1]
Modules linked in: ipv6
CPU:
Jan Kiszka wrote:
> We've noticed some problems with current gdbstub in kvm's qemu:
>
> # qemu-system-x86_64 -hda myimage -S -s &
> # gdb
> (gdb) tar re :1234
> Remote debugging using :1234
> Remote 'g' packet reply is too long:
> [...]
>
> This issue did not o
Avi Kivity wrote:
> Jan Kiszka wrote:
>> Jan Kiszka wrote:
>>
>>> We've noticed some problems with current gdbstub in kvm's qemu:
>>>
>>> # qemu-system-x86_64 -hda myimage -S -s &
>>> # gdb
>>> (gdb) tar re :1234
>>> Remote debugging using :1234
>>> Remote 'g' packet reply is too long:
>>> 00
Avi Kivity wrote:
> Indeed, I'll rearrange the directory layout tomorrow and then we can
> finally see actual arch support instead of preparations!
Yipieh :-).
-
SF.Net email is sponsored by:
Check out the new Source
Jan Kiszka wrote:
> BTW, are there plans to merge the kvm branch into qemu at some point and
> continue development unitedly with the qemu people?
>
There is the intent, but no concrete plans. What is missing is someone
to prepare a suitable patchset for qemu-devel; that's no small amount of
Jan Kiszka wrote:
> Jan Kiszka wrote:
>
>> We've noticed some problems with current gdbstub in kvm's qemu:
>>
>> # qemu-system-x86_64 -hda myimage -S -s &
>> # gdb
>> (gdb) tar re :1234
>> Remote debugging using :1234
>> Remote 'g' packet reply is too long:
>> 000
Zhang, Xiantao wrote:
> Hi, Avi
> As you know, we have to change to kvm_vcpu_arch concept since meet
> various issues about #includes.
> This patches enables it. I also prepared a series of patches to split
> kvm with similar idea.
> Now, kvm.h includes x86.h by default. X86.c needs includes kvm.
* Avi Kivity <[EMAIL PROTECTED]> [2007-12-14 08:49]:
> Ryan Harper wrote:
> >Add printk_ratelimit check in front of printk. This prevents spamming
> >of the message during 32-bit ubuntu 6.06server install. Previously, it
> >would hang during the partition formatting stage.
> >
>
> Applied, but
David P. Reed wrote:
> Replace use of outb to "unused" diagnostic port 0x80 for time delay
> with udelay based time delay on x86_64 architecture machines. Fix for
> bugs 9511 and 6307 in bugzilla, plus bugs reported in
> bugzilla.redhat.com.
>
> Derived from suggestion (that didn't compile) by Pav
On Thu, Dec 13, 2007 at 05:06:41PM +0200, Avi Kivity wrote:
> Alexey Eremenko wrote:
> >
> > Yes, You're right, KVM-56 doesn't compiles on 32-bit systems. (tested
> > on openSUSE 10.3, 32-bit)
> >
>
> It compiles on 32-bit systems. It doesn't compile on 32-bit non-pae
> systems.
gentoo non-pa
Theodore Tso wrote:
> BTW, there were changes between 2.6.24-rc3 and -rc5 such that there
> are merge conflicts when I tried to do a git pull from kvm/master unto
> Linus's git mainline.
>
>
In general I merge regularly and resolve conflicts. Currently kvm.git is
based on 2.6.24-rc5.
--
Any
Ryan Harper wrote:
> Add printk_ratelimit check in front of printk. This prevents spamming
> of the message during 32-bit ubuntu 6.06server install. Previously, it
> would hang during the partition formatting stage.
>
Applied, but this is worrying. Do you know whether this is a regression?
On Thu, Dec 13, 2007 at 06:59:06AM -0800, Alexey Eremenko wrote:
>
>Yes, You're right, KVM-56 doesn't compiles on 32-bit systems. (tested on
>openSUSE 10.3, 32-bit)
it compiles ok in Gentoo 2007.0 building against the last stable gentoo
kernels 2.6.22 and 2.6.23 for x86 :
gentoo-source
Bugs item #1850911, was opened at 2007-12-14 12:10
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1850911&group_id=180599
Please note that this message will contain a full copy
Dor Laor wrote:
> Christian Borntraeger wrote:
>> Am Mittwoch, 12. Dezember 2007 schrieb Dor Laor:
>>> Christian Borntraeger wrote:
Am Mittwoch, 12. Dezember 2007 schrieb Dor Laor:
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -406,10 +405,10 @@ again:
* Ryan Harper <[EMAIL PROTECTED]> [2007-12-14 09:36]:
> * Avi Kivity <[EMAIL PROTECTED]> [2007-12-14 08:49]:
> > Ryan Harper wrote:
> > >Add printk_ratelimit check in front of printk. This prevents spamming
> > >of the message during 32-bit ubuntu 6.06server install. Previously, it
> > >would han
Avi Kivity wrote:
> Zhang, Xiantao wrote:
>> Hi, Avi
>> As you know, we have to change to kvm_vcpu_arch concept since meet
>> various issues about #includes.
>> This patches enables it. I also prepared a series of patches to
>> split kvm with similar idea. Now, kvm.h includes x86.h by default.
>> X
* Ryan Harper <[EMAIL PROTECTED]> [2007-12-14 16:14]:
> * Ryan Harper <[EMAIL PROTECTED]> [2007-12-14 09:36]:
> > * Avi Kivity <[EMAIL PROTECTED]> [2007-12-14 08:49]:
> > > Ryan Harper wrote:
> > > >Add printk_ratelimit check in front of printk. This prevents spamming
> > > >of the message during
Avi Kivity wrote:
> kvm will forward a virtual machine's writes to port 0x80 to the real
> port. The reason is that the write is much faster than exiting and
> emulating it; the difference is measurable when compiling kernels.
>
> Now if the cause is simply writing to port 0x80, then we must sto
David P. Reed wrote:
>
> I believe (though no one seems to have confirming documentation from the
> chipset or motherboard vendor) that port 80 is actually functional for
> some unknown function on these machines. (They do respond to "in"
> instructions faster than a bus cycle abort does - mo
The following patch fixes building the kvm module for kernels older than
2.6.21 and which were missing an include to in
resulting in the following error :
include/asm/io_apic.h:61: error: 'MAX_IO_APICS' undeclared here (not in a
function)
Signed-off-by: Carlo Marcelo Arenas Belon <[EMAIL
28 matches
Mail list logo