Re: [PATCH] KVM: PPC: Fix emulation of H_SET_DABR/X on POWER8
On 20/11/2015 09:11, Thomas Huth wrote: > In the old DABR register, the BT (Breakpoint Translation) bit > is bit number 61. In the new DAWRX register, the WT (Watchpoint > Translation) bit is bit number 59. So to move the DABR-BT bit > into the position of the DAWRX-WT bit, it has to be shifted by > two, not only by one. This fixes hardware watchpoints in gdb of > older guests that only use the H_SET_DABR/X interface instead > of the new H_SET_MODE interface. > > Signed-off-by: Thomas Huth > --- > arch/powerpc/kvm/book3s_hv_rmhandlers.S | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S > b/arch/powerpc/kvm/book3s_hv_rmhandlers.S > index b98889e..3983b87 100644 > --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S > +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S > @@ -2143,7 +2143,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S) > > /* Emulate H_SET_DABR/X on P8 for the sake of compat mode guests */ > 2: rlwimi r5, r4, 5, DAWRX_DR | DAWRX_DW > - rlwimi r5, r4, 1, DAWRX_WT > + rlwimi r5, r4, 2, DAWRX_WT > clrrdi r4, r4, 3 > std r4, VCPU_DAWR(r3) > std r5, VCPU_DAWRX(r3) > Nice catch. Reviewed-by: Laurent Vivier -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Two fixes for dynamic micro-threading
On 23/07/2015 14:02, Alexander Graf wrote: > > > On 20.07.15 08:49, David Gibson wrote: >> On Thu, Jul 16, 2015 at 05:11:12PM +1000, Paul Mackerras wrote: >>> This series contains two fixes for the new dynamic micro-threading >>> code that was added recently for HV-mode KVM on Power servers. >>> The patches are against Alex Graf's kvm-ppc-queue branch. Please >>> apply. >> >> agraf, >> >> Any word on these? These appear to fix a really nasty host crash in >> current upstream. I'd really like to see them merged ASAP. > > Thanks, applied to kvm-ppc-queue. > > The host crash should only occur with dynamic micro-threading enabled, > which is not in Linus' tree, correct? Yes, it only occurs with dynamic micro-threading enabled. Yes, this is not in Linus' tree. Laurent -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Two fixes for dynamic micro-threading
On 16/07/2015 09:11, Paul Mackerras wrote: > This series contains two fixes for the new dynamic micro-threading > code that was added recently for HV-mode KVM on Power servers. > The patches are against Alex Graf's kvm-ppc-queue branch. Please > apply. > > Paul. > > arch/powerpc/kvm/book3s_hv.c | 12 +--- > 1 file changed, 9 insertions(+), 3 deletions(-) Tested-by: Laurent Vivier [this series has corrected a host kernel crash when CPU are overcommitted] -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: Add Kconfig option to signal cross-endian guests
On 09/07/2015 09:49, Thomas Huth wrote: > The option for supporting cross-endianness legacy guests in > the vhost and tun code should only be available on systems > that support cross-endian guests. I'm sure I misunderstand something, but what happens if we use QEMU with TCG instead of KVM, i.e. a big endian powerpc kernel guest on x86_64 little endian host ? Do you forbid the use of vhost in this case ? > Signed-off-by: Thomas Huth > --- > arch/arm/kvm/Kconfig | 1 + > arch/arm64/kvm/Kconfig | 1 + > arch/powerpc/kvm/Kconfig | 1 + > drivers/net/Kconfig | 1 + > drivers/vhost/Kconfig| 1 + > virt/kvm/Kconfig | 3 +++ > 6 files changed, 8 insertions(+) > > diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig > index bfb915d..9d8f363 100644 > --- a/arch/arm/kvm/Kconfig > +++ b/arch/arm/kvm/Kconfig > @@ -31,6 +31,7 @@ config KVM > select KVM_VFIO > select HAVE_KVM_EVENTFD > select HAVE_KVM_IRQFD > + select KVM_CROSS_ENDIAN_GUESTS > depends on ARM_VIRT_EXT && ARM_LPAE && ARM_ARCH_TIMER > ---help--- > Support hosting virtualized guest machines. > diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig > index bfffe8f..9af39fe 100644 > --- a/arch/arm64/kvm/Kconfig > +++ b/arch/arm64/kvm/Kconfig > @@ -31,6 +31,7 @@ config KVM > select KVM_VFIO > select HAVE_KVM_EVENTFD > select HAVE_KVM_IRQFD > + select KVM_CROSS_ENDIAN_GUESTS > ---help--- > Support hosting virtualized guest machines. > > diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig > index 3caec2c..e028710 100644 > --- a/arch/powerpc/kvm/Kconfig > +++ b/arch/powerpc/kvm/Kconfig > @@ -79,6 +79,7 @@ config KVM_BOOK3S_64_HV > select KVM_BOOK3S_HV_POSSIBLE > select MMU_NOTIFIER > select CMA > + select KVM_CROSS_ENDIAN_GUESTS > ---help--- > Support running unmodified book3s_64 guest kernels in > virtual machines on POWER7 and PPC970 processors that have > diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig > index c18f9e6..0c4ce47 100644 > --- a/drivers/net/Kconfig > +++ b/drivers/net/Kconfig > @@ -261,6 +261,7 @@ config TUN > config TUN_VNET_CROSS_LE > bool "Support for cross-endian vnet headers on little-endian kernels" > default n > + depends on KVM_CROSS_ENDIAN_GUESTS > ---help--- > This option allows TUN/TAP and MACVTAP device drivers in a > little-endian kernel to parse vnet headers that come from a > diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig > index 533eaf0..4d8ae6b 100644 > --- a/drivers/vhost/Kconfig > +++ b/drivers/vhost/Kconfig > @@ -35,6 +35,7 @@ config VHOST > > config VHOST_CROSS_ENDIAN_LEGACY > bool "Cross-endian support for vhost" > + depends on KVM_CROSS_ENDIAN_GUESTS > default n > ---help--- > This option allows vhost to support guests with a different byte > diff --git a/virt/kvm/Kconfig b/virt/kvm/Kconfig > index e2c876d..cc7b28a 100644 > --- a/virt/kvm/Kconfig > +++ b/virt/kvm/Kconfig > @@ -47,3 +47,6 @@ config KVM_GENERIC_DIRTYLOG_READ_PROTECT > config KVM_COMPAT > def_bool y > depends on COMPAT && !S390 > + > +config KVM_CROSS_ENDIAN_GUESTS > + bool > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] KVM: PPC: Book3S HV: Dynamic micro-threading/split-core
On 22/06/2015 02:09, Paul Mackerras wrote: > On Wed, Jun 17, 2015 at 07:30:09PM +0200, Laurent Vivier wrote: >> >> Tested-by: Laurent Vivier >> >> Performance is better, but Paul could you explain why it is better if I >> disable dynamic micro-threading ? >> Did I miss something ? >> >> My test system is an IBM Power S822L. >> >> I run two guests with 8 vCPUs (-smp 8,sockets=8,cores=1,threads=1) both >> attached on the same core (with pinning option of virt-manager). Then, I >> measure the time needed to compile a kernel in parallel in both guests >> with "make -j 16". >> >> My kernel without micro-threading: >> >> real37m23.424s real37m24.959s >> user167m31.474suser165m44.142s >> sys 113m26.195ssys 113m45.072s >> >> With micro-threading patches (PATCH 1+2): >> >> target_smt_mode 0 [in fact It was 8 here, but it should behave like 0, as it >> is > max threads/sub-core] >> dynamic_mt_modes 6 >> >> real32m13.338s real 32m26.652s >> user139m21.181suser 140m20.994s >> sys 77m35.339s sys 78m16.599s >> >> It's better, but if I disable dynamic micro-threading (but PATCH 1+2): >> >> target_smt_mode 0 >> dynamic_mt_modes 0 >> >> real30m49.100s real 30m48.161s >> user144m22.989suser 142m53.886s >> sys 65m4.942s sys 66m8.159s >> >> it's even better. > > I think what's happening here is that with dynamic_mt_modes=0 the > system alternates between the two guests, whereas with > dynamic_mt_modes=6 it will spend some of the time running both guests > simultaneously in two-way split mode. Since you have two > compute-bound guests that each have threads=1 and 8 vcpus, it can fill > up the core either way. In that case it is more efficient to fill up > the core with vcpus from one guest and not have to split the core, > firstly because you avoid the split/unsplit latency and secondly > because the threads run a little faster in whole-core mode than in > split-core. Thank you for the explanation. So it has more sense to have vCPUs with threads ? It seems: I did same tests with 4 vCPUs x 2 threads x 2 guests concurrently on one 8 threaded bare metal core. target_smt_mode 0 dynamic_mt_modes 0 real35m33.142s real35m44.967s user167m16.971s user163m14.320s sys 84m19.618s sys 90m38.978s target_smt_mode 0 dynamic_mt_modes 6 real26m41.993s real25m54.270s user130m31.362s user127m55.145s sys 58m17.378s sys 55m10.202s In this case, it really improves performance. Laurent -- To unsubscribe from this list: send the line "unsubscribe kvm" in
Re: [PATCH 0/2] KVM: PPC: Book3S HV: Dynamic micro-threading/split-core
[I resend my message because MLs have refused the first one in HTML] On 28/05/2015 07:17, Paul Mackerras wrote: > This patch series provides a way to use more of the capacity of each > processor core when running guests configured with threads=1, 2 or 4 > on a POWER8 host with HV KVM, without having to change the static > micro-threading (the official name for split-core) mode for the whole > machine. The problem with setting the machine to static 2-way or > 4-way micro-threading mode is that (a) then you can't run guests with > threads=8 and (b) selecting the right mode can be tricky and requires > knowledge of what guests you will be running. > > Instead, with these two patches, we can now run more than one virtual > core (vcore) on a given physical core if possible, and if that means > we need to switch the core to 2-way or 4-way micro-threading mode, > then we do that on entry to the guests and switch back to whole-core > mode on exit (and we only switch the one core, not the whole machine). > The core mode switching is only done if the machine is in static > whole-core mode. > > All of this only comes into effect when a core is over-committed. > When the machine is lightly loaded everything operates the same with > these patches as without. Only when some core has a vcore that is > able to run while there is also another vcore that was wanting to run > on that core but got preempted does the logic kick in to try to run > both vcores at once. > > Paul. > --- > > arch/powerpc/include/asm/kvm_book3s_asm.h | 20 + > arch/powerpc/include/asm/kvm_host.h | 22 +- > arch/powerpc/kernel/asm-offsets.c | 9 + > arch/powerpc/kvm/book3s_hv.c | 648 > ++ > arch/powerpc/kvm/book3s_hv_builtin.c | 32 +- > arch/powerpc/kvm/book3s_hv_rm_xics.c | 4 +- > arch/powerpc/kvm/book3s_hv_rmhandlers.S | 111 - > 7 files changed, 740 insertions(+), 106 deletions(-) Tested-by: Laurent Vivier Performance is better, but Paul could you explain why it is better if I disable dynamic micro-threading ? Did I miss something ? My test system is an IBM Power S822L. I run two guests with 8 vCPUs (-smp 8,sockets=8,cores=1,threads=1) both attached on the same core (with pinning option of virt-manager). Then, I measure the time needed to compile a kernel in parallel in both guests with "make -j 16". My kernel without micro-threading: real37m23.424s real37m24.959s user167m31.474suser165m44.142s sys 113m26.195ssys 113m45.072s With micro-threading patches (PATCH 1+2): target_smt_mode 0 [in fact It was 8 here, but it should behave like 0, as it is > max threads/sub-core] dynamic_mt_modes 6 real32m13.338s real 32m26.652s user139m21.181suser 140m20.994s sys 77m35.339s sys 78m16.599s It's better, but if I disable dynamic micro-threading (but PATCH 1+2): target_smt_mode 0 dynamic_mt_modes 0 real30m49.100s real 30m48.161s user144m22.989suser 142m53.886s sys 65m4.942s sys 66m8.159s it's even better. without dynamic micro-threading patch (with PATCH1 but not PATCH2): target_smt_mode 0 real33m57.279s real 34m19.524s user158m43.064suser 156m19.863s sys 74m25.442s sys 76m42.994s Laurent -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2][v2][QEMU] Add BIOS splash image
This patch adds to qemu the functions needed to display a splash image
under BIOS control through the firmware control device.
It adds a "-splash" option allowing to specify the picture file name (a
.PNG) to display. You can enable/disable a fade in, fade out and the
bootmenu. The time to display the image can be also given (in seconds).
Signed-off-by: Laurent Vivier
---
qemu/Makefile.target |5 +-
qemu/configure | 19 +++
qemu/hw/fw_cfg.h |1 +
qemu/hw/pc.c | 11 ++-
qemu/hw/press_f12.h | 231 +++
qemu/hw/splash.c | 297 ++
qemu/hw/splash.h | 38 +++
qemu/qemu-doc.texi | 20
qemu/sysemu.h|1 +
qemu/vl.c| 19 +++
10 files changed, 639 insertions(+), 3 deletions(-)
create mode 100644 qemu/hw/press_f12.h
create mode 100644 qemu/hw/splash.c
create mode 100644 qemu/hw/splash.h
Changelog:
v2: make it generic, move splash functions to their own files,
add documentation
diff --git a/qemu/Makefile.target b/qemu/Makefile.target
index 315c3c9..5887bba 100644
--- a/qemu/Makefile.target
+++ b/qemu/Makefile.target
@@ -613,6 +613,9 @@ ifndef CONFIG_USER_ONLY
OBJS=vl.o osdep.o monitor.o pci.o loader.o isa_mmio.o machine.o
OBJS+=fw_cfg.o
+ifdef CONFIG_PNGLITE
+OBJS+=splash.o
+endif
ifdef CONFIG_KVM
OBJS+=kvm.o kvm-all.o
endif
@@ -865,7 +868,7 @@ firmware.o: firmware.c
endif
$(QEMU_PROG): $(OBJS) ../libqemu_common.a libqemu.a $(DEPLIBS)
- $(CC) $(LDFLAGS) -o $@ $^ $(LIBS) $(SDL_LIBS) $(COCOA_LIBS)
$(CURSES_LIBS) $(BRLAPI_LIBS) $(VDE_LIBS)
+ $(CC) $(LDFLAGS) -o $@ $^ $(LIBS) $(SDL_LIBS) $(COCOA_LIBS)
$(PNGLITE_LIBS) $(CURSES_LIBS) $(BRLAPI_LIBS) $(VDE_LIBS)
endif # !CONFIG_USER_ONLY
diff --git a/qemu/configure b/qemu/configure
index 5f5264f..60523fd 100755
--- a/qemu/configure
+++ b/qemu/configure
@@ -767,6 +767,19 @@ else
fi
##
+# libpnglite check
+
+cat > $TMPC << EOF
+#include
+int main(void) { (void)png_init(NULL, NULL); return 0; }
+EOF
+if $cc $ARCH_CFLAGS -o $TMPE ${OS_CFLAGS} $TMPC -lz -lpnglite 2> /dev/null ;
then
+pnglite=yes
+else
+pnglite=no
+fi
+
+##
# SDL probe
sdl_too_old=no
@@ -1145,6 +1158,7 @@ echo "SDL support $sdl"
if test "$sdl" != "no" ; then
echo "SDL static link $sdl_static"
fi
+echo "pnglite support $pnglite"
echo "curses support$curses"
echo "mingw32 support $mingw32"
echo "Audio drivers $audio_drv_list"
@@ -1437,6 +1451,11 @@ if test "$cocoa" = "yes" ; then
echo "#define CONFIG_COCOA 1" >> $config_h
echo "CONFIG_COCOA=yes" >> $config_mak
fi
+if test "$pnglite" = "yes" ; then
+ echo "#define CONFIG_PNGLITE 1" >> $config_h
+ echo "CONFIG_PNGLITE=yes" >> $config_mak
+ echo "PNGLITE_LIBS=-lpnglite" >> $config_mak
+fi
if test "$curses" = "yes" ; then
echo "#define CONFIG_CURSES 1" >> $config_h
echo "CONFIG_CURSES=yes" >> $config_mak
diff --git a/qemu/hw/fw_cfg.h b/qemu/hw/fw_cfg.h
index ef8f378..41fdde8 100644
--- a/qemu/hw/fw_cfg.h
+++ b/qemu/hw/fw_cfg.h
@@ -8,6 +8,7 @@
#define FW_CFG_NOGRAPHIC0x04
#define FW_CFG_NB_CPUS 0x05
#define FW_CFG_MACHINE_ID 0x06
+#define FW_CFG_SPLASH (FW_CFG_WRITE_CHANNEL | 0x07)
#define FW_CFG_MAX_ENTRY0x10
#define FW_CFG_WRITE_CHANNEL0x4000
diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
index 2924b2a..f6979fe 100644
--- a/qemu/hw/pc.c
+++ b/qemu/hw/pc.c
@@ -36,6 +36,8 @@
#include "virtio-blk.h"
#include "virtio-balloon.h"
#include "device-assignment.h"
+#include "splash.h"
+#include "press_f12.h"
#include "qemu-kvm.h"
@@ -423,7 +425,7 @@ static void bochs_bios_write(void *opaque, uint32_t addr,
uint32_t val)
}
}
-static void bochs_bios_init(void)
+static void *bochs_bios_init(void)
{
void *fw_cfg;
@@ -441,6 +443,8 @@ static void bochs_bios_init(void)
fw_cfg = fw_cfg_init(BIOS_CFG_IOPORT, BIOS_CFG_IOPORT + 1, 0, 0);
fw_cfg_add_i32(fw_cfg, FW_CFG_ID, 1);
fw_cfg_add_i64(fw_cfg, FW_CFG_RAM_SIZE, (uint64_t)ram_size);
+
+return fw_cfg;
}
/* Generate an initial boot sector which sets state and jump to
@@ -818,6 +822,7 @@ static void pc_init1(ram_addr_t ram_size, int vga_ram_size,
int index;
BlockDriverState *hd[MAX_IDE_BUS * MAX_IDE_DEVS];
BlockDriverState *fd[MAX_FD];
+void *fw_cfg;
if (ram_size >= 0xe000 ) {
above_4g_mem_size = ram_size - 0xe000;
@@ -977,7 +982,7 @@ static void pc_init1(ram_addr_t ram_size, int vga_ram_size,
cpu_register_physical_memory
[PATCH 1/2][v2][BIOS] Add splash image support
This patch adds Qemu firmware configuration device interface to display
a splash image at BIOS startup.
Idea stollen from VirtualBox.
Signed-off-by: Laurent Vivier
---
bios/Makefile |4 +-
bios/rombios.c | 142 ---
bios/splash.c | 144
bios/splash.h | 32
4 files changed, 271 insertions(+), 51 deletions(-)
create mode 100644 bios/splash.c
create mode 100644 bios/splash.h
Changelog:
v2: totally remove code from VirtualBox to not bring GPLv2 to bios.
diff --git a/bios/Makefile b/bios/Makefile
index a2759a9..605d31f 100644
--- a/bios/Makefile
+++ b/bios/Makefile
@@ -79,7 +79,7 @@ dist-clean: clean
bios-clean:
rm -f BIOS-bochs-*
-BIOS-bochs-legacy: rombios.c apmbios.S biossums rombios.h
+BIOS-bochs-legacy: rombios.c apmbios.S biossums rombios.h splash.c splash.h
$(GCC) $(BIOS_BUILD_DATE) -DLEGACY -E -P $< > _rombiosl_.c
$(BCC) -o rombiosl.s -C-c -D__i86__ -0 -S _rombiosl_.c
sed -e 's/^\.text//' -e 's/^\.data//' rombiosl.s > _rombiosl_.s
@@ -90,7 +90,7 @@ BIOS-bochs-legacy: rombios.c apmbios.S biossums rombios.h
rm -f _rombiosl_.s
-rombios16.bin: rombios.c apmbios.S biossums rombios.h
+rombios16.bin: rombios.c apmbios.S biossums rombios.h splash.c splash.h
$(GCC) $(BIOS_BUILD_DATE) -E -P $< > _rombios_.c
$(BCC) -o rombios.s -C-c -D__i86__ -0 -S _rombios_.c
sed -e 's/^\.text//' -e 's/^\.data//' rombios.s > _rombios_.s
diff --git a/bios/rombios.c b/bios/rombios.c
index 9a1cdd6..a02b50f 100644
--- a/bios/rombios.c
+++ b/bios/rombios.c
@@ -1433,6 +1433,22 @@ void uart_tx_byte(base_port, data)
#endif
void
+set_video(mode)
+ Bit8u mode;
+{
+ ASM_START
+ push bp
+ mov bp, sp
+
+ mov ah, #0x00
+ mov al, 4[bp]
+ int #0x10
+
+ pop bp
+ ASM_END
+}
+
+ void
wrch(c)
Bit8u c;
{
@@ -1533,6 +1549,8 @@ void put_str(action, segment, offset)
}
}
+#define TICKS_PER_SECONDS 18
+
void
delay_ticks(ticks)
Bit16u ticks;
@@ -1917,6 +1935,10 @@ shutdown_status_panic(status)
BX_PANIC("Unimplemented shutdown status: %02x\n",(Bit8u)status);
}
+#ifdef BX_QEMU
+#include "splash.c"
+#endif
+
//--
// print_bios_banner
// displays a the bios version
@@ -1924,6 +1946,10 @@ shutdown_status_panic(status)
void
print_bios_banner()
{
+#ifdef BX_QEMU
+ if (splash_enabled())
+return;
+#endif
printf(BX_APPNAME" BIOS - build: %s\n%s\nOptions: ",
BIOS_BUILD_DATE, bios_cvs_version_string);
printf(
@@ -2021,65 +2047,77 @@ interactive_bootkey()
Bit16u ss = get_SS();
Bit16u valid_choice = 0;
+#ifdef BX_QEMU
+ if (splash_enabled()) {
+Bit16u duration;
+
+splash_show();
+duration = splash_duration();
+if (!check_for_keystroke())
+ delay_ticks_and_check_for_keystroke(TICKS_PER_SECONDS, duration / 1000);
+splash_hide();
+if (!splash_display_boot_list())
+ return;
+ } else
+#endif // BX_QEMU
+ {
+while (check_for_keystroke())
+ get_keystroke();
+printf("Press F12 for boot menu.\n\n");
+delay_ticks_and_check_for_keystroke(11, 5); /* ~3 seconds */
+ }
+ if (!check_for_keystroke())
+return;
+ scan_code = get_keystroke();
+ if (scan_code != 0x58) /* F12 */
+return;
+
while (check_for_keystroke())
get_keystroke();
- printf("Press F12 for boot menu.\n\n");
+ printf("Select boot device:\n\n");
- delay_ticks_and_check_for_keystroke(11, 5); /* ~3 seconds */
- if (check_for_keystroke())
+ count = read_word(IPL_SEG, IPL_COUNT_OFFSET);
+ for (i = 0; i < count; i++)
{
-scan_code = get_keystroke();
-if (scan_code == 0x58) /* F12 */
+memcpyb(ss, &e, IPL_SEG, IPL_TABLE_OFFSET + i * sizeof (e), sizeof (e));
+printf("%d. ", i+1);
+switch(e.type)
{
- while (check_for_keystroke())
-get_keystroke();
-
- printf("Select boot device:\n\n");
-
- count = read_word(IPL_SEG, IPL_COUNT_OFFSET);
- for (i = 0; i < count; i++)
- {
-memcpyb(ss, &e, IPL_SEG, IPL_TABLE_OFFSET + i * sizeof (e), sizeof
(e));
-printf("%d. ", i+1);
-switch(e.type)
+ case IPL_TYPE_FLOPPY:
+ case IPL_TYPE_HARDDISK:
+ case IPL_TYPE_CDROM:
+printf("%s\n", drivetypes[e.type]);
+break;
+ case IPL_TYPE_BEV:
+printf("%s", drivetypes[4]);
+if (e.description != 0)
{
- case IPL_TYPE_FLOPPY:
- case IPL_TYPE_HARDDISK:
- case IPL_TYPE_CDROM:
-printf("%s\n", drivetypes[e.type]);
-break;
- case IPL_TYPE_BEV:
-printf("%s", drivetypes[4]);
-if (e.description
[PATCH 0/2][v2] Add BIOS splash image support
This series of patches adds a nice BIOS startup splash screen. It adds a "-splash" option allowing to specify the picture file name (a 640x480 (or less) and true color PNG) to display. You can enable/disable a fade in, fade out and the bootmenu. The time to display the image can be also given (in seconds). Idea stollen from VirtualBox. [PATCH 1/2] [BIOS] Add splash image support [PATCH 2/2] [QEMU] Add BIOS splash image -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bochs-developers] [PATCH 0/3] Add BIOS splash image support
Le mercredi 17 décembre 2008 à 22:58 +0100, Sebastian Herbszt a écrit : > Laurent Vivier wrote: > > This series of patches adds a nice BIOS startup splash screen. > > > > It adds a "-splash" option allowing to specify the picture file name (a > > 640x480 (or less) and true color PNG) to > > display. You can enable/disable fade in, > > fade out and bootmenu. The time to display the image can be also given (in > > seconds). > > > > Idea and some parts of code are stollen from VirtualBox (GPLv2/CDDL). > > rombios.c is LGPL. Can we mix it with GPLv2/CDDL code without any downsides? Good question. But the GPLv2 code is not in rombios.c (but in logo.h, logo.c) and moreover VirtualBox uses the same rombios.c with their GPLv2 logo.[ch]... perhaps we can ask Sun lawyers ;-) ? I'm the author of all the code added to rombios.c to manage splash screen and I agree to put this under LGPL. For the logo.[ch], I keep only approximately 20% of original VirtualBox code (data structure, to set vga mode, to clear screen and some name), if needed I can rewrite this to put logo.[ch] under LGPL. Regards, Laurent -- -- laurent.viv...@bull.net -- "Tout ce qui est impossible reste à accomplir"Jules Verne "Things are only impossible until they're not" Jean-Luc Picard -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support
Le mercredi 17 décembre 2008 à 01:10 +0100, Carl-Daniel Hailfinger a écrit : > On 16.12.2008 22:51, Laurent Vivier wrote: > > Le mardi 16 décembre 2008 à 22:46 +0200, Blue Swirl a écrit : > > > >> On 12/16/08, Anthony Liguori wrote: > >> > >>> Blue Swirl wrote: > >>> > > > > > >>>> The control channel may still be needed. > >>>> > >>>> Alternatively the BIOS could load the image and fade parameters from a > >>>> new ROM or from the configuration device and draw it to screen. This > >>>> would need some PNG support to BIOS, or that the image stored in raw > >>>> form. > >>>> > >>>> > >>>> > >>> Yeah, having QEMU render to the VGA directly is a bit ugly. It would be > >>> nicer if the BIOS actually rendered the image but I'm not sure I think we > >>> should reject the patch just because it doesn't. > >>> > >> Actually this way the image can be in full color even if the emulated > >> device was an EGA in text mode. > >> > > > > And you can provide the image name on the command line, and complexity > > is in Qemu, not in BIOS. > > > > If one of the goals of QEMU is to be somewhat similar to hardware, this > should be done in the BIOS. A lot of things in Qemu are already not similar to hardware: virtio, firmware configuration device, instruction timing... > What happens if the BIOS provides a splash screen? Will it override the > QEMU splash screen? Yes. The BIOS asks Qemu to display the image... or not. > > But in fact, my first idea was to read the image data from the > > configuration device (which is always possible with LOGO_CMD_OFFSET), > > but when I saw how it has been done in VirtualBox, I though it was a > > good idea. > > > > Modern x86 BIOSes read the splash screen from the BIOS ROM and the > settings from NVRAM (sometimes the BIOS ROM is used for that as well by > reflashing a sector of the ROM on every boot). A BIOS, by definition, is not modern... ;-) (Openfirmware is...) Laurent -- -- laurent.viv...@bull.net -- "Tout ce qui est impossible reste à accomplir"Jules Verne "Things are only impossible until they're not" Jean-Luc Picard -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support
Le mardi 16 décembre 2008 à 22:46 +0200, Blue Swirl a écrit : > On 12/16/08, Anthony Liguori wrote: > > Blue Swirl wrote: > > > The control channel may still be needed. > > > > > > Alternatively the BIOS could load the image and fade parameters from a > > > new ROM or from the configuration device and draw it to screen. This > > > would need some PNG support to BIOS, or that the image stored in raw > > > form. > > > > > > > > > > Yeah, having QEMU render to the VGA directly is a bit ugly. It would be > > nicer if the BIOS actually rendered the image but I'm not sure I think we > > should reject the patch just because it doesn't. > > Actually this way the image can be in full color even if the emulated > device was an EGA in text mode. And you can provide the image name on the command line, and complexity is in Qemu, not in BIOS. But in fact, my first idea was to read the image data from the configuration device (which is always possible with LOGO_CMD_OFFSET), but when I saw how it has been done in VirtualBox, I though it was a good idea. But I agree, it's ugly. Regards, Laurent -- -- laurent.viv...@bull.net -- "Tout ce qui est impossible reste à accomplir"Jules Verne "Things are only impossible until they're not" Jean-Luc Picard -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] [QEMU] Add BIOS splash image
This patch adds to qemu the function needed to display a splash image under
BIOS control through the firmware control device.
It adds a "-splash" option allowing to specify the picture file name (a .PNG)
to display. You can enable/disable a fade in, fade out and the bootmenu. The
time to display the image can be also given (in seconds).
Signed-off-by: Laurent Vivier
---
qemu/Makefile.target |2 +-
qemu/configure| 19 +++
qemu/hw/bootmenu_pixmap.h | 231 +
qemu/hw/fw_cfg.h |1 +
qemu/hw/pc.c | 276 -
qemu/sysemu.h |1 +
qemu/vl.c | 19 +++
7 files changed, 545 insertions(+), 4 deletions(-)
create mode 100644 qemu/hw/bootmenu_pixmap.h
diff --git a/qemu/Makefile.target b/qemu/Makefile.target
index d6a6479..65f0252 100644
--- a/qemu/Makefile.target
+++ b/qemu/Makefile.target
@@ -894,7 +894,7 @@ firmware.o: firmware.c
endif
$(QEMU_PROG): $(OBJS) ../libqemu_common.a libqemu.a $(DEPLIBS)
- $(CC) $(LDFLAGS) -o $@ $^ $(LIBS) $(SDL_LIBS) $(COCOA_LIBS)
$(CURSES_LIBS) $(BRLAPI_LIBS) $(VDE_LIBS)
+ $(CC) $(LDFLAGS) -o $@ $^ $(LIBS) $(SDL_LIBS) $(COCOA_LIBS)
$(PNGLITE_LIBS) $(CURSES_LIBS) $(BRLAPI_LIBS) $(VDE_LIBS)
endif # !CONFIG_USER_ONLY
diff --git a/qemu/configure b/qemu/configure
index 1f8b9b4..7f20a4b 100755
--- a/qemu/configure
+++ b/qemu/configure
@@ -833,6 +833,19 @@ else
fi
##
+# libpnglite check
+
+cat > $TMPC << EOF
+#include
+int main(void) { (void)png_init(NULL, NULL); return 0; }
+EOF
+if $cc $ARCH_CFLAGS -o $TMPE ${OS_CFLAGS} $TMPC -lz -lpnglite 2> /dev/null ;
then
+pnglite=yes
+else
+pnglite=no
+fi
+
+##
# SDL probe
sdl_too_old=no
@@ -1187,6 +1200,7 @@ echo "SDL support $sdl"
if test "$sdl" != "no" ; then
echo "SDL static link $sdl_static"
fi
+echo "pnglite support $pnglite"
echo "curses support$curses"
echo "mingw32 support $mingw32"
echo "Audio drivers $audio_drv_list"
@@ -1477,6 +1491,11 @@ if test "$cocoa" = "yes" ; then
echo "#define CONFIG_COCOA 1" >> $config_h
echo "CONFIG_COCOA=yes" >> $config_mak
fi
+if test "$pnglite" = "yes" ; then
+ echo "#define CONFIG_PNGLITE 1" >> $config_h
+ echo "CONFIG_PNGLITE=yes" >> $config_mak
+ echo "PNGLITE_LIBS=-lpnglite" >> $config_mak
+fi
if test "$curses" = "yes" ; then
echo "#define CONFIG_CURSES 1" >> $config_h
echo "CONFIG_CURSES=yes" >> $config_mak
diff --git a/qemu/hw/bootmenu_pixmap.h b/qemu/hw/bootmenu_pixmap.h
new file mode 100644
index 000..a33ddb4
--- /dev/null
+++ b/qemu/hw/bootmenu_pixmap.h
@@ -0,0 +1,231 @@
+/* GIMP header image file format (INDEXED): /home/vivierl/Desktop/Press F12
for boot menu.h */
+
+#define SPLASH_BOOTMENU_WIDTH 216
+#define SPLASH_BOOTMENU_HEIGHT 16
+
+static char bootmenu_pixmap[] = {
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,0,0,0,0,0,0,0,
+ 1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,
+ 0,0
[PATCH 1/3] Correct fw_cfg_add_callback()
This patch is needed to be able to register firmware configuration
device callback.
It is already included in qemu as commit r5978.
Signed-off-by: Laurent Vivier
---
qemu/hw/fw_cfg.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/qemu/hw/fw_cfg.c b/qemu/hw/fw_cfg.c
index 4e68670..c3b09c6 100644
--- a/qemu/hw/fw_cfg.c
+++ b/qemu/hw/fw_cfg.c
@@ -57,7 +57,6 @@ static void fw_cfg_write(FWCfgState *s, uint8_t value)
FWCfgEntry *e = &s->entries[arch][s->cur_entry & FW_CFG_ENTRY_MASK];
FW_CFG_DPRINTF("write %d\n", value);
-
if (s->cur_entry & FW_CFG_WRITE_CHANNEL && s->cur_offset < e->len) {
e->data[s->cur_offset++] = value;
if (s->cur_offset == e->len) {
@@ -240,10 +239,12 @@ int fw_cfg_add_callback(void *opaque, uint16_t key,
FWCfgCallback callback,
FWCfgState *s = opaque;
int arch = !!(key & FW_CFG_ARCH_LOCAL);
+if (!(key & FW_CFG_WRITE_CHANNEL))
+return 0;
+
key &= FW_CFG_ENTRY_MASK;
-if (key >= FW_CFG_MAX_ENTRY || !(key & FW_CFG_WRITE_CHANNEL)
-|| len > 65535)
+if (key >= FW_CFG_MAX_ENTRY || len > 65535)
return 0;
s->entries[arch][key].data = data;
--
1.5.6.5
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Add BIOS splash image support
This series of patches adds a nice BIOS startup splash screen. It adds a "-splash" option allowing to specify the picture file name (a 640x480 (or less) and true color PNG) to display. You can enable/disable fade in, fade out and bootmenu. The time to display the image can be also given (in seconds). Idea and some parts of code are stollen from VirtualBox (GPLv2/CDDL). [PATCH 1/3] Correct fw_cfg_add_callback() [PATCH 2/3] [BIOS] Add splash image support [PATCH 3/3] [QEMU] Add BIOS splash image -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] [BIOS] Add splash image support
This patch adds Qemu firmware configuration device interface to display
a splash image at BIOS startup.
Idea and some parts of code are stollen from VirtualBox.
Signed-off-by: Laurent Vivier
---
bios/Makefile |4 +-
bios/logo.c| 206
bios/logo.h| 56 +++
bios/rombios.c | 125 +-
4 files changed, 340 insertions(+), 51 deletions(-)
create mode 100644 bios/logo.c
create mode 100644 bios/logo.h
diff --git a/bios/Makefile b/bios/Makefile
index a2759a9..d30be7d 100644
--- a/bios/Makefile
+++ b/bios/Makefile
@@ -79,7 +79,7 @@ dist-clean: clean
bios-clean:
rm -f BIOS-bochs-*
-BIOS-bochs-legacy: rombios.c apmbios.S biossums rombios.h
+BIOS-bochs-legacy: rombios.c apmbios.S biossums rombios.h logo.c logo.h
$(GCC) $(BIOS_BUILD_DATE) -DLEGACY -E -P $< > _rombiosl_.c
$(BCC) -o rombiosl.s -C-c -D__i86__ -0 -S _rombiosl_.c
sed -e 's/^\.text//' -e 's/^\.data//' rombiosl.s > _rombiosl_.s
@@ -90,7 +90,7 @@ BIOS-bochs-legacy: rombios.c apmbios.S biossums rombios.h
rm -f _rombiosl_.s
-rombios16.bin: rombios.c apmbios.S biossums rombios.h
+rombios16.bin: rombios.c apmbios.S biossums rombios.h logo.c logo.h
$(GCC) $(BIOS_BUILD_DATE) -E -P $< > _rombios_.c
$(BCC) -o rombios.s -C-c -D__i86__ -0 -S _rombios_.c
sed -e 's/^\.text//' -e 's/^\.data//' rombios.s > _rombios_.s
diff --git a/bios/logo.c b/bios/logo.c
new file mode 100644
index 000..d41eb10
--- /dev/null
+++ b/bios/logo.c
@@ -0,0 +1,206 @@
+/**
+ * Stuff for drawing the BIOS logo.
+ */
+
+/*
+ * Copyright (C) 2004-2008 Sun Microsystems, Inc.
+ *
+ * This file is part of VirtualBox Open Source Edition (OSE), as
+ * available from http://www.virtualbox.org. This file is free software;
+ * you can redistribute it and/or modify it under the terms of the GNU
+ * General Public License (GPL) as published by the Free Software
+ * Foundation, in version 2 as it comes in the "COPYING" file of the
+ * VirtualBox OSE distribution. VirtualBox OSE is distributed in the
+ * hope that it will be useful, but WITHOUT ANY WARRANTY of any kind.
+ *
+ * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa
+ * Clara, CA 95054 USA or visit http://www.sun.com if you need
+ * additional information or have any questions.
+ *
+ * QEMU/KVM port by Laurent Vivier
+ *
+ */
+
+#include "logo.h"
+
+#define BIOS_CFG_IOPORT 0x510
+#define BIOS_CFG_SIGNATURE 0x
+#define BIOS_CFG_SPLASH 0x4007
+
+#define WAIT_MS 16
+
+/**
+ * Set video mode (VGA).
+ * @paramsNew video mode.
+ */
+void set_mode(mode)
+ Bit8u mode;
+ {
+ ASM_START
+push bp
+mov bp, sp
+
+ push ax
+
+ mov ah, #0
+ mov al, 4[bp] ; mode
+ int #0x10
+
+ pop ax
+
+pop bp
+ ASM_END
+ }
+
+Bit8u read_logo_byte(offset)
+ Bit8u offset;
+{
+outw(BIOS_CFG_IOPORT, BIOS_CFG_SPLASH);
+outb(BIOS_CFG_IOPORT + 1, LOGO_CMD_SET_OFFSET);
+outb(BIOS_CFG_IOPORT + 1, offset);
+return inb(BIOS_CFG_IOPORT + 1);
+}
+
+Bit16u read_logo_word(offset)
+ Bit8u offset;
+{
+Bit16u word;
+outw(BIOS_CFG_IOPORT, BIOS_CFG_SPLASH);
+outb(BIOS_CFG_IOPORT + 1, LOGO_CMD_SET_OFFSET);
+outb(BIOS_CFG_IOPORT + 1, offset);
+word = inb(BIOS_CFG_IOPORT + 1);
+word = (inb(BIOS_CFG_IOPORT + 1) << 8) | word;
+return word;
+}
+
+void clear_screen()
+{
+// Hide cursor, clear screen and move cursor to starting position
+ASM_START
+push bx
+push cx
+push dx
+
+mov ax, #0x100
+mov cx, #0x1000
+int #0x10
+
+mov ax, #0x700
+mov bh, #7
+xor cx, cx
+mov dx, #0x184f
+int #0x10
+
+mov ax, #0x200
+xor bx, bx
+xor dx, dx
+int #0x10
+
+pop dx
+pop cx
+pop bx
+ASM_END
+}
+
+Bit8u
+logo_enabled()
+{
+LOGOHDR*logo_hdr = 0;
+Bit8u is_fade_in, is_fade_out, uBootMenu;
+Bit16u logo_time;
+
+/* check QEMU signature */
+
+outw(BIOS_CFG_IOPORT, BIOS_CFG_SIGNATURE);
+if (inb(BIOS_CFG_IOPORT + 1) != 'Q')
+return 0;
+if (inb(BIOS_CFG_IOPORT + 1) != 'E')
+return 0;
+if (inb(BIOS_CFG_IOPORT + 1) != 'M')
+return 0;
+if (inb(BIOS_CFG_IOPORT + 1) != 'U')
+return 0;
+
+/* check splash signature */
+
+if (read_logo_word(&logo_hdr->u16Signature) != LOGO_HDR_MAGIC)
+return 0;
+
+/* Get options */
+
+is_fade_in = read_logo_byte(&logo_hdr->fu8FadeIn);
+is_fade_out = read_logo_byte(&logo_hdr->fu8FadeOut);
+logo_time = read_logo_word(&logo_hdr->u16LogoMillies);
+
+return (is_fade_in || is_fade_out || logo_time);
+}
+
+void logo_show()
+{
+LOGOHDR*logo_hdr = 0;
+Bit8u is_fade_in;
+Bit16u i;
+
+set_mode(0x12); /* 640x480 */
+
+is_fade_in = read
[PATCH][BIOS][v2] Fill IPL table according discovered ATA drives
This patch shows in boot menu only available devices.
This patch has been tested with Bochs BIOS version from the KVM source tree.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
bios/rombios.c | 49 ++---
1 files changed, 38 insertions(+), 11 deletions(-)
diff --git a/bios/rombios.c b/bios/rombios.c
index e0a419f..8c7ead2 100644
--- a/bios/rombios.c
+++ b/bios/rombios.c
@@ -1982,16 +1982,11 @@ init_boot_vectors()
memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e), ss, &e, sizeof (e));
count++;
+#if !BX_USE_ATADRV
/* First HDD */
e.type = IPL_TYPE_HARDDISK; e.flags = 0; e.vector = 0; e.description = 0;
e.reserved = 0;
memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e), ss, &e, sizeof (e));
count++;
-
-#if BX_ELTORITO_BOOT
- /* CDROM */
- e.type = IPL_TYPE_CDROM; e.flags = 0; e.vector = 0; e.description = 0;
e.reserved = 0;
- memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e), ss, &e, sizeof (e));
- count++;
#endif
/* Remember how many devices we have */
@@ -2031,15 +2026,19 @@ Bit16u i;
if (i >= count) return 0;
type = read_word(IPL_SEG, IPL_TABLE_OFFSET + i * sizeof (ipl_entry_t),
sizeof(Bit16u));
- if (type != IPL_TYPE_HARDDISK)
+ if (type == IPL_TYPE_HARDDISK)
+drv = 0x80;
+ else if (type == IPL_TYPE_CDROM)
+drv = 0xe0;
+ else
return 0;
- for (curr = 0, drv = 0; curr < i; curr++) {
+ for (curr = 0; curr < i; curr++) {
curr_type = read_word(IPL_SEG,
IPL_TABLE_OFFSET + curr * sizeof (ipl_entry_t),
sizeof(Bit16u));
if (type == curr_type) drv++;
}
- return 0x80 + drv;
+ return drv;
}
#if BX_ELTORITO_BOOT
@@ -2086,6 +2085,9 @@ interactive_bootkey()
memcpyb(ss, &description, (Bit16u)(e.description >> 16),
(Bit16u)(e.description & 0x), 32);
description[32] = 0;
printf(" [%S]", ss, description);
+ } else {
+ Bit8u drive = get_bootdrv(i);
+ if (drive) printf(" (0x%02x)", drive);
}
printf("\n");
break;
@@ -2488,6 +2490,9 @@ void ata_detect( )
Bit16u ebda_seg=read_word(0x0040,0x000E);
Bit8u hdcount, cdcount, device, type;
Bit8u buffer[0x0200];
+ Bit16u ss = get_SS();
+ ipl_entry_t e;
+ Bit16u count;
#if BX_MAX_ATA_INTERFACES > 0
write_byte(ebda_seg,&EbdaData->ata.channels[0].iface,ATA_IFACE_ISA);
@@ -2754,6 +2759,16 @@ void ata_detect( )
printf(" ATA-%d Hard-Disk (%4u MBytes)\n", version,
(Bit16u)sizeinmb);
else
printf(" ATA-%d Hard-Disk (%4u GBytes)\n", version,
(Bit16u)(sizeinmb>>10));
+ /* add to IPL list */
+ count = read_word(IPL_SEG, IPL_COUNT_OFFSET);
+ e.type = IPL_TYPE_HARDDISK;
+ e.flags = 0;
+ e.vector = 0;
+ e.description = 0;
+ e.reserved = 0;
+ memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e),
+ ss, &e, sizeof (e));
+ write_word(IPL_SEG, IPL_COUNT_OFFSET, count + 1);
break;
case ATA_TYPE_ATAPI:
printf("ata%d %s: ",channel,slave?" slave":"master");
@@ -2762,6 +2777,18 @@ void ata_detect( )
printf(" ATAPI-%d CD-Rom/DVD-Rom\n",version);
else
printf(" ATAPI-%d Device\n",version);
+ /* add to IPL list */
+#if BX_ELTORITO_BOOT
+ count = read_word(IPL_SEG, IPL_COUNT_OFFSET);
+ e.type = IPL_TYPE_CDROM;
+ e.flags = 0;
+ e.vector = 0;
+ e.description = 0;
+ e.reserved = 0;
+ memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e),
+ ss, &e, sizeof (e));
+ write_word(IPL_SEG, IPL_COUNT_OFFSET, count + 1);
+#endif
break;
case ATA_TYPE_UNKNOWN:
printf("ata%d %s: Unknown device\n",channel,slave?" slave":"master");
@@ -10667,6 +10694,8 @@ post_default_ints:
;;
call hard_drive_post
+ call _init_boot_vectors
+
#if BX_USE_ATADRV
;;
@@ -10686,8 +10715,6 @@ post_default_ints:
;;
#endif // BX_ELTORITO_BOOT
- call _init_boot_vectors
-
mov cx, #0xc800 ;; init option roms
mov ax, #0xe000
call rom_scan
--
1.5.6.5
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH][BIOS][v2] Add BCV option rom in boot menu
This patch allows to select and boot from an option ROM
with a Boot Connection Vector (BCV) entry.
The BIOS detects the BCV option ROM and adds it to the IPL table, and then
you are able to select it to boot.
This patch has been tested with Bochs BIOS version from the KVM source tree
and a gPXE ROM modified to be a BCV one.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
bios/rombios.c | 75 ++-
1 files changed, 68 insertions(+), 7 deletions(-)
diff --git a/bios/rombios.c b/bios/rombios.c
index 9a1cdd6..e0a419f 100644
--- a/bios/rombios.c
+++ b/bios/rombios.c
@@ -177,10 +177,15 @@
#define IPL_SEQUENCE_OFFSET 0x0082 /* u16: next boot device */
#define IPL_BOOTFIRST_OFFSET 0x0084 /* u16: user selected device */
#define IPL_SIZE 0xff
+#define IPL_TYPE_RESERVED0x00
#define IPL_TYPE_FLOPPY 0x01
#define IPL_TYPE_HARDDISK0x02
#define IPL_TYPE_CDROM 0x03
+#define IPL_TYPE_PCMCIA 0x04
+#define IPL_TYPE_USBDEVICE 0x05
+#define IPL_TYPE_NETWORK 0x06/* Embedded Network */
#define IPL_TYPE_BEV 0x80
+#define IPL_TYPE_UNKNOWN 0xff
// Sanity Checks
#if BX_USE_ATADRV && BX_CPU<3
@@ -2009,6 +2014,34 @@ Bit16u i; ipl_entry_t *e;
return 1;
}
+static Bit8u
+get_bootdrv(i)
+Bit16u i;
+{
+ Bit16u count;
+ Bit16u type;
+ Bit16u curr_type;
+ Bit16u curr;
+ Bit16u drv;
+ /* Get the count of boot devices, and refuse to overrun the array
+ * in case of overrun or invalid IPL type entry, return 0
+ * to boot from floppy.
+ */
+ count = read_word(IPL_SEG, IPL_COUNT_OFFSET);
+ if (i >= count) return 0;
+ type = read_word(IPL_SEG, IPL_TABLE_OFFSET + i * sizeof (ipl_entry_t),
+ sizeof(Bit16u));
+ if (type != IPL_TYPE_HARDDISK)
+return 0;
+ for (curr = 0, drv = 0; curr < i; curr++) {
+curr_type = read_word(IPL_SEG,
+ IPL_TABLE_OFFSET + curr * sizeof (ipl_entry_t),
+ sizeof(Bit16u));
+if (type == curr_type) drv++;
+ }
+ return 0x80 + drv;
+}
+
#if BX_ELTORITO_BOOT
void
interactive_bootkey()
@@ -2047,8 +2080,15 @@ interactive_bootkey()
case IPL_TYPE_FLOPPY:
case IPL_TYPE_HARDDISK:
case IPL_TYPE_CDROM:
-printf("%s\n", drivetypes[e.type]);
-break;
+printf("%s", drivetypes[e.type]);
+if (e.description != 0)
+{
+ memcpyb(ss, &description, (Bit16u)(e.description >> 16),
(Bit16u)(e.description & 0x), 32);
+ description[32] = 0;
+ printf(" [%S]", ss, description);
+ }
+ printf("\n");
+ break;
case IPL_TYPE_BEV:
printf("%s", drivetypes[4]);
if (e.description != 0)
@@ -8045,7 +8085,7 @@ Bit16u seq_nr;
case IPL_TYPE_FLOPPY: /* FDD */
case IPL_TYPE_HARDDISK: /* HDD */
-bootdrv = (e.type == IPL_TYPE_HARDDISK) ? 0x80 : 0x00;
+bootdrv = get_bootdrv(bootdev);
bootseg = 0x07c0;
status = 0;
@@ -10245,10 +10285,11 @@ block_count_rounded:
mov bx, 0x001a ;; 0x1A is the offset into ROM header that contains...
mov ax, [bx] ;; the offset of PnP expansion header, where...
cmp ax, #0x5024 ;; we look for signature "$PnP"
- jne no_bev
+ jne no_pnp
mov ax, 2[bx]
cmp ax, #0x506e
- jne no_bev
+ jne no_pnp
+ ;; Look for the Bootstrap Entry Vector (BEV)
mov ax, 0x1a[bx] ;; 0x1A is also the offset into the expansion header of...
cmp ax, #0x ;; the Bootstrap Entry Vector, or zero if there is none.
je no_bev
@@ -10259,9 +10300,29 @@ block_count_rounded:
mov ds, bx
mov bx, IPL_COUNT_OFFSET;; Read the number of entries so far
cmp bx, #IPL_TABLE_ENTRIES
- je no_bev ;; Get out if the table is full
+ je no_pnp ;; Get out if the table is full
shl bx, #0x4;; Turn count into offset (entries are 16 bytes)
mov 0[bx], #IPL_TYPE_BEV;; This entry is a BEV device
+ jmp add_ipl
+
+no_bev:
+ ;; Look for the Boot Connection Vector (BCV)
+ mov ax, 0x16[bx] ;; 0x16 is the offset into the expansion header of...
+ cmp ax, #0x ;; the Boot Connection Vector, or zero if there is none.
+ je no_pnp
+
+ ;; Found a device that thinks it can boot the system.
+ mov di, 0x10[bx];; Pointer to the product name string or zero
if none
+ mov bx, #IPL_SEG;; Go to the segment where the IPL table lives
+ mov ds, bx
+ mov bx, IPL_COUNT_OFFSET;; Read the number of entries so far
+ cmp bx, #IPL_TABLE_ENTRIES
+ je no_pnp ;; Get out if the table is full
+ shl bx, #0x4;; Turn count into offset (entries are 16 bytes)
+ mov 0[bx], #IPL_TYPE_HARDDISK;; This entry is a BCV device
+
+add_ipl:
+
mov 6[bx], cx
Re: [Bochs-developers] [PATCH][BIOS] Fill IPL table accordingdiscovered ATA drives
Le dimanche 07 décembre 2008 à 19:11 +0100, Sebastian Herbszt a écrit : > Laurent Vivier wrote: > > This patch shows in boot menu only available devices. > > > > This patch has been tested with Bochs BIOS version from the KVM source tree. > > > > Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]> > > --- > > bios/rombios.c | 54 +- > > 1 files changed, 37 insertions(+), 17 deletions(-) > > > > diff --git a/bios/rombios.c b/bios/rombios.c > > index 70b3584..d2a7c09 100644 > > --- a/bios/rombios.c > > +++ b/bios/rombios.c > > @@ -1981,18 +1981,6 @@ init_boot_vectors() > > memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e), ss, &e, sizeof > > (e)); > > count++; > > > > - /* First HDD */ > > - e.type = IPL_TYPE_HARDDISK; e.flags = 0; e.vector = 0; e.description = > > 0; e.reserved = 0; > > - memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e), ss, &e, sizeof > > (e)); > > - count++; > > We need this bit for the !BX_USE_ATADRV case. Please "#if !BX_USE_ATADRV ... > #endif" it > instead of removing. If there is no ATA drive, what is the aim of adding an harddrive in the IPL table ? Thank you for all your comments (I'm going to resend the two patches) Regards, Laurent -- -- [EMAIL PROTECTED] -- "Tout ce qui est impossible reste à accomplir"Jules Verne "Things are only impossible until they're not" Jean-Luc Picard -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH][BIOS] Fill IPL table according discovered ATA drives
This patch shows in boot menu only available devices.
This patch has been tested with Bochs BIOS version from the KVM source tree.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
bios/rombios.c | 54 +-
1 files changed, 37 insertions(+), 17 deletions(-)
diff --git a/bios/rombios.c b/bios/rombios.c
index 70b3584..d2a7c09 100644
--- a/bios/rombios.c
+++ b/bios/rombios.c
@@ -1981,18 +1981,6 @@ init_boot_vectors()
memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e), ss, &e, sizeof (e));
count++;
- /* First HDD */
- e.type = IPL_TYPE_HARDDISK; e.flags = 0; e.vector = 0; e.description = 0;
e.reserved = 0;
- memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e), ss, &e, sizeof (e));
- count++;
-
-#if BX_ELTORITO_BOOT
- /* CDROM */
- e.type = IPL_TYPE_CDROM; e.flags = 0; e.vector = 0; e.description = 0;
e.reserved = 0;
- memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e), ss, &e, sizeof (e));
- count++;
-#endif
-
/* Remember how many devices we have */
write_word(IPL_SEG, IPL_COUNT_OFFSET, count);
/* Not tried booting anything yet */
@@ -2027,15 +2015,19 @@ Bit16u i;
if (i >= count) return 0;
type = read_word(IPL_SEG, IPL_TABLE_OFFSET + i * sizeof (ipl_entry_t),
sizeof(Bit16u));
- if (type != IPL_TYPE_HARDDISK)
+ if (type == IPL_TYPE_HARDDISK)
+drv = 0x80;
+ else if(type == IPL_TYPE_CDROM)
+drv = 0xe0;
+ else
return 0;
- for (curr = 0, drv = 0; curr < i; curr++) {
+ for (curr = 0; curr < i; curr++) {
curr_type = read_word(IPL_SEG,
IPL_TABLE_OFFSET + curr * sizeof (ipl_entry_t),
sizeof(Bit16u));
if (type == curr_type) drv++;
}
- return 0x80 + drv;
+ return drv;
}
#if BX_ELTORITO_BOOT
@@ -2082,6 +2074,9 @@ interactive_bootkey()
memcpyb(ss, &description, (Bit16u)(e.description >> 16),
(Bit16u)(e.description & 0x), 32);
description[32] = 0;
printf(" [%S]", ss, description);
+ } else {
+ Bit16u drive = get_bootdrv(i);
+ if (drive) printf(" (0x%02x)", drive);
}
printf("\n");
break;
@@ -2484,6 +2479,9 @@ void ata_detect( )
Bit16u ebda_seg=read_word(0x0040,0x000E);
Bit8u hdcount, cdcount, device, type;
Bit8u buffer[0x0200];
+ Bit16u ss = get_SS();
+ ipl_entry_t e;
+ Bit16u count;
#if BX_MAX_ATA_INTERFACES > 0
write_byte(ebda_seg,&EbdaData->ata.channels[0].iface,ATA_IFACE_ISA);
@@ -2750,6 +2748,16 @@ void ata_detect( )
printf(" ATA-%d Hard-Disk (%4u MBytes)\n", version,
(Bit16u)sizeinmb);
else
printf(" ATA-%d Hard-Disk (%4u GBytes)\n", version,
(Bit16u)(sizeinmb>>10));
+ /* add to IPL list */
+ count = read_word(IPL_SEG, IPL_COUNT_OFFSET);
+ e.type = IPL_TYPE_HARDDISK;
+ e.flags = 0;
+ e.vector = 0;
+ e.description = 0;
+ e.reserved = 0;
+ memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e),
+ ss, &e, sizeof (e));
+ write_word(IPL_SEG, IPL_COUNT_OFFSET, count + 1);
break;
case ATA_TYPE_ATAPI:
printf("ata%d %s: ",channel,slave?" slave":"master");
@@ -2758,6 +2766,18 @@ void ata_detect( )
printf(" ATAPI-%d CD-Rom/DVD-Rom\n",version);
else
printf(" ATAPI-%d Device\n",version);
+ /* add to IPL list */
+#if BX_ELTORITO_BOOT
+ count = read_word(IPL_SEG, IPL_COUNT_OFFSET);
+ e.type = IPL_TYPE_CDROM;
+ e.flags = 0;
+ e.vector = 0;
+ e.description = 0;
+ e.reserved = 0;
+ memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e),
+ ss, &e, sizeof (e));
+ write_word(IPL_SEG, IPL_COUNT_OFFSET, count + 1);
+#endif
break;
case ATA_TYPE_UNKNOWN:
printf("ata%d %s: Unknown device\n",channel,slave?" slave":"master");
@@ -10663,6 +10683,8 @@ post_default_ints:
;;
call hard_drive_post
+ call _init_boot_vectors
+
#if BX_USE_ATADRV
;;
@@ -10682,8 +10704,6 @@ post_default_ints:
;;
#endif // BX_ELTORITO_BOOT
- call _init_boot_vectors
-
mov cx, #0xc800 ;; init option roms
mov ax, #0xe000
call rom_scan
--
1.5.6.5
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH][BIOS] Add BCV option rom in boot menu
This patch allows to select and boot from an option ROM
with a Boot Connection Vector (BCV) entry.
The BIOS detects the BCV option ROM and adds it to the IPL table, and then
you are able to select it to boot.
This patch has been tested with Bochs BIOS version from the KVM source tree
and a gPXE ROM modified to be a BCV one.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
bios/rombios.c | 71 ++-
1 files changed, 64 insertions(+), 7 deletions(-)
diff --git a/bios/rombios.c b/bios/rombios.c
index 9a1cdd6..70b3584 100644
--- a/bios/rombios.c
+++ b/bios/rombios.c
@@ -180,7 +180,11 @@
#define IPL_TYPE_FLOPPY 0x01
#define IPL_TYPE_HARDDISK0x02
#define IPL_TYPE_CDROM 0x03
+#define IPL_TYPE_PCMCIA 0x04
+#define IPL_TYPE_USBDEVICE 0x05
+#define IPL_TYPE_NETWORK 0x06
#define IPL_TYPE_BEV 0x80
+#define IPL_TYPE_UNKNOWN 0xff
// Sanity Checks
#if BX_USE_ATADRV && BX_CPU<3
@@ -2009,6 +2013,31 @@ Bit16u i; ipl_entry_t *e;
return 1;
}
+static Bit8u
+get_bootdrv(i)
+Bit16u i;
+{
+ Bit16u count;
+ Bit16u type;
+ Bit16u curr_type;
+ Bit16u curr;
+ Bit16u drv;
+ /* Get the count of boot devices, and refuse to overrun the array */
+ count = read_word(IPL_SEG, IPL_COUNT_OFFSET);
+ if (i >= count) return 0;
+ type = read_word(IPL_SEG, IPL_TABLE_OFFSET + i * sizeof (ipl_entry_t),
+ sizeof(Bit16u));
+ if (type != IPL_TYPE_HARDDISK)
+return 0;
+ for (curr = 0, drv = 0; curr < i; curr++) {
+curr_type = read_word(IPL_SEG,
+ IPL_TABLE_OFFSET + curr * sizeof (ipl_entry_t),
+ sizeof(Bit16u));
+if (type == curr_type) drv++;
+ }
+ return 0x80 + drv;
+}
+
#if BX_ELTORITO_BOOT
void
interactive_bootkey()
@@ -2047,8 +2076,15 @@ interactive_bootkey()
case IPL_TYPE_FLOPPY:
case IPL_TYPE_HARDDISK:
case IPL_TYPE_CDROM:
-printf("%s\n", drivetypes[e.type]);
-break;
+printf("%s", drivetypes[e.type]);
+if (e.description != 0)
+{
+ memcpyb(ss, &description, (Bit16u)(e.description >> 16),
(Bit16u)(e.description & 0x), 32);
+ description[32] = 0;
+ printf(" [%S]", ss, description);
+ }
+ printf("\n");
+ break;
case IPL_TYPE_BEV:
printf("%s", drivetypes[4]);
if (e.description != 0)
@@ -8045,7 +8081,7 @@ Bit16u seq_nr;
case IPL_TYPE_FLOPPY: /* FDD */
case IPL_TYPE_HARDDISK: /* HDD */
-bootdrv = (e.type == IPL_TYPE_HARDDISK) ? 0x80 : 0x00;
+bootdrv = get_bootdrv(bootdev);
bootseg = 0x07c0;
status = 0;
@@ -10245,10 +10281,11 @@ block_count_rounded:
mov bx, 0x001a ;; 0x1A is the offset into ROM header that contains...
mov ax, [bx] ;; the offset of PnP expansion header, where...
cmp ax, #0x5024 ;; we look for signature "$PnP"
- jne no_bev
+ jne no_pnp
mov ax, 2[bx]
cmp ax, #0x506e
- jne no_bev
+ jne no_pnp
+ ;; Look for the Bootstrap Entry Vector (BEV)
mov ax, 0x1a[bx] ;; 0x1A is also the offset into the expansion header of...
cmp ax, #0x ;; the Bootstrap Entry Vector, or zero if there is none.
je no_bev
@@ -10259,9 +10296,29 @@ block_count_rounded:
mov ds, bx
mov bx, IPL_COUNT_OFFSET;; Read the number of entries so far
cmp bx, #IPL_TABLE_ENTRIES
- je no_bev ;; Get out if the table is full
+ je no_pnp ;; Get out if the table is full
shl bx, #0x4;; Turn count into offset (entries are 16 bytes)
mov 0[bx], #IPL_TYPE_BEV;; This entry is a BEV device
+ jmp add_ipl
+
+no_bev:
+ ;; Look for the Boot Connection Vector (BCV)
+ mov ax, 0x16[bx] ;; 0x16 is also the offset into the expansion header of...
+ cmp ax, #0x ;; the Boots Entry Vector, or zero if there is none.
+ je no_pnp
+
+ ;; Found a device that thinks it can boot the system.
+ mov di, 0x10[bx];; Pointer to the product name string or zero
if none
+ mov bx, #IPL_SEG;; Go to the segment where the IPL table lives
+ mov ds, bx
+ mov bx, IPL_COUNT_OFFSET;; Read the number of entries so far
+ cmp bx, #IPL_TABLE_ENTRIES
+ je no_pnp ;; Get out if the table is full
+ shl bx, #0x4;; Turn count into offset (entries are 16 bytes)
+ mov 0[bx], #IPL_TYPE_HARDDISK;; This entry is a BEV device
+
+add_ipl:
+
mov 6[bx], cx ;; Build a far pointer from the segment...
mov 4[bx], ax ;; and the offset
cmp di, #0x
@@ -10273,7 +10330,7 @@ no_prod_str:
inc bx ;; We have one more entry now
mov IPL_COUNT_OFFSET, bx;; Remember that.
-no_bev:
+no_pnp:
pop di ;; Restore DI
pop ax
Re: Windows 2003, virtio Ethernet and USB - Strange Interaction
Le mardi 30 septembre 2008 à 10:41 +0200, Sven Rudolph a écrit :
> Hello,
>
> I have an (as far as I understand it) complex problem. I just got some
> good debugging hints, so I tried some more things and reproduced the
> problem with recent KVM.
>
> I tested it now with kvm-76 (both kernel and userspace) with virtio
> Ethernet on Linux 2.6.27-rc7. The guest runs Windows Server 2003
> (Standard Edition, SP2) with the virtio guest driver (Version
> 5.1.0.3107).
>
> First a description of my environment. I start KVM's qemu:
>
> /usr/local/bin/qemu-system-x86_64 -m 3584 -boot n -hda hda.dat \
> -net nic,macaddr=00:50:56:24:0b:37,model=virtio \
> -net tap,ifname=vm03,script=no,downscript=no \
> -usb -usbdevice tablet
>
> This does a DHCP request via an etherboot virtio rom; it reports the
> version as Etherboot 5.4.3, the MD5 sum is:
>
> 9b3dbc97cc819508f2984ac00b90adc0 /usr/local/share/qemu/pxe-virtio.bin
Where is coming from your rom ?
Is etherboot or gPXE rom ?
> This starts pxegrub; pxegrub configuration is compiled-in and boots
> from harddisk:
>
> default 0
>
> timeout 5
>
> title boot from first disk
>
> root (hd0)
> chainloader +1
>
> (This is our way of configuring DHCP to boot the locally-installed
> Windows. In order to boot a network Linux, the DHCP configuration is
> automatically changed.)
Is linux able to reboot ?
>
> Now the problem: When I reboot Windows (shutdown /r), the newly booted
> windows hangs during boot. (The problem stays the same when I reset
> the VM (using the monitor command "system_reset") instead of rebooting
> with "shutdown /r".) It hangs in the first graphical screen (where
> the windows logo and "Microsoft Windows Server 2003" are displayed in
> the center), and the "activity bar" below this stops after some
> seconds (and qemu starts eating 100% CPU). Resetting the VM with
> "system_reset" does not solve the problem; the next booted Windows
> hangs in the same place.
>
>
> There are many ways that make the problem disappear:
>
> When I stop the qemu process and start a new one, Windows boots again
> (but the problem can be reproduced by rebooting Windows as described
> above).
>
> When I reset the VM with "system_reset", boot Linux (Version 2.6.25.9)
> from network, reboot this Linux and then boot Windows again, it works.
>
> When I use the Realtek network driver (model=rtl8139), Windows boots
> again.
>
> When I do not use the network boot, etherboot and pxegrub sequence
> (using "-boot c" instead of "-boot n"), Windows boots again.
>
> And now the real fun: when I remove the "-usb -usbdevice tablet"
> option (and this is the only change!), everything works. (It is the
> "-usb" part that makes the difference, "-usbdevice tablet" doesn't
> influence this problem.) I have no idea how virtio Ethernet and USB
> interact in order to cause this problem...
Did you try to reduce the amount of memory ("-m 1024") ?
> Trying a summary: When using virtio Ethernet and "-usb"; Windows
> leaves something (virtio Ethernet or USB ?) in a state that isn't
> reset by my reboot sequence (etherboot/pxegrub) and makes the next
> Windows boot hang. Booting Linux inbetween resets that state, and
> using the "-boot c" path does that too.
>
> So my first workaround would be to not use the USB tablet, because
> this isn't critical for me. But it took us some time to diagnose the
> problem, hence I wanted to tell you about this in order to save you
> the same work.
Regards,
Laurent
--
- [EMAIL PROTECTED] --
"La perfection est atteinte non quand il ne reste rien à
ajouter mais quand il ne reste rien à enlever." Saint Exupéry
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: Device Assignment with VT-d
Le mardi 16 septembre 2008 à 00:58 +, Avi Kivity a écrit :
> From: Ben-Ami Yassour <[EMAIL PROTECTED]>
>
> Based on a patch by: Kay, Allen M <[EMAIL PROTECTED]>
>
> This patch enables PCI device assignment based on VT-d support.
> When a device is assigned to the guest, the guest memory is pinned and
> the mapping is updated in the VT-d IOMMU.
>
> [Amit: Expose KVM_CAP_IOMMU so we can check if an IOMMU is present
> and also control enable/disable from userspace]
>
> Signed-off-by: Kay, Allen M <[EMAIL PROTECTED]>
> Signed-off-by: Weidong Han <[EMAIL PROTECTED]>
> Signed-off-by: Ben-Ami Yassour <[EMAIL PROTECTED]>
> Signed-off-by: Amit Shah <[EMAIL PROTECTED]>
>
> Acked-by: Mark Gross <[EMAIL PROTECTED]>
> Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
>
> diff --git a/arch/x86/kvm/Makefile b/arch/x86/kvm/Makefile
> index d0e940b..3072b17 100644
> --- a/arch/x86/kvm/Makefile
> +++ b/arch/x86/kvm/Makefile
> @@ -12,6 +12,9 @@ EXTRA_CFLAGS += -Ivirt/kvm -Iarch/x86/kvm
>
> kvm-objs := $(common-objs) x86.o mmu.o x86_emulate.o i8259.o irq.o lapic.o \
> i8254.o
> +ifeq ($(CONFIG_DMAR),y)
> +kvm-objs += vtd.o
> +endif
> obj-$(CONFIG_KVM) += kvm.o
> kvm-intel-objs = vmx.o
> obj-$(CONFIG_KVM_INTEL) += kvm-intel.o
> diff --git a/arch/x86/kvm/vtd.c b/arch/x86/kvm/vtd.c
> new file mode 100644
> index 000..667bf3f
> --- /dev/null
> +++ b/arch/x86/kvm/vtd.c
> @@ -0,0 +1,198 @@
> +/*
> + * Copyright (c) 2006, Intel Corporation.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> with
> + * this program; if not, write to the Free Software Foundation, Inc., 59
> Temple
> + * Place - Suite 330, Boston, MA 02111-1307 USA.
> + *
> + * Copyright (C) 2006-2008 Intel Corporation
> + * Copyright IBM Corporation, 2008
> + * Author: Allen M. Kay <[EMAIL PROTECTED]>
> + * Author: Weidong Han <[EMAIL PROTECTED]>
> + * Author: Ben-Ami Yassour <[EMAIL PROTECTED]>
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static int kvm_iommu_unmap_memslots(struct kvm *kvm);
> +static void kvm_iommu_put_pages(struct kvm *kvm,
> + gfn_t base_gfn, unsigned long npages);
> +
> +int kvm_iommu_map_pages(struct kvm *kvm,
> + gfn_t base_gfn, unsigned long npages)
> +{
> + gfn_t gfn = base_gfn;
> + pfn_t pfn;
> + int i, r;
> + struct dmar_domain *domain = kvm->arch.intel_iommu_domain;
> +
> + /* check if iommu exists and in use */
> + if (!domain)
> + return 0;
> +
> + r = -EINVAL;
> + for (i = 0; i < npages; i++) {
> + /* check if already mapped */
> + pfn = (pfn_t)intel_iommu_iova_to_pfn(domain,
> + gfn_to_gpa(gfn));
> + if (pfn && !is_mmio_pfn(pfn))
> + continue;
> +
> + pfn = gfn_to_pfn(kvm, gfn);
> + if (!is_mmio_pfn(pfn)) {
> + r = intel_iommu_page_mapping(domain,
> + gfn_to_gpa(gfn),
> + pfn_to_hpa(pfn),
> + PAGE_SIZE,
> + DMA_PTE_READ |
> + DMA_PTE_WRITE);
> + if (r) {
> + printk(KERN_DEBUG "kvm_iommu_map_pages:"
> +"iommu failed to map pfn=%lx\n", pfn);
> + goto unmap_pages;
> + }
> + } else {
> + printk(KERN_DEBUG "kvm_iommu_map_page:"
> +"invalid pfn=%lx\n", pfn);
> + goto unmap_pages;
> + }
> + gfn++;
> + }
> + return 0;
> +
> +unmap_pages:
> + kvm_iommu_put_pages(kvm, base_gfn, i);
> + return r;
> +}
> +
> +static int kvm_iommu_map_memslots(struct kvm *kvm)
> +{
> + int i, r;
> +
> + down_read(&kvm->slots_lock);
> + for (i = 0; i < kvm->nmemslots; i++) {
> + r = kvm_iommu_map_pages(kvm, kvm->memslots[i].base_gfn,
> + kvm->memslots[i].npages);
> + if (r)
> + break;
> + }
> + up_read(&kvm->slots_lock);
> + return r;
> +}
> +
> +int kvm_iommu_map_guest(struct kvm *kvm,
> + struct kvm_assigned_dev_kernel *assigned_dev)
> +{
> + struct p
Re: tape support
Le samedi 13 septembre 2008 à 07:51 +0300, Avi Kivity a écrit : > Laurent Vivier wrote: > > Le jeudi 11 septembre 2008 à 12:54 +0200, Dietmar Maurer a écrit : > > > >> Is there a way to use a scsi tape? I tried -drive file=/dev/sg0, but > >> that does not work (eject, rewind works, but read/write fails - no date > >> is written - no errors) > >> > > > > try "-drive file=/dev/sg0,if=scsi" > > > > How would that work? Won't qemu attempt to show the tape as a disk? Or > does it detect this special case and passes-through the scsi device? Yes, Qemu detects it's SCSI interface and passes the SCSI commands to devices. But qemu ignores the type of the device but OS (linux) detects this as a tape (with INQUIRY). It works well for CD/DVD and disk, but I'm working with Dietmar to make it working with tape (commands encoding differs)... and I found some devices to test. Regards, Laurent -- - [EMAIL PROTECTED] -- "La perfection est atteinte non quand il ne reste rien à ajouter mais quand il ne reste rien à enlever." Saint Exupéry -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tape support
Le jeudi 11 septembre 2008 à 12:54 +0200, Dietmar Maurer a écrit : > Is there a way to use a scsi tape? I tried -drive file=/dev/sg0, but > that does not work (eject, rewind works, but read/write fails - no date > is written - no errors) try "-drive file=/dev/sg0,if=scsi" Laurent -- - [EMAIL PROTECTED] -- "La perfection est atteinte non quand il ne reste rien à ajouter mais quand il ne reste rien à enlever." Saint Exupéry -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: VMX: Leave atomic context while emulating real mode
Le mercredi 20 août 2008 à 14:01 +, Avi Kivity a écrit :
> From: Avi Kivity <[EMAIL PROTECTED]>
>
> Emulation requires access to user memory, and potentially schedules.
>
> Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
>
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index d5d25a2..81c121c 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -2911,6 +2911,9 @@ static void handle_invalid_guest_state(struct kvm_vcpu
> *vcpu,
> struct vcpu_vmx *vmx = to_vmx(vcpu);
> int err;
>
> + preempt_enable();
> + local_irq_enable();
> +
> while (!guest_state_valid(vcpu)) {
> err = emulate_instruction(vcpu, kvm_run, 0, 0, 0);
>
> @@ -2932,6 +2935,9 @@ static void handle_invalid_guest_state(struct kvm_vcpu
> *vcpu,
> schedule();
> }
>
> + local_irq_disable();
> + preempt_enable();
should be a preempt_disable() ?
> /* Guest state should be valid now, no more emulation should be needed
> */
> vmx->emulation_required = 0;
> }
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-commits" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
- [EMAIL PROTECTED] --
"La perfection est atteinte non quand il ne reste rien à
ajouter mais quand il ne reste rien à enlever." Saint Exupéry
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Clear temporary interrupt blocking on halt in real mode
Le dimanche 10 août 2008 à 11:36 +0300, Avi Kivity a écrit :
> Laurent Vivier wrote:
> > When "halt" is emulated, skip_emulated_instruction() is called and
> > interruptibility state is cleared.
> > But when halt is emulated in real mode, skip_emulated_instruction() is not
> > called and the interruptiblity state is not cleared.
> >
> > The following code, from gPXE, never exits from loop because interrupts are
> > not delivered to increase %fs:(0x6c):
> >
> > movl%fs:(0x6c), %eax
> > 1: pushf
> > sti
> > hlt
> > popf
> > cmpl%fs:(0x6c), %eax
> > je 1b
> >
> > This patch clears the interruptibility state when halt is emulated in real
> > mode.
> >
> > Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
> > ---
> > arch/x86/kvm/vmx.c | 10 ++
> > 1 files changed, 10 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> > index c4510fe..82c4324 100644
> > --- a/arch/x86/kvm/vmx.c
> > +++ b/arch/x86/kvm/vmx.c
> > @@ -2329,7 +2329,17 @@ static int handle_exception(struct kvm_vcpu *vcpu,
> > struct kvm_run *kvm_run)
> > handle_rmode_exception(vcpu, intr_info & INTR_INFO_VECTOR_MASK,
> > error_code)) {
> > if (vcpu->arch.halt_request) {
> > + u32 interruptibility;
> > vcpu->arch.halt_request = 0;
> > + /*
> > +* We emulated an instruction, so temporary interrupt
> > blocking
> > +* should be removed, if set.
> > + */
> > + interruptibility =
> > vmcs_read32(GUEST_INTERRUPTIBILITY_INFO);
> > + if (interruptibility & 3)
> > + vmcs_write32(GUEST_INTERRUPTIBILITY_INFO,
> > +interruptibility & ~3);
> > + vcpu->arch.interrupt_window_open = 1;
> > return kvm_emulate_halt(vcpu);
> > }
> > return 1;
> >
>
>
> Shouldn't interruptibility state be cleared if *any* instruction is
> emulated?
>
> (of course, an emulated instruction may update interruptibility state
> itself, say sti).
I don't know what to do with that...
I think emulated instructions already clear interruptibility state via
skip_emulated_instruction().
The case of kvm_emulate_halt() and real mode is a special case.
Laurent
--
- [EMAIL PROTECTED] --
"La perfection est atteinte non quand il ne reste rien à
ajouter mais quand il ne reste rien à enlever." Saint Exupéry
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 63 sectors
Le jeudi 04 septembre 2008 à 09:58 +0100, Ian Kirk a écrit : > Avi Kivity wrote: > > > - add a partitioning tool (or option to qemu-img) to format the disk, > > placing > > the first partition on the fourth cylinder, aligning it. tell the users not > > to wipe the disks out but instead install to one of the existing parititions > > I thought that updating qemu-img to have quasi-fdisk functionality was a > good idea myself. Is there a respected libfdisk.so thing that could be > used to abstract most of the work ? libparted ? Laurent -- - [EMAIL PROTECTED] -- "La perfection est atteinte non quand il ne reste rien à ajouter mais quand il ne reste rien à enlever." Saint Exupéry -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Clear temporary interrupt blocking on halt in real mode
When "halt" is emulated, skip_emulated_instruction() is called and
interruptibility state is cleared.
But when halt is emulated in real mode, skip_emulated_instruction() is not
called and the interruptiblity state is not cleared.
The following code, from gPXE, never exits from loop because interrupts are not
delivered to increase %fs:(0x6c):
movl%fs:(0x6c), %eax
1: pushf
sti
hlt
popf
cmpl%fs:(0x6c), %eax
je 1b
This patch clears the interruptibility state when halt is emulated in real mode.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
arch/x86/kvm/vmx.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index c4510fe..82c4324 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2329,7 +2329,17 @@ static int handle_exception(struct kvm_vcpu *vcpu,
struct kvm_run *kvm_run)
handle_rmode_exception(vcpu, intr_info & INTR_INFO_VECTOR_MASK,
error_code)) {
if (vcpu->arch.halt_request) {
+ u32 interruptibility;
vcpu->arch.halt_request = 0;
+ /*
+* We emulated an instruction, so temporary interrupt
blocking
+* should be removed, if set.
+ */
+ interruptibility =
vmcs_read32(GUEST_INTERRUPTIBILITY_INFO);
+ if (interruptibility & 3)
+ vmcs_write32(GUEST_INTERRUPTIBILITY_INFO,
+interruptibility & ~3);
+ vcpu->arch.interrupt_window_open = 1;
return kvm_emulate_halt(vcpu);
}
return 1;
--
1.5.2.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ROM][v2] virtio-net etherboot ROM
Le mercredi 18 juin 2008 à 06:26 -0700, Avi Kivity a écrit : > Laurent Vivier wrote: > > This new version of virtio-net etherboot ROM clears the ISR on reset, > > and thus allows linux to use it again (on Qemu/KVM). > > > > What's the status of upstreaming this? Didn't see it on etherboot.git. Virtio-net driver is now included in etherboot git and gPXE git (thank you to Stefan Hajnoczi for his work on this) So, virtio-net ROM image is now available from http://rom-o-matic.net. Regards, Laurent -- - [EMAIL PROTECTED] -- "La perfection est atteinte non quand il ne reste rien à ajouter mais quand il ne reste rien à enlever." Saint Exupéry -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Failure to boot CDROM with -drive arg
Le mardi 08 juillet 2008 à 09:59 -0500, Anthony Liguori a écrit : > Laurent Vivier wrote: > > So, "boot=on" means in fact "bootable=true" > > > > I guess. I don't know that the later is more clear. I think the source > of the confusion is the entire concept of "first bootable harddisk" > which is what -boot c really means. > > FWIW, the reason media=cdrom,boot=on doesn't work, is that a CDROM's > boot record is in el torito format instead of the traditional BIOS boot > sector. > > media=cdrom,boot=on would work if the image was a disk image instead of > an ISO. > > In fact, I'm inclined to think that media=cdrom,boot=on should not be > explicitly prohibited because of this fact. To simplify, I think qemu should ignore "boot=on" when "if=ide". Laurent -- - [EMAIL PROTECTED] -- "L'avenir ne se prévoit pas, il se prépare." - Maurice Blondel -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Failure to boot CDROM with -drive arg
Le mardi 08 juillet 2008 à 08:01 -0500, Anthony Liguori a écrit : > Daniel P. Berrange wrote: > > On Tue, Jul 08, 2008 at 11:17:24AM +0200, Soren Hansen wrote: > > > >> On Tue, Jul 08, 2008 at 09:37:30AM +0100, Daniel P. Berrange wrote: > >> > >>> The following two command lines should be identical from the user's > >>> point of view: > >>> > >>> # qemu-kvm -cdrom /home/berrange/boot.iso -boot d -m 500 > >>> > >>> # qemu-kvm -drive > >>> file=/home/berrange/boot.iso,if=ide,media=cdrom,index=2,boot=on -m 500 > >>> > >> http://sourceforge.net/tracker/index.php?func=detail&aid=1977971&group_id=180599&atid=893831 > >> > > > > Ok, so basically this is saying that boot=on only works for media=disk. > > I really don't like the fact that we now have 2 different ways of flagging > > bootable disks, depending on whether want to use BIOS boot or extboot. > > > > Semantically, boot=on means "make this the first bootable hard disk". > That's not to say that there shouldn't be a check. > > If you did: > > qemu-system-x86 -drive file=foo.img,boot=on -boot d > > You would still boot from the cdrom. So, "boot=on" means in fact "bootable=true" Regards, Laurent -- - [EMAIL PROTECTED] -- "L'avenir ne se prévoit pas, il se prépare." - Maurice Blondel -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Failure to boot CDROM with -drive arg
Le mardi 08 juillet 2008 à 10:21 +0100, Daniel P. Berrange a écrit : > On Tue, Jul 08, 2008 at 11:17:24AM +0200, Soren Hansen wrote: > > On Tue, Jul 08, 2008 at 09:37:30AM +0100, Daniel P. Berrange wrote: > > > The following two command lines should be identical from the user's > > > point of view: > > > > > > # qemu-kvm -cdrom /home/berrange/boot.iso -boot d -m 500 > > > > > > # qemu-kvm -drive > > > file=/home/berrange/boot.iso,if=ide,media=cdrom,index=2,boot=on -m 500 > > > > http://sourceforge.net/tracker/index.php?func=detail&aid=1977971&group_id=180599&atid=893831 > > Ok, so basically this is saying that boot=on only works for media=disk. > I really don't like the fact that we now have 2 different ways of flagging > bootable disks, depending on whether want to use BIOS boot or extboot. > > The management apps shouldn't have to make such a decision - QEMU should > be picking the most appropriate choice for us. ie, if we have boot=on > with an IDE cdrom, then QEMU should automatically do a BIOS boot instead > of extboot. This way if extboot gets improved, QEMU can update its logic > to correspond without needing to change all the management apps using > QEMU. I agree. Laurent -- - [EMAIL PROTECTED] -- "L'avenir ne se prévoit pas, il se prépare." - Maurice Blondel -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Failure to boot CDROM with -drive arg
Le mardi 08 juillet 2008 à 11:17 +0200, Soren Hansen a écrit : > On Tue, Jul 08, 2008 at 09:37:30AM +0100, Daniel P. Berrange wrote: > > The following two command lines should be identical from the user's > > point of view: > > > > # qemu-kvm -cdrom /home/berrange/boot.iso -boot d -m 500 > > > > # qemu-kvm -drive > > file=/home/berrange/boot.iso,if=ide,media=cdrom,index=2,boot=on -m 500 > > http://sourceforge.net/tracker/index.php?func=detail&aid=1977971&group_id=180599&atid=893831 yes, in fact "media=cdrom,boot=on" is not equal to "-cdrom ... -boot d". "boot=on" means "use bios extension extboot with this drive", and using extboot allows the bios to manage this device and to boot from it. Laurent -- - [EMAIL PROTECTED] -- "L'avenir ne se prévoit pas, il se prépare." - Maurice Blondel -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM Test result, kernel a81a686.., userspace 619ca34..
Le mardi 08 juillet 2008 à 16:58 +0800, Xu, Jiajun a écrit : > Hi All, > > This is today's KVM test result against kvm.git > a81a686682d6f04c842ebf9e084e30cd875f1048 and kvm-userspace.git > 619ca34310a8968b6939fa6aba5b85a16b20315e. > There's no new issue today. > > Three Old Issues: > > 1. 32bits Rhel5/FC6 guest may fail to reboot after installation > https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1991647&group_id=180599 > > > > 2. vista auto-unattended installation failed on kvm guests > https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1991653&group_id=180599 > Is this a duplicate of https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1967368&group_id=180599 ? If so, it is corrected in qemu. > > 3. failure to migrate guests with more than 4GB of RAM > https://sourceforge.net/tracker/index.php?func=detail&aid=1971512&group_id=180599&atid=893831 > > > > > > Test environment > > Platform > Woodcrest > CPU 4 > Memory size 8G' > > Details > > IA32-pae: 1. boot guest with 256M > memory PASS > 2. boot guest with 1500M memory PASS > 3. boot 4 same guest in parallel PASS > 4. boot two windows xp guestPASS > 5. boot linux and windows guest in parallel PASS > 6. save/restore 32-bit HVM guests PASS > 7. save/restore 32-bit HVM guests with 4 vcpus PASS > 8. live migration 32-bit HVM guests PASS > 9. live migration 32-bit HVM guests with 4 vcpus PASS > 10. boot base kernel linux > PASS > 11. kernel build on SMP linux guestPASS > 12. LTP on linux guest > PASS > 13. boot Windows 2000 without ACPI PASS > 14. boot Windows 2000 with ACPI enabled PASS > 15. boot Windows 2003 with ACPI enabled PASS > 16. boot Windows xp with ACPI enabled PASS > 17. boot Windows vista with ACPI enabled PASS > 18. boot SMP Windows 2000 with ACPI enabled PASS > 19. boot SMP Windows 2003 with ACPI enabled PASS > 20. boot SMP Windows xp with ACPI enabled PASS > 21. boot SMP Windows 2008 with ACPI enabled PASS > > > IA32e: 1. boot 32-bit guest with 256M > memory PASS > 2. boot 64-bit guest with 256M memory PASS > 3. boot 32-bit guest with 1500M memory PASS > 4. boot 64-bit guest with 1500M memory PASS > 5. boot 4G pae > guest PASS > 6. boot 4G 64-bit > guest PASS > 7. boot four 32-bit guest in > parallel PASS > 8. boot four 64-bit guest in > parallel PASS > 9. boot two 32-bit windows xp in parallel PASS > 10. boot 32-bit linux and 32 bit windows guest in parallel PASS > 11. boot four 32-bit different guest in para > PASS > 12. save/restore 32-bit linux guests > PASS > 13. save/restore 64-bit linux guests > PASS > 14. save/restore 64-bit linux guests with 4 vcpus PASS > 15. save/restore 32-bit linux guests with 4 vcpus PASS > 16. live migration 64bit linux > guests PASS > 17. live migration 32bit linux > guests PASS > 18. live migration 64bit linux guests with 4 vcpus PASS > 19. live migration 32bit linux guests with 4 vcpus PASS > 20. boot 32-bit > x-server PASS 21. > kernel build in 32-bit linux guest OS PASS > 22. kernel build in 64-bit linux guest OS PASS > 23. LTP on 32-bit linux guest OS > PASS > 24. LTP on 64-bit linux guest OS > PASS > 25. boot 64-bit guests with ACPI enabled PASS > 26. boot 32-bit Windows 2000 without ACPIPASS > 27. boot 32-bit Windows xp without ACPIPASS > 28. boot 64-bit Windows xp with ACPI enabledPASS > 29. boot 64-bit Windows vist
Re: Failure to boot CDROM with -drive arg
Le mardi 08 juillet 2008 à 09:51 +0100, Daniel P. Berrange a écrit : > On Tue, Jul 08, 2008 at 10:48:18AM +0200, Laurent Vivier wrote: > > Le mardi 08 juillet 2008 à 09:37 +0100, Daniel P. Berrange a écrit : > > > The following two command lines should be identical from the user's > > > point of view: > > > > > > # qemu-kvm -cdrom /home/berrange/boot.iso -boot d -m 500 > > > > > > # qemu-kvm -drive > > > file=/home/berrange/boot.iso,if=ide,media=cdrom,index=2,boot=on -m 500 > > > > > > > "-cdrom /home/berrange/boot.iso" is identical to > > "-drive file=/home/berrange/boot.iso,index=1,media=cdrom" > > > > with if=ide by default. > > > > Could you try you command line without "boot=on" ? > > Yep, that works - so its clearly something todo with the extboot support I think "boot=on" must be used only with device that are not managed by the bios (scsi, virtio-blk, ...). We should modify the command line interface to check that... Laurent -- - [EMAIL PROTECTED] -- "L'avenir ne se prévoit pas, il se prépare." - Maurice Blondel -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Failure to boot CDROM with -drive arg
Le mardi 08 juillet 2008 à 09:37 +0100, Daniel P. Berrange a écrit : > The following two command lines should be identical from the user's > point of view: > > # qemu-kvm -cdrom /home/berrange/boot.iso -boot d -m 500 > > # qemu-kvm -drive > file=/home/berrange/boot.iso,if=ide,media=cdrom,index=2,boot=on -m 500 > "-cdrom /home/berrange/boot.iso" is identical to "-drive file=/home/berrange/boot.iso,index=1,media=cdrom" with if=ide by default. Could you try you command line without "boot=on" ? > With the 2nd though, the initial CDROM syslinux loads, but fails to load > the graphical menu, and also fails to boot in text mode fallback: > > 'vesamenu.c32: attempted DOS system call" > > (See screenshot: https://bugzilla.redhat.com/attachment.cgi?id=311221 ) > > I've reproduced this with both KVM 65 and 70, on a Fedora 9 host. The CDROM > boot.iso image I'm using here is the Fedora 9 $URL/images/boot.iso from > any standard Fedora install tree. > > I can only imagine there's something different in the way extboot sets up > the CPU/pagetables during cdrom boot, but its rather beyond my skills > > This was originally reported by a Fedora user here > > https://bugzilla.redhat.com/show_bug.cgi?id=452355 > > Daniel -- - [EMAIL PROTECTED] -- "L'avenir ne se prévoit pas, il se prépare." - Maurice Blondel -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Use qemu_memalign instead of qemu_malloc
Le mercredi 25 juin 2008 à 16:15 +0200, Kevin Wolf a écrit : > Anthony Liguori schrieb: > > Kevin Wolf wrote: > >> Anthony Liguori schrieb: > >> > >>> I guess the main block code is not as defensive as I thought it was. > >>> This patch > >>> uses qemu_memalign to allocate the buffers for IO so that you don't > >>> get errors > >>> when using O_DIRECT. > >>> > >> > >> Actually, the block code should be able to deal with unaligned buffers > >> since qemu rev. 4599. This change seems to be present in current KVM. > >> > > > > That was what I thought at first too. > > > >> Can you tell exactly which operation failed? > > > > The aio requests fail with -22 (EINVAL). > > Yes, if it fails, the EINVAL is no surprise. I meant what code path it > was using. Obviously we missed something in our patch and I'd like to > fix that. Did the error occur on raw images or something like qcow2? Generally EINVAL with O_DIRECT opened files means there is an alignment problem with offset, buffer address or size to read (must be multiple of 512). Regards, Laurent -- - [EMAIL PROTECTED] --- "The best way to predict the future is to invent it." - Alan Kay -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sharing disks between two kvm guests
Le vendredi 20 juin 2008 à 11:37 -0500, Anthony Liguori a écrit : > Laurent Vivier wrote: > > Le vendredi 20 juin 2008 à 09:07 -0500, Javier Guerra a écrit : > > > >> On Fri, Jun 20, 2008 at 7:23 AM, carlopmart <[EMAIL PROTECTED]> wrote: > >> > >>> Felix Leimbach wrote: > >>> > >>>>> This is my first post to this list. I have already installed kvm-70 > >>>>> under rhel5.2. My intention is to share on disk image betwwen two > >>>>> rhel5.2 > >>>>> kvm guests. Is it possible to accomplish this in kvm like xen or vmware > >>>>> does?? How can I do?? I didn't find any reference abou this on kvm > >>>>> documentation ... > >>>>> > >> i tried this looong ago and didn't really work because there was some > >> userspace cache on each QEMU instance. but the -drive option has a > >> 'cache=off' setting that should be enough. > >> > >> in theory (i haven't tested, but Avi 'blessed' it): > >> - create a new image with qemu-img > >> - add it to the command line using -drive file=xxx,cache=off on both > >> KVM instances > >> - use a cluster filesystem! > >> > > > > RFC: > > > > Well, well, perhaps it is delusions of a sick mind but since the > > introduction of qemu-nbd I think we can develop easily something to > > share a disk between several virtual hosts: > > > > I- in a first step, we can modify qemu-nbd to accept several connections > > for one disk image, for instance: > > > > # qemu-nbd my-disk.qcow2 > > # nbd-client localhost 1024 /dev/nbd0 > > # nbd-client localhost 1024 /dev/nbd1 > > > > and start two virtual hosts: > > > > "qemu -hda v1.img -hdb /dev/nbd0" and "qemu -hda v2.img -hdb /dev/nbd1" > > > > Of course the filesystem must know how to share the access to the disk > > with others (-> "cluster filesystem") > > > > II- in a second step, we can include directly the nbd protocol in qemu > > (block-nbd.c, "-drive file=nbd:localhost:1024") to connect to the > > server. We can also add some commands to the protocol to manage lock, > > HA, "what else ?" (Hi George). > > > > http://hg.codemonkey.ws/qemu-pq/file/25ca451f2040/block-nbd.diff You're not fun, Anthony. Perhaps, now, it should be better if you use functions defined in the (new) file "nbd.c". Laurent > Regards, > > Anthony Liguori > > > Any comments ? > > > > Cheers, > > Laurent > > > > -- - [EMAIL PROTECTED] --- "The best way to predict the future is to invent it." - Alan Kay -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sharing disks between two kvm guests
Le vendredi 20 juin 2008 à 09:07 -0500, Javier Guerra a écrit : > On Fri, Jun 20, 2008 at 7:23 AM, carlopmart <[EMAIL PROTECTED]> wrote: > > Felix Leimbach wrote: > >> > >>> This is my first post to this list. I have already installed kvm-70 > >>> under rhel5.2. My intention is to share on disk image betwwen two rhel5.2 > >>> kvm guests. Is it possible to accomplish this in kvm like xen or vmware > >>> does?? How can I do?? I didn't find any reference abou this on kvm > >>> documentation ... > > i tried this looong ago and didn't really work because there was some > userspace cache on each QEMU instance. but the -drive option has a > 'cache=off' setting that should be enough. > > in theory (i haven't tested, but Avi 'blessed' it): > - create a new image with qemu-img > - add it to the command line using -drive file=xxx,cache=off on both > KVM instances > - use a cluster filesystem! RFC: Well, well, perhaps it is delusions of a sick mind but since the introduction of qemu-nbd I think we can develop easily something to share a disk between several virtual hosts: I- in a first step, we can modify qemu-nbd to accept several connections for one disk image, for instance: # qemu-nbd my-disk.qcow2 # nbd-client localhost 1024 /dev/nbd0 # nbd-client localhost 1024 /dev/nbd1 and start two virtual hosts: "qemu -hda v1.img -hdb /dev/nbd0" and "qemu -hda v2.img -hdb /dev/nbd1" Of course the filesystem must know how to share the access to the disk with others (-> "cluster filesystem") II- in a second step, we can include directly the nbd protocol in qemu (block-nbd.c, "-drive file=nbd:localhost:1024") to connect to the server. We can also add some commands to the protocol to manage lock, HA, "what else ?" (Hi George). Any comments ? Cheers, Laurent -- - [EMAIL PROTECTED] -- "In short: just say NO TO DRUGS and maybe you won't end up like the Hurd people." -- Linus Torvald -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ROM][v2] virtio-net etherboot ROM
Le mercredi 18 juin 2008 à 06:26 -0700, Avi Kivity a écrit : > Laurent Vivier wrote: > > This new version of virtio-net etherboot ROM clears the ISR on reset, > > and thus allows linux to use it again (on Qemu/KVM). > > > > What's the status of upstreaming this? Didn't see it on etherboot.git. I have no answer from etherboot maintainers... Regards, Laurent -- - [EMAIL PROTECTED] --- "The best way to predict the future is to invent it." - Alan Kay -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] libkvm: export init for coalesced MMIO support
Le mercredi 18 juin 2008 à 00:22 -0500, Carlo Marcelo Arenas Belon a écrit : > complement 2680f3df932a3119880a692609943587ecc8f409 to export the > definition for kvm_init_coalesced_mmio as it is used by the per > arch libkvm as shown by the following warning : > > libkvm-x86.c: In function 'kvm_arch_create': > libkvm-x86.c:182: warning: implicit declaration of function > 'kvm_init_coalesced_mmio' > > Signed-off-by: Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> Looks good for me. Laurent > --- > libkvm/libkvm.h |9 + > 1 files changed, 9 insertions(+), 0 deletions(-) > > diff --git a/libkvm/libkvm.h b/libkvm/libkvm.h > index a33e9db..4fd8587 100644 > --- a/libkvm/libkvm.h > +++ b/libkvm/libkvm.h > @@ -576,6 +576,15 @@ int kvm_set_lapic(kvm_context_t kvm, int vcpu, struct > kvm_lapic_state *s); > */ > int kvm_pit_in_kernel(kvm_context_t kvm); > > +/*! > + * \brief Initialize coalesced MMIO > + * > + * Check for coalesced MMIO capability and store in context > + * > + * \param kvm Pointer to the current kvm_context > + */ > +int kvm_init_coalesced_mmio(kvm_context_t kvm); > + > #ifdef KVM_CAP_PIT > > #if defined(__i386__) || defined(__x86_64__) -- - [EMAIL PROTECTED] --- "The best way to predict the future is to invent it." - Alan Kay -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ kvm-Bugs-1985977 ] Guests crash while rebooting
Le lundi 16 juin 2008 à 14:29 -0300, Marcelo Tosatti a écrit : > On Mon, Jun 16, 2008 at 03:31:10PM +0200, Laurent Vivier wrote: > > Le samedi 14 juin 2008 à 12:12 -0700, Avi Kivity a écrit : > > > Laurent Vivier wrote: > > > > Perhaps you can re-apply 36742c5470 ? > > > > > > > > > > As it's not 100% reliable, I prefer to wait until it is fixed. > > > > I'm not able to reproduce the failure we met originally. > > Could you ? > > > > Did you make a change which could correct this ? > > FreeBSD 7.0 LIVECD reboot "reliably crashes": I was speaking about instability noticed by Anthony on ubuntu-7 boot: "There still seems to be an issue with this series. When running: sudo qemu-system-x86_64 -hda ./10gig.img -snapshot -cdrom isos/ubuntu-7.10-server-amd64.iso -boot dc Occassionally, I'll get: kvm_run: failed entry, reason 5 kvm_run returned -8" which was introduced by commit 36742c5470 not about the crash while rebooting (but this patch has been reverted because of it). Regards, Laurent -- - [EMAIL PROTECTED] --- "The best way to predict the future is to invent it." - Alan Kay -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ kvm-Bugs-1985977 ] Guests crash while rebooting
Le samedi 14 juin 2008 à 12:12 -0700, Avi Kivity a écrit : > Laurent Vivier wrote: > > Perhaps you can re-apply 36742c5470 ? > > > > As it's not 100% reliable, I prefer to wait until it is fixed. I'm not able to reproduce the failure we met originally. Could you ? Did you make a change which could correct this ? Regards, Laurent -- - [EMAIL PROTECTED] --- "The best way to predict the future is to invent it." - Alan Kay -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ kvm-Bugs-1985977 ] Guests crash while rebooting
Le samedi 14 juin 2008 à 11:58 -0700, Avi Kivity a écrit : > Yunfeng Zhao wrote: > > > >> Date: 2008-06-12 16:26 > >> > >> Message: > >> Logged In: YES user_id=539971 > >> Originator: NO > >> > >> Okay, I reverted the patch. > >> > > Avi, > > > > The issue still exists on our nightly testing machine even after > > reverted the pmode transition patch. > > Okay, I think I found the real problem. I just pushed 3a82930aa403 > which ought to fix this. > Perhaps you can re-apply 36742c5470 ? Laurent -- - [EMAIL PROTECTED] --- "The best way to predict the future is to invent it." - Alan Kay -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ROM][v2] virtio-net etherboot ROM
This new version of virtio-net etherboot ROM clears the ISR on reset, and thus allows linux to use it again (on Qemu/KVM). Laurent -- - [EMAIL PROTECTED] --- "The best way to predict the future is to invent it." - Alan Kay pxe-virtio.bin Description: Binary data
[PATCH] [v2] etherboot: add virtio-net driver
This patch allows to boot from network using the virtio-net adapter
provided by KVM.
It applies on etherboot-5.4 sources from
git://git.etherboot.org/scm/etherboot.git
Changelog:
v2: Clear ISR on reset, some cosmetic changes, implement virtnet_irq().
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
src/Families |5 +
src/drivers/net/virtio-net.c | 493 +
src/drivers/net/virtio-net.h | 44
src/drivers/net/virtio-pci.h | 96
src/drivers/net/virtio-ring.h | 93
5 files changed, 731 insertions(+), 0 deletions(-)
create mode 100644 src/drivers/net/virtio-net.c
create mode 100644 src/drivers/net/virtio-net.h
create mode 100644 src/drivers/net/virtio-pci.h
create mode 100644 src/drivers/net/virtio-ring.h
diff --git a/src/Families b/src/Families
index ee47d13..160c4ee 100644
--- a/src/Families
+++ b/src/Families
@@ -148,3 +148,8 @@ family drivers/net/mlx_ipoib/mt25218
family drivers/net/via-velocity
family drivers/net/etherfabric
+
+# KVM virtio
+
+family drivers/net/virtio-net
+virtio-net - Virtio Network Interface
diff --git a/src/drivers/net/virtio-net.c b/src/drivers/net/virtio-net.c
new file mode 100644
index 000..4cecefc
--- /dev/null
+++ b/src/drivers/net/virtio-net.c
@@ -0,0 +1,493 @@
+/* virtio-net.c - etherboot driver for virtio network interface
+ *
+ * (c) Copyright 2008 Bull S.A.S.
+ *
+ * Author: Laurent Vivier <[EMAIL PROTECTED]>
+ *
+ * some parts from Linux Virtio PCI driver
+ *
+ * Copyright IBM Corp. 2007
+ * Authors: Anthony Liguori <[EMAIL PROTECTED]>
+ *
+ * some parts from Linux Virtio Ring
+ *
+ * Copyright Rusty Russell IBM Corporation 2007
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ *
+ */
+
+#include "etherboot.h"
+#include "pci.h"
+#include "nic.h"
+#include "timer.h"
+#include "virtio-ring.h"
+#include "virtio-pci.h"
+#include "virtio-net.h"
+
+#define BUG() do { \
+ printf("BUG: failure at %s:%d/%s()!\n", \
+ __FILE__, __LINE__, __FUNCTION__); \
+ while(1); \
+} while (0)
+#define BUG_ON(condition) do { if (condition) BUG(); } while (0)
+
+/* Ethernet header */
+
+struct eth_hdr {
+ unsigned char dst_addr[ETH_ALEN];
+ unsigned char src_addr[ETH_ALEN];
+ unsigned short type;
+};
+
+struct eth_frame {
+ struct eth_hdr hdr;
+ unsigned char data[ETH_MAX_MTU];
+};
+
+typedef unsigned char virtio_queue_t[PAGE_MASK + vring_size(MAX_QUEUE_NUM)];
+
+/* TX: virtio header and eth buffer */
+
+static struct virtio_net_hdr tx_virtio_hdr;
+static struct eth_frame tx_eth_frame;
+
+/* RX: virtio headers and buffers */
+
+#define RX_BUF_NB 6
+static struct virtio_net_hdr rx_hdr[RX_BUF_NB];
+static unsigned char rx_buffer[RX_BUF_NB][ETH_FRAME_LEN];
+
+/* virtio queues and vrings */
+
+enum {
+ RX_INDEX = 0,
+ TX_INDEX,
+ QUEUE_NB
+};
+
+static virtio_queue_t queue[QUEUE_NB];
+static struct vring vring[QUEUE_NB];
+static u16 free_head[QUEUE_NB];
+static u16 last_used_idx[QUEUE_NB];
+static u16 vdata[QUEUE_NB][MAX_QUEUE_NUM];
+
+/*
+ * Virtio PCI interface
+ *
+ */
+
+static int vp_find_vq(struct nic *nic, int queue_index)
+{
+ struct vring * vr = &vring[queue_index];
+ u16 num;
+
+ /* select the queue */
+
+ outw(queue_index, nic->ioaddr + VIRTIO_PCI_QUEUE_SEL);
+
+ /* check if the queue is available */
+
+ num = inw(nic->ioaddr + VIRTIO_PCI_QUEUE_NUM);
+ if (!num) {
+ printf("ERROR: queue size is 0\n");
+ return -1;
+ }
+
+ if (num > MAX_QUEUE_NUM) {
+ printf("ERROR: queue size %d > %d\n", num, MAX_QUEUE_NUM);
+ return -1;
+ }
+
+ /* check if the queue is already active */
+
+ if (inl(nic->ioaddr + VIRTIO_PCI_QUEUE_PFN)) {
+ printf("ERROR: queue already active\n");
+ return -1;
+ }
+
+ /* initialize the queue */
+
+ vring_init(vr, num, (unsigned char*)&queue[queue_index]);
+
+ /* activate the queue
+*
+* NOTE: vr->desc is initialized by vring_init()
+*/
+
+ outl((unsigned long)virt_to_phys(vr->desc) >> PAGE_SHIFT,
+nic->ioaddr + VIRTIO_PCI_QUEUE_PFN);
+
+ return num;
+}
+
+/*
+ * Virtual ring management
+ *
+ */
+
+static void vring_enable_cb(int queue_index)
+{
+ vring[queue_index].avail->flags &= ~VRING_AVAIL_F_NO_INTERRUPT;
+}
+
+static void vring_disable_cb(int queue_index)
+{
+ vring[queue_index].avail->flags |= VRING_AVAIL_F_NO_INTERRUPT;
+}
+
+/*
+ * vring_free
+ *
+ * put at the begin of the free list the current desc[head]
+ */
+
+sta
Re: VT enabled in BIOS, still kvm says 'disabled by bios'
Hi, You need to go through a power-down/power-up cycle. (See the help associated with the flag in the BIOS) Laurent Le jeudi 12 juin 2008 à 16:04 +0530, Sukanto Ghosh a écrit : > Hi all, > > On my system: > > Processor: Intel Core 2 Duo 6300 1.86 GHz > Motherboard: Intel DG965RY > OS: Ubuntu 7.10 (Gutsy) > Linux Kernel: 2.6.22-14-generic > BIOS has VT technology 'enable/disable' feature. > > 'cat /proc/cpuinfo' shows 'vmx' flags. > I checked and enabled the VT support in the BIOS. > > 'modprobe kvm' runs fine. > But still 'modprobe kvm_intel' gives 'operation not supported' error. > > (I issued both of them after 'su') > > After looking into the /var/log/syslog, file I found that the message is > 'kvm: disabled by bios'. > > > I am puzzled, please help me out. What's going wrong ? > > > > Thanks and Regards, > > Sukanto Ghosh > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- - [EMAIL PROTECTED] --- "The best way to predict the future is to invent it." - Alan Kay -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] call virtio_update_irq() to clear irq according isr
if we clear vdev->isr, it seems logic to call virtio_update_irq(vdev) to
update irq.
The bug appears when we boot with etherboot virtio driver which
never read the interrupt status and so never clear it.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
qemu/hw/virtio.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/qemu/hw/virtio.c b/qemu/hw/virtio.c
index 2ea1ebe..3429ac8 100644
--- a/qemu/hw/virtio.c
+++ b/qemu/hw/virtio.c
@@ -214,6 +214,7 @@ void virtio_reset(void *opaque)
vdev->queue_sel = 0;
vdev->status = 0;
vdev->isr = 0;
+virtio_update_irq(vdev);
for(i = 0; i < VIRTIO_PCI_QUEUE_MAX; i++) {
vdev->vq[i].vring.desc = NULL;
--
1.5.2.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ROM] virtio-net etherboot ROM
You can find attached to this e-mail an etherboot ROM supporting virtio-net device. Laurent -- - [EMAIL PROTECTED] --- "The best way to predict the future is to invent it." - Alan Kay pxe-virtio.bin Description: Binary data
[PATCH] Add virtio-net driver
This patch allows to boot from network using the virtio-net adapter
provided by KVM.
It applies on etherboot-5.4 sources from
git://git.etherboot.org/scm/etherboot.git
[why etherboot-5.4 ?
because it doesn't hang like gPXE and ROM size is only 32 KB]
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
src/Families |5 +
src/drivers/net/virtio-net.c | 476 +
src/drivers/net/virtio-net.h | 41
src/drivers/net/virtio-pci.h | 91
src/drivers/net/virtio-ring.h | 90
5 files changed, 703 insertions(+), 0 deletions(-)
create mode 100644 src/drivers/net/virtio-net.c
create mode 100644 src/drivers/net/virtio-net.h
create mode 100644 src/drivers/net/virtio-pci.h
create mode 100644 src/drivers/net/virtio-ring.h
diff --git a/src/Families b/src/Families
index ee47d13..160c4ee 100644
--- a/src/Families
+++ b/src/Families
@@ -148,3 +148,8 @@ family drivers/net/mlx_ipoib/mt25218
family drivers/net/via-velocity
family drivers/net/etherfabric
+
+# KVM virtio
+
+family drivers/net/virtio-net
+virtio-net - Virtio Network Interface
diff --git a/src/drivers/net/virtio-net.c b/src/drivers/net/virtio-net.c
new file mode 100644
index 000..db7bdae
--- /dev/null
+++ b/src/drivers/net/virtio-net.c
@@ -0,0 +1,476 @@
+/* virtnet.c - etherboot driver for virtio network interface
+ *
+ * (c) Copyright 2008 Bull S.A.S.
+ *
+ * Author: Laurent Vivier <[EMAIL PROTECTED]>
+ *
+ * some parts from Linux Virtio PCI driver
+ *
+ * Copyright IBM Corp. 2007
+ * Authors: Anthony Liguori <[EMAIL PROTECTED]>
+ *
+ * some parts from Linux Virtio Ring
+ *
+ * Copyright Rusty Russell IBM Corporation 2007
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ *
+ */
+
+#include "etherboot.h"
+#include "pci.h"
+#include "nic.h"
+#include "timer.h"
+#include "virtio-ring.h"
+#include "virtio-pci.h"
+#include "virtio-net.h"
+
+#define BUG() do { \
+ printf("BUG: failure at %s:%d/%s()!\n", \
+ __FILE__, __LINE__, __FUNCTION__); \
+ while(1); \
+} while (0)
+#define BUG_ON(condition) do { if (condition) BUG(); } while (0)
+
+/* Ethernet header */
+
+struct eth_hdr {
+ unsigned char dst_addr[ETH_ALEN];
+ unsigned char src_addr[ETH_ALEN];
+ unsigned short type;
+};
+
+struct eth_frame {
+ struct eth_hdr hdr;
+ unsigned char data[ETH_MAX_MTU];
+};
+
+typedef unsigned char virtio_queue_t[PAGE_MASK + vring_size(MAX_QUEUE_NUM)];
+
+/* TX: virtio header and eth buffer */
+
+static struct virtio_net_hdr tx_virtio_hdr;
+static struct eth_frame tx_eth_frame;
+
+/* RX: virtio headers and buffers */
+
+#define RX_BUF_NB 6
+static struct virtio_net_hdr rx_hdr[RX_BUF_NB];
+static unsigned char rx_buffer[RX_BUF_NB][ETH_FRAME_LEN];
+
+/* virtio queues and vrings */
+
+enum {
+ RX_INDEX = 0,
+ TX_INDEX,
+ QUEUE_NB
+};
+
+static virtio_queue_t queue[QUEUE_NB];
+static struct vring vring[QUEUE_NB];
+static u16 free_head[QUEUE_NB];
+static u16 last_used_idx[QUEUE_NB];
+static u16 vdata[QUEUE_NB][MAX_QUEUE_NUM];
+
+/*
+ * Virtio PCI interface
+ *
+ */
+
+static int vp_find_vq(struct nic *nic, int queue_index)
+{
+ struct vring * vr = &vring[queue_index];
+ u16 num;
+
+ /* select the queue */
+
+ outw(queue_index, nic->ioaddr + VIRTIO_PCI_QUEUE_SEL);
+
+ /* check if the queue is available */
+
+ num = inw(nic->ioaddr + VIRTIO_PCI_QUEUE_NUM);
+ if (!num) {
+ printf("ERROR: queue size is 0\n");
+ return -1;
+ }
+
+ if (num > MAX_QUEUE_NUM) {
+ printf("ERROR: queue size %d > %d\n", num, MAX_QUEUE_NUM);
+ return -1;
+ }
+
+ /* check if the queue is already active */
+
+ if (inl(nic->ioaddr + VIRTIO_PCI_QUEUE_PFN)) {
+ printf("ERROR: queue already active\n");
+ return -1;
+ }
+
+ /* initialize the queue */
+
+ vring_init(vr, num, (unsigned char*)&queue[queue_index]);
+
+ /* activate the queue
+*
+* NOTE: vr->desc is initialized by vring_init()
+*/
+
+ outl((unsigned long)virt_to_phys(vr->desc) >> PAGE_SHIFT,
+nic->ioaddr + VIRTIO_PCI_QUEUE_PFN);
+
+ return num;
+}
+
+/*
+ * Virtual ring management
+ *
+ */
+
+static void vring_disable_cb(int queue_index)
+{
+ vring[queue_index].avail->flags |= VRING_AVAIL_F_NO_INTERRUPT;
+}
+
+/*
+ * vring_free
+ *
+ * put at the begin of the free list the current desc[head]
+ */
+
+static void vring_detach(int queue_index, unsigned int head)
+{
+ struct vring *vr = &vring[queue_index];
+unsigned int i;
[PATCH 6/7] qemu: coalesced MMIO support (VGA)
This patch defines coalesced MMIO zones for VGA cards.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
qemu/hw/cirrus_vga.c |2 ++
qemu/hw/vga.c|4
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/qemu/hw/cirrus_vga.c b/qemu/hw/cirrus_vga.c
index 2c4aeec..1e36446 100644
--- a/qemu/hw/cirrus_vga.c
+++ b/qemu/hw/cirrus_vga.c
@@ -3291,6 +3291,8 @@ static void cirrus_init_common(CirrusVGAState * s, int
device_id, int is_pci)
cirrus_vga_mem_write, s);
cpu_register_physical_memory(isa_mem_base + 0x000a, 0x2,
vga_io_memory);
+if (kvm_enabled())
+qemu_kvm_register_coalesced_mmio(isa_mem_base + 0x000a, 0x2);
s->sr[0x06] = 0x0f;
if (device_id == CIRRUS_ID_CLGD5446) {
diff --git a/qemu/hw/vga.c b/qemu/hw/vga.c
index 3a49573..52749e3 100644
--- a/qemu/hw/vga.c
+++ b/qemu/hw/vga.c
@@ -2257,6 +2257,8 @@ void vga_init(VGAState *s)
vga_io_memory = cpu_register_io_memory(0, vga_mem_read, vga_mem_write, s);
cpu_register_physical_memory(isa_mem_base + 0x000a, 0x2,
vga_io_memory);
+if (kvm_enabled())
+qemu_kvm_register_coalesced_mmio(isa_mem_base + 0x000a, 0x2);
}
/* Memory mapped interface */
@@ -2332,6 +2334,8 @@ static void vga_mm_init(VGAState *s, target_phys_addr_t
vram_base,
cpu_register_physical_memory(ctrl_base, 0x10, s_ioport_ctrl);
s->bank_offset = 0;
cpu_register_physical_memory(vram_base + 0x000a, 0x2,
vga_io_memory);
+if (kvm_enabled())
+qemu_kvm_register_coalesced_mmio(vram_base + 0x000a, 0x2);
}
int isa_vga_init(DisplayState *ds, uint8_t *vga_ram_base,
--
1.5.2.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] qemu: coalesced MMIO support (e1000)
This patch defines coalesced MMIO zones for e1000 ethernet card.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
qemu/hw/e1000.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/qemu/hw/e1000.c b/qemu/hw/e1000.c
index 01f8983..5b3a365 100644
--- a/qemu/hw/e1000.c
+++ b/qemu/hw/e1000.c
@@ -26,6 +26,7 @@
#include "hw.h"
#include "pci.h"
#include "net.h"
+#include "qemu-kvm.h"
#include "e1000_hw.h"
@@ -938,6 +939,18 @@ e1000_mmio_map(PCIDevice *pci_dev, int region_num,
d->mmio_base = addr;
cpu_register_physical_memory(addr, PNPMMIO_SIZE, d->mmio_index);
+
+if (kvm_enabled()) {
+ int i;
+uint32_t excluded_regs[] = {
+E1000_MDIC, E1000_ICR, E1000_ICS, E1000_IMS,
+E1000_IMC, E1000_TCTL, E1000_TDT, PNPMMIO_SIZE
+};
+qemu_kvm_register_coalesced_mmio(addr, excluded_regs[0]);
+for (i = 0; excluded_regs[i] != PNPMMIO_SIZE; i++)
+qemu_kvm_register_coalesced_mmio(addr + excluded_regs[i] + 4,
+ excluded_regs[i + 1] - excluded_regs[i] - 4);
+}
}
static int
--
1.5.2.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] qemu: coalesced MMIO support (core)
This patch introduces in qemu the coalesced MMIO.
It defines qemu_kvm_register_coalesced_mmio() and
qemu_kvm_unregister_coalesced_mmio() to register and unregister coalesced MMIO
zone.
It calls qemu_kvm_unregister_coalesced_mmio() on pci_update_mappings().
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
qemu/hw/pci.c |4
qemu/qemu-kvm.c | 11 +++
qemu/qemu-kvm.h |4
3 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/qemu/hw/pci.c b/qemu/hw/pci.c
index a23a466..92683d1 100644
--- a/qemu/hw/pci.c
+++ b/qemu/hw/pci.c
@@ -26,6 +26,7 @@
#include "console.h"
#include "net.h"
#include "pc.h"
+#include "qemu-kvm.h"
//#define DEBUG_PCI
@@ -323,6 +324,9 @@ static void pci_update_mappings(PCIDevice *d)
cpu_register_physical_memory(pci_to_cpu_addr(r->addr),
r->size,
IO_MEM_UNASSIGNED);
+if (kvm_enabled())
+qemu_kvm_unregister_coalesced_mmio(r->addr,
+ r->size);
}
}
r->addr = new_addr;
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
index 5398e53..8adf24b 100644
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -1023,3 +1023,14 @@ void kvm_mutex_lock(void)
pthread_mutex_lock(&qemu_mutex);
cpu_single_env = NULL;
}
+
+int qemu_kvm_register_coalesced_mmio(target_phys_addr_t addr, unsigned int
size)
+{
+return kvm_register_coalesced_mmio(kvm_context, addr, size);
+}
+
+int qemu_kvm_unregister_coalesced_mmio(target_phys_addr_t addr,
+ unsigned int size)
+{
+return kvm_unregister_coalesced_mmio(kvm_context, addr, size);
+}
diff --git a/qemu/qemu-kvm.h b/qemu/qemu-kvm.h
index 7412e20..8b7dcde 100644
--- a/qemu/qemu-kvm.h
+++ b/qemu/qemu-kvm.h
@@ -76,6 +76,10 @@ int handle_tpr_access(void *opaque, int vcpu,
void kvm_tpr_vcpu_start(CPUState *env);
int qemu_kvm_get_dirty_pages(unsigned long phys_addr, void *buf);
+int qemu_kvm_register_coalesced_mmio(target_phys_addr_t addr,
+unsigned int size);
+int qemu_kvm_unregister_coalesced_mmio(target_phys_addr_t addr,
+ unsigned int size);
void qemu_kvm_system_reset_request(void);
--
1.5.2.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] libkvm: coalesced MMIO support (x86 part)
This patch enables coalesced MMIO for x86 architecture.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
libkvm/kvm-x86.h|2 ++
libkvm/libkvm-x86.c |4
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/libkvm/kvm-x86.h b/libkvm/kvm-x86.h
index 1dccf64..e988cb7 100644
--- a/libkvm/kvm-x86.h
+++ b/libkvm/kvm-x86.h
@@ -50,4 +50,6 @@ int kvm_disable_tpr_access_reporting(kvm_context_t kvm, int
vcpu);
#endif
+#define smp_wmb() asm volatile("" ::: "memory")
+
#endif
diff --git a/libkvm/libkvm-x86.c b/libkvm/libkvm-x86.c
index d46fdcc..ea97bdd 100644
--- a/libkvm/libkvm-x86.c
+++ b/libkvm/libkvm-x86.c
@@ -179,6 +179,10 @@ int kvm_arch_create(kvm_context_t kvm, unsigned long
phys_mem_bytes,
if (r < 0)
return r;
+ r = kvm_init_coalesced_mmio(kvm);
+ if (r < 0)
+ return r;
+
return 0;
}
--
1.5.2.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] libkvm: coalesced MMIO support (powerpc part)
This patch enables coalesced MMIO for powerpc architecture.
WARNING: this has not been tested.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
libkvm/kvm-powerpc.h|7 +++
libkvm/libkvm-powerpc.c |6 ++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/libkvm/kvm-powerpc.h b/libkvm/kvm-powerpc.h
index 77aee54..b09511c 100644
--- a/libkvm/kvm-powerpc.h
+++ b/libkvm/kvm-powerpc.h
@@ -26,4 +26,11 @@ extern int kvm_page_size;
#define PAGE_SIZE kvm_page_size
#define PAGE_MASK (~(PAGE_SIZE - 1))
+static inline void eieio(void)
+{
+ asm volatile("eieio" : : : "memory");
+}
+
+#define smp_wmb() eieio()
+
#endif
diff --git a/libkvm/libkvm-powerpc.c b/libkvm/libkvm-powerpc.c
index 53a2478..376aca4 100644
--- a/libkvm/libkvm-powerpc.c
+++ b/libkvm/libkvm-powerpc.c
@@ -93,6 +93,12 @@ void kvm_show_regs(kvm_context_t kvm, int vcpu)
int kvm_arch_create(kvm_context_t kvm, unsigned long phys_mem_bytes,
void **vm_mem)
{
+ int r;
+
+ r = kvm_init_coalesced_mmio(kvm);
+ if (r < 0)
+ return r;
+
return 0;
}
--
1.5.2.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] libkvm: coalesced support (ia64 part)
This patch enables coalesced MMIO for ia64 architecture.
WARNING: this has not been tested.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
libkvm/kvm-ia64.h|3 +++
libkvm/libkvm-ia64.c |6 ++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/libkvm/kvm-ia64.h b/libkvm/kvm-ia64.h
index 304496d..ad87ae7 100644
--- a/libkvm/kvm-ia64.h
+++ b/libkvm/kvm-ia64.h
@@ -25,4 +25,7 @@ extern int kvm_page_size;
#define PAGE_SIZE kvm_page_size
#define PAGE_MASK (~(kvm_page_size - 1))
+#define ia64_mf() asm volatile ("mf" ::: "memory")
+#define smp_wmb() ia64_mf()
+
#endif
diff --git a/libkvm/libkvm-ia64.c b/libkvm/libkvm-ia64.c
index d7477d0..f35a16c 100644
--- a/libkvm/libkvm-ia64.c
+++ b/libkvm/libkvm-ia64.c
@@ -67,6 +67,12 @@ void *kvm_create_kernel_phys_mem(kvm_context_t kvm, unsigned
long phys_start,
int kvm_arch_create(kvm_context_t kvm, unsigned long phys_mem_bytes,
void **vm_mem)
{
+ int r;
+
+ r = kvm_init_coalesced_mmio(kvm);
+ if (r < 0)
+ return r;
+
return 0;
}
--
1.5.2.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] libkvm: coalesced MMIO support (common part)
This patch introduces in libkvm the common part of coalesced MMIO interface.
It checks the coalesced MMIO availability with ioctl(KVM_CHECK_EXTENSION).
If KVM_CAP_COALESCED_MMIO is available, it processes the MMIO ring buffer
at the return of ioctl(KVM_RUN).
It defines kvm_register_coalesced_mmio() to register a coalesced MMIO zone, and
kvm_unregister_coalesced_mmio() to unregister it.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
libkvm/kvm-common.h |2 +
libkvm/libkvm.c | 75 +++
libkvm/libkvm.h |4 +++
3 files changed, 81 insertions(+), 0 deletions(-)
diff --git a/libkvm/kvm-common.h b/libkvm/kvm-common.h
index a3549e2..9780fb8 100644
--- a/libkvm/kvm-common.h
+++ b/libkvm/kvm-common.h
@@ -49,6 +49,8 @@ struct kvm_context {
int no_pit_creation;
/// in-kernel pit status
int pit_in_kernel;
+ /// in-kernel coalesced mmio
+ int coalesced_mmio;
};
void init_slots(void);
diff --git a/libkvm/libkvm.c b/libkvm/libkvm.c
index d1e95a4..1e7bbed 100644
--- a/libkvm/libkvm.c
+++ b/libkvm/libkvm.c
@@ -879,6 +879,22 @@ again:
post_kvm_run(kvm, vcpu);
+#if defined(KVM_CAP_COALESCED_MMIO)
+ if (kvm->coalesced_mmio) {
+ struct kvm_coalesced_mmio_ring *ring = (void *)run +
+ kvm->coalesced_mmio * PAGE_SIZE;
+ while (ring->first != ring->last) {
+ kvm->callbacks->mmio_write(kvm->opaque,
+ring->coalesced_mmio[ring->first].phys_addr,
+ &ring->coalesced_mmio[ring->first].data[0],
+ring->coalesced_mmio[ring->first].len);
+ smp_wmb();
+ ring->first = (ring->first + 1) %
+ KVM_COALESCED_MMIO_MAX;
+ }
+ }
+#endif
+
if (r == -1) {
r = handle_io_window(kvm);
goto more;
@@ -983,3 +999,62 @@ int kvm_pit_in_kernel(kvm_context_t kvm)
{
return kvm->pit_in_kernel;
}
+
+int kvm_init_coalesced_mmio(kvm_context_t kvm)
+{
+ int r = 0;
+ kvm->coalesced_mmio = 0;
+#ifdef KVM_CAP_COALESCED_MMIO
+ r = ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_COALESCED_MMIO);
+ if (r > 0) {
+ kvm->coalesced_mmio = r;
+ return 0;
+ }
+#endif
+ return r;
+}
+
+int kvm_register_coalesced_mmio(kvm_context_t kvm, uint64_t addr, uint32_t
size)
+{
+#ifdef KVM_CAP_COALESCED_MMIO
+ struct kvm_coalesced_mmio_zone zone;
+ int r;
+
+ if (kvm->coalesced_mmio) {
+
+ zone.addr = addr;
+ zone.size = size;
+
+ r = ioctl(kvm->vm_fd, KVM_REGISTER_COALESCED_MMIO, &zone);
+ if (r == -1) {
+ perror("kvm_register_coalesced_mmio_zone");
+ return -errno;
+ }
+ return 0;
+ }
+#endif
+ return -ENOSYS;
+}
+
+int kvm_unregister_coalesced_mmio(kvm_context_t kvm, uint64_t addr, uint32_t
size)
+{
+#ifdef KVM_CAP_COALESCED_MMIO
+ struct kvm_coalesced_mmio_zone zone;
+ int r;
+
+ if (kvm->coalesced_mmio) {
+
+ zone.addr = addr;
+ zone.size = size;
+
+ r = ioctl(kvm->vm_fd, KVM_UNREGISTER_COALESCED_MMIO, &zone);
+ if (r == -1) {
+ perror("kvm_unregister_coalesced_mmio_zone");
+ return -errno;
+ }
+ return 0;
+ }
+#endif
+ return -ENOSYS;
+}
+
diff --git a/libkvm/libkvm.h b/libkvm/libkvm.h
index 63183b8..a33e9db 100644
--- a/libkvm/libkvm.h
+++ b/libkvm/libkvm.h
@@ -457,6 +457,10 @@ int kvm_get_dirty_pages_range(kvm_context_t kvm, unsigned
long phys_addr,
unsigned long end_addr, void *buf, void*opaque,
int (*cb)(unsigned long start, unsigned long len,
void*bitmap, void *opaque));
+int kvm_register_coalesced_mmio(kvm_context_t kvm,
+ uint64_t addr, uint32_t size);
+int kvm_unregister_coalesced_mmio(kvm_context_t kvm,
+ uint64_t addr, uint32_t size);
/*!
* \brief Create a memory alias
--
1.5.2.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] kvm-userspace: Batch writes to MMIO
When kernel has to send MMIO writes to userspace, it stores them in memory until it has to pass the hand to userspace for another reason. This avoids to have too many context switches on operations that can wait. [PATCH 1/7] libkvm: coalesced MMIO support (common part) This patch introduces in libkvm the common part of coalesced MMIO interface. [PATCH 2/7] libkvm: coalesced MMIO support (x86 part) This patch enables coalesced MMIO for x86 architecture. [PATCH 3/7] libkvm: coalesced MMIO support (powerpc part) This patch enables coalesced MMIO for powerpc architecture. WARNING: this has not been tested. [PATCH 4/7] libkvm: coalesced support (ia64 part) This patch enables coalesced MMIO for ia64 architecture. WARNING: this has not been tested. [PATCH 5/7] qemu: coalesced MMIO support (core) This patch introduces in qemu the coalesced MMIO. [PATCH 6/7] qemu: coalesced MMIO support (VGA) This patch defines coalesced MMIO zones for VGA cards. [PATCH 7/7] qemu: coalesced MMIO support (e1000) This patch defines coalesced MMIO zones for e1000 ethernet card. Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] Add coalesced MMIO support (powerpc part)
This patch enables coalesced MMIO for powerpc architecture. It defines KVM_MMIO_PAGE_OFFSET and KVM_CAP_COALESCED_MMIO. It enables the compilation of coalesced_mmio.c. WARNING: this has not been tested. Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]> --- arch/powerpc/kvm/Makefile |2 +- arch/powerpc/kvm/powerpc.c |3 +++ include/asm-powerpc/kvm_host.h |2 ++ 3 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile index d0d358d..04e3449 100644 --- a/arch/powerpc/kvm/Makefile +++ b/arch/powerpc/kvm/Makefile @@ -4,7 +4,7 @@ EXTRA_CFLAGS += -Ivirt/kvm -Iarch/powerpc/kvm -common-objs = $(addprefix ../../../virt/kvm/, kvm_main.o) +common-objs = $(addprefix ../../../virt/kvm/, kvm_main.o coalesced_mmio.o) kvm-objs := $(common-objs) powerpc.o emulate.o booke_guest.o obj-$(CONFIG_KVM) += kvm.o diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c index 0513b35..b850d24 100644 --- a/arch/powerpc/kvm/powerpc.c +++ b/arch/powerpc/kvm/powerpc.c @@ -145,6 +145,9 @@ int kvm_dev_ioctl_check_extension(long ext) case KVM_CAP_USER_MEMORY: r = 1; break; + case KVM_CAP_COALESCED_MMIO: + r = KVM_COALESCED_MMIO_PAGE_OFFSET; + break; default: r = 0; break; diff --git a/include/asm-powerpc/kvm_host.h b/include/asm-powerpc/kvm_host.h index 81a69d7..2655e2a 100644 --- a/include/asm-powerpc/kvm_host.h +++ b/include/asm-powerpc/kvm_host.h @@ -31,6 +31,8 @@ /* memory slots that does not exposed to userspace */ #define KVM_PRIVATE_MEM_SLOTS 4 +#define KVM_COALESCED_MMIO_PAGE_OFFSET 1 + /* We don't currently support large pages. */ #define KVM_PAGES_PER_HPAGE (1<<31) -- 1.5.2.4 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] kvm: Batch writes to MMIO
When kernel has to send MMIO writes to userspace, it stores them in memory until it has to pass the hand to userspace for another reason. This avoids to have too many context switches on operations that can wait. These patches introduce an ioctl() to define MMIO allowed to be coalesced. This is the kernel part of the coalesced MMIO functionality. [PATCH 1/5] kvm_io_device: extend in_range() to manage len and write attribute Modify member in_range() of structure kvm_io_device to pass length and the type of the I/O (write or read). [PATCH 2/5] Add coalesced MMIO support (common part) This patch adds all needed structures to coalesce MMIOs. [PATCH 3/5] Add coalesced MMIO support (x86 part) This patch enables coalesced MMIO for x86 architecture. [PATCH 4/5] Add coalesced MMIO support (powerpc part) This patch enables coalesced MMIO for powerpc architecture. WARNING: this has not been tested. [PATCH 5/5] Add coalesced MMIO support (ia64 part) This patch enables coalesced MMIO for ia64 architecture. WARNING: this has not been tested. Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] Add coalesced MMIO support (ia64 part)
This patch enables coalesced MMIO for ia64 architecture. It defines KVM_MMIO_PAGE_OFFSET and KVM_CAP_COALESCED_MMIO. It enables the compilation of coalesced_mmio.c. WARNING: this has not been tested. Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]> --- arch/ia64/kvm/Makefile |3 ++- arch/ia64/kvm/kvm-ia64.c|3 +++ include/asm-ia64/kvm_host.h |1 + 3 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/ia64/kvm/Makefile b/arch/ia64/kvm/Makefile index 112791d..bf22fb9 100644 --- a/arch/ia64/kvm/Makefile +++ b/arch/ia64/kvm/Makefile @@ -43,7 +43,8 @@ $(obj)/$(offsets-file): arch/ia64/kvm/asm-offsets.s EXTRA_CFLAGS += -Ivirt/kvm -Iarch/ia64/kvm/ EXTRA_AFLAGS += -Ivirt/kvm -Iarch/ia64/kvm/ -common-objs = $(addprefix ../../../virt/kvm/, kvm_main.o ioapic.o) +common-objs = $(addprefix ../../../virt/kvm/, kvm_main.o ioapic.o \ + coalesced_mmio.o) kvm-objs := $(common-objs) kvm-ia64.o kvm_fw.o obj-$(CONFIG_KVM) += kvm.o diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c index b59231b..4815c31 100644 --- a/arch/ia64/kvm/kvm-ia64.c +++ b/arch/ia64/kvm/kvm-ia64.c @@ -187,6 +187,9 @@ int kvm_dev_ioctl_check_extension(long ext) r = 1; break; + case KVM_CAP_COALESCED_MMIO:: + r = KVM_COALESCED_MMIO_PAGE_OFFSET; + break; default: r = 0; } diff --git a/include/asm-ia64/kvm_host.h b/include/asm-ia64/kvm_host.h index 5c958b0..1efe513 100644 --- a/include/asm-ia64/kvm_host.h +++ b/include/asm-ia64/kvm_host.h @@ -38,6 +38,7 @@ /* memory slots that does not exposed to userspace */ #define KVM_PRIVATE_MEM_SLOTS 4 +#define KVM_COALESCED_MMIO_PAGE_OFFSET 1 /* define exit reasons from vmm to kvm*/ #define EXIT_REASON_VM_PANIC 0 -- 1.5.2.4 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] Add coalesced MMIO support (x86 part)
This patch enables coalesced MMIO for x86 architecture. It defines KVM_MMIO_PAGE_OFFSET and KVM_CAP_COALESCED_MMIO. It enables the compilation of coalesced_mmio.c. Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]> --- arch/x86/kvm/Makefile |3 ++- arch/x86/kvm/x86.c |3 +++ include/asm-x86/kvm_host.h |1 + 3 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/x86/kvm/Makefile b/arch/x86/kvm/Makefile index c97d35c..d0e940b 100644 --- a/arch/x86/kvm/Makefile +++ b/arch/x86/kvm/Makefile @@ -2,7 +2,8 @@ # Makefile for Kernel-based Virtual Machine module # -common-objs = $(addprefix ../../../virt/kvm/, kvm_main.o ioapic.o) +common-objs = $(addprefix ../../../virt/kvm/, kvm_main.o ioapic.o \ +coalesced_mmio.o) ifeq ($(CONFIG_KVM_TRACE),y) common-objs += $(addprefix ../../../virt/kvm/, kvm_trace.o) endif diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index f829319..c7c41b7 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -836,6 +836,9 @@ int kvm_dev_ioctl_check_extension(long ext) case KVM_CAP_MP_STATE: r = 1; break; + case KVM_CAP_COALESCED_MMIO: + r = KVM_COALESCED_MMIO_PAGE_OFFSET; + break; case KVM_CAP_VAPIC: r = !kvm_x86_ops->cpu_has_accelerated_tpr(); break; diff --git a/include/asm-x86/kvm_host.h b/include/asm-x86/kvm_host.h index 8322fc1..f414858 100644 --- a/include/asm-x86/kvm_host.h +++ b/include/asm-x86/kvm_host.h @@ -26,6 +26,7 @@ #define KVM_PRIVATE_MEM_SLOTS 4 #define KVM_PIO_PAGE_OFFSET 1 +#define KVM_COALESCED_MMIO_PAGE_OFFSET 2 #define CR3_PAE_RESERVED_BITS ((X86_CR3_PWT | X86_CR3_PCD) - 1) #define CR3_NONPAE_RESERVED_BITS ((PAGE_SIZE-1) & ~(X86_CR3_PWT | X86_CR3_PCD)) -- 1.5.2.4 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] Add coalesced MMIO support (common part)
This patch adds all needed structures to coalesce MMIOs.
Until an architecture uses it, it is not compiled.
Coalesced MMIO introduces two ioctl() to define where are the MMIO zones that
can be coalesced:
- KVM_REGISTER_COALESCED_MMIO registers a coalesced MMIO zone.
It requests one parameter (struct kvm_coalesced_mmio_zone) which defines
a memory area where MMIOs can be coalesced until the next switch to
user space. The maximum number of MMIO zones is KVM_COALESCED_MMIO_ZONE_MAX.
- KVM_UNREGISTER_COALESCED_MMIO cancels all registered zones inside
the given bounds (bounds are also given by struct kvm_coalesced_mmio_zone).
The userspace client can check kernel coalesced MMIO availability by asking
ioctl(KVM_CHECK_EXTENSION) for the KVM_CAP_COALESCED_MMIO capability.
The ioctl() call to KVM_CAP_COALESCED_MMIO will return 0 if not supported,
or the page offset where will be stored the ring buffer.
The page offset depends on the architecture.
After an ioctl(KVM_RUN), the first page of the KVM memory mapped points to
a kvm_run structure. The offset given by KVM_CAP_COALESCED_MMIO is
an offset to the coalesced MMIO ring expressed in PAGE_SIZE relatively
to the address of the start of th kvm_run structure. The MMIO ring buffer
is defined by the structure kvm_coalesced_mmio_ring.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
include/linux/kvm.h | 29
include/linux/kvm_host.h |4 +
virt/kvm/coalesced_mmio.c | 156 +
virt/kvm/coalesced_mmio.h | 23 +++
virt/kvm/kvm_main.c | 57
5 files changed, 269 insertions(+), 0 deletions(-)
create mode 100644 virt/kvm/coalesced_mmio.c
create mode 100644 virt/kvm/coalesced_mmio.h
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index a281afe..1c908ac 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -173,6 +173,30 @@ struct kvm_run {
};
};
+/* for KVM_REGISTER_COALESCED_MMIO / KVM_UNREGISTER_COALESCED_MMIO */
+
+struct kvm_coalesced_mmio_zone {
+ __u64 addr;
+ __u32 size;
+ __u32 pad;
+};
+
+struct kvm_coalesced_mmio {
+ __u64 phys_addr;
+ __u32 len;
+ __u32 pad;
+ __u8 data[8];
+};
+
+struct kvm_coalesced_mmio_ring {
+ __u32 first, last;
+ struct kvm_coalesced_mmio coalesced_mmio[0];
+};
+
+#define KVM_COALESCED_MMIO_MAX \
+ ((PAGE_SIZE - sizeof(struct kvm_coalesced_mmio_ring)) / \
+sizeof(struct kvm_coalesced_mmio))
+
/* for KVM_TRANSLATE */
struct kvm_translation {
/* in */
@@ -346,6 +370,7 @@ struct kvm_trace_rec {
#define KVM_CAP_NOP_IO_DELAY 12
#define KVM_CAP_PV_MMU 13
#define KVM_CAP_MP_STATE 14
+#define KVM_CAP_COALESCED_MMIO 15
/*
* ioctls for VM fds
@@ -371,6 +396,10 @@ struct kvm_trace_rec {
#define KVM_CREATE_PIT _IO(KVMIO, 0x64)
#define KVM_GET_PIT _IOWR(KVMIO, 0x65, struct kvm_pit_state)
#define KVM_SET_PIT _IOR(KVMIO, 0x66, struct kvm_pit_state)
+#define KVM_REGISTER_COALESCED_MMIO \
+ _IOW(KVMIO, 0x67, struct kvm_coalesced_mmio_zone)
+#define KVM_UNREGISTER_COALESCED_MMIO \
+ _IOW(KVMIO, 0x68, struct kvm_coalesced_mmio_zone)
/*
* ioctls for vcpu fds
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 57b376b..5424ecc 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -116,6 +116,10 @@ struct kvm {
struct kvm_vm_stat stat;
struct kvm_arch arch;
atomic_t users_count;
+#ifdef KVM_COALESCED_MMIO_PAGE_OFFSET
+ struct kvm_coalesced_mmio_dev *coalesced_mmio_dev;
+ struct kvm_coalesced_mmio_ring *coalesced_mmio_ring;
+#endif
};
/* The guest did something we don't support. */
diff --git a/virt/kvm/coalesced_mmio.c b/virt/kvm/coalesced_mmio.c
new file mode 100644
index 000..5ae620d
--- /dev/null
+++ b/virt/kvm/coalesced_mmio.c
@@ -0,0 +1,156 @@
+/*
+ * KVM coalesced MMIO
+ *
+ * Copyright (c) 2008 Bull S.A.S.
+ *
+ * Author: Laurent Vivier <[EMAIL PROTECTED]>
+ *
+ */
+
+#include "iodev.h"
+
+#include
+#include
+
+#include "coalesced_mmio.h"
+
+static int coalesced_mmio_in_range(struct kvm_io_device *this,
+ gpa_t addr, int len, int is_write)
+{
+ struct kvm_coalesced_mmio_dev *dev =
+ (struct kvm_coalesced_mmio_dev*)this->private;
+ struct kvm_coalesced_mmio_zone *zone;
+ int next;
+ int i;
+
+ if (!is_write)
+ return 0;
+
+ /* kvm->lock is taken by the caller and must be not released before
+ * dev.read/write
+ */
+
+ /* Are we able to batch it ? */
+
+ /* last is the first free entry
+* check if we don't meet the first used entry
+* there is always one unused entry in the buffer
+*/
+
+
[PATCH 1/5] kvm_io_device: extend in_range() to manage len and write attribute
Modify member in_range() of structure kvm_io_device to pass length and the type
of the I/O (write or read).
This modification allows to use kvm_io_device with coalesced MMIO.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
arch/ia64/kvm/kvm-ia64.c |6 +++---
arch/x86/kvm/i8254.c |6 --
arch/x86/kvm/i8259.c |3 ++-
arch/x86/kvm/lapic.c |3 ++-
arch/x86/kvm/x86.c | 28 +---
include/linux/kvm_host.h |3 ++-
virt/kvm/ioapic.c|3 ++-
virt/kvm/iodev.h |8 +---
virt/kvm/kvm_main.c |5 +++--
9 files changed, 40 insertions(+), 25 deletions(-)
diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
index adb74f7..b59231b 100644
--- a/arch/ia64/kvm/kvm-ia64.c
+++ b/arch/ia64/kvm/kvm-ia64.c
@@ -195,11 +195,11 @@ int kvm_dev_ioctl_check_extension(long ext)
}
static struct kvm_io_device *vcpu_find_mmio_dev(struct kvm_vcpu *vcpu,
- gpa_t addr)
+ gpa_t addr, int len, int is_write)
{
struct kvm_io_device *dev;
- dev = kvm_io_bus_find_dev(&vcpu->kvm->mmio_bus, addr);
+ dev = kvm_io_bus_find_dev(&vcpu->kvm->mmio_bus, addr, len, is_write);
return dev;
}
@@ -231,7 +231,7 @@ static int handle_mmio(struct kvm_vcpu *vcpu, struct
kvm_run *kvm_run)
kvm_run->exit_reason = KVM_EXIT_MMIO;
return 0;
mmio:
- mmio_dev = vcpu_find_mmio_dev(vcpu, p->addr);
+ mmio_dev = vcpu_find_mmio_dev(vcpu, p->addr, p->size, !p->dir);
if (mmio_dev) {
if (!p->dir)
kvm_iodevice_write(mmio_dev, p->addr, p->size,
diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c
index 6d6dc6c..1558034 100644
--- a/arch/x86/kvm/i8254.c
+++ b/arch/x86/kvm/i8254.c
@@ -445,7 +445,8 @@ static void pit_ioport_read(struct kvm_io_device *this,
mutex_unlock(&pit_state->lock);
}
-static int pit_in_range(struct kvm_io_device *this, gpa_t addr)
+static int pit_in_range(struct kvm_io_device *this, gpa_t addr,
+ int len, int is_write)
{
return ((addr >= KVM_PIT_BASE_ADDRESS) &&
(addr < KVM_PIT_BASE_ADDRESS + KVM_PIT_MEM_LENGTH));
@@ -486,7 +487,8 @@ static void speaker_ioport_read(struct kvm_io_device *this,
mutex_unlock(&pit_state->lock);
}
-static int speaker_in_range(struct kvm_io_device *this, gpa_t addr)
+static int speaker_in_range(struct kvm_io_device *this, gpa_t addr,
+ int len, int is_write)
{
return (addr == KVM_SPEAKER_BASE_ADDRESS);
}
diff --git a/arch/x86/kvm/i8259.c b/arch/x86/kvm/i8259.c
index ab29cf2..5857f59 100644
--- a/arch/x86/kvm/i8259.c
+++ b/arch/x86/kvm/i8259.c
@@ -346,7 +346,8 @@ static u32 elcr_ioport_read(void *opaque, u32 addr1)
return s->elcr;
}
-static int picdev_in_range(struct kvm_io_device *this, gpa_t addr)
+static int picdev_in_range(struct kvm_io_device *this, gpa_t addr,
+ int len, int is_write)
{
switch (addr) {
case 0x20:
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 8fcd84e..7d0670e 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -785,7 +785,8 @@ static void apic_mmio_write(struct kvm_io_device *this,
}
-static int apic_mmio_range(struct kvm_io_device *this, gpa_t addr)
+static int apic_mmio_range(struct kvm_io_device *this, gpa_t addr,
+ int len, int size)
{
struct kvm_lapic *apic = (struct kvm_lapic *)this->private;
int ret = 0;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 2751e98..f829319 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1748,13 +1748,14 @@ static void kvm_init_msr_list(void)
* Only apic need an MMIO device hook, so shortcut now..
*/
static struct kvm_io_device *vcpu_find_pervcpu_dev(struct kvm_vcpu *vcpu,
- gpa_t addr)
+ gpa_t addr, int len,
+ int is_write)
{
struct kvm_io_device *dev;
if (vcpu->arch.apic) {
dev = &vcpu->arch.apic->dev;
- if (dev->in_range(dev, addr))
+ if (dev->in_range(dev, addr, len, is_write))
return dev;
}
return NULL;
@@ -1762,13 +1763,15 @@ static struct kvm_io_device
*vcpu_find_pervcpu_dev(struct kvm_vcpu *vcpu,
static struct kvm_io_device *vcpu_find_mmio_dev(struct kvm_vcpu *vcpu,
- gpa_t addr)
+ gpa_t addr, int len,
+ int is_write)
{
struct kvm_io_device *dev;
- dev = vcpu_find_pervcpu_dev(vcpu, addr);
+
[PATCH 3/7] libkvm: delayed MMIO support (powerpc part)
This patch enables MMIO batching for powerpc architecture.
WARNING: this has not been tested.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
libkvm/libkvm-powerpc.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/libkvm/libkvm-powerpc.c b/libkvm/libkvm-powerpc.c
index 53a2478..0f342d7 100644
--- a/libkvm/libkvm-powerpc.c
+++ b/libkvm/libkvm-powerpc.c
@@ -93,6 +93,12 @@ void kvm_show_regs(kvm_context_t kvm, int vcpu)
int kvm_arch_create(kvm_context_t kvm, unsigned long phys_mem_bytes,
void **vm_mem)
{
+ int r;
+
+ r = kvm_init_delayed_mmio(kvm);
+ if (r < 0)
+ return r;
+
return 0;
}
--
1.5.2.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] qemu: delayed MMIO support (VGA)
This patch defines delayed MMIO zones for VGA cards.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
qemu/hw/cirrus_vga.c |2 ++
qemu/hw/vga.c|4
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/qemu/hw/cirrus_vga.c b/qemu/hw/cirrus_vga.c
index 2c4aeec..9eb6929 100644
--- a/qemu/hw/cirrus_vga.c
+++ b/qemu/hw/cirrus_vga.c
@@ -3291,6 +3291,8 @@ static void cirrus_init_common(CirrusVGAState * s, int
device_id, int is_pci)
cirrus_vga_mem_write, s);
cpu_register_physical_memory(isa_mem_base + 0x000a, 0x2,
vga_io_memory);
+if (kvm_enabled())
+qemu_kvm_register_delayed_mmio(isa_mem_base + 0x000a, 0x2);
s->sr[0x06] = 0x0f;
if (device_id == CIRRUS_ID_CLGD5446) {
diff --git a/qemu/hw/vga.c b/qemu/hw/vga.c
index 3a49573..69afbd9 100644
--- a/qemu/hw/vga.c
+++ b/qemu/hw/vga.c
@@ -2257,6 +2257,8 @@ void vga_init(VGAState *s)
vga_io_memory = cpu_register_io_memory(0, vga_mem_read, vga_mem_write, s);
cpu_register_physical_memory(isa_mem_base + 0x000a, 0x2,
vga_io_memory);
+if (kvm_enabled())
+ qemu_kvm_register_delayed_mmio(isa_mem_base + 0x000a, 0x2);
}
/* Memory mapped interface */
@@ -2332,6 +2334,8 @@ static void vga_mm_init(VGAState *s, target_phys_addr_t
vram_base,
cpu_register_physical_memory(ctrl_base, 0x10, s_ioport_ctrl);
s->bank_offset = 0;
cpu_register_physical_memory(vram_base + 0x000a, 0x2,
vga_io_memory);
+if (kvm_enabled())
+qemu_kvm_register_delayed_mmio(vram_base + 0x000a, 0x2);
}
int isa_vga_init(DisplayState *ds, uint8_t *vga_ram_base,
--
1.5.2.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] qemu: delayed MMIO support (e1000)
This patch defines delayed MMIO zones for e1000 ethernet card.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
qemu/hw/e1000.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/qemu/hw/e1000.c b/qemu/hw/e1000.c
index 01f8983..97f46f6 100644
--- a/qemu/hw/e1000.c
+++ b/qemu/hw/e1000.c
@@ -26,6 +26,7 @@
#include "hw.h"
#include "pci.h"
#include "net.h"
+#include "qemu-kvm.h"
#include "e1000_hw.h"
@@ -938,6 +939,22 @@ e1000_mmio_map(PCIDevice *pci_dev, int region_num,
d->mmio_base = addr;
cpu_register_physical_memory(addr, PNPMMIO_SIZE, d->mmio_index);
+
+if (kvm_enabled()) {
+/* delayed zones are:
+ * 0x0 -> 0x000C0exclude: E1000_ICR,4
+ * 0x000C4 -> 0x00400exclude: E1000_TCTL,4
+ * 0x00404 -> 0x03818exclude: E1000_TDT,4
+ * 0x0381C -> 0x2PNPMMIO_SIZE
+ */
+qemu_kvm_register_delayed_mmio(addr, E1000_ICR);
+qemu_kvm_register_delayed_mmio(addr + E1000_ICR + 4,
+ E1000_TCTL - (E1000_ICR + 4));
+qemu_kvm_register_delayed_mmio(addr + E1000_TCTL + 4,
+ E1000_TDT - (E1000_TCTL + 4));
+qemu_kvm_register_delayed_mmio(addr + E1000_TDT + 4,
+ PNPMMIO_SIZE - (E1000_TDT + 4));
+}
}
static int
--
1.5.2.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] qemu: delayed MMIO support (core)
This patch introduces in qemu the MMIO batching.
It defines qemu_kvm_register_delayed_mmio() and
qemu_kvm_unregister_delayed_mmio() to register and unregister delayed MMIO
zone.
It calls qemu_kvm_unregister_delayed_mmio() on pci_update_mappings().
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
qemu/hw/pci.c |4
qemu/qemu-kvm.c | 10 ++
qemu/qemu-kvm.h |2 ++
3 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/qemu/hw/pci.c b/qemu/hw/pci.c
index a23a466..70809fb 100644
--- a/qemu/hw/pci.c
+++ b/qemu/hw/pci.c
@@ -26,6 +26,7 @@
#include "console.h"
#include "net.h"
#include "pc.h"
+#include "qemu-kvm.h"
//#define DEBUG_PCI
@@ -323,6 +324,9 @@ static void pci_update_mappings(PCIDevice *d)
cpu_register_physical_memory(pci_to_cpu_addr(r->addr),
r->size,
IO_MEM_UNASSIGNED);
+if (kvm_enabled())
+qemu_kvm_unregister_delayed_mmio(r->addr,
+ r->size);
}
}
r->addr = new_addr;
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
index 02776bc..484a713 100644
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -928,3 +928,13 @@ void kvm_mutex_lock(void)
pthread_mutex_lock(&qemu_mutex);
cpu_single_env = NULL;
}
+
+int qemu_kvm_register_delayed_mmio(target_phys_addr_t addr, unsigned int size)
+{
+return kvm_register_delayed_mmio(kvm_context, addr, size);
+}
+
+int qemu_kvm_unregister_delayed_mmio(target_phys_addr_t addr, unsigned int
size)
+{
+return kvm_unregister_delayed_mmio(kvm_context, addr, size);
+}
diff --git a/qemu/qemu-kvm.h b/qemu/qemu-kvm.h
index 7412e20..a69142c 100644
--- a/qemu/qemu-kvm.h
+++ b/qemu/qemu-kvm.h
@@ -76,6 +76,8 @@ int handle_tpr_access(void *opaque, int vcpu,
void kvm_tpr_vcpu_start(CPUState *env);
int qemu_kvm_get_dirty_pages(unsigned long phys_addr, void *buf);
+int qemu_kvm_register_delayed_mmio(target_phys_addr_t addr, unsigned int size);
+int qemu_kvm_unregister_delayed_mmio(target_phys_addr_t addr, unsigned int
size);
void qemu_kvm_system_reset_request(void);
--
1.5.2.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] libkvm: delayed MMIO support (ia64 part)
This patch enables MMIO batching for ia64 architecture.
WARNING: this has not been tested.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
libkvm/libkvm-ia64.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/libkvm/libkvm-ia64.c b/libkvm/libkvm-ia64.c
index d7477d0..b9ea600 100644
--- a/libkvm/libkvm-ia64.c
+++ b/libkvm/libkvm-ia64.c
@@ -67,6 +67,12 @@ void *kvm_create_kernel_phys_mem(kvm_context_t kvm, unsigned
long phys_start,
int kvm_arch_create(kvm_context_t kvm, unsigned long phys_mem_bytes,
void **vm_mem)
{
+ int r;
+
+ r = kvm_init_delayed_mmio(kvm);
+ if (r < 0)
+ return r;
+
return 0;
}
--
1.5.2.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] libkvm: delayed MMIO support (x86 part)
This patch enables MMIO batching for x86 architecture. Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]> --- libkvm/libkvm-x86.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/libkvm/libkvm-x86.c b/libkvm/libkvm-x86.c index d46fdcc..6762b91 100644 --- a/libkvm/libkvm-x86.c +++ b/libkvm/libkvm-x86.c @@ -179,6 +179,10 @@ int kvm_arch_create(kvm_context_t kvm, unsigned long phys_mem_bytes, if (r < 0) return r; + r = kvm_init_delayed_mmio(kvm); + if (r < 0) + return r; + return 0; } -- 1.5.2.4 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] libkvm: delayed MMIO support (common part)
This patch introduces in libkvm the common part of MMIO batching interface.
It checks the MMIO batching availability with ioctl(KVM_CHECK_EXTENSION).
If KVM_CAP_DELAYED_MMIO is available, it processes the MMIO ring buffer
at the return of ioctl(KVM_RUN).
It defines kvm_register_delayed_mmio() to register a delayed MMIO zone, and
kvm_unregister_delayed_mmio() to unregister it.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
libkvm/kvm-common.h |2 +
libkvm/libkvm.c | 73 +++
libkvm/libkvm.h |2 +
3 files changed, 77 insertions(+), 0 deletions(-)
diff --git a/libkvm/kvm-common.h b/libkvm/kvm-common.h
index a3549e2..f975d56 100644
--- a/libkvm/kvm-common.h
+++ b/libkvm/kvm-common.h
@@ -49,6 +49,8 @@ struct kvm_context {
int no_pit_creation;
/// in-kernel pit status
int pit_in_kernel;
+ /// in-kernel delayed mmio
+ int delayed_mmio;
};
void init_slots(void);
diff --git a/libkvm/libkvm.c b/libkvm/libkvm.c
index d1e95a4..718f4c6 100644
--- a/libkvm/libkvm.c
+++ b/libkvm/libkvm.c
@@ -879,6 +879,20 @@ again:
post_kvm_run(kvm, vcpu);
+#if defined(KVM_CAP_DELAYED_MMIO)
+ if (kvm->delayed_mmio) {
+ struct kvm_batch *batch = (void *)run +
+ kvm->delayed_mmio * PAGE_SIZE;
+ while (batch->first != batch->last) {
+ kvm->callbacks->mmio_write(kvm->opaque,
+ batch->mmio[batch->first].phys_addr,
+ &batch->mmio[batch->first].data[0],
+ batch->mmio[batch->first].len);
+ batch->first = (batch->first + 1) % KVM_MAX_BATCH;
+ }
+ }
+#endif
+
if (r == -1) {
r = handle_io_window(kvm);
goto more;
@@ -983,3 +997,62 @@ int kvm_pit_in_kernel(kvm_context_t kvm)
{
return kvm->pit_in_kernel;
}
+
+int kvm_init_delayed_mmio(kvm_context_t kvm)
+{
+ int r = 0;
+ kvm->delayed_mmio = 0;
+#ifdef KVM_CAP_DELAYED_MMIO
+ r = ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_DELAYED_MMIO);
+ if (r > 0) {
+ kvm->delayed_mmio = r;
+ return 0;
+ }
+#endif
+ return r;
+}
+
+int kvm_register_delayed_mmio(kvm_context_t kvm, uint64_t addr, uint32_t size)
+{
+#ifdef KVM_CAP_DELAYED_MMIO
+ struct kvm_delayed_mmio_zone zone;
+ int r;
+
+ if (kvm->delayed_mmio) {
+
+ zone.addr = addr;
+ zone.size = size;
+
+ r = ioctl(kvm->vm_fd, KVM_REGISTER_DELAYED_MMIO, &zone);
+ if (r == -1) {
+ perror("kvm_register_delayed_mmio_zone");
+ return -errno;
+ }
+ return 0;
+ }
+#endif
+ return -1;
+}
+
+int kvm_unregister_delayed_mmio(kvm_context_t kvm, uint64_t addr, uint32_t
size)
+{
+#ifdef KVM_CAP_DELAYED_MMIO
+ struct kvm_delayed_mmio_zone zone;
+ int r;
+
+ if (kvm->delayed_mmio) {
+
+ zone.addr = addr;
+ zone.size = size;
+
+ r = ioctl(kvm->vm_fd, KVM_UNREGISTER_DELAYED_MMIO, &zone);
+ if (r == -1) {
+ perror("kvm_unregister_delayed_mmio_zone");
+ return -errno;
+ }
+ return 0;
+ }
+#endif
+ return -1;
+}
+
diff --git a/libkvm/libkvm.h b/libkvm/libkvm.h
index 63183b8..dfb615a 100644
--- a/libkvm/libkvm.h
+++ b/libkvm/libkvm.h
@@ -457,6 +457,8 @@ int kvm_get_dirty_pages_range(kvm_context_t kvm, unsigned
long phys_addr,
unsigned long end_addr, void *buf, void*opaque,
int (*cb)(unsigned long start, unsigned long len,
void*bitmap, void *opaque));
+int kvm_register_delayed_mmio(kvm_context_t kvm, uint64_t addr, uint32_t size);
+int kvm_unregister_delayed_mmio(kvm_context_t kvm, uint64_t addr, uint32_t
size);
/*!
* \brief Create a memory alias
--
1.5.2.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] kvm-userspace: Batch writes to MMIO
When kernel has to send MMIO writes to userspace, it stores them in memory until it has to pass the hand to userspace for another reason. This avoids to have too many context switches on operations that can wait. WITHOUT WITH PATCH PATCH iperf (e1000) 169 MB/s185,5 MB/s +9,7% host_state_reload(626594)(391825)-37% [9,7% is a more realistic value than my previous benchmark] boot XP host_state_reload 764677 516059 -32% VGA text scroll host_state_reload 13280568 (6:15) 3608362 (4:42) -73% (-25%) This is the userspace part of the MMIO batching functionality. [PATCH 1/7] libkvm: delayed MMIO support (common part) This patch introduces in libkvm the common part of MMIO batching interface. [PATCH 2/7] libkvm: delayed MMIO support (x86 part) This patch enables MMIO batching for x86 architecture. [PATCH 3/7] libkvm: delayed MMIO support (powerpc part) This patch enables MMIO batching for powerpc architecture. WARNING: this has not been tested. [PATCH 4/7] libkvm: delayed MMIO support (ia64 part) This patch enables MMIO batching for ia64 architecture. WARNING: this has not been tested. [PATCH 5/7] qemu: delayed MMIO support (core) This patch introduces in qemu the MMIO batching. [PATCH 6/7] qemu: delayed MMIO support (VGA) This patch defines delayed MMIO zones for VGA cards. [PATCH 7/7] qemu: delayed MMIO support (e1000) This patch defines delayed MMIO zones for e1000 ethernet card. Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] Add delayed MMIO support (x86 part)
This patch enables MMIO batching for x86 architecture. It defines KVM_MMIO_PAGE_OFFSET and KVM_CAP_DELAYED_MMIO. It enables the compilation of delayed_mmio.c. Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]> --- arch/x86/kvm/Makefile |3 ++- arch/x86/kvm/x86.c |3 +++ include/asm-x86/kvm_host.h |1 + 3 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/x86/kvm/Makefile b/arch/x86/kvm/Makefile index c97d35c..534aeef 100644 --- a/arch/x86/kvm/Makefile +++ b/arch/x86/kvm/Makefile @@ -2,7 +2,8 @@ # Makefile for Kernel-based Virtual Machine module # -common-objs = $(addprefix ../../../virt/kvm/, kvm_main.o ioapic.o) +common-objs = $(addprefix ../../../virt/kvm/, kvm_main.o ioapic.o \ +delayed_mmio.o) ifeq ($(CONFIG_KVM_TRACE),y) common-objs += $(addprefix ../../../virt/kvm/, kvm_trace.o) endif diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index e500651..03255d6 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -792,6 +792,9 @@ int kvm_dev_ioctl_check_extension(long ext) case KVM_CAP_MP_STATE: r = 1; break; + case KVM_CAP_DELAYED_MMIO: + r = KVM_MMIO_PAGE_OFFSET; + break; case KVM_CAP_VAPIC: r = !kvm_x86_ops->cpu_has_accelerated_tpr(); break; diff --git a/include/asm-x86/kvm_host.h b/include/asm-x86/kvm_host.h index a71f3aa..7283924 100644 --- a/include/asm-x86/kvm_host.h +++ b/include/asm-x86/kvm_host.h @@ -26,6 +26,7 @@ #define KVM_PRIVATE_MEM_SLOTS 4 #define KVM_PIO_PAGE_OFFSET 1 +#define KVM_MMIO_PAGE_OFFSET 2 #define CR3_PAE_RESERVED_BITS ((X86_CR3_PWT | X86_CR3_PCD) - 1) #define CR3_NONPAE_RESERVED_BITS ((PAGE_SIZE-1) & ~(X86_CR3_PWT | X86_CR3_PCD)) -- 1.5.2.4 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] Add delayed MMIO support (powerpc part)
This patch enables MMIO batching for powerpc architecture. It defines KVM_MMIO_PAGE_OFFSET and KVM_CAP_DELAYED_MMIO. It enables the compilation of delayed_mmio.c. WARNING: this has not been tested. Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]> --- arch/powerpc/kvm/Makefile |2 +- arch/powerpc/kvm/powerpc.c |3 +++ include/asm-powerpc/kvm_host.h |2 ++ 3 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile index d0d358d..88cce9c 100644 --- a/arch/powerpc/kvm/Makefile +++ b/arch/powerpc/kvm/Makefile @@ -4,7 +4,7 @@ EXTRA_CFLAGS += -Ivirt/kvm -Iarch/powerpc/kvm -common-objs = $(addprefix ../../../virt/kvm/, kvm_main.o) +common-objs = $(addprefix ../../../virt/kvm/, kvm_main.o delayed_mmio.o) kvm-objs := $(common-objs) powerpc.o emulate.o booke_guest.o obj-$(CONFIG_KVM) += kvm.o diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c index 0513b35..44b39b9 100644 --- a/arch/powerpc/kvm/powerpc.c +++ b/arch/powerpc/kvm/powerpc.c @@ -145,6 +145,9 @@ int kvm_dev_ioctl_check_extension(long ext) case KVM_CAP_USER_MEMORY: r = 1; break; + case KVM_CAP_DELAYED_MMIO: + r = KVM_MMIO_PAGE_OFFSET; + break; default: r = 0; break; diff --git a/include/asm-powerpc/kvm_host.h b/include/asm-powerpc/kvm_host.h index 81a69d7..74d9958 100644 --- a/include/asm-powerpc/kvm_host.h +++ b/include/asm-powerpc/kvm_host.h @@ -31,6 +31,8 @@ /* memory slots that does not exposed to userspace */ #define KVM_PRIVATE_MEM_SLOTS 4 +#define KVM_MMIO_PAGE_OFFSET 1 + /* We don't currently support large pages. */ #define KVM_PAGES_PER_HPAGE (1<<31) -- 1.5.2.4 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] Add delayed MMIO support (ia64 part)
This patch enables MMIO batching for ia64 architecture. It defines KVM_MMIO_PAGE_OFFSET and KVM_CAP_DELAYED_MMIO. It enables the compilation of delayed_mmio.c. WARNING: this has not been tested. Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]> --- arch/ia64/kvm/Makefile |3 ++- arch/ia64/kvm/kvm-ia64.c|3 +++ include/asm-ia64/kvm_host.h |1 + 3 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/ia64/kvm/Makefile b/arch/ia64/kvm/Makefile index 112791d..b1c65fa 100644 --- a/arch/ia64/kvm/Makefile +++ b/arch/ia64/kvm/Makefile @@ -43,7 +43,8 @@ $(obj)/$(offsets-file): arch/ia64/kvm/asm-offsets.s EXTRA_CFLAGS += -Ivirt/kvm -Iarch/ia64/kvm/ EXTRA_AFLAGS += -Ivirt/kvm -Iarch/ia64/kvm/ -common-objs = $(addprefix ../../../virt/kvm/, kvm_main.o ioapic.o) +common-objs = $(addprefix ../../../virt/kvm/, kvm_main.o ioapic.o \ + delayed_mmio.o) kvm-objs := $(common-objs) kvm-ia64.o kvm_fw.o obj-$(CONFIG_KVM) += kvm.o diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c index b59231b..355b098 100644 --- a/arch/ia64/kvm/kvm-ia64.c +++ b/arch/ia64/kvm/kvm-ia64.c @@ -187,6 +187,9 @@ int kvm_dev_ioctl_check_extension(long ext) r = 1; break; + case KVM_CAP_DELAYED_MMIO: + r = KVM_MMIO_PAGE_OFFSET; + break; default: r = 0; } diff --git a/include/asm-ia64/kvm_host.h b/include/asm-ia64/kvm_host.h index c082c20..e3ffd99 100644 --- a/include/asm-ia64/kvm_host.h +++ b/include/asm-ia64/kvm_host.h @@ -38,6 +38,7 @@ /* memory slots that does not exposed to userspace */ #define KVM_PRIVATE_MEM_SLOTS 4 +#define KVM_MMIO_PAGE_OFFSET 1 /* define exit reasons from vmm to kvm*/ #define EXIT_REASON_VM_PANIC 0 -- 1.5.2.4 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] Add delayed MMIO support (common part)
This patch adds all needed structures to batch MMIOs.
Until an architecture uses it, it is not compiled.
MMIO batching introduces two ioctl() to define where are the MMIO zones that
can be delayed and batched:
- KVM_REGISTER_DELAYED_MMIO registers a delayed MMIO zone.
It requests one parameter (struct kvm_delayed_mmio_zone) which defines
a memory area where MMIOs can be delayed until the next switch to
user space. The maxium number of MMIO zones is KVM_MAX_DELAYED_MMIO_ZONE (100)
- KVM_UNREGISTER_DELAYED_MMIO cancels all registered zones inside
the given bounds (bounds are also given by struct kvm_delayed_mmio_zone).
The userspace client can check kernel MMIO batching availability by asking
ioctl(KVM_CHECK_EXTENSION) for the KVM_CAP_DELAYED_MMIO capability.
The ioctl() call to KVM_CAP_DELAYED_MMIO will return 0 if not supported,
or the page offset where will be stored the batching ring buffer.
The page offset depends on the architecture.
After an ioctl(KVM_RUN), the first page of the KVM memory mapped points to
a kvm_run structure. The offset given by KVM_CAP_DELAYED_MMIO is
an offset to the MMIO batching ring expressed in PAGE_SIZE relatively
to the address of the start of th kvm_run structure. The MMIO ring buffer
is defined by the structure kvm_batch.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
include/linux/kvm.h | 26
include/linux/kvm_host.h |4 +
virt/kvm/delayed_mmio.c | 152 ++
virt/kvm/delayed_mmio.h | 23 +++
virt/kvm/kvm_main.c | 54
5 files changed, 259 insertions(+), 0 deletions(-)
create mode 100644 virt/kvm/delayed_mmio.c
create mode 100644 virt/kvm/delayed_mmio.h
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index a281afe..80f44d8 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -173,6 +173,29 @@ struct kvm_run {
};
};
+/* for KVM_REGISTER_DELAYED_MMIO / KVM_UNREGISTER_DELAYED_MMIO */
+
+struct kvm_delayed_mmio_zone {
+ __u64 addr;
+ __u32 size;
+ __u32 pad;
+};
+struct kvm_batch_ring {
+ __u64 phys_addr;
+ __u32 len;
+ __u32 pad;
+ __u8 data[8];
+};
+
+struct kvm_batch {
+ __u32 first, last;
+ struct kvm_batch_ring mmio[0];
+};
+
+#define KVM_MAX_BATCH ((PAGE_SIZE - sizeof(struct kvm_batch)) / \
+ sizeof(struct kvm_batch_ring))
+
/* for KVM_TRANSLATE */
struct kvm_translation {
/* in */
@@ -346,6 +369,7 @@ struct kvm_trace_rec {
#define KVM_CAP_NOP_IO_DELAY 12
#define KVM_CAP_PV_MMU 13
#define KVM_CAP_MP_STATE 14
+#define KVM_CAP_DELAYED_MMIO 15
/*
* ioctls for VM fds
@@ -371,6 +395,8 @@ struct kvm_trace_rec {
#define KVM_CREATE_PIT _IO(KVMIO, 0x64)
#define KVM_GET_PIT _IOWR(KVMIO, 0x65, struct kvm_pit_state)
#define KVM_SET_PIT _IOR(KVMIO, 0x66, struct kvm_pit_state)
+#define KVM_REGISTER_DELAYED_MMIO _IOW(KVMIO, 0x67, struct
kvm_delayed_mmio_zone)
+#define KVM_UNREGISTER_DELAYED_MMIO _IOW(KVMIO, 0x68, struct
kvm_delayed_mmio_zone)
/*
* ioctls for vcpu fds
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 57b376b..355a4ab 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -116,6 +116,10 @@ struct kvm {
struct kvm_vm_stat stat;
struct kvm_arch arch;
atomic_t users_count;
+#ifdef KVM_MMIO_PAGE_OFFSET
+ struct kvm_delayed_mmio *delayed_mmio;
+ struct kvm_batch *batch;
+#endif
};
/* The guest did something we don't support. */
diff --git a/virt/kvm/delayed_mmio.c b/virt/kvm/delayed_mmio.c
new file mode 100644
index 000..9d7784c
--- /dev/null
+++ b/virt/kvm/delayed_mmio.c
@@ -0,0 +1,152 @@
+/*
+ * KVM delayed MMIO
+ *
+ * Copyright (c) 2008 Bull S.A.S.
+ *
+ * Author: Laurent Vivier <[EMAIL PROTECTED]>
+ *
+ */
+
+#include "iodev.h"
+
+#include
+#include
+
+#include "delayed_mmio.h"
+
+static int delayed_mmio_in_range(struct kvm_io_device *this,
+gpa_t addr, int len, int is_write)
+{
+ struct kvm_delayed_mmio *mmio = (struct kvm_delayed_mmio*)this->private;
+ struct kvm_delayed_mmio_zone *zone;
+ int next;
+ int i;
+
+ if (!is_write)
+ return 0;
+
+ /* kvm->lock is taken by caller and must be not released before
+ * dev.read/write
+ */
+
+ /* Are we able to batch it ? */
+
+ /* last is the first free entry
+* check if we don't meet the first used entry
+* there is always one unused entry in the buffer
+*/
+
+ next = (mmio->kvm->batch->last + 1) % KVM_MAX_BATCH;
+ if (next == mmio->kvm->batch->first) {
+ /* full */
+ return 0;
+ }
+
+ /* is there in a batchable area ? */
+
+ for (i = 0; i < mmio->nb_zones; i++) {
+
[PATCH 1/5] kvm_io_device: extend in_range() to manage len and write attribute
Modify member in_range() of structure kvm_io_device to pass length and the type
of the I/O (write or read).
This modification allows to use kvm_io_device with MMIO batching.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
arch/ia64/kvm/kvm-ia64.c |6 +++---
arch/x86/kvm/i8254.c |6 --
arch/x86/kvm/i8259.c |3 ++-
arch/x86/kvm/lapic.c |3 ++-
arch/x86/kvm/x86.c | 28 +---
include/linux/kvm_host.h |3 ++-
virt/kvm/ioapic.c|3 ++-
virt/kvm/iodev.h |8 +---
virt/kvm/kvm_main.c |5 +++--
9 files changed, 40 insertions(+), 25 deletions(-)
diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
index adb74f7..b59231b 100644
--- a/arch/ia64/kvm/kvm-ia64.c
+++ b/arch/ia64/kvm/kvm-ia64.c
@@ -195,11 +195,11 @@ int kvm_dev_ioctl_check_extension(long ext)
}
static struct kvm_io_device *vcpu_find_mmio_dev(struct kvm_vcpu *vcpu,
- gpa_t addr)
+ gpa_t addr, int len, int is_write)
{
struct kvm_io_device *dev;
- dev = kvm_io_bus_find_dev(&vcpu->kvm->mmio_bus, addr);
+ dev = kvm_io_bus_find_dev(&vcpu->kvm->mmio_bus, addr, len, is_write);
return dev;
}
@@ -231,7 +231,7 @@ static int handle_mmio(struct kvm_vcpu *vcpu, struct
kvm_run *kvm_run)
kvm_run->exit_reason = KVM_EXIT_MMIO;
return 0;
mmio:
- mmio_dev = vcpu_find_mmio_dev(vcpu, p->addr);
+ mmio_dev = vcpu_find_mmio_dev(vcpu, p->addr, p->size, !p->dir);
if (mmio_dev) {
if (!p->dir)
kvm_iodevice_write(mmio_dev, p->addr, p->size,
diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c
index 6d6dc6c..1558034 100644
--- a/arch/x86/kvm/i8254.c
+++ b/arch/x86/kvm/i8254.c
@@ -445,7 +445,8 @@ static void pit_ioport_read(struct kvm_io_device *this,
mutex_unlock(&pit_state->lock);
}
-static int pit_in_range(struct kvm_io_device *this, gpa_t addr)
+static int pit_in_range(struct kvm_io_device *this, gpa_t addr,
+ int len, int is_write)
{
return ((addr >= KVM_PIT_BASE_ADDRESS) &&
(addr < KVM_PIT_BASE_ADDRESS + KVM_PIT_MEM_LENGTH));
@@ -486,7 +487,8 @@ static void speaker_ioport_read(struct kvm_io_device *this,
mutex_unlock(&pit_state->lock);
}
-static int speaker_in_range(struct kvm_io_device *this, gpa_t addr)
+static int speaker_in_range(struct kvm_io_device *this, gpa_t addr,
+ int len, int is_write)
{
return (addr == KVM_SPEAKER_BASE_ADDRESS);
}
diff --git a/arch/x86/kvm/i8259.c b/arch/x86/kvm/i8259.c
index ab29cf2..5857f59 100644
--- a/arch/x86/kvm/i8259.c
+++ b/arch/x86/kvm/i8259.c
@@ -346,7 +346,8 @@ static u32 elcr_ioport_read(void *opaque, u32 addr1)
return s->elcr;
}
-static int picdev_in_range(struct kvm_io_device *this, gpa_t addr)
+static int picdev_in_range(struct kvm_io_device *this, gpa_t addr,
+ int len, int is_write)
{
switch (addr) {
case 0x20:
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 8fcd84e..7d0670e 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -785,7 +785,8 @@ static void apic_mmio_write(struct kvm_io_device *this,
}
-static int apic_mmio_range(struct kvm_io_device *this, gpa_t addr)
+static int apic_mmio_range(struct kvm_io_device *this, gpa_t addr,
+ int len, int size)
{
struct kvm_lapic *apic = (struct kvm_lapic *)this->private;
int ret = 0;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index e537005..e500651 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1704,13 +1704,14 @@ static void kvm_init_msr_list(void)
* Only apic need an MMIO device hook, so shortcut now..
*/
static struct kvm_io_device *vcpu_find_pervcpu_dev(struct kvm_vcpu *vcpu,
- gpa_t addr)
+ gpa_t addr, int len,
+ int is_write)
{
struct kvm_io_device *dev;
if (vcpu->arch.apic) {
dev = &vcpu->arch.apic->dev;
- if (dev->in_range(dev, addr))
+ if (dev->in_range(dev, addr, len, is_write))
return dev;
}
return NULL;
@@ -1718,13 +1719,15 @@ static struct kvm_io_device
*vcpu_find_pervcpu_dev(struct kvm_vcpu *vcpu,
static struct kvm_io_device *vcpu_find_mmio_dev(struct kvm_vcpu *vcpu,
- gpa_t addr)
+ gpa_t addr, int len,
+ int is_write)
{
struct kvm_io_device *dev;
- dev = vcpu_find_pervcpu_dev(vcpu, addr);
+
[PATCH 0/5] kvm: Batch writes to MMIO
When kernel has to send MMIO writes to userspace, it stores them in memory until it has to pass the hand to userspace for another reason. This avoids to have too many context switches on operations that can wait. These patches introduce an ioctl() to define MMIO allowed to be delayed. WITHOUT WITH PATCH PATCH iperf (e1000) 169 MB/s185,5 MB/s +9,7% host_state_reload(626594)(391825)-37% [9,7% is a more realistic value than my previous benchmark] boot XP host_state_reload 764677 516059 -32% VGA text scroll host_state_reload 13280568 (6:15) 3608362 (4:42) -73% (-25%) This is the kernel part of the MMIO batching functionality. [PATCH 1/5] kvm_io_device: extend in_range() to manage len and write attribute Modify member in_range() of structure kvm_io_device to pass length and the type of the I/O (write or read). [PATCH 2/5] Add delayed MMIO support (common part) This patch adds all needed structures to batch MMIOs. Until an architecture uses it, it is not compiled. [PATCH 3/5] Add delayed MMIO support (x86 part) This patch enables MMIO batching for x86 architecture. [PATCH 4/5] Add delayed MMIO support (powerpc part) This patch enables MMIO batching for powerpc architecture. WARNING: this has not been tested. [PATCH 5/5] Add delayed MMIO support (ia64 part) This patch enables MMIO batching for ia64 architecture. WARNING: this has not been tested. Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2][RFC][v2] kvm: Batch writes to MMIO
Le mardi 20 mai 2008 à 10:43 -0500, Hollis Blanchard a écrit : > On Tuesday 20 May 2008 02:39:42 Laurent Vivier wrote: > > Le lundi 19 mai 2008 à 22:04 -0500, Hollis Blanchard a écrit : > > > On Monday 19 May 2008 03:36:30 Laurent Vivier wrote: > > > > Thank you for your comments. > > > > > > > > I agree with all. > > > > > > > > I'll move my code to mulator_write_emulated_onepage(). > > > > I'll use kvm_io_device mechanism: is there an existing ioctl() to > > > > register MMIO zone ? > > > > I'll add a KVM_CAP_ > > > > > > Does that mean you'll move "batch" from kvm_vcpu_arch to kvm_vcpu as well? > > > > No, except if people like you (non-x86 developers) asks for it. > > (but I can't compile/test). > > Please include it in the existing CONFIG_HAS_IOMEM block inside struct > kvm_vcpu. > > Most of the new functions you've introduced should similarly go into > kvm_main.c, since there is nothing x86-specific in them. OK, I'll do it Laurent -- - [EMAIL PROTECTED] --- "The best way to predict the future is to invent it." - Alan Kay -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2][RFC][v2] kvm: Batch writes to MMIO
Le lundi 19 mai 2008 à 22:04 -0500, Hollis Blanchard a écrit : > On Monday 19 May 2008 03:36:30 Laurent Vivier wrote: > > Thank you for your comments. > > > > I agree with all. > > > > I'll move my code to mulator_write_emulated_onepage(). > > I'll use kvm_io_device mechanism: is there an existing ioctl() to > > register MMIO zone ? > > I'll add a KVM_CAP_ > > Does that mean you'll move "batch" from kvm_vcpu_arch to kvm_vcpu as well? No, except if people like you (non-x86 developers) asks for it. (but I can't compile/test). Regards, Laurent -- - [EMAIL PROTECTED] --- "The best way to predict the future is to invent it." - Alan Kay -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2][RFC][v2] kvm: Batch writes to MMIO
Thank you for your comments.
I agree with all.
I'll move my code to mulator_write_emulated_onepage().
I'll use kvm_io_device mechanism: is there an existing ioctl() to
register MMIO zone ?
I'll add a KVM_CAP_
Regards,
Laurent
Le dimanche 18 mai 2008 à 10:39 +0300, Avi Kivity a écrit :
> [resend to new list]
>
> Laurent Vivier wrote:
> > This patch is the kernel part of the "batch writes to MMIO" patch.
> >
> > It intoduces the ioctl interface to define MMIO zone it is allowed to delay.
> > Inside a zone, we can define sub-part we must not delay.
> >
> > If an MMIO can be delayed, it is stored in a ring buffer which common for
> > all VCPUs.
> >
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index dab3d4f..930986b 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -1518,6 +1518,103 @@ out:
> > return r;
> > }
> >
> > +static struct kvm_delayed_mmio_zone *kvm_mmio_find_zone(struct kvm *kvm,
> > + u64 addr, u32 size)
> >
>
> gpa_t addr
>
> > +{
> > + int i;
> > + struct kvm_delayed_mmio_zone *zone;
> > +
> > + for (i = 0; i < kvm->arch.nb_mmio_zones; i++) {
> > + zone = &kvm->arch.mmio_zone[i];
> > +
> > + /* (addr,size) is fully included in
> > +* (zone->addr, zone->size)
> > +*/
> > +
> > + if (zone->addr <= addr &&
> > + addr + size <= zone->addr + zone->size)
> > + return zone;
> > + }
> > + return NULL;
> > +}
> > +
> > +static struct kvm_excluded_mmio_zone *
> > +kvm_mmio_find_excluded(struct kvm_delayed_mmio_zone *zone, u64 addr, u32
> > size)
> > +{
> > + static struct kvm_excluded_mmio_zone *excluded;
> > + int i;
> > +
> > + addr -= zone->addr;
> > + for (i = 0; i < zone->nb_excluded_zones; i++) {
> > + excluded = &zone->excluded[i];
> > +
> > + if ((excluded->offset <= addr &&
> > +addr < excluded->offset + excluded->size) ||
> > +(excluded->offset < addr + size &&
> > + addr + size <= excluded->offset +
> > + excluded->size))
> > + return excluded;
> > + }
> > + return NULL;
> > +}
> > +
> >
>
> Instead of included/excluded zones (with the default excluded), I
> suggest having just included zones (with the default excluded). If the
> user specifies an excluded zone within an included zone, simply split
> the included zone into two:
>
> [100, 200) + ^[150, 160) = [100, 150) + [160, 200)
>
> Or maybe, push all this logic to userspace and only allow adding include
> zones (and clearing previously set include zones).
>
> > +static int kvm_vm_ioctl_set_mmio(struct kvm *kvm,
> > +struct kvm_mmio_zone *zone)
> >
>
> "mmio" is too generic a name. Please use delayed mmio or batched mmio
> consistently.
>
> > +{
> > + struct kvm_delayed_mmio_zone *z;
> > +
> > + if (zone->is_delayed &&
> > + kvm->arch.nb_mmio_zones >= KVM_MAX_DELAYED_MMIO_ZONE)
> > + return -ENOMEM;
> >
>
> -ENOBUFS. -ENOMEM is generally not recoverable, ENOBUFS means just this
> specific operation failed.
>
> > +
> > + if (zone->is_delayed) {
> > +
> > + /* already defined ? */
> > +
> > + if (kvm_mmio_find_zone(kvm, zone->addr, 1) ||
> > + kvm_mmio_find_zone(kvm, zone->addr + zone->size - 1, 1))
> > + return 0;
> > +
> > + z = &kvm->arch.mmio_zone[kvm->arch.nb_mmio_zones];
> > + z->addr = zone->addr;
> > + z->size = zone->size;
> > + kvm->arch.nb_mmio_zones++;
> > + return 0;
> > + }
> > +
> > + /* exclude some parts of the delayed MMIO zone */
> > +
> > + z = kvm_mmio_find_zone(kvm, zone->addr, zone->size);
> > + if (z == NULL)
> > + return -EINVAL;
> > +
> > + if (z->nb_excluded_zones >= KVM_MAX_EXCLUDED_MMIO_ZONE)
> > + return -ENOMEM;
> > +
> > + if (kvm_mmio_find_excluded(z, zone->addr, 1) ||
> > + kvm_mmio_find_excluded(z, zone->addr + zone->size
