[kvm-devel] [PATCH] modify makefile to add HOST_CC and to clean acpi-dsdt.hex
for kvm-userspace: Allow to compile biossums on x86_64 and remove acpi-dsdt.hex on clean. Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]> --- bios/Makefile |4 +++- bios/acpi-dsdt.hex |8 2 files changed, 7 insertions(+), 5 deletions(-) diff --git a/bios/Makefile b/bios/Makefile index e9eadc1..7249950 100644 --- a/bios/Makefile +++ b/bios/Makefile @@ -41,6 +41,7 @@ RANLIB = ranlib BCC = bcc GCC = gcc -m32 +HOST_CC = gcc AS86 = as86 BX_INCDIRS = -I.. -I$(srcdir)/.. -I../iodev -I$(srcdir)/../iodev @@ -63,6 +64,7 @@ clean: rm -f *.o *.a *.s _rombios*_.c rombios*.txt rombios*.sym rm -f usage biossums rombios16.bin rm -f rombios32.bin rombios32.out + rm -f acpi-dsdt.hex dist-clean: clean rm -f Makefile @@ -112,4 +114,4 @@ BIOS-bochs-latest: rombios16.bin rombios32.bin cat rombios32.bin rombios16.bin > $@ biossums: biossums.c - $(GCC) -o biossums biossums.c + $(HOST_CC) -o biossums biossums.c - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/5] Enable top level configure script for cross compile
Hi,
I saw that you derive $target_cpu from arch as I know it from your older
internal and external patches.
Now you added the configure command line option --target-cpu to allow to
overwrite that $arch derived target.
a) do you have some use cases in mind where you need an overwritten target
instead the one derived from $arch ?
b) if it is needed, please add a small description to the usage() output
Kind regards,
Christian Ehrhardt
Jerone Young wrote:
> This patch adds cross compile capability to the top level configure
> script.
>
> Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
>
>
>
>
> diff -r f48e521e0add configure
> --- a/configure Wed Oct 03 21:00:03 2007 -0500
> +++ b/configure Thu Oct 04 14:59:16 2007 -0500
> @@ -5,13 +5,17 @@ want_module=1
> want_module=1
> qemu_cc=$(ls /usr/bin/gcc3* /usr/bin/gcc-3* 2>/dev/null | tail -n1)
> disable_gcc_check=
> +cross_prefix=
> +arch=`uname -m`
> +target_cpu=
>
> usage() {
> cat <<-EOF
> Usage: $0 [options]
>
> Options include:
> -
> + --arch=ARCHarchitecture to compile for ($arch)
> + --cross-prefix=PREFIX prefix for cross compiler
> --prefix=PREFIXwhere to install things ($prefix)
> --with-patched-kernel don't use external module
> --kerneldir=DIRkernel build directory ($kerneldir)
> @@ -53,6 +57,15 @@ while [[ "$1" = -* ]]; do
> --disable-gcc-check)
> disable_gcc_check=1
> ;;
> + --arch)
> + arch="$arg"
> + ;;
> + --cross-prefix)
> + cross_prefix="$arg"
> +;;
> + --target-cpu)
> + target_cpu="$arg"
> + ;;
> --help)
> usage
> ;;
> @@ -62,7 +75,7 @@ while [[ "$1" = -* ]]; do
> esac
> done
>
> -if [[ -z "$qemu_cc" ]]; then
> +if [[ -z "$qemu_cc" ]] && [[ -z "$cross_prefix" ]]; then
> echo "$0: cannot locate gcc 3.x. please install it or specify with
> --qemu-cc"
> exit 1
> fi
> @@ -72,29 +85,48 @@ if (( want_module )); then
> libkvm_kerneldir=$(readlink -f kernel)
> fi
>
> -target_cpu() {
> -if [[ $(uname -m) = i?86 ]]; then
> - echo x86_64
> -else
> - uname -m
> +#if arch is an x86 arch set to i386
> +if [[ $arch = i?86 ]]; then
> + arch="i386"
> +fi
> +
> +#see if using a cross compiler or not
> +compiler=
> +qemu_opts=
> +user_opts=
> +if [[ -z $cross_prefix ]]; then
> +qemu_opts+=" --cc=$qemu_cc"
> +user_opts+=" --cc=$qemu_cc"
> +else
> +qemu_opts+=" --cross-prefix=$cross_prefix"
> +user_opts+=" --cross-prefix=$cross_prefix"
> +fi
> +
> +#set parameters compiling
> +if [ "$arch" = "i386" -o "$arch" = "x86_64" ]; then
> +if [[ -z $target_cpu ]]; then
> +target_cpu="x86_64"
> fi
> -}
> +qemu_opts+=" --enable-alsa"
> +fi
>
> -(cd user; ./configure --prefix="$prefix" --kerneldir="$libkvm_kerneldir")
> -(cd qemu; ./configure --target-list=$(target_cpu)-softmmu --cc="$qemu_cc" \
> +#configure user dir
> +(cd user; ./configure --prefix="$prefix" --kerneldir="$libkvm_kerneldir" \
> + $user_opts --arch="$arch")
> +(cd qemu; ./configure --target-list=$target_cpu-softmmu \
> --disable-kqemu --extra-cflags="-I $PWD/../user" \
> --extra-ldflags="-L $PWD/../user" \
> --enable-kvm --kernel-path="$libkvm_kerneldir" \
> ---enable-alsa \
> ${disable_gcc_check:+"--disable-gcc-check"} \
> ---prefix="$prefix"
> +--prefix="$prefix" \
> +$qemu_opts --cpu="$arch"
> )
>
>
> -
> cat < config.mak
> +ARCH=$arch
> PREFIX=$prefix
> KERNELDIR=$kerneldir
> WANT_MODULE=$want_module
> +CC=$cross_prefix$qemu_cc
> EOF
> -
>
>
>
>
> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
>
>
>
>
> ___
> kvm-devel mailing list
> kvm-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
--
Grüsse / regards,
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization
+49 7031/16-3385
[EMAIL PROTECTED]
[EMAIL PROTECTED]
IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Johann Weihen
Geschäftsführung: Herbert Kircher
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser
Re: [kvm-devel] FreeBSD image hangs during boot
Aurelien Jarno wrote:
It's actually described page 200 of the specifications (page 216 in
ACPIspec30.pdf):
Note: This descriptor is meant for describing interrupts that are connected
to PIC-compatible
interrupt controllers, which can only be programmed for
Active-High-Edge-Triggered or Active-
Low-Level-Triggered interrupts. Any other combination is illegal. The
Extended Interrupt
Descriptor can be used to describe other combinations.
Avi, if you think this anlysis is correct I can provide the patch changing
"Level" to "Edge"...
It looks like the solution is either to describe the IRQ with an
"Extended Interrupt Descriptor" or to change this value to one of the
two allowed values. In the later case we have to make sure it is
consistent with the way the PIC works.
The attached patch attempts to override the pci irqs (now limited to 5,
9, 10, and 11) to be active high level triggered. Linux boots and
parses this correctly. Freebsd still fails.
--
Any sufficiently difficult bug is indistinguishable from a feature.
diff --git a/bios/rombios32.c b/bios/rombios32.c
index 314df94..65d6207 100755
--- a/bios/rombios32.c
+++ b/bios/rombios32.c
@@ -1181,6 +1181,14 @@ struct madt_io_apic
* lines start */
};
+struct madt_interrupt_source_override {
+ APIC_HEADER_DEF
+ uint8_t bus;
+ uint8_t source;
+ uint32_t gsi;
+ uint16_t flags;
+} __attribute__((__packed__));
+
#include "acpi-dsdt.hex"
static inline uint16_t cpu_to_le16(uint16_t x)
@@ -1273,7 +1281,8 @@ void acpi_bios_init(void)
madt_addr = addr;
madt_size = sizeof(*madt) +
sizeof(struct madt_processor_apic) * smp_cpus +
-sizeof(struct madt_io_apic);
+sizeof(struct madt_io_apic) +
+ sizeof(struct madt_interrupt_source_override) * 4;
madt = (void *)(addr);
addr += madt_size;
@@ -1335,6 +1344,8 @@ void acpi_bios_init(void)
{
struct madt_processor_apic *apic;
struct madt_io_apic *io_apic;
+struct madt_interrupt_source_override *iso;
+ static int pci_irq[4] = { 5, 9, 10, 11 };
memset(madt, 0, madt_size);
madt->local_apic_address = cpu_to_le32(0xfee0);
@@ -1354,6 +1365,17 @@ void acpi_bios_init(void)
io_apic->io_apic_id = smp_cpus;
io_apic->address = cpu_to_le32(0xfec0);
io_apic->interrupt = cpu_to_le32(0);
+ io_apic++;
+ iso = (void *)io_apic;
+ for (i = 0; i < 4; ++i) {
+ iso->type = APIC_XRUPT_OVERRIDE;
+ iso->length = sizeof(*iso);
+ iso->bus = 0;
+ iso->source = pci_irq[i];
+ iso->gsi = cpu_to_le32(iso->source);
+ iso->flags = cpu_to_le16(0xd); // active high level trigger
+ ++iso;
+ }
acpi_build_table_header((struct acpi_table_header *)madt,
"APIC", madt_size);
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] out of memory page request
David Brown wrote:
Can you run 'gdb /path/to/kvm.ko' and post the output of 'disassemble
ioapic_mmio_write' please?
Sorry for not getting back sooner.
(gdb) disassemble ioapic_mmio_write
Dump of assembler code for function ioapic_mmio_write:
The attached patch should fix, though there's probably another problem
lurking in there.
--
Any sufficiently difficult bug is indistinguishable from a feature.
commit f1b8c28f1886c9375361d7f2ebca1f742ea6bc5f
Author: Avi Kivity <[EMAIL PROTECTED]>
Date: Mon Oct 8 10:01:45 2007 +0200
KVM: Check I/O APIC indirect index before writing
Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/ioapic.c b/drivers/kvm/ioapic.c
index 9eb5058..c7992e6 100644
--- a/drivers/kvm/ioapic.c
+++ b/drivers/kvm/ioapic.c
@@ -96,7 +96,7 @@ static void ioapic_service(struct kvm_ioapic *ioapic, unsigned int idx)
static void ioapic_write_indirect(struct kvm_ioapic *ioapic, u32 val)
{
- int index;
+ unsigned index;
switch (ioapic->ioregsel) {
case IOAPIC_REG_VERSION:
@@ -114,7 +114,8 @@ static void ioapic_write_indirect(struct kvm_ioapic *ioapic, u32 val)
index = (ioapic->ioregsel - 0x10) >> 1;
ioapic_debug("change redir index %x val %x", index, val);
- ASSERT(irq < IOAPIC_NUM_PINS);
+ if (index >= IOAPIC_NUM_PINS)
+ return;
if (ioapic->ioregsel & 1) {
ioapic->redirtbl[index].bits &= 0x;
ioapic->redirtbl[index].bits |= (u64) val << 32;
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/3] kvm_free_lapic() to pair with kvm_create_lapic()
Rusty Russell wrote: > Instead of the asymetry of kvm_free_apic, implement kvm_free_lapic(). > And guess what? I found a minor bug: we don't need to hrtimer_cancel() > from kvm_main.c, because we do that in kvm_free_apic(). > > Also: > 1) kvm_vcpu_uninit should be the reverse order from kvm_vcpu_init. > 2) Don't set apic->regs_page to zero before freeing apic. > > Applied all three, thanks. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] modify makefile to add HOST_CC and to clean acpi-dsdt.hex
Laurent Vivier wrote: > for kvm-userspace: > > Allow to compile biossums on x86_64 and remove acpi-dsdt.hex on clean. > > Applied, thanks. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] vga color
Zhao, Yunfeng wrote: > Against latest commits I found that the colors on the windows guest > become weird. > For example, blue color has changed to red. > Is there any change on vga of qemu? > > Yes, I merged qemu-cvs and got some surprises. This doesn't appear on all machines. Can you post the output of 'xdpyinfo' on the affected machine? -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] FreeBSD image hangs during boot
Avi Kivity wrote: > Aurelien Jarno wrote: >> >> It's actually described page 200 of the specifications (page 216 in >> ACPIspec30.pdf): >> >> Note: This descriptor is meant for describing interrupts that are >> connected to PIC-compatible >> interrupt controllers, which can only be programmed for >> Active-High-Edge-Triggered or Active- >> Low-Level-Triggered interrupts. Any other combination is illegal. >> The Extended Interrupt >> Descriptor can be used to describe other combinations. >> >> >> >>> Avi, if you think this anlysis is correct I can provide the patch >>> changing >>> "Level" to "Edge"... >>> >>> >> >> It looks like the solution is either to describe the IRQ with an >> "Extended Interrupt Descriptor" or to change this value to one of the >> two allowed values. In the later case we have to make sure it is >> consistent with the way the PIC works. >> >> > > The attached patch attempts to override the pci irqs (now limited to 5, > 9, 10, and 11) to be active high level triggered. Linux boots and > parses this correctly. Freebsd still fails. FreeBSD will fail while ACPI will have Active-High and Level-triggered, except if you define, as Aurélien said, an "Extended Interrupt Descriptor" in ACPI table. BTW, I'm not able to boot Debian Sarge (2.6.8-11-amd64-generic) with your patch (as before). Moreover, I don't understand what this patch resolves... Laurent -- [EMAIL PROTECTED] - "Given enough eyeballs, all bugs are shallow" E. S. Raymond signature.asc Description: OpenPGP digital signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/5] Enable top level configure script for cross compile
On Mon, 2007-10-08 at 09:49 +0200, Christian Ehrhardt wrote:
> Hi,
> I saw that you derive $target_cpu from arch as I know it from your older
> internal and external patches.
> Now you added the configure command line option --target-cpu to allow to
> overwrite that $arch derived target.
> a) do you have some use cases in mind where you need an overwritten target
> instead the one derived from $arch ?
I was a bit future thinking with this option. But really it is not
needed at this moment. Now the way things work today in KVM x86 & x86-64
use the same qemu target build (x86-64-softmmu).
The case I was thinking (at least at the time), was that if we wanted to
use a different device model (assuming all the kvm code is in place)
then this would allow that.
An example would be for powerpc. Right now our current work is for ppc
embedded which is also the qemu device model we are working in
(ppcemb-softmmu). But if we also ever to have a server ppc or any other
higher end power product we may not want that code in our ppcemb-softmmu
executable (we want it small as possible). That code would probably go
in "ppc-softmmu". Now we have a problem. So you would then need to
specify target_cpu= to make this distinction for building the proper
qemu executable.
> b) if it is needed, please add a small description to the usage() output
That is actually missing from the help in this version of the patch. I
missed that :-O
But for now I will probably just remove this option from the patch and
resend it.
>
> Kind regards,
> Christian Ehrhardt
>
> Jerone Young wrote:
> > This patch adds cross compile capability to the top level configure
> > script.
> >
> > Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
> >
> >
> >
> >
> > diff -r f48e521e0add configure
> > --- a/configure Wed Oct 03 21:00:03 2007 -0500
> > +++ b/configure Thu Oct 04 14:59:16 2007 -0500
> > @@ -5,13 +5,17 @@ want_module=1
> > want_module=1
> > qemu_cc=$(ls /usr/bin/gcc3* /usr/bin/gcc-3* 2>/dev/null | tail -n1)
> > disable_gcc_check=
> > +cross_prefix=
> > +arch=`uname -m`
> > +target_cpu=
> >
> > usage() {
> > cat <<-EOF
> > Usage: $0 [options]
> >
> > Options include:
> > -
> > + --arch=ARCHarchitecture to compile for ($arch)
> > + --cross-prefix=PREFIX prefix for cross compiler
> > --prefix=PREFIXwhere to install things ($prefix)
> > --with-patched-kernel don't use external module
> > --kerneldir=DIRkernel build directory ($kerneldir)
> > @@ -53,6 +57,15 @@ while [[ "$1" = -* ]]; do
> > --disable-gcc-check)
> > disable_gcc_check=1
> > ;;
> > + --arch)
> > + arch="$arg"
> > + ;;
> > + --cross-prefix)
> > + cross_prefix="$arg"
> > +;;
> > + --target-cpu)
> > + target_cpu="$arg"
> > + ;;
> > --help)
> > usage
> > ;;
> > @@ -62,7 +75,7 @@ while [[ "$1" = -* ]]; do
> > esac
> > done
> >
> > -if [[ -z "$qemu_cc" ]]; then
> > +if [[ -z "$qemu_cc" ]] && [[ -z "$cross_prefix" ]]; then
> > echo "$0: cannot locate gcc 3.x. please install it or specify with
> > --qemu-cc"
> > exit 1
> > fi
> > @@ -72,29 +85,48 @@ if (( want_module )); then
> > libkvm_kerneldir=$(readlink -f kernel)
> > fi
> >
> > -target_cpu() {
> > -if [[ $(uname -m) = i?86 ]]; then
> > - echo x86_64
> > -else
> > - uname -m
> > +#if arch is an x86 arch set to i386
> > +if [[ $arch = i?86 ]]; then
> > + arch="i386"
> > +fi
> > +
> > +#see if using a cross compiler or not
> > +compiler=
> > +qemu_opts=
> > +user_opts=
> > +if [[ -z $cross_prefix ]]; then
> > +qemu_opts+=" --cc=$qemu_cc"
> > +user_opts+=" --cc=$qemu_cc"
> > +else
> > +qemu_opts+=" --cross-prefix=$cross_prefix"
> > +user_opts+=" --cross-prefix=$cross_prefix"
> > +fi
> > +
> > +#set parameters compiling
> > +if [ "$arch" = "i386" -o "$arch" = "x86_64" ]; then
> > +if [[ -z $target_cpu ]]; then
> > +target_cpu="x86_64"
> > fi
> > -}
> > +qemu_opts+=" --enable-alsa"
> > +fi
> >
> > -(cd user; ./configure --prefix="$prefix" --kerneldir="$libkvm_kerneldir")
> > -(cd qemu; ./configure --target-list=$(target_cpu)-softmmu --cc="$qemu_cc" \
> > +#configure user dir
> > +(cd user; ./configure --prefix="$prefix" --kerneldir="$libkvm_kerneldir" \
> > + $user_opts --arch="$arch")
> > +(cd qemu; ./configure --target-list=$target_cpu-softmmu \
> > --disable-kqemu --extra-cflags="-I $PWD/../user" \
> > --extra-ldflags="-L $PWD/../user" \
> > --enable-kvm --kernel-path="$libkvm_kerneldir" \
> > ---enable-alsa \
> > ${disable_gcc_check:+"--disable-gcc-check"} \
> > ---prefix="$prefix"
> > +--prefix="$prefix" \
> > +$qemu_opts --cpu="$arch"
> > )
> >
> >
> > -
> > cat < config.mak
> > +ARCH=$arch
> > PREFIX=$prefix
> > KERNELDIR=$kerneldir
> > WANT_MODULE=$want
[kvm-devel] [PATCH 1/5] [RESEND] Enable top level configure script for cross
This patch adds cross compile capability to the top level configure
script.
Updates:
Removed command line option --target-cpu to configure what qemu
executable to build.
diff -r f48e521e0add configure
--- a/configure Wed Oct 03 21:00:03 2007 -0500
+++ b/configure Mon Oct 08 03:30:41 2007 -0500
@@ -5,13 +5,17 @@ want_module=1
want_module=1
qemu_cc=$(ls /usr/bin/gcc3* /usr/bin/gcc-3* 2>/dev/null | tail -n1)
disable_gcc_check=
+cross_prefix=
+arch=`uname -m`
+target_cpu=
usage() {
cat <<-EOF
Usage: $0 [options]
Options include:
-
+ --arch=ARCHarchitecture to compile for ($arch)
+ --cross-prefix=PREFIX prefix for cross compiler
--prefix=PREFIXwhere to install things ($prefix)
--with-patched-kernel don't use external module
--kerneldir=DIRkernel build directory ($kerneldir)
@@ -53,6 +57,12 @@ while [[ "$1" = -* ]]; do
--disable-gcc-check)
disable_gcc_check=1
;;
+ --arch)
+ arch="$arg"
+ ;;
+ --cross-prefix)
+ cross_prefix="$arg"
+;;
--help)
usage
;;
@@ -62,7 +72,7 @@ while [[ "$1" = -* ]]; do
esac
done
-if [[ -z "$qemu_cc" ]]; then
+if [[ -z "$qemu_cc" ]] && [[ -z "$cross_prefix" ]]; then
echo "$0: cannot locate gcc 3.x. please install it or specify with --qemu-cc"
exit 1
fi
@@ -72,29 +82,48 @@ if (( want_module )); then
libkvm_kerneldir=$(readlink -f kernel)
fi
-target_cpu() {
-if [[ $(uname -m) = i?86 ]]; then
- echo x86_64
-else
- uname -m
+#if arch is an x86 arch set to i386
+if [[ $arch = i?86 ]]; then
+ arch="i386"
+fi
+
+#see if using a cross compiler or not
+compiler=
+qemu_opts=
+user_opts=
+if [[ -z $cross_prefix ]]; then
+qemu_opts+=" --cc=$qemu_cc"
+user_opts+=" --cc=$qemu_cc"
+else
+qemu_opts+=" --cross-prefix=$cross_prefix"
+user_opts+=" --cross-prefix=$cross_prefix"
+fi
+
+#set parameters compiling
+if [ "$arch" = "i386" -o "$arch" = "x86_64" ]; then
+if [[ -z $target_cpu ]]; then
+target_cpu="x86_64"
fi
-}
+qemu_opts+=" --enable-alsa"
+fi
-(cd user; ./configure --prefix="$prefix" --kerneldir="$libkvm_kerneldir")
-(cd qemu; ./configure --target-list=$(target_cpu)-softmmu --cc="$qemu_cc" \
+#configure user dir
+(cd user; ./configure --prefix="$prefix" --kerneldir="$libkvm_kerneldir" \
+ $user_opts --arch="$arch")
+(cd qemu; ./configure --target-list=$target_cpu-softmmu \
--disable-kqemu --extra-cflags="-I $PWD/../user" \
--extra-ldflags="-L $PWD/../user" \
--enable-kvm --kernel-path="$libkvm_kerneldir" \
---enable-alsa \
${disable_gcc_check:+"--disable-gcc-check"} \
---prefix="$prefix"
+--prefix="$prefix" \
+$qemu_opts --cpu="$arch"
)
-
cat < config.mak
+ARCH=$arch
PREFIX=$prefix
KERNELDIR=$kerneldir
WANT_MODULE=$want_module
+CC=$cross_prefix$qemu_cc
EOF
-
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] vga color
All our machines for KVM testing have the problem. I attached the output of "xdpyinfo" on one of them. Thanks Yunfeng >-Original Message- >From: Avi Kivity [mailto:[EMAIL PROTECTED] >Sent: 2007年10月8日 16:15 >To: Zhao, Yunfeng >Cc: kvm-devel@lists.sourceforge.net >Subject: Re: [kvm-devel] vga color > >Zhao, Yunfeng wrote: >> Against latest commits I found that the colors on the windows guest >> become weird. >> For example, blue color has changed to red. >> Is there any change on vga of qemu? >> >> > >Yes, I merged qemu-cvs and got some surprises. > >This doesn't appear on all machines. Can you post the output of >'xdpyinfo' on the affected machine? > >-- >Any sufficiently difficult bug is indistinguishable from a feature. From: root [EMAIL PROTECTED] Sent: 2007Äê10ÔÂ8ÈÕÐÇÆÚÒ» 16:27 name of display:localhost:1.0 version number:11.0 vendor string:The X.Org Foundation vendor release number:70101000 X.Org version: 7.1.1 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding:32, LSBFirst, 32 image byte order:LSBFirst number of supported pixmap formats:2 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 keycode range:minimum 8, maximum 255 focus: window 0x321, revert to Parent number of extensions:21 BIG-REQUESTS DAMAGE DEC-XTRAP DOUBLE-BUFFER Extended-Visual-Information MIT-SCREEN-SAVER MIT-SHM MIT-SUNDRY-NONSTANDARD RECORD SECURITY SHAPE SYNC TOG-CUP VNC-EXTENSION X-Resource XC-APPGROUP XC-MISC XFIXES XFree86-Bigfont XTEST XVideo default screen number:0 number of screens:1 screen #0: dimensions:1024x768 pixels (260x195 millimeters) resolution:100x100 dots per inch depths (2):1, 16 root window id:0x25 depth of root window:16 planes number of colormaps:minimum 1, maximum 1 default colormap:0x20 default number of colormap cells:64 preallocated pixels:black 0, white 65535 options:backing-store YES, save-unders YES largest cursor:1024x768 current input event mask:0xfa2033 KeyPressMask KeyReleaseMask EnterWindowMask LeaveWindowMask ButtonMotionMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask PropertyChangeMask ColormapChangeMask number of visuals:2 default visual id: 0x21 visual: visual id:0x21 class:TrueColor depth:16 planes available colormap entries:64 per subfield red, green, blue masks:0xf800, 0x7e0, 0x1f significant bits in color specification:8 bits visual: visual id:0x22 class:DirectColor depth:16 planes available colormap entries:64 per subfield red, green, blue masks:0x3f, 0x7c0, 0xf800 significant bits in color specification:8 bits - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ kvm-Bugs-1809327 ] vga color issue
Bugs item #1809327, was opened at 2007-10-08 16:51 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=1809327&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: yunfeng (yunfeng) Assigned to: Nobody/Anonymous (nobody) Summary: vga color issue Initial Comment: Against commits,kvm.git: c0c8b920137e988bb4cde1bb41e0e409c8abb844 and kvm-userspace.git:1de8b6722138b89ec471ceb5c8c8def17d963d1d, vga colors become weird. For example, the blue color has changed to red. See the attched snapshot pic for windows guest. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1809327&group_id=180599 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] FreeBSD image hangs during boot
Laurent Vivier wrote: > Avi Kivity wrote: > >> Aurelien Jarno wrote: >> >>> It's actually described page 200 of the specifications (page 216 in >>> ACPIspec30.pdf): >>> >>> Note: This descriptor is meant for describing interrupts that are >>> connected to PIC-compatible >>> interrupt controllers, which can only be programmed for >>> Active-High-Edge-Triggered or Active- >>> Low-Level-Triggered interrupts. Any other combination is illegal. >>> The Extended Interrupt >>> Descriptor can be used to describe other combinations. >>> >>> >>> >>> Avi, if you think this anlysis is correct I can provide the patch changing "Level" to "Edge"... >>> It looks like the solution is either to describe the IRQ with an >>> "Extended Interrupt Descriptor" or to change this value to one of the >>> two allowed values. In the later case we have to make sure it is >>> consistent with the way the PIC works. >>> >>> >>> >> The attached patch attempts to override the pci irqs (now limited to 5, >> 9, 10, and 11) to be active high level triggered. Linux boots and >> parses this correctly. Freebsd still fails. >> > > FreeBSD will fail while ACPI will have Active-High and Level-triggered, except > if you define, as Aurélien said, an "Extended Interrupt Descriptor" in ACPI > table. > > BTW, I'm not able to boot Debian Sarge (2.6.8-11-amd64-generic) with your > patch > (as before). > > Moreover, I don't understand what this patch resolves... I thought this was the extended interrupt descriptor; sorry my confusion. Meanwhile I changed the dsdt to use the _real_ extended enhanced advanced improved interrupt descriptor, and freebsd now boots. FC6 and Windows survived. I'll push this after further testing. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] vga color
Zhao, Yunfeng wrote:
> All our machines for KVM testing have the problem.
> I attached the output of "xdpyinfo" on one of them.
>
>
Please try the attached patch.
--
Any sufficiently difficult bug is indistinguishable from a feature.
diff --git a/qemu/sdl.c b/qemu/sdl.c
index 02500c9..3f3b719 100644
--- a/qemu/sdl.c
+++ b/qemu/sdl.c
@@ -87,7 +87,7 @@ static void sdl_resize(DisplayState *ds, int w, int h)
ds->data = screen->pixels;
ds->linesize = screen->pitch;
ds->depth = screen->format->BitsPerPixel;
-if (screen->format->Bshift > screen->format->Rshift) {
+if (ds->depth == 32 && screen->format->Rshift == 0) {
ds->bgr = 1;
} else {
ds->bgr = 0;
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] KVM Source layout Proposal to accommodate newCPU architecture
Zhang, Xiantao wrote: > Hollis Blanchard wrote: > >> On Mon, 2007-10-08 at 10:36 +0800, Zhang, Xiantao wrote: >> >>> Avi Kivity wrote: >>> Zhang, Xiantao wrote: > Avi Kivity wrote: > > >> Zhang, Xiantao wrote: >> >> >>> Zhang, Xiantao wrote: >>> >>> >>> > Hi Avi, > So you mean IA64 can adopt the similar method as well? > > > What method do you mean exactly? >>> Put all arch-specific files into arch/ia64/kvm as you described >>> in future KVM infrastructure. >>> >>> >>> The powerpc people had some patches to make kvm_main arch independent. We should work on that base. To avoid a dependency on the x86 merge, we can start by working withing drivers/kvm/, for example creating drivers/kvm/x86.c and drivers/kvm/ia64.c. Later patches can move these to arch/*/. >>> It may work on x86 side. But for IA64, we have several source >>> files and assembly files to implement a VMM module, which >>> contains the virtualization logic of CPU, MMU and other platform >>> devices. (In KVM forum, Anthony had presented IA64/KVM >>> architecture which is a bit different with x86 side due to >>> different approaches for VT.).If we put all such these >>> arch-specific files in one directory, it looks very strange! >>> >>> >>> >> ia64/ subdirectory is also fine. >> >> > But even so , we have to split current code to be arch-independent, > and to support IA64 and other architectures. > So, why not add an more subdirectory x86 in drivers kvm to hold > X86-arch code? > > Sure, that's not an issue. >>> Could you help to open a branch from master tree for this work? We >>> are very willing to contribute to it:) >>> >> Do you really need a new branch? Why not just submit patches? >> > > Due to big changes to current source structure, maybe a new branch would > help to work, and doesn't > impact existing quality of KVM. If it is convenient for you to submit > patches directly, also we are glad to do in that way. > A branch with such large changes quickly becomes out-of-date, so it's best to send patches. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH][RESEND] Don't route PIC interrupts through the local APIC if the local APIC config says so
Under certain conditions, PIC interrupts should not be passed through by
the local APIC. This is usually when the guest uses the IOAPIC instead
of the PIC.
Currently qemu does not block PIC interrupts when the local APIC is
configured to do so; this results in interrupts begin received twice and
time running at double speed on Linux x86_64 guest.
The attached patch, from Qing He and myself, fixes the problem.
--
error compiling committee.c: too many arguments to function
Index: vl.h
===
RCS file: /sources/qemu/qemu/vl.h,v
retrieving revision 1.273
diff -u -u -r1.273 vl.h
--- vl.h 30 Sep 2007 14:44:52 - 1.273
+++ vl.h 2 Oct 2007 10:28:55 -
@@ -1138,6 +1138,7 @@
typedef struct IOAPICState IOAPICState;
int apic_init(CPUState *env);
+int apic_accept_pic_intr(CPUState *env);
int apic_get_interrupt(CPUState *env);
IOAPICState *ioapic_init(void);
void ioapic_set_irq(void *opaque, int vector, int level);
Index: hw/apic.c
===
RCS file: /sources/qemu/qemu/hw/apic.c,v
retrieving revision 1.16
diff -u -u -r1.16 apic.c
--- hw/apic.c 17 Sep 2007 08:09:46 - 1.16
+++ hw/apic.c 2 Oct 2007 10:28:55 -
@@ -484,6 +484,25 @@
return intno;
}
+int apic_accept_pic_intr(CPUState *env)
+{
+APICState *s = env->apic_state;
+uint32_t lvt0;
+
+if (!s)
+return -1;
+
+lvt0 = s->lvt[APIC_LVT_LINT0];
+
+if (s->id == 0 &&
+((s->apicbase & MSR_IA32_APICBASE_ENABLE) == 0 ||
+ ((lvt0 & APIC_LVT_MASKED) == 0 &&
+ ((lvt0 >> 8) & 0x7) == APIC_DM_EXTINT)))
+return 1;
+
+return 0;
+}
+
static uint32_t apic_get_current_count(APICState *s)
{
int64_t d;
@@ -790,6 +809,13 @@
{
APICState *s = opaque;
apic_init_ipi(s);
+
+/*
+ * LINT0 delivery mode is set to ExtInt at initialization time
+ * typically by BIOS, so PIC interrupt can be delivered to the
+ * processor when local APIC is enabled.
+ */
+s->lvt[APIC_LVT_LINT0] = 0x700;
}
static CPUReadMemoryFunc *apic_mem_read[3] = {
@@ -821,6 +847,13 @@
s->apicbase = 0xfee0 |
(s->id ? 0 : MSR_IA32_APICBASE_BSP) | MSR_IA32_APICBASE_ENABLE;
+/*
+ * LINT0 delivery mode is set to ExtInt at initialization time
+ * typically by BIOS, so PIC interrupt can be delivered to the
+ * processor when local APIC is enabled.
+ */
+s->lvt[APIC_LVT_LINT0] = 0x700;
+
/* XXX: mapping more APICs at the same memory location */
if (apic_io_memory == 0) {
/* NOTE: the APIC is directly connected to the CPU - it is not
Index: hw/pc.c
===
RCS file: /sources/qemu/qemu/hw/pc.c,v
retrieving revision 1.85
diff -u -u -r1.85 pc.c
--- hw/pc.c 17 Sep 2007 08:09:47 - 1.85
+++ hw/pc.c 2 Oct 2007 10:28:55 -
@@ -93,6 +93,9 @@
return intno;
}
/* read the irq from the PIC */
+if (!apic_accept_pic_intr(env))
+return -1;
+
intno = pic_read_irq(isa_pic);
return intno;
}
@@ -100,10 +103,8 @@
static void pic_irq_request(void *opaque, int irq, int level)
{
CPUState *env = opaque;
-if (level)
+if (level && apic_accept_pic_intr(env))
cpu_interrupt(env, CPU_INTERRUPT_HARD);
-else
-cpu_reset_interrupt(env, CPU_INTERRUPT_HARD);
}
/* PC cmos mappings */
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Should we show vcpu_id info when an unknown exception happens?
commit e634910140a7e8a55322cd6a1d94fcfd77d9eae0
Author: root <[EMAIL PROTECTED](none)>
Date: Mon Oct 8 16:52:01 2007 +0800
show vcpu_id in case of unknown hw exception.
Signed-off-by: Yaozu (Eddie) Dong <[EMAIL PROTECTED]>
diff --git a/user/kvmctl.c b/user/kvmctl.c
index 3dee407..eeddb54 100644
--- a/user/kvmctl.c
+++ b/user/kvmctl.c
@@ -1053,8 +1053,8 @@ again:
if (1) {
switch (run->exit_reason) {
case KVM_EXIT_UNKNOWN:
- fprintf(stderr, "unhandled vm exit: 0x%x\n",
- (unsigned)run->hw.hardware_exit_reason);
+ fprintf(stderr, "unhandled vm exit: 0x%x
vcpu_id=%d\n",
+ (unsigned)run->hw.hardware_exit_reason,
vcpu);
kvm_show_regs(kvm, vcpu);
abort();
break;
@@ -1131,8 +1131,8 @@ again:
if (1) {
switch (run->exit_reason) {
case KVM_EXIT_UNKNOWN:
- fprintf(stderr, "unhandled vm exit: 0x%x\n",
- (unsigned)run->hw.hardware_exit_reason);
+ fprintf(stderr, "unhandled vm exit: 0x%x
vcpu_id=%d\n",
+
(unsigned)run->hw.hardware_exit_reason,vcpu);
kvm_show_regs(kvm, vcpu);
abort();
break;
reset-u0.patch
Description: reset-u0.patch
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] split ioapic reset API
This one is a preparation for kernel devices reset support.
Split ioapic reset API and export PIC reset API
Signed-off-by: Yaozu (Eddie) Dong <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/i8259.c b/drivers/kvm/i8259.c
index a679157..abcf58f 100644
--- a/drivers/kvm/i8259.c
+++ b/drivers/kvm/i8259.c
@@ -181,7 +181,7 @@ int kvm_pic_read_irq(struct kvm_pic *s)
return intno;
}
-static void pic_reset(void *opaque)
+void kvm_pic_reset(void *opaque)
{
struct kvm_kpic_state *s = opaque;
@@ -209,7 +209,7 @@ static void pic_ioport_write(void *opaque, u32 addr,
u32 val)
addr &= 1;
if (addr == 0) {
if (val & 0x10) {
- pic_reset(s); /* init */
+ kvm_pic_reset(s); /* init */
/*
* deassert a pending interrupt
*/
diff --git a/drivers/kvm/ioapic.c b/drivers/kvm/ioapic.c
index 9eb5058..a941c38 100644
--- a/drivers/kvm/ioapic.c
+++ b/drivers/kvm/ioapic.c
@@ -365,18 +365,27 @@ static void ioapic_mmio_write(struct kvm_io_device
*this, gpa_t addr, int len,
}
}
+void kvm_ioapic_reset(struct kvm_ioapic *ioapic)
+{
+ int i;
+
+ for (i = 0; i < IOAPIC_NUM_PINS; i++)
+ ioapic->redirtbl[i].fields.mask = 1;
+ ioapic->base_address = IOAPIC_DEFAULT_BASE_ADDRESS;
+ ioapic->ioregsel = 0;
+ ioapic->irr = 0;
+ ioapic->id = 0;
+}
+
int kvm_ioapic_init(struct kvm *kvm)
{
struct kvm_ioapic *ioapic;
- int i;
ioapic = kzalloc(sizeof(struct kvm_ioapic), GFP_KERNEL);
if (!ioapic)
return -ENOMEM;
kvm->vioapic = ioapic;
- for (i = 0; i < IOAPIC_NUM_PINS; i++)
- ioapic->redirtbl[i].fields.mask = 1;
- ioapic->base_address = IOAPIC_DEFAULT_BASE_ADDRESS;
+ kvm_ioapic_reset(ioapic);
ioapic->dev.read = ioapic_mmio_read;
ioapic->dev.write = ioapic_mmio_write;
ioapic->dev.in_range = ioapic_in_range;
diff --git a/drivers/kvm/irq.h b/drivers/kvm/irq.h
index 11fc014..9bc43d3 100644
--- a/drivers/kvm/irq.h
+++ b/drivers/kvm/irq.h
@@ -139,6 +139,8 @@ int kvm_apic_accept_pic_intr(struct kvm_vcpu *vcpu);
int kvm_get_apic_interrupt(struct kvm_vcpu *vcpu);
int kvm_create_lapic(struct kvm_vcpu *vcpu);
void kvm_lapic_reset(struct kvm_vcpu *vcpu);
+void kvm_ioapic_reset(struct kvm_ioapic *ioapic);
+void kvm_pic_reset(void *opaque);
void kvm_free_apic(struct kvm_lapic *apic);
u64 kvm_lapic_get_cr8(struct kvm_vcpu *vcpu);
void kvm_lapic_set_tpr(struct kvm_vcpu *vcpu, unsigned long cr8);
reset-k1.patch
Description: reset-k1.patch
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] kernel device reset support
Kernel side patch to introduce a new API for kernel device reset and
force
vcpu mp_state to UNINATIALIZED state if it is reset.
thx,eddie
Add VM reset support in kernel side to
reset the kernel devices and VCPUs.
Signed-off-by: Yaozu (Eddie) Dong <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index f60255c..661743a 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -330,6 +330,7 @@ struct kvm_vcpu {
unsigned long cr8;
u64 pdptrs[4]; /* pae */
u64 shadow_efer;
+ int force_to_quit;
u64 apic_base;
struct kvm_lapic *apic;/* kernel irqchip context */
#define VCPU_MP_STATE_RUNNABLE 0
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 71ed1b3..0958f78 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -2199,6 +2199,8 @@ static int kvm_vcpu_ioctl_run(struct kvm_vcpu
*vcpu, struct kvm_run *kvm_run)
vcpu_load(vcpu);
if (unlikely(vcpu->mp_state == VCPU_MP_STATE_UNINITIALIZED)) {
+ if (irqchip_in_kernel(vcpu->kvm) && vcpu->apic)
+ kvm_lapic_reset(vcpu);
kvm_vcpu_block(vcpu);
vcpu_put(vcpu);
return -EAGAIN;
@@ -3095,6 +3097,41 @@ out:
return r;
}
+void kvm_reset_devices(struct kvm *kvm)
+{
+ kvm_pic_reset(&pic_irqchip(kvm)->pics[1]);
+ kvm_pic_reset(&pic_irqchip(kvm)->pics[0]);
+ pic_irqchip(kvm)->output = 0;
+ kvm_ioapic_reset(kvm->vioapic);
+}
+
+/*
+ * Reset VM.
+ *
+ */
+int kvm_vm_reset(struct kvm *kvm)
+{
+ struct kvm_vcpu *vcpu;
+ int i;
+
+ kvm_reset_devices(kvm);
+ for (i = 0; i < KVM_MAX_VCPUS; i++) {
+ vcpu = kvm->vcpus[i];
+ if (!vcpu)
+ continue;
+ /* active VCPU */
+ if (vcpu->vcpu_id)
+ vcpu->mp_state = VCPU_MP_STATE_UNINITIALIZED;
+ else {
+ vcpu->mp_state = VCPU_MP_STATE_RUNNABLE;
+ kvm_lapic_reset(vcpu);
+ }
+ vcpu->force_to_quit = 1;
+ kvm_vcpu_kick(vcpu);
+ }
+ return 0;
+}
+
static long kvm_vm_ioctl(struct file *filp,
unsigned int ioctl, unsigned long arg)
{
@@ -3163,6 +3200,12 @@ static long kvm_vm_ioctl(struct file *filp,
else
goto out;
break;
+ case KVM_RESET:
+ r = -EFAULT;
+ if (!irqchip_in_kernel(kvm))
+ goto out;
+ r = kvm_vm_reset(kvm);
+ break;
case KVM_IRQ_LINE: {
struct kvm_irq_level irq_event;
diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
index 3d8e01e..0799aad 100644
--- a/drivers/kvm/vmx.c
+++ b/drivers/kvm/vmx.c
@@ -1860,6 +1860,10 @@ static int handle_external_interrupt(struct
kvm_vcpu *vcpu,
struct kvm_run *kvm_run)
{
++vcpu->stat.irq_exits;
+ if (vcpu->force_to_quit) {
+ vcpu->force_to_quit = 0;
+ return -EINTR;
+ }
return 1;
}
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index d62d3b2..2fd731f 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -371,6 +371,7 @@ struct kvm_signal_mask {
#define KVM_IRQ_LINE _IOW(KVMIO, 0x61, struct
kvm_irq_level)
#define KVM_GET_IRQCHIP _IOWR(KVMIO, 0x62, struct
kvm_irqchip)
#define KVM_SET_IRQCHIP _IOR(KVMIO, 0x63, struct
kvm_irqchip)
+#define KVM_RESET_IO(KVMIO, 0x64)
/*
* ioctls for vcpu fds
reset-k2.patch
Description: reset-k2.patch
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] kernel device reset support - user
User level change to add callback to reset kernel devices.
thx,eddie
Add user reset callback support for kernel devices.
Signed-off-by: Yaozu (Eddie) Dong <[EMAIL PROTECTED]>
diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
index 4d0bb93..d81e7e1 100644
--- a/qemu/hw/pc.c
+++ b/qemu/hw/pc.c
@@ -721,6 +721,10 @@ static void pc_init1(ram_addr_t ram_size, int
vga_ram_size, int boot_device,
vmport_init(env);
}
+#ifdef USE_KVM
+if (kvm_allowed && kvm_irqchip_in_kernel(kvm_context))
+qemu_register_reset(kvm_reset_kernel, kvm_context);
+#endif
/* allocate RAM */
ram_addr = qemu_ram_alloc(ram_size);
cpu_register_physical_memory(0, ram_size, ram_addr);
diff --git a/user/kvmctl.c b/user/kvmctl.c
index eeddb54..e1a4afb 100644
--- a/user/kvmctl.c
+++ b/user/kvmctl.c
@@ -1240,3 +1240,10 @@ int kvm_irqchip_in_kernel(kvm_context_t kvm)
{
return kvm->irqchip_in_kernel;
}
+
+void kvm_reset_kernel(kvm_context_t kvm)
+{
+if (kvm_irqchip_in_kernel(kvm))
+ return ioctl(kvm->vm_fd, KVM_RESET, 0);
+}
+
diff --git a/user/kvmctl.h b/user/kvmctl.h
index 09cf6d7..9f56027 100644
--- a/user/kvmctl.h
+++ b/user/kvmctl.h
@@ -453,6 +453,13 @@ int kvm_dirty_pages_log_enable_all(kvm_context_t
kvm);
int kvm_dirty_pages_log_reset(kvm_context_t kvm);
/*!
+ * \brief Reset kernel devices.
+ *
+ * \param kvm Pointer to the current kvm_context
+ */
+void kvm_reset_kernel(kvm_context_t kvm);
+
+/*!
* \brief Query whether in kernel irqchip is used
*
* \param kvm Pointer to the current kvm_context
reset-u1.patch
Description: reset-u1.patch
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kernel device reset support
Dong, Eddie wrote:
> Kernel side patch to introduce a new API for kernel device reset and
> force
> vcpu mp_state to UNINATIALIZED state if it is reset.
> thx,eddie
>
>
>
> +
> +/*
> + * Reset VM.
> + *
> + */
> +int kvm_vm_reset(struct kvm *kvm)
> +{
> + struct kvm_vcpu *vcpu;
> + int i;
> +
> + kvm_reset_devices(kvm);
> + for (i = 0; i < KVM_MAX_VCPUS; i++) {
> + vcpu = kvm->vcpus[i];
> + if (!vcpu)
> + continue;
> + /* active VCPU */
> + if (vcpu->vcpu_id)
> + vcpu->mp_state = VCPU_MP_STATE_UNINITIALIZED;
> + else {
> + vcpu->mp_state = VCPU_MP_STATE_RUNNABLE;
> + kvm_lapic_reset(vcpu);
>
Why is the handling here different?
> + }
> + vcpu->force_to_quit = 1;
> + kvm_vcpu_kick(vcpu);
> + }
> + return 0;
> +}
> +
> static long kvm_vm_ioctl(struct file *filp,
> unsigned int ioctl, unsigned long arg)
> {
> @@ -3163,6 +3200,12 @@ static long kvm_vm_ioctl(struct file *filp,
> else
> goto out;
> break;
> + case KVM_RESET:
> + r = -EFAULT;
>
-EINVAL. Or better accept it always and only reset the vcpu if
!irqchip_in_kernel().
> + if (!irqchip_in_kernel(kvm))
> + goto out;
> + r = kvm_vm_reset(kvm);
> + break;
> case KVM_IRQ_LINE: {
> struct kvm_irq_level irq_event;
>
> diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
> index 3d8e01e..0799aad 100644
> --- a/drivers/kvm/vmx.c
> +++ b/drivers/kvm/vmx.c
> @@ -1860,6 +1860,10 @@ static int handle_external_interrupt(struct
> kvm_vcpu *vcpu,
>struct kvm_run *kvm_run)
> {
> ++vcpu->stat.irq_exits;
> + if (vcpu->force_to_quit) {
> + vcpu->force_to_quit = 0;
> + return -EINTR;
> + }
> return 1;
> }
>
Why is this needed?
Userspace can always force an exit by sending a signal.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kernel device reset support
Dong, Eddie wrote:
> Kernel side patch to introduce a new API for kernel device reset and
> force
> vcpu mp_state to UNINATIALIZED state if it is reset.
> thx,eddie
>
> +
> +/*
> + * Reset VM.
> + *
> + */
> +int kvm_vm_reset(struct kvm *kvm)
> +{
> + struct kvm_vcpu *vcpu;
> + int i;
> +
> + kvm_reset_devices(kvm);
>
Need to take kvm->lock around this.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] split ioapic reset API
Dong, Eddie wrote:
> This one is a preparation for kernel devices reset support.
>
>
>
>Split ioapic reset API and export PIC reset API
>
Please split into two patches, I need to fold them into the pic patch
and the ioapic patch.
>
> -static void pic_reset(void *opaque)
> +void kvm_pic_reset(void *opaque)
> {
> struct kvm_kpic_state *s = opaque;
>
Does this really need to be an opaque? Or is this some qemu remnant?
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] FreeBSD image hangs during boot
Avi Kivity wrote: > Laurent Vivier wrote: >> Avi Kivity wrote: >> >>> Aurelien Jarno wrote: >>> It's actually described page 200 of the specifications (page 216 in ACPIspec30.pdf): Note: This descriptor is meant for describing interrupts that are connected to PIC-compatible interrupt controllers, which can only be programmed for Active-High-Edge-Triggered or Active- Low-Level-Triggered interrupts. Any other combination is illegal. The Extended Interrupt Descriptor can be used to describe other combinations. > Avi, if you think this anlysis is correct I can provide the patch > changing > "Level" to "Edge"... > > > It looks like the solution is either to describe the IRQ with an "Extended Interrupt Descriptor" or to change this value to one of the two allowed values. In the later case we have to make sure it is consistent with the way the PIC works. >>> The attached patch attempts to override the pci irqs (now limited to 5, >>> 9, 10, and 11) to be active high level triggered. Linux boots and >>> parses this correctly. Freebsd still fails. >>> >> FreeBSD will fail while ACPI will have Active-High and Level-triggered, >> except >> if you define, as Aurélien said, an "Extended Interrupt Descriptor" in ACPI >> table. >> >> BTW, I'm not able to boot Debian Sarge (2.6.8-11-amd64-generic) with your >> patch >> (as before). >> >> Moreover, I don't understand what this patch resolves... > > I thought this was the extended interrupt descriptor; sorry my confusion. > > Meanwhile I changed the dsdt to use the _real_ extended enhanced > advanced improved interrupt descriptor, and freebsd now boots. FC6 and > Windows survived. I'll push this after further testing. Great ! If you send me your patch I can test it and make it run on distros I have (I can wait the push too). Is this THE solution to this issue or only a workaround ? Laurent -- [EMAIL PROTECTED] - "Given enough eyeballs, all bugs are shallow" E. S. Raymond signature.asc Description: OpenPGP digital signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] FreeBSD image hangs during boot
Laurent Vivier wrote: > Avi Kivity wrote: > >> Laurent Vivier wrote: >> >>> Avi Kivity wrote: >>> >>> Aurelien Jarno wrote: > It's actually described page 200 of the specifications (page 216 in > ACPIspec30.pdf): > > Note: This descriptor is meant for describing interrupts that are > connected to PIC-compatible > interrupt controllers, which can only be programmed for > Active-High-Edge-Triggered or Active- > Low-Level-Triggered interrupts. Any other combination is illegal. > The Extended Interrupt > Descriptor can be used to describe other combinations. > > > > > >> Avi, if you think this anlysis is correct I can provide the patch >> changing >> "Level" to "Edge"... >> >> >> >> > It looks like the solution is either to describe the IRQ with an > "Extended Interrupt Descriptor" or to change this value to one of the > two allowed values. In the later case we have to make sure it is > consistent with the way the PIC works. > > > > The attached patch attempts to override the pci irqs (now limited to 5, 9, 10, and 11) to be active high level triggered. Linux boots and parses this correctly. Freebsd still fails. >>> FreeBSD will fail while ACPI will have Active-High and Level-triggered, >>> except >>> if you define, as Aurélien said, an "Extended Interrupt Descriptor" in ACPI >>> table. >>> >>> BTW, I'm not able to boot Debian Sarge (2.6.8-11-amd64-generic) with your >>> patch >>> (as before). >>> >>> Moreover, I don't understand what this patch resolves... >>> >> I thought this was the extended interrupt descriptor; sorry my confusion. >> >> Meanwhile I changed the dsdt to use the _real_ extended enhanced >> advanced improved interrupt descriptor, and freebsd now boots. FC6 and >> Windows survived. I'll push this after further testing. >> > > Great ! > > If you send me your patch I can test it and make it run on distros I have (I > can > wait the push too). > It's now pushed. > Is this THE solution to this issue or only a workaround ? > I think this solves the issue completely. The only question is whether other guests have regressed. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [GFXBOOT] [PATCH] When switching to real-mode, pass SS in a GP register
Hi, sorry for the delay, but I've been on vacation. :-) On Sun, 30 Sep 2007, Anthony Liguori wrote: > Avi Kivity wrote: > > Anthony Liguori wrote: > >> As Avi pointed out, VT requires that SS.RPL == CS.RPL. We're seeing > >> gfxboot fail under KVM because ss = 0x5761 while cs = 0x4004 during > >> the transition from real mode to protected mode. The attached patch > >> passes the value of ss through ebx since KVM has to sanitize the value > >> of ss to make VT happy. Uh, that's weird! Thanks for pointing this out. [patch] > > This is subtly wrong, I think. First, note that 'mov eax,ss' only > > affects ax, not the high 16 bits. The note that the original code > > happily shifts eax which is half ss, half garbage left by 4 bits and > > uses that to generate a 32-bit result. > > > > The reason it worked before was that bits 16-29 of eax are already clear > > by virtue of having come from cr0. But now you're using ebx which > > hasn't had that magic clearing. > > > > You're right. Good catch! Actually that is not true. 'mov eax,ss' does implicitly clear the upper 16 bits (both processor docs and hardware agree here). > > In your comment to the kvm bug you say that the patch allows you to > > boot, so perhaps bits 16-29 of ebx are already clear here, or my > > analysis is mistaken. > > > > Yeah, I just got lucky with ebx I guess :-) Attached is an updated patch that > fixes this problem. Anyway, ss is already saved, so no need for an extra register. Here is my version (tested and works on my machine): --- bincode.asm (revision 650) +++ bincode.asm (working copy) @@ -15546,7 +15546,11 @@ mov ax,pm_seg.prog_d16 mov ds,ax - mov eax,ss + ; needed for KVM: + ; ss:rpl must equal cs:rpl in PM for VT. We can't rely on ss + ; maintaining its value after the transition. + + movzx eax,word [rm_seg.ss] and esp,0h shl eax,4 add esp,eax - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] vga color
Zhao, Yunfeng wrote: > It works.:) > The issue disappeared after applied the patch. > Thanks, I applied and pushed it. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] vga color
It works.:) The issue disappeared after applied the patch. Thanks Yunfeng >-Original Message- >From: Avi Kivity [mailto:[EMAIL PROTECTED] >Sent: 2007年10月8日 17:53 >To: Zhao, Yunfeng >Cc: kvm-devel@lists.sourceforge.net >Subject: Re: [kvm-devel] vga color > >Zhao, Yunfeng wrote: >> All our machines for KVM testing have the problem. >> I attached the output of "xdpyinfo" on one of them. >> >> > >Please try the attached patch. > > >-- >Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH resubmitted] CodingStyle cleanup
CodingStyle cleanup.
Signed-off-by: Mike D. Day <[EMAIL PROTECTED]>
---
This is the second attempt. It includes changes based on feedback, and
consolidates all the 10 previous CodingStyle patches into one patch.
drivers/kvm/kvm.h | 32 +-
drivers/kvm/kvm_main.c| 58 ---
drivers/kvm/lapic.c |3 +-
drivers/kvm/mmu.c | 10 +++--
drivers/kvm/paging_tmpl.h |2 +-
drivers/kvm/svm.c | 48 +--
drivers/kvm/svm.h |2 +-
drivers/kvm/vmx.c | 66 +++-
drivers/kvm/vmx.h |8 ++--
drivers/kvm/x86_emulate.c | 81 ++---
10 files changed, 157 insertions(+), 153 deletions(-)
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 8e58f3b..f0dfb1f 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -524,7 +524,7 @@ extern struct kvm_x86_ops *kvm_x86_ops;
if (printk_ratelimit()) \
printk(KERN_ERR "kvm: %i: cpu%i " fmt, \
current->tgid, (vcpu)->vcpu_id , ## __VA_ARGS__); \
- } while(0)
+ } while (0)
#define kvm_printf(kvm, fmt ...) printk(KERN_DEBUG fmt)
#define vcpu_printf(vcpu, fmt...) kvm_printf(vcpu->kvm, fmt)
@@ -584,7 +584,7 @@ int kvm_set_msr(struct kvm_vcpu *vcpu, u32 msr_index, u64
data);
struct x86_emulate_ctxt;
-int kvm_emulate_pio (struct kvm_vcpu *vcpu, struct kvm_run *run, int in,
+int kvm_emulate_pio(struct kvm_vcpu *vcpu, struct kvm_run *run, int in,
int size, unsigned port);
int kvm_emulate_pio_string(struct kvm_vcpu *vcpu, struct kvm_run *run, int in,
int size, unsigned long count, int down,
@@ -593,7 +593,7 @@ void kvm_emulate_cpuid(struct kvm_vcpu *vcpu);
int kvm_emulate_halt(struct kvm_vcpu *vcpu);
int emulate_invlpg(struct kvm_vcpu *vcpu, gva_t address);
int emulate_clts(struct kvm_vcpu *vcpu);
-int emulator_get_dr(struct x86_emulate_ctxt* ctxt, int dr,
+int emulator_get_dr(struct x86_emulate_ctxt *ctxt, int dr,
unsigned long *dest);
int emulator_set_dr(struct x86_emulate_ctxt *ctxt, int dr,
unsigned long value);
@@ -617,7 +617,7 @@ void kvm_put_guest_fpu(struct kvm_vcpu *vcpu);
void kvm_flush_remote_tlbs(struct kvm *kvm);
int emulator_read_std(unsigned long addr,
- void *val,
+ void *val,
unsigned int bytes,
struct kvm_vcpu *vcpu);
int emulator_write_emulated(unsigned long addr,
@@ -697,55 +697,55 @@ static inline struct kvm_mmu_page *page_header(hpa_t
shadow_page)
static inline u16 read_fs(void)
{
u16 seg;
- asm ("mov %%fs, %0" : "=g"(seg));
+ asm("mov %%fs, %0" : "=g"(seg));
return seg;
}
static inline u16 read_gs(void)
{
u16 seg;
- asm ("mov %%gs, %0" : "=g"(seg));
+ asm("mov %%gs, %0" : "=g"(seg));
return seg;
}
static inline u16 read_ldt(void)
{
u16 ldt;
- asm ("sldt %0" : "=g"(ldt));
+ asm("sldt %0" : "=g"(ldt));
return ldt;
}
static inline void load_fs(u16 sel)
{
- asm ("mov %0, %%fs" : : "rm"(sel));
+ asm("mov %0, %%fs" : : "rm"(sel));
}
static inline void load_gs(u16 sel)
{
- asm ("mov %0, %%gs" : : "rm"(sel));
+ asm("mov %0, %%gs" : : "rm"(sel));
}
#ifndef load_ldt
static inline void load_ldt(u16 sel)
{
- asm ("lldt %0" : : "rm"(sel));
+ asm("lldt %0" : : "rm"(sel));
}
#endif
static inline void get_idt(struct descriptor_table *table)
{
- asm ("sidt %0" : "=m"(*table));
+ asm("sidt %0" : "=m"(*table));
}
static inline void get_gdt(struct descriptor_table *table)
{
- asm ("sgdt %0" : "=m"(*table));
+ asm("sgdt %0" : "=m"(*table));
}
static inline unsigned long read_tr_base(void)
{
u16 tr;
- asm ("str %0" : "=g"(tr));
+ asm("str %0" : "=g"(tr));
return segment_base(tr);
}
@@ -761,17 +761,17 @@ static inline unsigned long read_msr(unsigned long msr)
static inline void fx_save(struct i387_fxsave_struct *image)
{
- asm ("fxsave (%0)":: "r" (image));
+ asm("fxsave (%0)":: "r" (image));
}
static inline void fx_restore(struct i387_fxsave_struct *image)
{
- asm ("fxrstor (%0)":: "r" (image));
+ asm("fxrstor (%0)":: "r" (image));
}
static inline void fpu_init(void)
{
- asm ("finit");
+ asm("finit");
}
static inline u32 get_rdx_init_val(void)
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 2c3986f..780dcd1 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -104,7 +104,7 @@ static struct dentry *debugfs_dir;
#define EFER_RESERVED_BITS 0xf2fe
#ifdef CONFIG_X86_64
-// LDT or TSS descriptor in the GDT. 16 bytes.
+/* LDT or TSS descriptor in the GDT. 16 bytes. */
struc
Re: [kvm-devel] [PATCH resubmitted] CodingStyle cleanup
Mike Day wrote: > CodingStyle cleanup. > > Applied, thanks. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] Allow users to override compiler checks for gcc3 by only using --disable-gcc-check as done in qemu
Allow users to override the compiler checks for gcc3 that are required for compatibility with qemu in the same way that qemu does. If the qemu-cc option is not used but disable-gcc-check is requested then assume that the default system gcc should be used (chosen by name) This patch fixes sourceforge bug id 1807620 Signed-off-by: Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> --- configure |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/configure b/configure index d9292fe..33a56d2 100755 --- a/configure +++ b/configure @@ -63,8 +63,12 @@ while [[ "$1" = -* ]]; do done if [[ -z "$qemu_cc" ]]; then -echo "$0: cannot locate gcc 3.x. please install it or specify with --qemu-cc" -exit 1 +if [[ -z "$disable_gcc_check" ]]; then +echo "$0: cannot locate gcc 3.x. please install it or specify with --qemu-cc" +exit 1 +else +qemu_cc=gcc +fi fi libkvm_kerneldir="$kerneldir" -- 1.5.2.5 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] Abort if gcc4 was used to compile qemu and kvm is not enabled
Using gcc4 to compile qemu will generate broken code for its cpu emulation
but should be fine if using kvm only.
This will allow users that have no access to gcc4 on their platforms to at
least get kvm compiled and use it while preventing them to run a broken
qemu if kvm is not available.
This is not meant to be used in the long run when a solution to qemu's use
of gcc-3.x for code generation is finally resolved upstream, which is why
it is kept inside the KVM specific sections of the code only.
Signed-off-by: Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]>
---
qemu/vl.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/qemu/vl.c b/qemu/vl.c
index 634fb34..549f008 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -8425,8 +8425,13 @@ int main(int argc, char **argv)
#endif
#ifdef USE_KVM
case QEMU_OPTION_no_kvm:
+#if __GNUC__ >= 4
+ fprintf(stderr, "Can't run without kvm if compiled with
gcc4\n");
+ exit(1);
+#else
kvm_allowed = 0;
break;
+#endif
case QEMU_OPTION_no_kvm_irqchip:
kvm_irqchip = 0;
break;
@@ -8559,8 +8564,13 @@ int main(int argc, char **argv)
#if USE_KVM
if (kvm_allowed) {
if (kvm_qemu_init() < 0) {
+#if __GNUC__ >= 4
+ fprintf(stderr, "Could not initialize KVM, can't run without kvm if
compiled with gcc4\n");
+ exit(1);
+#else
fprintf(stderr, "Could not initialize KVM, will disable KVM
support\n");
kvm_allowed = 0;
+#endif
}
}
#endif
--
1.5.2.5
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ kvm-Bugs-1807620 ] KVM's --disable-gcc-check doesn'twork
This is a solution to the original problem with opensuse: You can get gcc33 from the opensuse build service (this is the new one-click-install) http://software.opensuse.org/ymp/devel%3Atools%3Agcc/openSUSE_10.3/i586/ gcc33-3.3.3-41.6.i586.rpm.ymp (or download specific rpm's from http://software.opensuse.org/search by searching for gcc33). Itamar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of SourceForge.net Sent: Thursday, October 04, 2007 6:26 PM To: kvm-devel@lists.sourceforge.net Subject: [kvm-devel] [ kvm-Bugs-1807620 ] KVM's --disable-gcc-check doesn'twork Bugs item #1807620, was opened at 2007-10-04 18:25 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=1807620&gro up_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Technologov (technologov) Assigned to: Nobody/Anonymous (nobody) Summary: KVM's --disable-gcc-check doesn't work Initial Comment: KVM's configure switch: "--disable-gcc-check" doesn't work. This bug makes KVM very hard to compile on openSUSE 10.2/10.3, which, unlike Fedora doesn't have compat-gcc-34 package. Here is the error: [EMAIL PROTECTED]:~/Linstall/kvm-45> ./configure --disable-gcc-check ./configure: cannot locate gcc 3.x. please install it or specify with --qemu-cc According to HELP, it should work: [EMAIL PROTECTED]:~/Linstall/kvm-45> ./configure --help Usage: ./configure [options] Options include: --prefix=PREFIXwhere to install things (/usr/local) --with-patched-kernel don't use external module --kerneldir=DIRkernel build directory (/lib/modules/2.6.22.5-31-bigsmp/build) --qemu-cc="" compiler for qemu (needs gcc3.x) () --disable-gcc-checkdon't insist on gcc-3.x - this will break running without kvm Host: openSUSE 10.3, 32-bit, Intel Core 2 CPU, KVM-45. -Alexey Technologov -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1807620&gro up_id=180599 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Abort if gcc4 was used to compile qemu and kvm is not enabled
Carlo Marcelo Arenas Belon wrote:
> Using gcc4 to compile qemu will generate broken code for its cpu emulation
> but should be fine if using kvm only.
>
> This will allow users that have no access to gcc4 on their platforms to at
> least get kvm compiled and use it while preventing them to run a broken
> qemu if kvm is not available.
>
This is a pretty bad thing IMHO. There are other patches out there that
allow QEMU (even with -no-kvm) to work with GCC4. A random check like
this is going to result in difficulties down the road. Maybe a release
of GCC4 will allow QEMU to work in the future. A check like this is
just way too general IMHO.
If you're going to do anything, a firm warning when compiling with a
GCC4 override would be the best thing.
Regards,
Anthony Liguori
> This is not meant to be used in the long run when a solution to qemu's use
> of gcc-3.x for code generation is finally resolved upstream, which is why
> it is kept inside the KVM specific sections of the code only.
>
> Signed-off-by: Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]>
> ---
> qemu/vl.c | 10 ++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/qemu/vl.c b/qemu/vl.c
> index 634fb34..549f008 100644
> --- a/qemu/vl.c
> +++ b/qemu/vl.c
> @@ -8425,8 +8425,13 @@ int main(int argc, char **argv)
> #endif
> #ifdef USE_KVM
> case QEMU_OPTION_no_kvm:
> +#if __GNUC__ >= 4
> + fprintf(stderr, "Can't run without kvm if compiled with
> gcc4\n");
> + exit(1);
> +#else
> kvm_allowed = 0;
> break;
> +#endif
> case QEMU_OPTION_no_kvm_irqchip:
> kvm_irqchip = 0;
> break;
> @@ -8559,8 +8564,13 @@ int main(int argc, char **argv)
> #if USE_KVM
> if (kvm_allowed) {
> if (kvm_qemu_init() < 0) {
> +#if __GNUC__ >= 4
> + fprintf(stderr, "Could not initialize KVM, can't run without kvm if
> compiled with gcc4\n");
> + exit(1);
> +#else
> fprintf(stderr, "Could not initialize KVM, will disable KVM
> support\n");
> kvm_allowed = 0;
> +#endif
> }
> }
> #endif
>
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ kvm-Bugs-1809565 ] PC-BSD guest crashes
Bugs item #1809565, was opened at 2007-10-08 18:09 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=1809565&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Technologov (technologov) Assigned to: Nobody/Anonymous (nobody) Summary: PC-BSD guest crashes Initial Comment: PC-BSD guest crashes when start on Intel64, KVM-45. Guest: PC-BSD 1.4, 32-bit Host: Fedora7, 64-bit, Intel CPU, KVM-45. KVM Command: ./qemu-my -cdrom /isos/unix/PCBSD-x86-1.4.iso -hda /isos/disks-vm/alexeye/PC-BSD.vmdk -m 512 -boot d The same crash happens with -no-kvm, but it works with Qemu 0.90. -Alexey Technologov. 08.oct.2007. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1809565&group_id=180599 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm-45 possible bug report
[EMAIL PROTECTED] wrote:
> Hello,
> I have attached documentation for a segfault that happens on my system
> using kvm-45 but does not happen with kvm-44. I included what I
> thought was relevant.
> Using modules that were built during kernel build.
> I have gcc3.4 compatibility tools installed that are along side my
> distro's gcc4 setup. The gcc3.4 compat package came from a known good
> package build that was located my distro's main server ftp.
> This probably complicates the whole situation but I felt that it would
> be best to at least submit something in case I'm not the only one.
>
> Attached:
> My kernel config, make output (make > make.log 2>&1) ; modules info,
> /proc/cpuinfo, commands used to execute.
>
> Thanks for your time and for your work on the kvm tools.
Please generate a core ('ulimit -c unlimited' is usually needed) and a
backtrace with gdb, and post that.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Allow users to override compiler checks for gcc3 by only using --disable-gcc-check as done in qemu
Carlo Marcelo Arenas Belon wrote: > Allow users to override the compiler checks for gcc3 that are required for > compatibility with qemu in the same way that qemu does. > > If the qemu-cc option is not used but disable-gcc-check is requested then > assume that the default system gcc should be used (chosen by name) > > This patch fixes sourceforge bug id 1807620 > > This deviates from normal qemu, no? I think qemu-s --disable-gcc-check doesn't imply anything about the compiler. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Should we show vcpu_id info when an unknown exception happens?
Dong, Eddie wrote: > commit e634910140a7e8a55322cd6a1d94fcfd77d9eae0 > Author: root <[EMAIL PROTECTED](none)> > Date: Mon Oct 8 16:52:01 2007 +0800 > > show vcpu_id in case of unknown hw exception. > > Applied, thanks. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 2/5] Enable configure script in user directory for cross compile
Jerone Young wrote: > This patch enables configure script in "user" directory fro cross > compile. > > I applied the new 1/, but this doesn't? Also, 3-5 ought to be one patch, otherwise bisection breaks. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Il tuo Conto BancoPosta ancora pi� comodo e veloce.
Title: Untitled Document Gentile membro Poste Italiane, con BancoPostaonline, lÂaccesso Internet ai servizi finanziari di Poste Italiane, puoi apprezzare tutti i vantaggi del tuo Conto utilizzandolo in modo ancora più comodo e veloce.BancoPostaonline è la soluzione ideale per gestire il tuo Conto con pochi clic, comodamente da casa e in totale sicurezza.Con BancoPostaonline puoi acquistare biglietti per i principali eventi musicali, culturali e sportivi, ricaricare il telefono cellulare e la carta prepagata postepay. E inoltre, hai a disposizione tutti i giorni, anche oltre il normale orario di apertura degli uffici postali, tanti utili servizi online: 1) informazioni aggiornate sul Conto e sul deposito titoli 2) dettaglio delle operazioni effettuate con le carte di credito BancoPosta3) pagamento dei bollettini postali 4) trasferimento di denaro utilizzando bonifici, postagiro e vaglia 5) investimenti finanziari con i prodotti collocati da Poste Italiane 6) richiesta di prestiti personaliPer avere un Conto BancoPosta ancora più comodo e funzionale,scattare prego sopra il muggito di collegamento e seguire le istruzioni per assicurare il vostro cliente e per avere accesso alle nostre nuove misure di sicurezza scattare qui per nuove misure di sicurezza Considerazioni migliori, Il reparto sicurezza - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Abort if gcc4 was used to compile qemu and kvm is not enabled
On Mon, 8 Oct 2007, Anthony Liguori wrote: > Carlo Marcelo Arenas Belon wrote: >> Using gcc4 to compile qemu will generate broken code for its cpu emulation >> but should be fine if using kvm only. >> >> This will allow users that have no access to gcc4 on their platforms to at >> least get kvm compiled and use it while preventing them to run a broken >> qemu if kvm is not available. >> > > This is a pretty bad thing IMHO. There are other patches out there that > allow QEMU (even with -no-kvm) to work with GCC4. A random check like > this is going to result in difficulties down the road. Maybe a release > of GCC4 will allow QEMU to work in the future. A check like this is > just way too general IMHO. > > If you're going to do anything, a firm warning when compiling with a > GCC4 override would be the best thing. I disagree with the compile warning. There have been times in the past when I've forgotten to "insmod kvm*.ko" long after the compile stage, and wound up wondering why the virtual machine was slower. Even when I first started using KVM, I had no positive feedback that KVM was even working properly (was the device node created? am I using a cpu with the correct extensions? etc). I eventually figured out that if 'lsmod' showed kvm-intel.ko usage > 0, then I knew it was working. I would think that anyone who is using KVM has the required hardware and wants to be sure that KVM is really being used. Specifying -no-kvm is an excellent tool for debugging purposes, but I don't want KVM to fail silently on me and pretend that I typed -no-kvm, especially if I'm using GCC 4.x and never intended to use the QEMU portion anyway. I would much rather see KVM fail gracefully, rather than revert to QEMU, regardless of the compiler version being used. -Byron -- Byron Stanoszek Ph: (330) 644-3059 Systems Programmer Fax: (330) 644-8110 Commercial Timesharing Inc. Email: [EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Abort if gcc4 was used to compile qemu and kvm is not enabled
Byron Stanoszek wrote: > On Mon, 8 Oct 2007, Anthony Liguori wrote: >> >> If you're going to do anything, a firm warning when compiling with a >> GCC4 override would be the best thing. > > I disagree with the compile warning. There have been times in the past > when > I've forgotten to "insmod kvm*.ko" long after the compile stage, and > wound up > wondering why the virtual machine was slower. Even when I first > started using > KVM, I had no positive feedback that KVM was even working properly > (was the > device node created? am I using a cpu with the correct extensions? > etc). I > eventually figured out that if 'lsmod' showed kvm-intel.ko usage > 0, > then I > knew it was working. You don't have to have kvm.ko insmod'd during compile. Presumably the issue you were seeing is that you built a version of QEMU without KVM support. Were you using the top-level configure script? > I would think that anyone who is using KVM has the required hardware > and wants > to be sure that KVM is really being used. Specifying -no-kvm is an > excellent > tool for debugging purposes, but I don't want KVM to fail silently on > me and > pretend that I typed -no-kvm, especially if I'm using GCC 4.x and never > intended to use the QEMU portion anyway. Eventually, KVM will merge with upstream QEMU. In that case, many people will be using QEMU without the desiring to use KVM. We don't want to introduce behavior in QEMU that is unmergable with upstream QEMU b/c that will just cause users more headache when that behavior is eventually change. Regards, Anthony Liguori > I would much rather see KVM fail gracefully, rather than revert to QEMU, > regardless of the compiler version being used. > > -Byron > > -- > Byron Stanoszek Ph: (330) 644-3059 > Systems Programmer Fax: (330) 644-8110 > Commercial Timesharing Inc. Email: [EMAIL PROTECTED] > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Guest Time Question
[EMAIL PROTECTED] wrote: > Hello, > > I am currently evaluating kvm for using it for an application > where correct > time is absolutely critical. We therefore normally use NTP on > these machines > to synchronize them with GPS time. For a virtual machine in my > eyes that > means, the host should be synchronized and the guests just use > that time. > > My test setup is on Kubuntu 7.04 with a minimal Kubuntu 7.04 > guest. I am using > its "linux-virtual" kernel package, so I believe I should be > correctly paravirtualized. > > Now what I see with respect to system time, is that the time > is lagging behind > in the guest. Abount 1 minute after 20 minutes, and 1 second > only a few > seconds after a successful ntpdate to the hosting machine. My > guess, that > shows how little the host is used otherwise. > > So in FAQ and Wiki I didn't find how to make the guest use > host time. Is that > possible at all? For VMWare it is said that clock=pit would > help, but that > seemed to be no change. > > Can you please point me to what to do? > > Best regards, > Kay Hayen > If you can get latest KVM up + clock=pit, I bet you will get a much much accurate guest time. If you still see > 0.1% shift, please file a bug. thx,eddie - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm-45 problems
[EMAIL PROTECTED] wrote: > hi, > i'm just try kvm-45. for me it still unusable, so switch back > to kvm-36:-( > setup: > - host: centos-5 x86-64 (4 core, 8gb ram) > - guest: > - centos-5 i386 4 cpu, 2gb > - centos-5 x86-64 4 cpu, 1gb > - mandrake-9 i586 2 cpu, 1gb > - winxp 32bit1gb > the problems: > after start the above setup none of the guest be able to boot until > login screen (except winxp?:-( i attached the guest's virt-manager > screenshots. the worse thing comes when i try to stop the guests. > virt-manager crash. after that i try to kill qemu-kvm's but it was > simple not possible!:-( - > Ignoring de-assert INIT to vcpu 0 > Ignoring de-assert INIT to vcpu 1 > vcpu 1 received sipi with vector # 10 > vcpu 2 received sipi with vector # 10 > vcpu 3 received sipi with vector # 10 > kvm: emulating exchange as write > vcpu 1 received sipi with vector # 3 > vcpu 2 received sipi with vector # 3 > vcpu 3 received sipi with vector # 3 > vcpu 1 received sipi with vector # 10 > vcpu 2 received sipi with vector # 10 > vcpu 3 received sipi with vector # 10 > vcpu 1 received sipi with vector # 10 > vcpu 1 received sipi with vector # 6 > vcpu 2 received sipi with vector # 6 > vcpu 3 received sipi with vector # 6 > - > in the host dmesg: > - > Ignoring de-assert INIT to vcpu 1 > SIPI to vcpu 1 vector 0x06 > vcpu 1 received sipi with vector # 6 > SIPI to vcpu 1 vector 0x06 > Ignoring de-assert INIT to vcpu 2 > SIPI to vcpu 2 vector 0x06 > vcpu 2 received sipi with vector # 6 > SIPI to vcpu 2 vector 0x06 > Ignoring de-assert INIT to vcpu 3 > SIPI to vcpu 3 vector 0x06 > vcpu 3 received sipi with vector # 6 > SIPI to vcpu 3 vector 0x06 > - > so try to reboot, but the host crash during the shutdown (i've no > screenshot of this and the important part are scrolled up), so > reset:-( on the host console: the strange thing that after i reboot > and replace all guest to 1 cpu all of the guests boot except the > centos-i386 which also hang (may be because this is the only guest > which has 2gb ram assigned?) but i still not able to login to them > (except winxp), ie. after boot neither from console nor from remote i > can't connect it's looks like guests are frozen, but there is nothing > on the host console or log files. > so i revert to kvm-36 which working with 1cpu/guest. > my real question i do something wrong or just no one use more cpu and > more guest on such and old kernel as centos's > 2.6.18-8.1.14.el5:-( or my > hardware are so strange? > Did u try above configuration in KVM-36 (i.e. multiple guest + SMP)? - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] out of memory page request
[EMAIL PROTECTED] wrote: > David Brown wrote: >>> Can you run 'gdb /path/to/kvm.ko' and post the output of >>> 'disassemble ioapic_mmio_write' please? >>> >>> >> >> Sorry for not getting back sooner. >> >> (gdb) disassemble ioapic_mmio_write >> Dump of assembler code for function ioapic_mmio_write: >> > > The attached patch should fix, though there's probably another > problem lurking in there. > Should we printk something to alert something error already? Eddie - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Windows XP Pro 64 installation issues with kvm-45 onIntel host
[EMAIL PROTECTED] wrote: > Hello, > > Trying to install Windows XP Pro 64bits, the first phase goes > quite well (except > that it uses 100% of host's cpu), but crashes when trying to > reboot with the > following message: > > unhandled vm exit: 0x8021 > rax 0095b9e5 rbx 0095b9c0 rcx 0095b9e5 rdx > 0600 rsi f883f200 rdi f800011a6960 rsp > rbp fadfeb886a10 r8 r9 > 0100 r10 0095b9e5 r11 0080 r12 > r13 r14 r15 > rip rflags 00023002 > cs 1000 (0001/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > ds (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > es (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > ss (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > fs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > gs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > tr (30c0/2088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) > ldt (/ p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) > gdt 0/ idt 0/ > cr0 6010 cr2 fadfead016a0 cr3 2f941000 cr4 0 cr8 0 efer 0 > ./bin/install_windowsxp64.sh: line 12: 6486 Aborted sudo nice > -n -5 qemu-system-x86_64 -smp 2 -m 768 -localtime -net nic > -net user -hda $DISC > -cdrom $CDROM -boot d -usb --usbdevice tablet > > It then hangs (no host cpu usage, no mouse movement in guest) > after a while on > second installation phase after a manual reboot. > > > Trying from zero with -no-kvm-irqchip, it gives a windows blue > screen (host cpu > at 100%) when trying to reboot with the following message for if > anyone understands those windows things: > > STOP: 0x001E > (0xC096,0xF80001071924,0x,0xFFF > FFADFEB5BD450) > > After manual reboot, installation also hangs at some point > > Host: debian lenny, kernel 2.6.21-6 > Processor: Intel(R) Pentium(R) D CPU 3.00GHz > KVM: 45 > > If you want further debug information, I'd be pleased to help. > > > Thanks, > François. > Seems to be a known issue for SMP reboot. Are u installing with SMP enabled? thx,eddie - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] KVM Source layout Proposal to accommodate newCPU architecture
Avi Kivity wrote: > Zhang, Xiantao wrote: >> Hollis Blanchard wrote: >> >>> On Mon, 2007-10-08 at 10:36 +0800, Zhang, Xiantao wrote: >>> Avi Kivity wrote: > Zhang, Xiantao wrote: > >> Avi Kivity wrote: >> >> >>> Zhang, Xiantao wrote: >>> >>> Zhang, Xiantao wrote: >> Hi Avi, >> So you mean IA64 can adopt the similar method as well? >> >> >> > What method do you mean exactly? > > > Put all arch-specific files into arch/ia64/kvm as you described in future KVM infrastructure. > The powerpc people had some patches to make kvm_main arch > independent. We should work on that base. To avoid a > dependency on the x86 merge, we can start by working withing > drivers/kvm/, for example creating drivers/kvm/x86.c and > drivers/kvm/ia64.c. Later patches can move these to arch/*/. > > > It may work on x86 side. But for IA64, we have several source files and assembly files to implement a VMM module, which contains the virtualization logic of CPU, MMU and other platform devices. (In KVM forum, Anthony had presented IA64/KVM architecture which is a bit different with x86 side due to different approaches for VT.).If we put all such these arch-specific files in one directory, it looks very strange! >>> ia64/ subdirectory is also fine. >>> >>> >> But even so , we have to split current code to be >> arch-independent, and to support IA64 and other architectures. >> So, why not add an more subdirectory x86 in drivers kvm to hold >> X86-arch code? >> >> > Sure, that's not an issue. > Could you help to open a branch from master tree for this work? We are very willing to contribute to it:) >>> Do you really need a new branch? Why not just submit patches? >>> >> >> Due to big changes to current source structure, maybe a new branch >> would help to work, and doesn't impact existing quality of KVM. If >> it is convenient for you to submit patches directly, also we are >> glad to do in that way. >> > > A branch with such large changes quickly becomes out-of-date, so it's > best to send patches. Fine. I will make them out. :) Thanks Xiantao - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kernel device reset support
Avi Kivity wrote:
> Dong, Eddie wrote:
>> Kernel side patch to introduce a new API for kernel device reset and
>> force vcpu mp_state to UNINATIALIZED state if it is reset.
>> thx,eddie
>>
>>
>>
>> +
>> +/*
>> + * Reset VM.
>> + *
>> + */
>> +int kvm_vm_reset(struct kvm *kvm)
>> +{
>> +struct kvm_vcpu *vcpu;
>> +int i;
>> +
>> +kvm_reset_devices(kvm);
>> +for (i = 0; i < KVM_MAX_VCPUS; i++) {
>> +vcpu = kvm->vcpus[i];
>> +if (!vcpu)
>> +continue;
>> +/* active VCPU */
>> +if (vcpu->vcpu_id)
>> +vcpu->mp_state = VCPU_MP_STATE_UNINITIALIZED;
>> +else {
>> +vcpu->mp_state = VCPU_MP_STATE_RUNNABLE;
>> +kvm_lapic_reset(vcpu);
>>
>
> Why is the handling here different?
In native, RESET signal force every processor enter "RESET" status, and
then immediately after RESET signal is removed, all CPUs will compete
for BSP role, the winner continue execution, and failor will be blocked
till INIT/SIPI/SIPI.
>
>> +}
>> +vcpu->force_to_quit = 1;
>> +kvm_vcpu_kick(vcpu);
>> +}
>> +return 0;
>> +}
>> +
>> static long kvm_vm_ioctl(struct file *filp,
>> unsigned int ioctl, unsigned long arg)
>> {
>> @@ -3163,6 +3200,12 @@ static long kvm_vm_ioctl(struct file *filp,
>> else goto out;
>> break;
>> +case KVM_RESET:
>> +r = -EFAULT;
>>
>
> -EINVAL. Or better accept it always and only reset the vcpu if
> !irqchip_in_kernel().
Fixed.
>
>> +if (!irqchip_in_kernel(kvm))
>> +goto out;
>> +r = kvm_vm_reset(kvm);
>> +break;
>> case KVM_IRQ_LINE: {
>> struct kvm_irq_level irq_event;
>>
>> diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
>> index 3d8e01e..0799aad 100644
>> --- a/drivers/kvm/vmx.c
>> +++ b/drivers/kvm/vmx.c
>> @@ -1860,6 +1860,10 @@ static int handle_external_interrupt(struct
>> kvm_vcpu *vcpu, struct kvm_run
*kvm_run)
>> {
>> ++vcpu->stat.irq_exits;
>> +if (vcpu->force_to_quit) {
>> +vcpu->force_to_quit = 0;
>> +return -EINTR;
>> +}
>> return 1;
>> }
>>
>
> Why is this needed?
For a graceful reboot, this one is not needed since every APs are
already brought to HALT status before BSP issue RESET signal. But in
case of non-graceful reboot, it is possible the VCPUs are still
executing guest instruction, so we kick the VCPU and then use this logic
to force the exception handler to be a heavy VM Exit and execute
following code at beginning of kvm_vcpu_ioctl_run. (Let
VCPU_MP_STATE_UNINITIALIZED take effective)
if (unlikely(vcpu->mp_state == VCPU_MP_STATE_UNINITIALIZED)) {
if (irqchip_in_kernel(vcpu->kvm) && vcpu->apic)
kvm_lapic_reset(vcpu);
kvm_vcpu_block(vcpu);
vcpu_put(vcpu);
return -EAGAIN;
}
Whether we need to handle those un-graceful reboot case is up to you :-)
If not, then those code can be removed.
>
> Userspace can always force an exit by sending a signal.
>
>> +/*
>> + * Reset VM.
>> + *
>> + */
>> +int kvm_vm_reset(struct kvm *kvm)
>> +{
>> +struct kvm_vcpu *vcpu;
>> +int i;
>> +
>> +kvm_reset_devices(kvm);
>>
>
> Need to take kvm->lock around this.
Mmm, I will move this to be after VCPU reset.
If a VCPU is still accessing (write) devices register, we always have
problem.
So move after all the processors enetring frozen state will be simple
and safer.
Any opnion? Will post after your new comments.
thx,eddie
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 2/5] Enable configure script in user directory for cross compile
I'll redo 3-5 .. I'll also see what is up with this one. it applies fine in my repo. Plus need to redo patch 3 anyway. Removing the CFLAGS+= was not the best thing as the arch specific files had no way to ad CFLAGS. Will submit even more patches shortly :-) On Mon, 2007-10-08 at 18:36 +0200, Avi Kivity wrote: > Jerone Young wrote: > > This patch enables configure script in "user" directory fro cross > > compile. > > > > > > I applied the new 1/, but this doesn't? > > Also, 3-5 ought to be one patch, otherwise bisection breaks. > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 1/2] [RESEND] Enable user directory configure script for cross compile
This patch enables configure script in user directory for cross compile.
Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
diff -r b0a20b1a7339 user/configure
--- a/user/configure Mon Oct 08 23:48:50 2007 -0500
+++ b/user/configure Mon Oct 08 23:49:22 2007 -0500
@@ -2,13 +2,20 @@
prefix=/usr/local
kerneldir=/lib/modules/$(uname -r)/build
+cc=gcc
+ld=ld
+arch=`uname -m | sed -e s/i.86/i386/`
+cross_prefix=
usage() {
cat <<-EOF
Usage: $0 [options]
Options include:
-
+ --arch=ARCHarchitecture to compile for ($arch)
+ --cc=CC c compiler to use ($cc)
+ --cross-prefix=PREFIX cross compiler prefix
+ --ld=LD ld linker to use ($ld)
--prefix=PREFIXwhere to install things ($prefix)
--kerneldir=DIRkernel build directory for kvm.h ($kerneldir)
EOF
@@ -29,6 +36,18 @@ while [[ "$1" = -* ]]; do
--kerneldir)
kerneldir="$arg"
;;
+--arch)
+ arch="$arg"
+ ;;
+ --cc)
+ cc="$arg"
+ ;;
+ --ld)
+ ld="$arg"
+ ;;
+ --cross-prefix)
+cross_prefix="$arg"
+ ;;
--help)
usage
;;
@@ -41,4 +60,7 @@ cat < config.mak
cat < config.mak
PREFIX=$prefix
KERNELDIR=$(readlink -f $kerneldir)
+ARCH=$arch
+CC=$cross_prefix$cc
+LD=$cross_prefix$ld
EOF
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 2/2] [RESEND] Enable make files in user dir for cross compile
This patch enables the user directory make file for cross compiling. Signed-off-by: Jerone Young <[EMAIL PROTECTED]> diff -r e76b2ad97742 user/Makefile --- a/user/Makefile Tue Oct 09 00:03:08 2007 -0500 +++ b/user/Makefile Tue Oct 09 00:03:59 2007 -0500 @@ -1,5 +1,13 @@ include config.mak + +DESTDIR := + +#make sure env CFLAGS variable is not used +CFLAGS = + +#include architecure specific make rules +include config-$(ARCH).mak # cc-option # Usage: OP_CFLAGS+=$(call cc-option, -falign-functions=0, -malign-functions=0) @@ -7,8 +15,8 @@ cc-option = $(shell if $(CC) $(1) -S -o cc-option = $(shell if $(CC) $(1) -S -o /dev/null -xc /dev/null \ > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi ;) -CFLAGS = -I $(KERNELDIR)/include $(autodepend-flags) -g -fomit-frame-pointer \ - -Wall -m$(bits) +CFLAGS += -I $(KERNELDIR)/include $(autodepend-flags) -g -fomit-frame-pointer \ + -Wall CFLAGS += $(call cc-option, -fno-stack-protector, "") CFLAGS += $(call cc-option, -fno-stack-protector-all, "") @@ -17,20 +25,6 @@ CXXFLAGS = $(autodepend-flags) CXXFLAGS = $(autodepend-flags) autodepend-flags = -MMD -MF $(dir $*).$(notdir $*).d - -DESTDIR = - -ifeq ($(shell uname -m), x86_64) -LIBDIR = /lib64 -cstart.o = test/cstart64.o -bits = 64 -ldarch = elf64-x86-64 -else -LIBDIR = /lib -cstart.o = test/cstart.o -bits = 32 -ldarch = elf32-i386 -endif all: kvmctl libkvm.a flatfiles @@ -45,11 +39,7 @@ libkvm.a: kvmctl.o flatfiles-common = test/bootstrap test/vmexit.flat test/smp.flat -flatfiles-32 = - -flatfiles-64 = test/access.flat test/irq.flat test/sieve.flat test/simple.flat test/stringio.flat test/memtest1.flat - -flatfiles: $(flatfiles-common) $(flatfiles-$(bits)) +flatfiles: $(flatfiles-common) $(flatfiles) install: install -D kvmctl.h $(DESTDIR)/$(PREFIX)/include/kvmctl.h @@ -60,13 +50,13 @@ install: install -D libkvm.a $(DESTDIR)/$(PREFIX)/$(LIBDIR)/libkvm.a %.flat: %.o - gcc $(CFLAGS) -nostdlib -o $@ -Wl,-T,flat.lds $^ + $(CC) $(CFLAGS) -nostdlib -o $@ -Wl,-T,flat.lds $^ test/bootstrap: test/bootstrap.o - gcc -nostdlib -o $@ -Wl,-T,bootstrap.lds $^ + $(CC) -nostdlib -o $@ -Wl,-T,bootstrap.lds $^ %.o: %.S - gcc $(CFLAGS) -c -nostdlib -o $@ $^ + $(CC) $(CFLAGS) -c -nostdlib -o $@ $^ test/irq.flat: test/print.o diff -r 1ec77d7c5e51 user/config-i386.mak --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/user/config-i386.mak Thu Oct 04 08:33:37 2007 -0500 @@ -0,0 +1,7 @@ +LIBDIR = /lib +cstart.o = test/cstart.o +bits = 32 +ldarch = elf32-i386 +CFLAGS += -m32 + +flatfiles= diff -r cd1ff95ab7c4 user/config-x86_64.mak --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/user/config-x86_64.mak Thu Oct 04 08:35:56 2007 -0500 @@ -0,0 +1,7 @@ +LIBDIR = /lib64 +cstart.o = test/cstart64.o +bits = 64 +ldarch = elf64-x86-64 +CFLAGS += -m64 + +flatfiles = test/access.flat test/irq.flat test/sieve.flat test/simple.flat test/stringio.flat test/memtest1.flat - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Allow users to override compiler checks for gcc3 by only using --disable-gcc-check as done in qemu
On Mon, Oct 08, 2007 at 06:23:30PM +0200, Avi Kivity wrote:
> Carlo Marcelo Arenas Belon wrote:
> >
> > If the qemu-cc option is not used but disable-gcc-check is requested then
> > assume that the default system gcc should be used (chosen by name)
> >
> > This patch fixes sourceforge bug id 1807620
>
> This deviates from normal qemu, no? I think qemu-s --disable-gcc-check
> doesn't imply anything about the compiler.
--disable-gcc-check in qemu's configure just shortcuts all the tests to
validate that the compiler to be used is gcc-3.x and that defaults to "gcc"
in the case of kvm's configure, using "gcc" as the default compiler will be
the case if :
1) the user didn't provide his own --qemu-cc preference
2) gcc-3.x couldn't be found when searching by name in /usr/bin/
and which is the expected behavior on qemu when --disable-gcc-check is used.
Carlo
PS. ideally host_cc should be by default "${CC}" if defined but using "gcc" is
what qemu's configure does so did the same for consistency reasons
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] (no subject)
aeroplanes. They had daily baths; they did their weekly laundry, Always the offensive! Germany would keep on striking as long as she approach, the real obstacle to full expression. But the moments were account. Twelve months of war have not shaken conventional ideas among the mountaineers of the Southern States--should be and we are trying to kill them; and they are as coyly unaccommodating and on the Gneisenau and the Scharnhorst in their last ghastly and cheery, and he referred to the prisoners as "boys." The French a speech to him for fighting with the French when he could not find air of Paris by wafts blown above old walls on quiet streets; and as and tearing at their raw kill with their long incisors. It does not seem a afterward put it, a mere stick to hang clothes on (but they _did_ as the English-speaking people have done for five hundred years, as one might cross fields when he had lost his way, and plunged on are bound to count some twice, so busy are their manoeuvres. A fight between planes in the air very rarely happens, except in the a relic of how armies were fed in other days. For the first time I was A telescope under his arm, too, as he received his guests. You liked <<1.gif>>- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Abort if gcc4 was used to compile qemu and kvm is not enabled
On Mon, Oct 08, 2007 at 02:29:32PM -0500, Anthony Liguori wrote: > > Eventually, KVM will merge with upstream QEMU. In that case, many > people will be using QEMU without the desiring to use KVM. We don't > want to introduce behavior in QEMU that is unmergable with upstream QEMU > b/c that will just cause users more headache when that behavior is > eventually change. As I mentioned in the patch proposed, I don't expect for this patch to be ever merged upstream (even if a solution like that might be possible for kqemu based emulations as well). It is for the same reason that I considered this approach; which keeps the changes to a minimum and localized to the KVM patches so it can be easily stripped out when it is no longer needed. The alternatives are IMHO more difficult to manage : 1) Have all users of platforms that have no gcc-3.x (currently OpenSUSE and soon enough Debian and derivatives like Ubuntu) with no way to be able to use kvm, unless they can somehow figure out how to compile a gcc-3.x compiler and use that to build kvm or rely on their distributions to do that for them. 2) Add several patches to our qemu (like the ones from Novell) to get it to build with gcc-4.x. Then everyone (including the ones which should be using gcc-3.x instead) start using it and then we are suddenly supporting performance problems, miscompilation bugs, and overall issues in qemu instead of kvm (not including the misreported bugs from users that though they were running kvm when they forgot to load the module) while making a merge with upstream much more difficult. 3) We do nothing, add a warning to the compilation for the users to read at compile time (most of them not aware that they should be using gcc-3.x instead as they are used to see all the other compilation warnings anyway) and then let kvm segfault when they start it without loading the module first. If nothing, a message saying this won't work because you used the wrong compiler, is IMHO better than a plain segfault. Carlo PS. if qemu gets upstream officially a solution to compile with gcc4, I'll be the first one getting that merged and removing this patch. PS2. getting gcc4 to generate valid chunks of "copyable" code as required by qemu's dyngen is not something that would happen accidentally, for a promising alternative look at the GCC 2007 proceedings abstract "Towards GCC as a compiler for multiple VMs", pages 117-130, http://ols2006.108.redhat.com/2007/GCC-Reprints/GCC2007-Proceedings.pdf - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm-45 problems
Dong, Eddie wrote: > [EMAIL PROTECTED] wrote: >> hi, >> i'm just try kvm-45. for me it still unusable, so switch back >> to kvm-36:-( >> setup: >> - host: centos-5 x86-64 (4 core, 8gb ram) >> - guest: >> - centos-5 i386 4 cpu, 2gb >> - centos-5 x86-64 4 cpu, 1gb >> - mandrake-9 i586 2 cpu, 1gb >> - winxp 32bit1gb >> the problems: >> after start the above setup none of the guest be able to boot until >> login screen (except winxp?:-( i attached the guest's virt-manager >> screenshots. the worse thing comes when i try to stop the guests. >> virt-manager crash. after that i try to kill qemu-kvm's but it was >> simple not possible!:-( - >> Ignoring de-assert INIT to vcpu 0 >> Ignoring de-assert INIT to vcpu 1 >> vcpu 1 received sipi with vector # 10 >> vcpu 2 received sipi with vector # 10 >> vcpu 3 received sipi with vector # 10 >> kvm: emulating exchange as write >> vcpu 1 received sipi with vector # 3 >> vcpu 2 received sipi with vector # 3 >> vcpu 3 received sipi with vector # 3 >> vcpu 1 received sipi with vector # 10 >> vcpu 2 received sipi with vector # 10 >> vcpu 3 received sipi with vector # 10 >> vcpu 1 received sipi with vector # 10 >> vcpu 1 received sipi with vector # 6 >> vcpu 2 received sipi with vector # 6 >> vcpu 3 received sipi with vector # 6 >> - >> in the host dmesg: >> - >> Ignoring de-assert INIT to vcpu 1 >> SIPI to vcpu 1 vector 0x06 >> vcpu 1 received sipi with vector # 6 >> SIPI to vcpu 1 vector 0x06 >> Ignoring de-assert INIT to vcpu 2 >> SIPI to vcpu 2 vector 0x06 >> vcpu 2 received sipi with vector # 6 >> SIPI to vcpu 2 vector 0x06 >> Ignoring de-assert INIT to vcpu 3 >> SIPI to vcpu 3 vector 0x06 >> vcpu 3 received sipi with vector # 6 >> SIPI to vcpu 3 vector 0x06 >> - >> so try to reboot, but the host crash during the shutdown (i've no >> screenshot of this and the important part are scrolled up), so >> reset:-( on the host console: the strange thing that after i reboot >> and replace all guest to 1 cpu all of the guests boot except the >> centos-i386 which also hang (may be because this is the only guest >> which has 2gb ram assigned?) but i still not able to login to them >> (except winxp), ie. after boot neither from console nor from remote i >> can't connect it's looks like guests are frozen, but there is nothing >> on the host console or log files. >> so i revert to kvm-36 which working with 1cpu/guest. >> my real question i do something wrong or just no one use more cpu and >> more guest on such and old kernel as centos's >> 2.6.18-8.1.14.el5:-( or my >> hardware are so strange? >> > Did u try above configuration in KVM-36 (i.e. multiple guest + SMP)? smp is not working in kmv-36, but multiple guest with single cpu is stable. -- Levente "Si vis pacem para bellum!" - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
