Re: [PATCH 0/13 v7] PCI: Linux kernel SR-IOV support
On Wed, Dec 17, 2008 at 03:07:23PM +0800, Zhao, Yu wrote: > Greg KH wrote: >> On Wed, Dec 17, 2008 at 10:37:54AM +0800, Jike Song wrote: >>> Jesse Barnes wrote: Given a respin of 10-13 I think it's reasonable to merge this into 2.6.29, but I'd be much happier about it if we got some driver code along with it, so as not to have an unused interface sitting around for who knows how many releases. Is that reasonable? Do you know if any of the corresponding PF/VF driver bits are ready yet? >>> Hi Jesse, >>> Yu Zhao has posted a patch set with subject "SR-IOV driver example" at >>> November 26, which illustrated the usage of SR-IOV API in Intel 82576 >>> VF/PF >>> drivers;-) >> Yes, but that driver was soundly rejected by the network driver >> maintainers, so I wouldn't go around showing that as your primary >> example of how to use this interface :) >> The point is valid, I don't think these apis should go into the tree >> without a driver or some other code using them. Otherwise they make no >> sense at all to have in-tree. > > I agree the point is valid, but on another hand this is a 'the chicken & > the egg' problem -- if we don't have the SR-IOV base, people who are > developing PF drivers can not get their changes in-tree. Maybe they are > holding the patches and waiting on the infrastructure... :-) Are they? They can both go in at the same time, like almost every other api addition to the kernel, right? thanks, greg k-h -- 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/13 v7] PCI: Linux kernel SR-IOV support
Greg KH wrote: On Wed, Dec 17, 2008 at 10:37:54AM +0800, Jike Song wrote: Jesse Barnes wrote: Given a respin of 10-13 I think it's reasonable to merge this into 2.6.29, but I'd be much happier about it if we got some driver code along with it, so as not to have an unused interface sitting around for who knows how many releases. Is that reasonable? Do you know if any of the corresponding PF/VF driver bits are ready yet? Hi Jesse, Yu Zhao has posted a patch set with subject "SR-IOV driver example" at November 26, which illustrated the usage of SR-IOV API in Intel 82576 VF/PF drivers;-) Yes, but that driver was soundly rejected by the network driver maintainers, so I wouldn't go around showing that as your primary example of how to use this interface :) The point is valid, I don't think these apis should go into the tree without a driver or some other code using them. Otherwise they make no sense at all to have in-tree. I agree the point is valid, but on another hand this is a 'the chicken & the egg' problem -- if we don't have the SR-IOV base, people who are developing PF drivers can not get their changes in-tree. Maybe they are holding the patches and waiting on the infrastructure... :-) -- 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
xen-in-kvm doesn't work with kvm-81.
Host info: h...@hs ~ $ uname -a Linux Hs 2.6.27-gentoo-r6 #1 SMP Mon Dec 15 11:43:12 CST 2008 x86_64 AMD Athlon(tm) X2 Dual Core Processor BE-2350 AuthenticAMD GNU/Linux KVM is version 81. Installed from portage. The guest is 64bit debian lenny, Within guest, we install the xen system. The xen-in-kvm won't boot fine after upgraded to kvm-81. After testing, I found: With kvm-81 userspace util and kernel modules bundled with kernel 2.6.27, xen-in-kvm boots fine.. If I try to use the kvm module bundled with kvm-81, The xen-in-kvm doesn't boot, with guest screen messed up. For the combination of both kernel modules and userspace utils are from kvm-81. With either -no-kvm-irqchip or -no-kvm-pit option passed, xen-in-kvm boots fine. With both -no-kvm-irqchip and -no-kvm-pit options passed, xen-in-kvm also boots fine. Though, We can see the screen messed up when the kernel boots. But the mess up will be cleared by newer kernel messages. The *problem* script used to start xen-in-kvm. TAPNAME=tap0 sudo /usr/bin/tunctl -u hyy -t $TAPNAME sudo /sbin/ifconfig $TAPNAME up sudo /sbin/brctl addif br0 $TAPNAME kvm -k en-us -m 2048 \ -daemonize \ -vnc localhost:5 \ -hda lenny-xen.img \ -net nic,model=rtl8139,macaddr=DE:AD:B3:EF:27:A8 \ -net tap,script=no,ifname=$TAPNAME \ -serial mon:telnet::,server,nowait \ Thanks. -- 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/13 v7] PCI: Linux kernel SR-IOV support
On Wed, Dec 17, 2008 at 10:37:54AM +0800, Jike Song wrote: > Jesse Barnes wrote: > > Given a respin of 10-13 I think it's reasonable to merge this into 2.6.29, > > but > > I'd be much happier about it if we got some driver code along with it, so > > as > > not to have an unused interface sitting around for who knows how many > > releases. Is that reasonable? Do you know if any of the corresponding > > PF/VF > > driver bits are ready yet? > > Hi Jesse, > > Yu Zhao has posted a patch set with subject "SR-IOV driver example" > at November 26, which illustrated the usage of SR-IOV API in Intel 82576 VF/PF > drivers;-) Yes, but that driver was soundly rejected by the network driver maintainers, so I wouldn't go around showing that as your primary example of how to use this interface :) The point is valid, I don't think these apis should go into the tree without a driver or some other code using them. Otherwise they make no sense at all to have in-tree. thanks, greg k-h -- 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] fix build w/ "--with-patched-kernel" on Ubuntu 8.10
And presumably any other distribution that puts only symlinks in /lib/modules//build/... Signed-off-by: Nolan Leake sigbus.net> diff --git a/kernel/Makefile b/kernel/Makefile index 8315e3d..6bf474b 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -65,12 +65,12 @@ headers-new = $(LINUX)/arch/$(ARCH_DIR)/include/asm/./kvm*.h \ header-sync: rm -rf $T - rsync -R \ + rsync -R -L \ "$(LINUX)"/./include/linux/kvm*.h \ $(if $(wildcard $(headers-old)), $(headers-old)) \ $T/ $(if $(wildcard $(headers-new)), \ - rsync -R \ + rsync -R -L \ $(wildcard $(headers-new)) \ $T/include/asm-$(ARCH_DIR)/) -- 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/13 v7] PCI: Linux kernel SR-IOV support
Jesse Barnes wrote: > Given a respin of 10-13 I think it's reasonable to merge this into 2.6.29, > but > I'd be much happier about it if we got some driver code along with it, so as > not to have an unused interface sitting around for who knows how many > releases. Is that reasonable? Do you know if any of the corresponding PF/VF > driver bits are ready yet? Hi Jesse, Yu Zhao has posted a patch set with subject "SR-IOV driver example" at November 26, which illustrated the usage of SR-IOV API in Intel 82576 VF/PF drivers;-) -- Thanks, Jike -- 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: Re:RE: [PATCH 1/3] KVM: pci passthrough un-page-aligned mmio device on machines w/o VT-d
刘晓建 wrote: > 2008-12-16，"Han, Weidong" wrote： >> Pls note that multiple devices may share one page for their MMIO, >> and they may be assigned to different guests, there is potential >> isolation issue. So we don't allow to assign these devices. > > In my view, we can modify the get_real_device() to open the file > /proc/iomem to find out whether the "potential issue" is a real one, > instead of disabling this feature all the times. > > Xiaojian Liu As I know, there are few devices that have unpage-aligned mmio, and they are almost legacy. What's more, it's a little weird to map unpage-aligned memory slot, though I don't know what's problem on it. In short, I don't perfer to assign these devices. Regards, Weidong
Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support
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. What happens if the BIOS provides a splash screen? Will it override the QEMU splash screen? > 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). Regards, Carl-Daniel -- http://www.hailfinger.org/ -- 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
kvm-81 and Windows XP - delayed write failed
G'day, I must be doing something wrong, because it sounds like everyone else is happy about kvm-81. My Windows XP guests now constantly show "Delayed Write Failed" popups. The problem vanishes when I revert to kvm-80, which I didn't have any problems on. The guest images are qcow2 compressed (via qemu-img convert -c) and I'm hosting on Fedora 9 x86-64 on an AMD Turion TK-55 laptop. Any ideas if I'm likely doing something wrong? I can happily stick with kvm-80 for now, but don't know if I'm going to be stuck there; any information appreciated. cheers, Ross -- Ross McKay, Toronto, NSW Australia "Let the laddie play wi the knife - he'll learn" - The Wee Book of Calvin -- 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] avoid kvm-userspace merge conflict with PowerPC KVM support in qemu
PowerPC KVM support was accepted into upstream qemu. To ease the merge
conflicts, you should apply this patch to remove all traces of PowerPC
KVM code from kvm-userspace before the next qemu pull.
Signed-off-by: Hollis Blanchard
---
You'll also want to remove qemu/pc-bios/bamboo.dtb, which I can't
express in this patch because guilt sucks.
Sorry if I missed anything; let me know if you you have problems.
diff --git a/qemu/Makefile b/qemu/Makefile
index b2ca039..745851d 100644
--- a/qemu/Makefile
+++ b/qemu/Makefile
@@ -228,7 +228,6 @@ BLOBS=bios.bin vgabios.bin vgabios-cirrus.bin ppc_rom.bin \
video.x openbios-sparc32 openbios-sparc64 pxe-ne2k_pci.bin \
pxe-rtl8139.bin pxe-pcnet.bin pxe-e1000.bin
BLOBS += extboot.bin
-BLOBS += bamboo.dtb
else
BLOBS=
endif
diff --git a/qemu/Makefile.target b/qemu/Makefile.target
index 315c3c9..a304570 100644
--- a/qemu/Makefile.target
+++ b/qemu/Makefile.target
@@ -231,12 +231,6 @@ LIBOBJS+=qemu-kvm-helper.o
endif
endif
-ifeq ($(TARGET_BASE_ARCH), ppc)
-ifeq ($(USE_KVM), 1)
-LIBOBJS+= qemu-kvm-powerpc.o
-endif
-endif
-
LIBOBJS+= op_helper.o
ifneq ($(TARGET_ARCH), ia64)
@@ -679,11 +673,6 @@ ifdef CONFIG_BLUEZ
LIBS += $(CONFIG_BLUEZ_LIBS)
endif
-ifdef CONFIG_LIBFDT
-LIBS += -lfdt
-DEPLIBS += ../libfdt/libfdt.a
-endif
-
# SCSI layer
OBJS+= lsi53c895a.o esp.o
@@ -747,7 +736,6 @@ OBJS+= heathrow_pic.o grackle_pci.o ppc_oldworld.o
OBJS+= unin_pci.o ppc_chrp.o
# PowerPC 4xx boards
OBJS+= pflash_cfi02.o ppc4xx_devs.o ppc4xx_pci.o ppc405_uc.o ppc405_boards.o
-OBJS+= ppc440.o ppc440_bamboo.o device_tree.o
# virtio support
OBJS+= virtio.o virtio-blk.o virtio-balloon.o
OBJS+= virtio-net.o
diff --git a/qemu/configure b/qemu/configure
index 5f5264f..468896e 100755
--- a/qemu/configure
+++ b/qemu/configure
@@ -124,7 +124,6 @@ blobs="yes"
signalfd="no"
eventfd="no"
cpu_emulation="yes"
-device_tree_support=""
# OS specific
targetos=`uname -s`
@@ -389,8 +388,6 @@ for opt do
;;
--disable-cpu-emulation) cpu_emulation="no"
;;
- --disable-libfdt) device_tree_support="no"
- ;;
*) echo "ERROR: unknown option $opt"; exit 1
;;
esac
@@ -503,7 +500,6 @@ echo " --disable-aiodisable AIO support"
echo " --disable-blobs disable installing provided firmware blobs"
echo " --kerneldir=PATH look for kernel includes in PATH"
echo " --disable-cpu-emulation disables use of qemu cpu emulation code"
-echo " --disable-libfdt disables use of libfdt support for device
tree"
echo ""
echo "NOTE: The object files are built at the place where configure is
launched"
exit 1
@@ -1092,31 +1088,6 @@ else
binsuffix="/bin"
fi
-##
-# libfdt probe
-#
-if test -z "$device_tree_support" -a \
- "$cpu" = "powerpc"; then
- device_tree_support="no"
- cat > $TMPC << EOF
-#include
-/* XXX uncomment later when libfdt is built before this test */
-//int main(void) { void *fdt; return fdt_create(fdt, 1024); }
-int main (void) {return 0;}
-EOF
-# XXX for now do not try to link to libfdt and just check for header */
-# if $cc $ARCH_CFLAGS $CFLAGS $LDFLAGS -o $TMPE $TMPC -lfdt 2> /dev/null ; then
- if $cc $ARCH_CFLAGS $CFLAGS $LDFLAGS -o $TMPE $TMPC 2> /dev/null; then
- device_tree_support="yes"
- else
-echo
-echo "Error: Could not find libfdt"
-echo "Make sure to have the libfdt libs and headers installed."
-echo
-exit 1
- fi
-fi
-
echo "Install prefix$prefix"
echo "BIOS directory$prefix$datasuffix"
echo "binary directory $prefix$binsuffix"
@@ -1161,9 +1132,6 @@ fi
echo "kqemu support $kqemu"
echo "kvm support $kvm"
echo "CPU emulation $cpu_emulation"
-if test $cpu = "powerpc"; then
-echo "libfdt support$device_tree_support"
-fi
echo "brlapi support$brlapi"
echo "Documentation $build_docs"
[ ! -z "$uname_release" ] && \
@@ -1726,10 +1694,6 @@ case "$target_cpu" in
echo "#define TARGET_ARCH \"ppcemb\"" >> $config_h
echo "#define TARGET_PPC 1" >> $config_h
echo "#define TARGET_PPCEMB 1" >> $config_h
-if test "$device_tree_support" = "yes" ; then
- echo "#define CONFIG_LIBFDT 1" >> $config_h
- echo "CONFIG_LIBFDT=1" >> $config_mak
-fi
configure_kvm
;;
ppc64)
diff --git a/qemu/hw/boards.h b/qemu/hw/boards.h
index d2b26c6..fae6d19 100644
--- a/qemu/hw/boards.h
+++ b/qemu/hw/boards.h
@@ -40,7 +40,6 @@ extern QEMUMachine core99_machine;
extern QEMUMachine heathrow_machine;
extern QEMUMachine ref405ep_machine;
extern QEMUMachine taihu_machine;
-extern QEMUMachine bamboo_machine;
/* mips_r4k.c */
extern QEMUMachine mips_machine;
diff --git a/qemu/hw/device_tree.c b/qemu/hw/device_tree.c
deleted file mode 100644
index 2621ff1..000
--- a/qemu/hw/device_tree.c
+++ /dev/null
@@ -1,193 +0,0 @@
-/*
- * Functions to help device tree manipulation using libfdt.
- * It also provides functions to read entries from device tree proc
- * interface.
- *
- * Copyright 2008 IBM Corporation.
Re: [PATCH 0/13 v7] PCI: Linux kernel SR-IOV support
On Friday, November 21, 2008 10:36 am Yu Zhao wrote: > Greetings, > > Following patches are intended to support SR-IOV capability in the > Linux kernel. With these patches, people can turn a PCI device with > the capability into multiple ones from software perspective, which > will benefit KVM and achieve other purposes such as QoS, security, > and etc. > > The Physical Function and Virtual Function drivers using the SR-IOV > APIs will come soon! > > Major changes from v6 to v7: > 1, remove boot-time resource rebalancing support. (Greg KH) > 2, emit uevent upon the PF driver is loaded. (Greg KH) > 3, put SR-IOV callback function into the 'pci_driver'. (Matthew Wilcox) > 4, register SR-IOV service at the PF loading stage. > 5, remove unnecessary APIs (pci_iov_enable/disable). Thanks for your patience with this, Yu, I know it's been a long haul. :) I applied 1-9 to my linux-next branch; and at least patch #10 needs a respin, so can you re-do 10-13 as a new patch set? On re-reading the last thread, there was a lot of smoke, but very little fire afaict. The main questions I saw were: 1) do we need SR-IOV at all? why not just make each subsystem export devices to guests? This is a bit of a red herring. Nothing about SR-IOV prevents us from making subsystems more v12n friendly. And since SR-IOV is a hardware feature supported by devices these days, we should make Linux support it. 2) should the PF/VF drivers be the same or not? Again, the SR-IOV patchset and PCI spec don't dictate this. We're free to do what we want here. 3) should VF devices be represented by pci_dev structs? Yes. (This is an easy one :) 4) can VF devices be used on the host? Yet again, SR-IOV doesn't dictate this. Developers can make PF/VF combo drivers or split them, and export the resulting devices however they want. Some subsystem work may be needed to make this efficient, but SR-IOV itself is agnostic about it. So overall I didn't see many objections to the actual code in the last post, and the issues above certainly don't merit a NAK IMO... Given a respin of 10-13 I think it's reasonable to merge this into 2.6.29, but I'd be much happier about it if we got some driver code along with it, so as not to have an unused interface sitting around for who knows how many releases. Is that reasonable? Do you know if any of the corresponding PF/VF driver bits are ready yet? Thanks, -- Jesse Barnes, Intel Open Source Technology Center -- 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] AF_VMCHANNEL address family for guest<->host communication.
Evgeniy Polyakov wrote: On Tue, Dec 16, 2008 at 08:57:27AM +0200, Gleb Natapov (g...@redhat.com) wrote: Another approach is to implement that virtio backend with netlink based userspace interface (like using connector or genetlink). This does not differ too much from what you have with special socket family, but at least it does not duplicate existing functionality of userspace-kernelspace communications. I implemented vmchannel using connector initially (the downside is that message can be dropped). Is this more expectable for upstream? The implementation was 300 lines of code. Hard to tell, it depends on implementation. But if things are good, I have no objections as connector maintainer :) Messages in connector in particular and netlink in general are only dropped, when receiving buffer is full (or when there is no memory), you can tune buffer size to match virtual queue size or vice versa. Gleb was aware of that and it's not a problem since all of the anticipated usages may drop msgs (guest statistics, cut&paste, mouse movements, single sign on commands, etc). Service that would need reliability could use basic acks. -- 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
Re: [PATCH] AF_VMCHANNEL address family for guest<->host communication.
On Tue, Dec 16, 2008 at 08:57:27AM +0200, Gleb Natapov (g...@redhat.com) wrote: > > Another approach is to implement that virtio backend with netlink based > > userspace interface (like using connector or genetlink). This does not > > differ too much from what you have with special socket family, but at > > least it does not duplicate existing functionality of > > userspace-kernelspace communications. > > > I implemented vmchannel using connector initially (the downside is that > message can be dropped). Is this more expectable for upstream? The > implementation was 300 lines of code. Hard to tell, it depends on implementation. But if things are good, I have no objections as connector maintainer :) Messages in connector in particular and netlink in general are only dropped, when receiving buffer is full (or when there is no memory), you can tune buffer size to match virtual queue size or vice versa. -- Evgeniy Polyakov -- 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
On 12/16/08, Anthony Liguori wrote: > Blue Swirl wrote: > > > On 12/16/08, 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). > > > > > > [PATCH 1/3] Correct fw_cfg_add_callback() > > > [PATCH 2/3] [BIOS] Add splash image support > > > [PATCH 3/3] [QEMU] Add BIOS splash image > > > > > > > > > > On second thought, there is no Gtk/Qt GUI because that is supposed to > > be external to Qemu. By the same logic, why should there be any splash > > screen? The external GUI can probably show it as easily using the same > > Gtk/Qt/whatever. > > > > You need it to be consistent on the SDL/VNC display. Oh, I didn't consider the VNC case. Then it may be difficult for the GUI to manage the boot screen. > Modern BIOSes have splash screens. I don't see why our BIOS shouldn't have > one too. > > > 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. -- 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
Blue Swirl wrote: On 12/16/08, 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). [PATCH 1/3] Correct fw_cfg_add_callback() [PATCH 2/3] [BIOS] Add splash image support [PATCH 3/3] [QEMU] Add BIOS splash image On second thought, there is no Gtk/Qt GUI because that is supposed to be external to Qemu. By the same logic, why should there be any splash screen? The external GUI can probably show it as easily using the same Gtk/Qt/whatever. You need it to be consistent on the SDL/VNC display. Modern BIOSes have splash screens. I don't see why our BIOS shouldn't have one too. 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. Regards, Anthony Liguori -- 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 -- 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: Loss of lock drop in qemu/net.c
Avi Kivity wrote: hThe recent qemu merged does not allow net.h to include kvm code (due to a dependency on cpu.h). This means I had to drop the kvm_sleep_begin()/kvm_sleep_end() around the packet send (which, btw, makes the whole thing vulnerable to hotunplug; we need refcounting or locking here). Why does net.h include cpu.h and why would net.h need kvm code? Regards, Anthony Liguori We'll need to find some way to put this back in. -- 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
On 12/16/08, 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). > > [PATCH 1/3] Correct fw_cfg_add_callback() > [PATCH 2/3] [BIOS] Add splash image support > [PATCH 3/3] [QEMU] Add BIOS splash image On second thought, there is no Gtk/Qt GUI because that is supposed to be external to Qemu. By the same logic, why should there be any splash screen? The external GUI can probably show it as easily using the same Gtk/Qt/whatever. 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. -- 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
Loss of lock drop in qemu/net.c
hThe recent qemu merged does not allow net.h to include kvm code (due to a dependency on cpu.h). This means I had to drop the kvm_sleep_begin()/kvm_sleep_end() around the packet send (which, btw, makes the whole thing vulnerable to hotunplug; we need refcounting or locking here). We'll need to find some way to put this back in. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO
On 12/16/08, Anthony Liguori wrote: > Avi Kivity wrote: > > > Blue Swirl wrote: > > > > > > > > > I don't understand. It's not a device that needs bouncing, it's a > > > > particular transfer. This could be either due to the transfer > targeting > > > > mmio, or due to the transfer requiring a transformation. > > > > > > > > > > > > > > Should the bouncing be something more much complex, for example > > > negotiated between the devices? Or maybe the devices set up a > > > transforming and non-transforming channel (which the other end should > > > be able to transform some more) and use them as needed? > > > > > > > > > > Yes. We already have two cases: > > > > - may do partial request: useful for block storage where requests can be > huge > > - need full request: networking, where you can't send or receive half a > packet; on the other hand, packets are small (even with tso) > > > > You're adding a third case, always bounce, when the data undergoes a > transformation which can't happen in-place. > > > > IMHO, IOMMU translation is distinct from mapping/data transformation. I > would think the IOMMU translation API would be different in that it took a > physical address and returned a physical address. Fully agree. On Sparc32, the incoming address is called DVMA (device virtual memory address). > The IOMMU DMA API (which could transform data potentially) should return a > virtual address and data a physical address. In the normal case > (non-transforming IOMMU), it should just fall-through to CPU DMA API (which > is just map/unmap). > > The PCI DMA API would normally fall through to the IOMMU DMA API. > > So we would have: > > PCI DMA map(addr): > if IOMMU: > return IOMMU DMA map(addr) > return CPU DMA map(addr) > > IOMMU DMA map(addr): > new_address = IOMMU translate(addr) > if transform: >return IOMMU byte-swap map(addr) > return CPU DMA map(addr) But with this we would be back to the original merged API. I'd propose three to four distinct steps: 1. Resolve the device addresses via IOMMU etc. to guest physical addresses (typically no changes if no IOMMU) 2. Negotiate bouncing (if bounced, the step returns a host address, if not, a physical address) 3. Map the physical addresses to host addresses, bypass for the bounce cases 4. Perform vectorized zero-copy AIO. (Profit?) 2 & 3 may/should be merged but I'm not sure we have the full picture yet. -- 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: [ANNOUNCE] kvm-81 release
Farkas Levente wrote: Avi Kivity wrote: This release fixes a bunch of display regressions, and restores userspace/kernel compatibility with older kernel modules. There are a few other goodies hidden in there, for example scsi is now enabled on 4G guests. the best news in the last 10-20 kmv release we finally able to run all of our guests with kvm-81 (even mandrake-10:-))) the only problem that fedora-9's older kernel can not boot, but i boot with the latest fedora-9 kernel, upgrade to fedora-10 hand in graphical mode, crash in text mode and preupgrade hang with 100% cpu) so we can use only f-9. i hope it'll be easier to fix this fedora kernel's problem the the mandrake one. our setup: - host: - Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz - Intel S3000AHV - 8GB RAM - CentOS-5.2 - kernel-2.6.18-92.1.18.el5 x86_64 64bit - guest-1: - CentOS-5.2 - 4 vcpu - kernel-2.6.18-92.1.18.el5 i386 32bit - guest-2: - CentOS-5.2 - 4 vcpu - kernel-2.6.18-92.1.18.el5 x86_64 64bit - guest-3: - Mandrake-9 - 1 vcpu - kernel-2.4.19.16mdk-1-1mdk 32bit - guest-4: - Mandrake-10 - 1 vcpu - kernel-2.6.14.2-p4-smp 32bit - guest-5: - Windows XP Professional 32bit - 2 vcpu - guest-7: - Fedora-9 - 4 vcpu - kernel-2.6.27.5-37.fc9.i686 Solaris 10 guest does not boot on CentOS 5.2. The boot screen keeps circling. -- 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 3 of 3] [PATCH] kvm-userspace: fix gdbstub kvm integration
Hello
I was trying to debug my patch that is not working and noticed this
crash in current kvm git.
The patch below makes kvm not crash when gdb is attched to gdbserver
so it certainly improves things.
Thanks
Michal
PS if you want further input from me add me to CC
On 16/12/2008, Christian Ehrhardt wrote:
> # HG changeset patch
> # User Christian Ehrhardt
> # Date 1228989958 -3600
> # Node ID f80fb35de91fe69dae889c70948c9a53212ee444
> # Parent 6f228c807ad0b239b7342d2974debfc66418d784
> [PATCH] kvm-userspace: fix gdbstub kvm integration
>
> From: Christian Ehrhardt
>
> Some recent qemu upstream merges brought in a new concept to not use "env" as
> current cpu in gdb_handle_packet anymore. But the kvm calls still do, this
> leads to SIGDEV's as env is not initialized when calling the functions like
> kvm_save_registers.
>
> Insted there is now a gdbstate structure holding current cpu for
> step/continue and "other" ops splitted.
>
> This patch changes the kvm_save_registers calls to use the right CPUState
> variable for the kvm calls in gdb_handle_packet.
>
> Signed-off-by: Christian Ehrhardt
> ---
>
> [diffstat]
> gdbstub.c |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> [diff]
>
> diff --git a/qemu/gdbstub.c b/qemu/gdbstub.c
> --- a/qemu/gdbstub.c
> +++ b/qemu/gdbstub.c
> @@ -1348,7 +1348,7 @@ static int gdb_handle_packet(GDBState *s
> }
> break;
> case 'g':
> -kvm_save_registers(env);
> +kvm_save_registers(s->g_cpu);
> len = 0;
> for (addr = 0; addr < num_g_regs; addr++) {
> reg_size = gdb_read_register(s->g_cpu, mem_buf + len, addr);
> @@ -1366,7 +1366,7 @@ static int gdb_handle_packet(GDBState *s
> len -= reg_size;
> registers += reg_size;
> }
> -kvm_load_registers(env);
> +kvm_load_registers(s->g_cpu);
> put_packet(s, "OK");
> break;
> case 'm':
>
> --
> 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
>
>
--
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] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO
Avi Kivity wrote: Blue Swirl wrote: I don't understand. It's not a device that needs bouncing, it's a particular transfer. This could be either due to the transfer targeting mmio, or due to the transfer requiring a transformation. Should the bouncing be something more much complex, for example negotiated between the devices? Or maybe the devices set up a transforming and non-transforming channel (which the other end should be able to transform some more) and use them as needed? Yes. We already have two cases: - may do partial request: useful for block storage where requests can be huge - need full request: networking, where you can't send or receive half a packet; on the other hand, packets are small (even with tso) You're adding a third case, always bounce, when the data undergoes a transformation which can't happen in-place. IMHO, IOMMU translation is distinct from mapping/data transformation. I would think the IOMMU translation API would be different in that it took a physical address and returned a physical address. The IOMMU DMA API (which could transform data potentially) should return a virtual address and data a physical address. In the normal case (non-transforming IOMMU), it should just fall-through to CPU DMA API (which is just map/unmap). The PCI DMA API would normally fall through to the IOMMU DMA API. So we would have: PCI DMA map(addr): if IOMMU: return IOMMU DMA map(addr) return CPU DMA map(addr) IOMMU DMA map(addr): new_address = IOMMU translate(addr) if transform: return IOMMU byte-swap map(addr) return CPU DMA map(addr) Regards, Anthony Liguori -- 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] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO
Blue Swirl wrote: I don't understand. It's not a device that needs bouncing, it's a particular transfer. This could be either due to the transfer targeting mmio, or due to the transfer requiring a transformation. Should the bouncing be something more much complex, for example negotiated between the devices? Or maybe the devices set up a transforming and non-transforming channel (which the other end should be able to transform some more) and use them as needed? Yes. We already have two cases: - may do partial request: useful for block storage where requests can be huge - need full request: networking, where you can't send or receive half a packet; on the other hand, packets are small (even with tso) You're adding a third case, always bounce, when the data undergoes a transformation which can't happen in-place. -- error compiling committee.c: too many arguments to function -- 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] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO
On 12/16/08, Avi Kivity wrote: > Anthony Liguori wrote: > > > > > > There are still some issues I'm not happy yet: > > > - handling of access violations: resolving should stop before the bad > > > page, the transfers should be done until that and then post error. > > > - bounce buffers needed for Lance byte swapping are not well designed > (stack) > > > > > > > > > > I think you could approach the bouncing via a map/unmap API but I'm not > sure. You would need a map() function to take a virtual address which is > sort of weird. That would allow you to stack them in an arbitrary fashion > though. > > > > > > I think that's broken. iommus converts physical addresses to physical > addresses (or bus addresses), possibly generating faults along the way, and > depending on the iommu context. map()/unmap() converts physical/bus > addresses to virtual addresses, possibly bouncing. Except for both doing > conversions, they're very different. > > > > > > > This lead me to the thought that maybe we should not hide the bounce > > > buffer activity, but instead make it more explicit for the device that > > > needs bouncing. For the other device, the buffering or lack of it > > > should be opaque. > > > > > > > > > > I think that's reasonable. > > > > I don't understand. It's not a device that needs bouncing, it's a > particular transfer. This could be either due to the transfer targeting > mmio, or due to the transfer requiring a transformation. Should the bouncing be something more much complex, for example negotiated between the devices? Or maybe the devices set up a transforming and non-transforming channel (which the other end should be able to transform some more) and use them as needed? In the Lance case, some of the DMA is byte swapped and some not, depending on the memory region used, some is swapped because of a global bit in a register and finally the Sparc32 DMA controller reverses the swapping. -- 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] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO
On 12/16/08, Paul Brook wrote: > > The generic resolving API should look something like > > > > int (*resolve)(target_phys_addr_t address_in, target_phys_addr_t > > length_in, target_phys_addr_t &address_out, target_phys_addr_t > > &length_out) > > > I don't think this is sufficient. A paged iommu may split a single range into > multiple disjoint sections. i.e. we need SG lists. That's why there is the length_out, it is called repeatedly until the length is zero or it fails. -- 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] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO
> The generic resolving API should look something like > > int (*resolve)(target_phys_addr_t address_in, target_phys_addr_t > length_in, target_phys_addr_t &address_out, target_phys_addr_t > &length_out) I don't think this is sufficient. A paged iommu may split a single range into multiple disjoint sections. i.e. we need SG lists. Paul -- 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 3/3] [QEMU] Add BIOS splash image
On 12/16/08, Laurent Vivier wrote: > 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). Nice. But shouldn't this be more generic, I think we want to use this on OpenBIOS/Sparc (or PPC) too? -- 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] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO
On 12/16/08, Anthony Liguori wrote: > Blue Swirl wrote: > > > I changed the ESP SCSI and Lance Ethernet on Sparc32 to resolve the IO > > address to physical memory (see patch). ESP works (no zero copy yet), > > Lance doesn't. It looks much better. Because the resolving activity is > > performed in serial steps, unbounded IO vector allocation does not > > happen, but we still could launch as many IO as there are free IO > > vectors. > > > > > > It is a good cleanup. > > > > There are still some issues I'm not happy yet: > > - handling of access violations: resolving should stop before the bad > > page, the transfers should be done until that and then post error. > > - bounce buffers needed for Lance byte swapping are not well designed > (stack) > > > > > > I think you could approach the bouncing via a map/unmap API but I'm not > sure. You would need a map() function to take a virtual address which is > sort of weird. That would allow you to stack them in an arbitrary fashion > though. I'd still like to keep resolving virtual addresses to physical addresses separate from physical address to host pointer mapping. I think this was the enlightening discovery we made earlier. The generic resolving API should look something like int (*resolve)(target_phys_addr_t address_in, target_phys_addr_t length_in, target_phys_addr_t &address_out, target_phys_addr_t &length_out) whereas the map/unmap API would be as you specified earlier. > > This lead me to the thought that maybe we should not hide the bounce > > buffer activity, but instead make it more explicit for the device that > > needs bouncing. For the other device, the buffering or lack of it > > should be opaque. > > > > > > I think that's reasonable. > > > > Also the virtual-to-physical address resolution API could be generic, > > ie all resolver functions should take same parameters so that the > > devices would not need to know the next higher level device. > > > > > > Yes. I think this is key. The only observation I would make is that the > resolution API should have some sort of release function (so map/unmap, > lock/unlock, whatever). I'm not so sure resolving works the same symmetric way, because the virtual to physical mapping will change over time because of guest activity. We could cache the resolved translations, but then there should be a way to invalidate the cache entries throughout the device chain with callbacks etc. -- 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,0,0,0,0,0,0,0,0,0,0,0,0,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,1,0,0,0,
+ 0,0,1,1,0,0,0,0,0,1,1,1,1,1,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,1,1,1,0,
+ 0,0,0,0,0,0,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,0,0,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_logo_byte(&logo_hdr->fu8FadeIn);
+
+outw(BIOS_CFG_IOPORT, BIOS_CFG_SPLASH);
+if (is_fade_in)
+{
+for (i = 0; i < LOGO_SHOW_STEPS; i++)
Re: Status of pci passthrough work?
- "xming" wrote: > > It's usable; but not ported to newer kernel versions. I can't say > when I'll get around doing it. In the meanwhile if someone else is > interested, drop me a line. > > Do you mean interested in porting to newer versions (kvm + kernel) or > interested > in to use pvdma? > > If it's the latter, I am. I mean interested in porting it. -- 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: Status of pci passthrough work?
> It's usable; but not ported to newer kernel versions. I can't say when I'll > get around doing it. In the meanwhile if someone else is interested, drop me > a line. Do you mean interested in porting to newer versions (kvm + kernel) or interested in to use pvdma? If it's the latter, I am. -- 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: Status of pci passthrough work?
Hello, - "xming" wrote: > When can we expect pvdma updates? Is it ever going to be merged into > mainline kvm? The pvdma tree at http://git.kernel.org/?p=linux/kernel/git/amit/kvm.git;a=shortlog;h=pvdma is based of an older Linux version. It's usable; but not ported to newer kernel versions. I can't say when I'll get around doing it. In the meanwhile if someone else is interested, drop me a line. Amit. -- 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: [ANNOUNCE] kvm-81 release
Avi Kivity wrote: > This release fixes a bunch of display regressions, and restores > userspace/kernel compatibility with older kernel modules. There are a > few other goodies hidden in there, for example scsi is now enabled on >>4G guests. the best news in the last 10-20 kmv release we finally able to run all of our guests with kvm-81 (even mandrake-10:-))) the only problem that fedora-9's older kernel can not boot, but i boot with the latest fedora-9 kernel, upgrade to fedora-10 hand in graphical mode, crash in text mode and preupgrade hang with 100% cpu) so we can use only f-9. i hope it'll be easier to fix this fedora kernel's problem the the mandrake one. our setup: - host: - Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz - Intel S3000AHV - 8GB RAM - CentOS-5.2 - kernel-2.6.18-92.1.18.el5 x86_64 64bit - guest-1: - CentOS-5.2 - 4 vcpu - kernel-2.6.18-92.1.18.el5 i386 32bit - guest-2: - CentOS-5.2 - 4 vcpu - kernel-2.6.18-92.1.18.el5 x86_64 64bit - guest-3: - Mandrake-9 - 1 vcpu - kernel-2.4.19.16mdk-1-1mdk 32bit - guest-4: - Mandrake-10 - 1 vcpu - kernel-2.6.14.2-p4-smp 32bit - guest-5: - Windows XP Professional 32bit - 2 vcpu - guest-7: - Fedora-9 - 4 vcpu - kernel-2.6.27.5-37.fc9.i686 -- Levente "Si vis pacem para bellum!" -- 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:RE: [PATCH 1/3] KVM: pci passthrough un-page-aligned mmio device on machines w/o VT-d
2008-12-16，"Han, Weidong" wrote： >Pls note that multiple devices may share one page for their MMIO, and they may > be > assigned to different guests, there is potential isolation issue. So we don't > allow to assign these devices. In my view, we can modify the get_real_device() to open the file /proc/iomem to find out whether the "potential issue" is a real one, instead of disabling this feature all the times. Xiaojian Liu -- 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:RE: [PATCH 1/3] KVM: pci passthrough un-page-aligned mmio device on machines w/o VT-d
> In my view, we can modify the get_real_device() to open the file /dev/iomem to > find out whether the "potential issue" is a real one, instead of disabling > this > feature all the times. Sorry, I made a mistake. I mean the file /proc/iomem, not /dev/iomem. Regards, Xiaojian Liu -- 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] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO
Anthony Liguori wrote: There are still some issues I'm not happy yet: - handling of access violations: resolving should stop before the bad page, the transfers should be done until that and then post error. - bounce buffers needed for Lance byte swapping are not well designed (stack) I think you could approach the bouncing via a map/unmap API but I'm not sure. You would need a map() function to take a virtual address which is sort of weird. That would allow you to stack them in an arbitrary fashion though. I think that's broken. iommus converts physical addresses to physical addresses (or bus addresses), possibly generating faults along the way, and depending on the iommu context. map()/unmap() converts physical/bus addresses to virtual addresses, possibly bouncing. Except for both doing conversions, they're very different. This lead me to the thought that maybe we should not hide the bounce buffer activity, but instead make it more explicit for the device that needs bouncing. For the other device, the buffering or lack of it should be opaque. I think that's reasonable. I don't understand. It's not a device that needs bouncing, it's a particular transfer. This could be either due to the transfer targeting mmio, or due to the transfer requiring a transformation. Also the virtual-to-physical address resolution API could be generic, ie all resolver functions should take same parameters so that the devices would not need to know the next higher level device. Yes. I think this is key. The only observation I would make is that the resolution API should have some sort of release function (so map/unmap, lock/unlock, whatever). Also, in order to support chaining, the input and output parameters need to be the same (both sglists). -- error compiling committee.c: too many arguments to function -- 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: Qemu: save nvram
Hi
Please drop former.
This is the modify patch for save nvram.
I add the new command line arg of "-nvram file" to specify the location
Of the file. Without the arg ,it will save the nvram in the current dir
and named as "nvram.dat". Also, it will read the saved file "nvram.dat"
from current dir without the arg.
>From 902ac71c035a641ac0c9e0a0859d8198dfbe3319 Mon Sep 17 00:00:00 2001
From: Zhang Yang
Date: Mon, 15 Dec 2008 23:56:12 +0800
Subject: [PATCH] KVM : Qemu: Save nvram
Save nvram to the file
Signed-off-by: Zhang Yang
---
qemu/hw/ipf.c | 20 +++-
qemu/target-ia64/firmware.c | 110 --
qemu/target-ia64/firmware.h | 24 +-
qemu/vl.c |9
4 files changed, 154 insertions(+), 9 deletions(-)
diff --git a/qemu/hw/ipf.c b/qemu/hw/ipf.c
index 3e24c98..ba3f0b4 100644
--- a/qemu/hw/ipf.c
+++ b/qemu/hw/ipf.c
@@ -53,6 +53,7 @@ static fdctrl_t *floppy_controller;
static RTCState *rtc_state;
static PCIDevice *i440fx_state;
+uint8_t *g_fw_start;
static uint32_t ipf_to_legacy_io(target_phys_addr_t addr)
{
return (uint32_t)(((addr&0x3ff) >> 12 << 2)|((addr) & 0x3));
@@ -454,9 +455,14 @@ static void ipf_init1(ram_addr_t ram_size, int
vga_ram_size,
unsigned long image_size;
char *image = NULL;
uint8_t *fw_image_start;
+unsigned long nvram_addr = 0;
+unsigned long nvram_fd = 0;
+unsigned long type = READ_FROM_NVRAM;
+unsigned long i = 0;
ram_addr_t fw_offset = qemu_ram_alloc(GFW_SIZE);
uint8_t *fw_start = phys_ram_base + fw_offset;
+g_fw_start = fw_start;
snprintf(buf, sizeof(buf), "%s/%s", bios_dir, FW_FILENAME);
image = read_image(buf, &image_size );
if (NULL == image || !image_size) {
@@ -472,7 +478,19 @@ static void ipf_init1(ram_addr_t ram_size, int
vga_ram_size,
free(image);
flush_icache_range((unsigned long)fw_image_start,
(unsigned long)fw_image_start + image_size);
-kvm_ia64_build_hob(ram_size + above_4g_mem_size, smp_cpus, fw_start);
+
+nvram_addr = NVRAM_START;
+nvram_fd = kvm_ia64_nvram_init(type);
+if (nvram_fd != -1) {
+kvm_ia64_copy_from_nvram_to_GFW(nvram_fd, g_fw_start);
+close(nvram_fd);
+}
+i = atexit(kvm_ia64_copy_from_GFW_to_nvram);
+if (i != 0)
+fprintf(stderr, "cannot set exit function\n");
+
+kvm_ia64_build_hob(ram_size + above_4g_mem_size, smp_cpus,
+ fw_start, nvram_addr);
}
/*Register legacy io address space, size:64M*/
diff --git a/qemu/target-ia64/firmware.c b/qemu/target-ia64/firmware.c
index bac2721..88fcaa8 100644
--- a/qemu/target-ia64/firmware.c
+++ b/qemu/target-ia64/firmware.c
@@ -31,6 +31,8 @@
#include "firmware.h"
+#include "qemu-common.h"
+
typedef struct {
unsigned long signature;
unsigned int type;
@@ -85,14 +87,16 @@ static int hob_init(void *buffer ,unsigned long buf_size);
static int add_pal_hob(void* hob_buf);
static int add_mem_hob(void* hob_buf, unsigned long dom_mem_size);
static int add_vcpus_hob(void* hob_buf, unsigned long nr_vcpu);
-static int build_hob(void* hob_buf, unsigned long hob_buf_size,
- unsigned long dom_mem_size, unsigned long vcpus);
+static int add_nvram_hob(void *hob_buf, unsigned long nvram_addr);
+static int build_hob(void *hob_buf, unsigned long hob_buf_size,
+ unsigned long dom_mem_size, unsigned long vcpus,
+ unsigned long nvram_addr);
static int load_hob(void *hob_buf,
unsigned long dom_mem_size, void* hob_start);
int
-kvm_ia64_build_hob(unsigned long memsize,
- unsigned long vcpus, uint8_t* fw_start)
+kvm_ia64_build_hob(unsigned long memsize, unsigned long vcpus,
+ uint8_t *fw_start, unsigned long nvram_addr)
{
char *hob_buf;
@@ -102,7 +106,7 @@ kvm_ia64_build_hob(unsigned long memsize,
return -1;
}
-if (build_hob(hob_buf, GFW_HOB_SIZE, memsize, vcpus) < 0) {
+if (build_hob(hob_buf, GFW_HOB_SIZE, memsize, vcpus, nvram_addr) < 0) {
free(hob_buf);
Hob_Output("Could not build hob");
return -1;
@@ -206,7 +210,8 @@ add_max_hob_entry(void* hob_buf)
static int
build_hob(void* hob_buf, unsigned long hob_buf_size,
- unsigned long dom_mem_size, unsigned long vcpus)
+ unsigned long dom_mem_size, unsigned long vcpus,
+ unsigned long nvram_addr)
{
//Init HOB List
if (hob_init(hob_buf, hob_buf_size) < 0) {
@@ -229,6 +234,11 @@ build_hob(void* hob_buf, unsigned long hob_buf_size,
goto err_out;
}
+if (add_nvram_hob(hob_buf, nvram_addr) < 0) {
+ Hob_Output("Add nvram hob failed, buffer too small");
+ goto err_out;
+ }
+
if (add_max_hob_entry(ho
[ kvm-Bugs-2411975 ] PAE Vista Guest display broken
Bugs item #2411975, was opened at 2008-12-09 07:24 Message generated for change (Comment added) made by jiajun You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2411975&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Jiajun Xu (jiajun) Assigned to: Nobody/Anonymous (nobody) >Summary: PAE Vista Guest display broken Initial Comment: Testing Environment: Kernel Commit:9ff66047142bd6a22825ada67eeaebbdf60c0280 Userspace Commit:8eae225cf8cd82316fcc78569aeb1adbbc077cb8 Host Kernel Version: 2.6.28-rc6 Bug detailed description: -- PAE Vista guest may not be able to boot on PAE host. (1) If with 2 vcpus assigned, vista guest can never boot up. (2) If 1 vcpus assigned, sometimes Vista guest can boot up and get network up, but the guest display always shows nothing(black). (3) on 32e platform PAE and IA32e Vista guest can boot up well with smp=1 and smp=2. Reproduce steps: (1) qemu-img create -b /share/xvs/img/Windows/ia32p_vista.img -f qcow2 /share/xvs/var/tmp-img_gbp18_1228724677_1 (2) qemu-system-x86_64 -m 768 -smp 2 -net nic,macaddr=00:16:3e:0a:52:36,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -hda /share/xvs/var/tmp-img_gbp18_1228730668_1 -- >Comment By: Jiajun Xu (jiajun) Date: 2008-12-16 00:51 Message: I changed the bug title since the commit 18b8d7e31fda064559e5ddb06e6dd3a2ff21cca0 is for display issue on 32bit host. And we verified with the commit, the issue is fixed. -- Comment By: Avi Kivity (avik) Date: 2008-12-14 05:19 Message: Fixed by: commit 18b8d7e31fda064559e5ddb06e6dd3a2ff21cca0 Author: Avi Kivity Date: Sun Dec 14 15:16:27 2008 +0200 kvm: libkvm: check for slot overlap using 64-bit arithmetic otherwise, a slot that ends on the 4GB boundary wraps around, resulting in a false positive, and leading to an early failure when attempting to get the bios slot's dirty log (which doesn't have dirty logging enabled). fixed broken display on 32-bit userspace. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2411975&group_id=180599 -- 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
