Re: [Qemu-devel] Re: [kvm-devel] FreeBSD image hangs during boot
Fabrice Bellard wrote: Avi Kivity wrote: Aurelien Jarno wrote: Well the IDE code hasn't changed a lot recently, so I checked the CVS history and easily (first test) found the commit that causes the problem: Last AIO patch, by Vladimir N. Oleynik. http://cvs.savannah.nongnu.org/viewvc/qemu/hw/ide.c?root=qemur1=1.64r2=1.65 Have we learned something about this issue? Should I revert the patch from kvm? Should qemu? Sure. The conversion from sync to async mode done in this patch is incomplete to say the least. Is reverting the patch safe, or will it cause new problems? (I'm not sure what Sure above refers to) -- error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH 2/2] KVM Userspace: IRQ injection into guest
This kernel module injects IRQs specified on the command line
via the passthrough parameter
This doesn't handle shared interrupts.
These patches don't yet work with the in-kernel apic, so you have
to use -no-kvm-irqchip.
These will soon be overridden by a new mechanism that utilises
the in-kernel apic.
Signed-off-by: Amit Shah [EMAIL PROTECTED]
---
Makefile | 10 ++-
irqhook/Kbuild |3 +
irqhook/Makefile | 25 ++
irqhook/irqhook_main.c | 217
4 files changed, 251 insertions(+), 4 deletions(-)
create mode 100644 irqhook/Kbuild
create mode 100644 irqhook/Makefile
create mode 100644 irqhook/irqhook_main.c
diff --git a/Makefile b/Makefile
index 776ff01..4ba6221 100644
--- a/Makefile
+++ b/Makefile
@@ -5,13 +5,13 @@ DESTDIR=
rpmrelease = devel
-.PHONY: kernel user libkvm qemu bios clean
+.PHONY: kernel irqhook user libkvm qemu bios clean
-all: $(if $(WANT_MODULE), kernel) user libkvm qemu
+all: $(if $(WANT_MODULE), kernel irqhook) user libkvm qemu
kcmd = $(if $(WANT_MODULE),,@\#)
-qemu kernel user libkvm:
+qemu kernel user irqhook libkvm:
$(MAKE) -C $@
qemu: libkvm
@@ -42,6 +42,7 @@ install-rpm:
install:
$(kcmd)make -C kernel DESTDIR=$(DESTDIR) install
+ $(kcmd)make -C irqhook DESTDIR=$(DESTDIR) install
make -C libkvm DESTDIR=$(DESTDIR) install
make -C qemu DESTDIR=$(DESTDIR) install
@@ -62,13 +63,14 @@ srpm:
tar czf SOURCES/user.tar.gz user
tar czf SOURCES/libkvm.tar.gz libkvm
tar czf SOURCES/kernel.tar.gz kernel
+ tar czf SOURCES/irqhook.tar.gz irqhook
tar czf SOURCES/scripts.tar.gz scripts
cp Makefile configure kvm_stat SOURCES
rpmbuild --define=_topdir $$(pwd) -bs $(tmpspec)
$(RM) $(tmpspec)
clean:
- for i in $(if $(WANT_MODULE), kernel) user libkvm qemu; do \
+ for i in $(if $(WANT_MODULE), kernel irqhook) user libkvm qemu; do \
make -C $$i clean; \
done
rm -f config.mak user/config.mak
diff --git a/irqhook/Kbuild b/irqhook/Kbuild
new file mode 100644
index 000..9af75a4
--- /dev/null
+++ b/irqhook/Kbuild
@@ -0,0 +1,3 @@
+EXTRA_CFLAGS := -I$(src)/include
+obj-m := irqhook.o
+irqhook-objs := irqhook_main.o
diff --git a/irqhook/Makefile b/irqhook/Makefile
new file mode 100644
index 000..3b1d851
--- /dev/null
+++ b/irqhook/Makefile
@@ -0,0 +1,25 @@
+include ../config.mak
+
+KVERREL = $(patsubst /lib/modules/%/build,%,$(KERNELDIR))
+
+DESTDIR=
+
+INSTALLDIR = $(patsubst %/build,%/extra,$(KERNELDIR))
+
+rpmrelease = devel
+
+LINUX = ../linux-2.6
+
+all::
+ $(MAKE) -C $(KERNELDIR) M=`pwd` $$@
+
+#sync:
+# rsync --exclude='*.mod.c' $(LINUX)/drivers/irqhook/*.[ch] .
+
+install:
+ mkdir -p $(DESTDIR)/$(INSTALLDIR)
+ cp *.ko $(DESTDIR)/$(INSTALLDIR)
+ /sbin/depmod -a
+
+clean:
+ $(MAKE) -C $(KERNELDIR) M=`pwd` $@
diff --git a/irqhook/irqhook_main.c b/irqhook/irqhook_main.c
new file mode 100644
index 000..812b714
--- /dev/null
+++ b/irqhook/irqhook_main.c
@@ -0,0 +1,217 @@
+#include linux/module.h
+#include linux/kernel.h
+#include linux/fs.h
+#include linux/bitmap.h
+#include linux/interrupt.h
+#include linux/spinlock.h
+#include linux/miscdevice.h
+#include linux/pci.h
+
+#include asm/uaccess.h
+
+#define irqh_VERSION 0.0.1
+#define irqh_MODULE_NAME irqhook
+#define irqh_DRIVER_NAME irqh_MODULE_NAME HW IRQ hook irqh_VERSION
+
+// based on earlier proprietary Tutis code; this modified version goes under
GPL
+MODULE_AUTHOR(Nir Peleg - Tutis);
+MODULE_DESCRIPTION(IRQ hook driver);
+MODULE_LICENSE(GPL);
+
+//#define irqh_DEBUG /* define to enable copious debugging info */
+
+#ifdef irqh_DEBUG
+#define DPRINTK(fmt, args...) printk(1 %s: fmt, __FUNCTION__ , ## args)
+#else
+#define DPRINTK(fmt, args...)
+#endif
+
+#define ERROR(fmt, args...) printk(1 %s: fmt, __FUNCTION__ , ## args)
+
+static spinlock_t irqh_lock;
+static wait_queue_head_t irqh_proc_list;
+
+enum {NINTR = 256};
+
+static DECLARE_BITMAP(pending, NINTR);
+static DECLARE_BITMAP(handled, NINTR);
+
+#define irqh_on(which, bit)test_bit(bit, which)
+#define irqh_set(which, bit) set_bit(bit, which)
+#define irqh_clear(which, bit) clear_bit(bit, which)
+#define irqh_ffs(which)find_first_bit(which, NINTR)
+
+static irqreturn_t
+irqh_interrupt(int irq, void *p)
+{
+ unsigned long flags;
+
+ DPRINTK(interrupt: %d\n, irq);
+ if (!irqh_on(handled, irq))
+ return IRQ_HANDLED;
+ spin_lock_irqsave(irqh_lock, flags);
+ irqh_set(pending, irq);
+ wake_up_interruptible(irqh_proc_list);
+ spin_unlock_irqrestore(irqh_lock, flags);
+ disable_irq_nosync(irq);
+ return IRQ_HANDLED;
+}
+
+static ssize_t
+irqh_dev_write(struct file *fp, const char *buf, size_t size, loff_t *offp)
+{
+ int n, device, func, devfn;
+ char arg[32], *cp, *cp1;
+ struct pci_dev *pdp
Re: [Qemu-devel] Re: [kvm-devel] FreeBSD image hangs during boot
Avi Kivity wrote: Fabrice Bellard wrote: Avi Kivity wrote: Aurelien Jarno wrote: Well the IDE code hasn't changed a lot recently, so I checked the CVS history and easily (first test) found the commit that causes the problem: Last AIO patch, by Vladimir N. Oleynik. http://cvs.savannah.nongnu.org/viewvc/qemu/hw/ide.c?root=qemur1=1.64r2=1.65 Have we learned something about this issue? Should I revert the patch from kvm? Should qemu? Sure. The conversion from sync to async mode done in this patch is incomplete to say the least. Is reverting the patch safe, or will it cause new problems? The patch must be reverted because it implements incorrectly the AIO write case (e.g. nsector is modified before the IO actually takes place). The previous code was at least correct if win2k_install_hack was not enabled and if one considered than the PIO I/Os were instantaneous. Regards, Fabrice.
Re: [kvm-devel] [Qemu-devel] [PATCH 1/2] KVM userspace: Add PCI device passthrough support
Fabrice Bellard wrote: Hi, Some remarks: - rename the option to -pcidevice. - Remove the directory passthrough and put the file directly in hw/. Rename the file to something more explicit such as pci_passthrough* - Suppress the files passthrough.h and neo_pci_tree.h - pt_init should be called only if there are really devices. Moreover the code should be disabled for non Linux hosts. Can this support work if KVM is not used for CPU emulation ? Can it work for non x86 targets ? This patchset can work without kvm (although not tested). It can do so using a kernel module that forwards irqs to userspace. I'm not sure it will make it into Linux kernel since it allows userspace irq handling. We actually try to convert the current patch to our in-kernel apic version that won't forward irqs to userspace and hence won't work without kvm. If you're interested in pass through to qemu/kqemu (seems like a cool feature) we can try to support both. Dor. Regards, Fabrice. Amit Shah wrote: This patch introduces support for device passthrough from the host to a paravirtualized guest. A new command-line option, -passthrough is added. For example, to invoke it for an Ethernet device sitting at PCI bus:dev.fn 04:08.0 with host IRQ 18, use this: -passthrough Ethernet/04:08.0-18 The host driver is to be removed before doing the passthrough.
Re: [Qemu-devel] [PATCH 1/3] Add args to -cdrom to define where is connected the cdrom
Laurent Vivier wrote: Le jeudi 08 novembre 2007 à 00:32 +0100, Fabrice Bellard a écrit : Laurent Vivier wrote: Thiemo Seufer a écrit : Laurent Vivier wrote: Daniel P. Berrange a écrit : On Sun, Oct 28, 2007 at 11:43:33PM +0100, [EMAIL PROTECTED] wrote: From: Laurent Vivier [EMAIL PROTECTED](none) This patch allows to define where is connected the CDROM device (bus, unit). It extends the -cdrom syntax to add these paramaters: -cdrom file[,if=type][,bus=n][,unit=m] where type defines the interface (by default, ide) n defines the bus number (by default 1) m defines the unit number (by default 0) Having a separately named arg just for CDROMs was always rather odd/unhelpful. I'd suggest that we leave all the -hda,hdb,hdc,-cdrom,-fda,-fdb etc unchanged and use the -disk for setting up all types of disks, floppys, cdroms, etc. It would just require one extra field for the -disk arg: -disk file[,if=type][,bus=n][,unit=m][,mode=mode] where type defines the interface. [ide,scsi,fd] (by default, ide) n defines the bus number (by default 1) m defines the unit number (by default 0) mode defines one of [disk,floppy,cdrom] If we ever up able to emulate other types of SCSI / IDE devices (tape drives, cdr, dvd perhaps) then the 'mode' can easily be extended to cover them. I agree with that. And if everyone agrees I can modify patches to do that... Please go ahead. :-) Well, it is done... is there someone that can comment them ? Or if they are perfect (as usual ;-) ) perhaps it could be included in CVS ? I had rejected a similar patch in the past, but I agree that a -disk command line option is needed. A few remarks: - Add a function in vl.c to add a disk so that all option handlers can call it instead of doing pstrcpy(); nb_disk++. I agree - You replaced the constant 2 in many machines by MAX_IDE_BUS. It is dangerous because each machine has its own constraints. I agree, I'll use MAX_IDE_BUS only for PC. But how can I compute MAX_DISKS if the number of IDE disks vary with target ? What is important is that MAX_IDE_BUS is bigger than the number of IDE disks used by every machine. If the machine does not use them it is less an issue. If you use DriveInfo you no longer have this problem. For the moment it is the sum of all available MAX_* . Should I take an explicit value like 32 or something like ? If you use my suggestion of DriveInfo structure, this problem disappears as you will have a single constant MAX_DISKS that you can set to a fixed value. - Maybe the real option name could be -drive to insist on the fact that a drive can be created without a disk in it ! Any more comments ? I agree, and a drive can be something else like a flash or a tape (in the future...). - disk_init() should not modify its argument str. Moreover, maybe having an explicit file= argument would be clearer in the case there is no disk in the drive. I'm not sure I understand correctly this one. For the moment -disk , allows to declare a drive without media (an empty CDROM drive, for instance). Do you mean we must use -drive file=a.img instead of -disk a.img and -drive file= instead of -disk , Yes -disk file=a.img or -disk media=cdrom. But I am open to other suggestion. I was just surprised by the syntax -disk ,media=cdrom. - While modifying the machine init function, you can suppress the snapshot parameter. OK - In disk_init(), you should factorize the bdrv_new() and bdrv_open() as it is the same for all types. OK. Can I use bdrv_set_geometry_hint() and bdrv_set_translation_hint() before the bdrv_open() ? It seems possible. - It could be simpler to export an array of structs containg a bdrv, each one tagged with if, index and bus. Then each machine could call a function to get the bdrv from the parameters if, index and bus. For example, look at the NICInfo structure and do the same with a structure DriveInfo... OK If you prefer, you can resubmit a big patch with all the changes. Well, I like to write a lot of little patches ;-) It is easier to review them, isn't it ? But it is as you want. As you wish. Regards, Fabrice.
[Qemu-devel] [PATCH 1/2] KVM userspace: Add PCI device passthrough support
This patch introduces support for device passthrough
from the host to a paravirtualized guest.
A new command-line option, -passthrough is added.
For example, to invoke it for an Ethernet device sitting at
PCI bus:dev.fn 04:08.0 with host IRQ 18, use this:
-passthrough Ethernet/04:08.0-18
The host driver is to be removed before doing the passthrough.
Signed-off-by: Amit Shah [EMAIL PROTECTED]
---
qemu/Makefile |6 +-
qemu/Makefile.target |4 +-
qemu/exec.c|1 +
qemu/hw/apic.c |2 +
qemu/hw/passthrough/neo_pci_tree.h | 44 +++
qemu/hw/passthrough/passthrough.c | 604
qemu/hw/passthrough/passthrough.h | 64
qemu/hw/pc.c |3 +
qemu/hw/pci.c |5 +
qemu/hw/piix_pci.c |6 +
qemu/vl.c |6 +
tools/pci_barsize.c| 53
tools/pci_mmio.c | 82 +
13 files changed, 876 insertions(+), 4 deletions(-)
create mode 100644 qemu/hw/passthrough/neo_pci_tree.h
create mode 100644 qemu/hw/passthrough/passthrough.c
create mode 100644 qemu/hw/passthrough/passthrough.h
create mode 100644 tools/pci_barsize.c
create mode 100644 tools/pci_mmio.c
diff --git a/qemu/Makefile b/qemu/Makefile
index 053c88c..3e599f3 100644
--- a/qemu/Makefile
+++ b/qemu/Makefile
@@ -37,7 +37,7 @@ qemu-img$(EXESUF): qemu-img.c cutils.c block.c block-raw.c
block-cow.c block-qco
dyngen$(EXESUF): dyngen.c
$(HOST_CC) $(CFLAGS) $(CPPFLAGS) $(BASE_CFLAGS) -o $@ $^
-clean:
+clean:
# avoid old build problems by removing potentially incorrect old files
rm -f config.mak config.h op-i386.h opc-i386.h gen-op-i386.h op-arm.h
opc-arm.h gen-op-arm.h
rm -f *.o *.a $(TOOLS) dyngen$(EXESUF) TAGS cscope.* *.pod *~ */*~
@@ -88,8 +88,8 @@ endif
test speed test2: all
$(MAKE) -C tests $@
-TAGS:
- etags *.[ch] tests/*.[ch]
+TAGS:
+ etags *.[ch] tests/*.[ch] hw/passthrough/*.[ch]
cscope:
rm -f ./cscope.*
diff --git a/qemu/Makefile.target b/qemu/Makefile.target
index 65f449e..9a96011 100644
--- a/qemu/Makefile.target
+++ b/qemu/Makefile.target
@@ -24,7 +24,7 @@ ifeq ($(TARGET_ARCH), sparc64)
TARGET_BASE_ARCH:=sparc
endif
TARGET_PATH=$(SRC_PATH)/target-$(TARGET_BASE_ARCH)
-VPATH=$(SRC_PATH):$(TARGET_PATH):$(SRC_PATH)/hw:$(SRC_PATH)/audio
+VPATH=$(SRC_PATH):$(TARGET_PATH):$(SRC_PATH)/hw:$(SRC_PATH)/hw/passthrough:$(SRC_PATH)/audio
CPPFLAGS=-I. -I.. -I$(TARGET_PATH) -I$(SRC_PATH)
ifdef CONFIG_DARWIN_USER
VPATH+=:$(SRC_PATH)/darwin-user
@@ -454,6 +454,8 @@ VL_OBJS+= ide.o pckbd.o ps2.o vga.o $(SOUND_HW) dma.o
$(AUDIODRV)
VL_OBJS+= fdc.o mc146818rtc.o serial.o i8259.o i8254.o pcspk.o pc.o
VL_OBJS+= cirrus_vga.o apic.o parallel.o acpi.o piix_pci.o
VL_OBJS+= usb-uhci.o smbus_eeprom.o vmmouse.o vmport.o vmware_vga.o
+# passthrough support
+VL_OBJS+= passthrough.o
CPPFLAGS += -DHAS_AUDIO -DHAS_AUDIO_CHOICE
endif
ifeq ($(TARGET_BASE_ARCH), ppc)
diff --git a/qemu/exec.c b/qemu/exec.c
index 3e588d5..7a21ca5 100644
--- a/qemu/exec.c
+++ b/qemu/exec.c
@@ -2484,6 +2484,7 @@ int cpu_register_io_memory(int io_index,
if (io_mem_nb = IO_MEM_NB_ENTRIES)
return -1;
io_index = io_mem_nb++;
+ fprintf(stderr, iomem index %d out of %d\n, io_index,
IO_MEM_NB_ENTRIES);
} else {
if (io_index = IO_MEM_NB_ENTRIES)
return -1;
diff --git a/qemu/hw/apic.c b/qemu/hw/apic.c
index 60d31fa..5b1bdf4 100644
--- a/qemu/hw/apic.c
+++ b/qemu/hw/apic.c
@@ -349,6 +349,7 @@ static void apic_eoi(APICState *s)
/* XXX: send the EOI packet to the APIC bus to allow the I/O APIC to
set the remote IRR bit for level triggered interrupts. */
apic_update_irq(s);
+pt_ack_mirq(isrv);
}
static void apic_get_delivery_bitmask(uint32_t *deliver_bitmask,
@@ -1122,6 +1123,7 @@ static void ioapic_mem_writel(void *opaque,
target_phys_addr_t addr, uint32_t va
} else {
s-ioredtbl[index] = ~0xULL;
s-ioredtbl[index] |= val;
+pt_set_vector(index, (val 24) 24);
}
ioapic_service(s);
}
diff --git a/qemu/hw/passthrough/neo_pci_tree.h
b/qemu/hw/passthrough/neo_pci_tree.h
new file mode 100644
index 000..79adef9
--- /dev/null
+++ b/qemu/hw/passthrough/neo_pci_tree.h
@@ -0,0 +1,44 @@
+/*
+
+Some data structures to save the result of the PCI probing.
+
+Copyright (c) 2007, Neocleus: Guy Zana, Alex Novik
+
+**/
+
+#ifndef __XC_NEO_PCI_TREE_H__
+#define __XC_NEO_PCI_TREE_H__
+
+#include linux/types.h
+
+typedef __u8 u8;
+typedef
Re: [Qemu-devel] [PATCH 1/3] Add args to -cdrom to define where is connected the cdrom
Le jeudi 08 novembre 2007 à 00:32 +0100, Fabrice Bellard a écrit : Laurent Vivier wrote: Thiemo Seufer a écrit : Laurent Vivier wrote: Daniel P. Berrange a écrit : On Sun, Oct 28, 2007 at 11:43:33PM +0100, [EMAIL PROTECTED] wrote: From: Laurent Vivier [EMAIL PROTECTED](none) This patch allows to define where is connected the CDROM device (bus, unit). It extends the -cdrom syntax to add these paramaters: -cdrom file[,if=type][,bus=n][,unit=m] where type defines the interface (by default, ide) n defines the bus number (by default 1) m defines the unit number (by default 0) Having a separately named arg just for CDROMs was always rather odd/unhelpful. I'd suggest that we leave all the -hda,hdb,hdc,-cdrom,-fda,-fdb etc unchanged and use the -disk for setting up all types of disks, floppys, cdroms, etc. It would just require one extra field for the -disk arg: -disk file[,if=type][,bus=n][,unit=m][,mode=mode] where type defines the interface. [ide,scsi,fd] (by default, ide) n defines the bus number (by default 1) m defines the unit number (by default 0) mode defines one of [disk,floppy,cdrom] If we ever up able to emulate other types of SCSI / IDE devices (tape drives, cdr, dvd perhaps) then the 'mode' can easily be extended to cover them. I agree with that. And if everyone agrees I can modify patches to do that... Please go ahead. :-) Well, it is done... is there someone that can comment them ? Or if they are perfect (as usual ;-) ) perhaps it could be included in CVS ? I had rejected a similar patch in the past, but I agree that a -disk command line option is needed. A few remarks: - Add a function in vl.c to add a disk so that all option handlers can call it instead of doing pstrcpy(); nb_disk++. I agree - You replaced the constant 2 in many machines by MAX_IDE_BUS. It is dangerous because each machine has its own constraints. I agree, I'll use MAX_IDE_BUS only for PC. But how can I compute MAX_DISKS if the number of IDE disks vary with target ? For the moment it is the sum of all available MAX_* . Should I take an explicit value like 32 or something like ? - Maybe the real option name could be -drive to insist on the fact that a drive can be created without a disk in it ! Any more comments ? I agree, and a drive can be something else like a flash or a tape (in the future...). - disk_init() should not modify its argument str. Moreover, maybe having an explicit file= argument would be clearer in the case there is no disk in the drive. I'm not sure I understand correctly this one. For the moment -disk , allows to declare a drive without media (an empty CDROM drive, for instance). Do you mean we must use -drive file=a.img instead of -disk a.img and -drive file= instead of -disk , - While modifying the machine init function, you can suppress the snapshot parameter. OK - In disk_init(), you should factorize the bdrv_new() and bdrv_open() as it is the same for all types. OK. Can I use bdrv_set_geometry_hint() and bdrv_set_translation_hint() before the bdrv_open() ? - It could be simpler to export an array of structs containg a bdrv, each one tagged with if, index and bus. Then each machine could call a function to get the bdrv from the parameters if, index and bus. For example, look at the NICInfo structure and do the same with a structure DriveInfo... OK If you prefer, you can resubmit a big patch with all the changes. Well, I like to write a lot of little patches ;-) It is easier to review them, isn't it ? But it is as you want. Regards, Fabrice. Thank you for your comments, Laurent signature.asc Description: Ceci est une partie de message numériquement signée
Re: [Qemu-devel] [PATCH 1/2] KVM userspace: Add PCI device passthrough support
Hi,
Some remarks:
- rename the option to -pcidevice.
- Remove the directory passthrough and put the file directly in hw/.
Rename the file to something more explicit such as pci_passthrough*
- Suppress the files passthrough.h and neo_pci_tree.h
- pt_init should be called only if there are really devices. Moreover
the code should be disabled for non Linux hosts.
Can this support work if KVM is not used for CPU emulation ? Can it work
for non x86 targets ?
Regards,
Fabrice.
Amit Shah wrote:
This patch introduces support for device passthrough
from the host to a paravirtualized guest.
A new command-line option, -passthrough is added.
For example, to invoke it for an Ethernet device sitting at
PCI bus:dev.fn 04:08.0 with host IRQ 18, use this:
-passthrough Ethernet/04:08.0-18
The host driver is to be removed before doing the passthrough.
Signed-off-by: Amit Shah [EMAIL PROTECTED]
---
qemu/Makefile |6 +-
qemu/Makefile.target |4 +-
qemu/exec.c|1 +
qemu/hw/apic.c |2 +
qemu/hw/passthrough/neo_pci_tree.h | 44 +++
qemu/hw/passthrough/passthrough.c | 604
qemu/hw/passthrough/passthrough.h | 64
qemu/hw/pc.c |3 +
qemu/hw/pci.c |5 +
qemu/hw/piix_pci.c |6 +
qemu/vl.c |6 +
tools/pci_barsize.c| 53
tools/pci_mmio.c | 82 +
13 files changed, 876 insertions(+), 4 deletions(-)
create mode 100644 qemu/hw/passthrough/neo_pci_tree.h
create mode 100644 qemu/hw/passthrough/passthrough.c
create mode 100644 qemu/hw/passthrough/passthrough.h
create mode 100644 tools/pci_barsize.c
create mode 100644 tools/pci_mmio.c
diff --git a/qemu/Makefile b/qemu/Makefile
index 053c88c..3e599f3 100644
--- a/qemu/Makefile
+++ b/qemu/Makefile
@@ -37,7 +37,7 @@ qemu-img$(EXESUF): qemu-img.c cutils.c block.c block-raw.c
block-cow.c block-qco
dyngen$(EXESUF): dyngen.c
$(HOST_CC) $(CFLAGS) $(CPPFLAGS) $(BASE_CFLAGS) -o $@ $^
-clean:
+clean:
# avoid old build problems by removing potentially incorrect old files
rm -f config.mak config.h op-i386.h opc-i386.h gen-op-i386.h op-arm.h
opc-arm.h gen-op-arm.h
rm -f *.o *.a $(TOOLS) dyngen$(EXESUF) TAGS cscope.* *.pod *~ */*~
@@ -88,8 +88,8 @@ endif
test speed test2: all
$(MAKE) -C tests $@
-TAGS:
- etags *.[ch] tests/*.[ch]
+TAGS:
+ etags *.[ch] tests/*.[ch] hw/passthrough/*.[ch]
cscope:
rm -f ./cscope.*
diff --git a/qemu/Makefile.target b/qemu/Makefile.target
index 65f449e..9a96011 100644
--- a/qemu/Makefile.target
+++ b/qemu/Makefile.target
@@ -24,7 +24,7 @@ ifeq ($(TARGET_ARCH), sparc64)
TARGET_BASE_ARCH:=sparc
endif
TARGET_PATH=$(SRC_PATH)/target-$(TARGET_BASE_ARCH)
-VPATH=$(SRC_PATH):$(TARGET_PATH):$(SRC_PATH)/hw:$(SRC_PATH)/audio
+VPATH=$(SRC_PATH):$(TARGET_PATH):$(SRC_PATH)/hw:$(SRC_PATH)/hw/passthrough:$(SRC_PATH)/audio
CPPFLAGS=-I. -I.. -I$(TARGET_PATH) -I$(SRC_PATH)
ifdef CONFIG_DARWIN_USER
VPATH+=:$(SRC_PATH)/darwin-user
@@ -454,6 +454,8 @@ VL_OBJS+= ide.o pckbd.o ps2.o vga.o $(SOUND_HW) dma.o
$(AUDIODRV)
VL_OBJS+= fdc.o mc146818rtc.o serial.o i8259.o i8254.o pcspk.o pc.o
VL_OBJS+= cirrus_vga.o apic.o parallel.o acpi.o piix_pci.o
VL_OBJS+= usb-uhci.o smbus_eeprom.o vmmouse.o vmport.o vmware_vga.o
+# passthrough support
+VL_OBJS+= passthrough.o
CPPFLAGS += -DHAS_AUDIO -DHAS_AUDIO_CHOICE
endif
ifeq ($(TARGET_BASE_ARCH), ppc)
diff --git a/qemu/exec.c b/qemu/exec.c
index 3e588d5..7a21ca5 100644
--- a/qemu/exec.c
+++ b/qemu/exec.c
@@ -2484,6 +2484,7 @@ int cpu_register_io_memory(int io_index,
if (io_mem_nb = IO_MEM_NB_ENTRIES)
return -1;
io_index = io_mem_nb++;
+ fprintf(stderr, iomem index %d out of %d\n, io_index,
IO_MEM_NB_ENTRIES);
} else {
if (io_index = IO_MEM_NB_ENTRIES)
return -1;
diff --git a/qemu/hw/apic.c b/qemu/hw/apic.c
index 60d31fa..5b1bdf4 100644
--- a/qemu/hw/apic.c
+++ b/qemu/hw/apic.c
@@ -349,6 +349,7 @@ static void apic_eoi(APICState *s)
/* XXX: send the EOI packet to the APIC bus to allow the I/O APIC to
set the remote IRR bit for level triggered interrupts. */
apic_update_irq(s);
+pt_ack_mirq(isrv);
}
static void apic_get_delivery_bitmask(uint32_t *deliver_bitmask,
@@ -1122,6 +1123,7 @@ static void ioapic_mem_writel(void *opaque,
target_phys_addr_t addr, uint32_t va
} else {
s-ioredtbl[index] = ~0xULL;
s-ioredtbl[index] |= val;
+pt_set_vector(index, (val 24) 24);
}
ioapic_service(s);
}
diff --git a/qemu/hw/passthrough/neo_pci_tree.h
b/qemu/hw/passthrough/neo_pci_tree.h
new file mode 100644
index 000..79adef9
--- /dev/null
+++
Re: [Qemu-devel] Re: [kvm-devel] FreeBSD image hangs during boot
Avi Kivity wrote: Aurelien Jarno wrote: Well the IDE code hasn't changed a lot recently, so I checked the CVS history and easily (first test) found the commit that causes the problem: Last AIO patch, by Vladimir N. Oleynik. http://cvs.savannah.nongnu.org/viewvc/qemu/hw/ide.c?root=qemur1=1.64r2=1.65 Have we learned something about this issue? Should I revert the patch from kvm? Should qemu? Sure. The conversion from sync to async mode done in this patch is incomplete to say the least. Fabrice.
[Qemu-devel] Re: [kvm-devel] FreeBSD image hangs during boot
Avi Kivity a écrit : Aurelien Jarno wrote: Well the IDE code hasn't changed a lot recently, so I checked the CVS history and easily (first test) found the commit that causes the problem: Last AIO patch, by Vladimir N. Oleynik. http://cvs.savannah.nongnu.org/viewvc/qemu/hw/ide.c?root=qemur1=1.64r2=1.65 Have we learned something about this issue? Should I revert the patch from kvm? Should qemu? From my side, I haven't found time to debug the problem. Instead I am reverting this patch locally each time I install qemu or kvm. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net
RE: [Qemu-devel] No cancel callback for usb-ohci
Seems like an ugly bug (common also to uhci), which I haven't noticed before. I guess this scenario has never happened to me. Can you please describe it? Call usb_defer_packet with cancel_cb which flags the packet, so the following usb_packet_complete will be ignored. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Salil Bijur Sent: Thursday, November 08, 2007 8:51 AM To: qemu-devel@nongnu.org Subject: [Qemu-devel] No cancel callback for usb-ohci Hello, There is a call to the function usb_cancel_packet in hw/usb-ohci.c. However, there is no cancel_cb callback registered for the ohci-usb_packet resulting in a segmentation fault. Are there any plans to implement this cancel callback? Thanks, Salil
Re: [Qemu-devel] Removal of some target CPU macros
Two side comments: Note that most (all ?) embedded Freescale PowerPC microcontrollers implement those extensions and that some ones are greatly interrested with having an usable emulation avaible for those CPUs. Has anyone started to implement spe ? - someone provide an open-source hypervisor, compatible with the ones used on real machines, that would allow at least Linux to be able to run on a CPU with hypervisor mode available. Does xen/ppc satisfy your requirement ? Maybe Hollis will comment.
RE: [Qemu-devel] No cancel callback for usb-ohci
You may add a flag to USBPacket and raise it upon your ohci_async_cancel_packet. ohci_async_complete_packet will check this flag and do nothing if it is up. Am I missing something? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Salil Bijur Sent: Thursday, November 08, 2007 12:47 PM To: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] No cancel callback for usb-ohci Hi Arnon, On Nov 8, 2007 3:28 PM, Arnon Gilboa [EMAIL PROTECTED] wrote: Seems like an ugly bug (common also to uhci), which I haven't noticed before. I guess this scenario has never happened to me. Can you please describe it? What I'm trying to do is to prevent the lag caused by the USBDEVFS_BULK ioctl and instead send the bulk transfers asynchronously using the USBDEVFS_SUBMITURB ioctl. I'm taking the help of the patch you had sent for isochronous packets. This scenario occurs when the usb bluetooth dongle is added to the linux guest and its interface is brought up. Call usb_defer_packet with cancel_cb which flags the packet, so the following usb_packet_complete will be ignored. To call usb_defer_packet, there needs to be a callback function like the usb_msd_cancel_io function used in hw/usb-msd.c: usb_defer_packet(p, usb_msd_cancel_io, s); There doesn't seem to be a similar cancel_cb callback for ohci. An empty stub function prevents this crash, but should it be doing more stuff like the msd one does? Salil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Salil Bijur Sent: Thursday, November 08, 2007 8:51 AM To: qemu-devel@nongnu.org Subject: [Qemu-devel] No cancel callback for usb-ohci Hello, There is a call to the function usb_cancel_packet in hw/usb-ohci.c. However, there is no cancel_cb callback registered for the ohci-usb_packet resulting in a segmentation fault. Are there any plans to implement this cancel callback? Thanks, Salil
[Qemu-devel] qemu hw/pc.c target-i386/cpu.h target-i386/help...
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/08 13:28:47 Modified files: hw : pc.c target-i386: cpu.h helper2.c Log message: added -cpu option for x86 (initial patch by Dan Kenigsberg) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pc.c?cvsroot=qemur1=1.89r2=1.90 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/cpu.h?cvsroot=qemur1=1.51r2=1.52 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper2.c?cvsroot=qemur1=1.54r2=1.55
Re: [Qemu-devel] PC Bios source code?
andrzej zaborowski wrote: As you said yourself, there's also a .diff file. It should contain all differences between original source code and modified source code. You can apply it to the original source code with patch. But how can he tell what the original source is? At the minimum the version numbers of all source files in the bochs cvs need to be listed. The .diff contains revision numbers for all files. Only for files that are changed by said .diff. -- error compiling committee.c: too many arguments to function
[Qemu-devel] qemu Makefile.target cpu-exec.c exec.c translat...
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/08 14:25:03 Modified files: . : Makefile.target cpu-exec.c exec.c translate-all.c vl.c darwin-user: main.c signal.c linux-user : main.c signal.c target-i386: cpu.h helper2.c translate.c tests : qruncom.c Log message: removed obsolete x86 code copy support CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemur1=1.217r2=1.218 http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-exec.c?cvsroot=qemur1=1.121r2=1.122 http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemur1=1.111r2=1.112 http://cvs.savannah.gnu.org/viewcvs/qemu/translate-all.c?cvsroot=qemur1=1.19r2=1.20 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.354r2=1.355 http://cvs.savannah.gnu.org/viewcvs/qemu/darwin-user/main.c?cvsroot=qemur1=1.8r2=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/darwin-user/signal.c?cvsroot=qemur1=1.1r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemur1=1.142r2=1.143 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/signal.c?cvsroot=qemur1=1.47r2=1.48 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/cpu.h?cvsroot=qemur1=1.52r2=1.53 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper2.c?cvsroot=qemur1=1.55r2=1.56 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/translate.c?cvsroot=qemur1=1.73r2=1.74 http://cvs.savannah.gnu.org/viewcvs/qemu/tests/qruncom.c?cvsroot=qemur1=1.6r2=1.7
Re: [Qemu-devel] PC Bios source code?
Hi, Am 08.11.2007 um 02:34 schrieb Jun Koi: In pc-bios/ directory, we have bios.bin and bios.diff. As I understand, qemu's bios is modified from bochs bios. But what are the differences between our bios.bin and bochs bios.bin? As there are some differences, where is the source code of our bios.bin?? As you said yourself, there's also a .diff file. It should contain all differences between original source code and modified source code. You can apply it to the original source code with patch. HTH, Andreas
[Qemu-devel] qemu/linux-user main.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/08 13:56:19 Modified files: linux-user : main.c Log message: added -cpu option for x86 - fixed glibc hack in case the global variables are moved CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemur1=1.140r2=1.141
[Qemu-devel] qemu/linux-user main.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/08 14:01:49 Modified files: linux-user : main.c Log message: removed unused code CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemur1=1.141r2=1.142
[Qemu-devel] qemu/target-i386 translate-copy.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/08 14:24:28 Removed files: target-i386: translate-copy.c Log message: removed CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/translate-copy.c?cvsroot=qemur1=1.9r2=0
Re: [Qemu-devel] PC Bios source code?
Andreas Färber wrote: Hi, Am 08.11.2007 um 02:34 schrieb Jun Koi: In pc-bios/ directory, we have bios.bin and bios.diff. As I understand, qemu's bios is modified from bochs bios. But what are the differences between our bios.bin and bochs bios.bin? As there are some differences, where is the source code of our bios.bin?? As you said yourself, there's also a .diff file. It should contain all differences between original source code and modified source code. You can apply it to the original source code with patch. But how can he tell what the original source is? At the minimum the version numbers of all source files in the bochs cvs need to be listed. -- error compiling committee.c: too many arguments to function
[Qemu-devel] fake device to access to host fs
Hi, has anyone already implemented a fake device to access to the host FS ? I am planning to implement one soon, but if it is already available... Thanks, Tristan.
Re: [Qemu-devel] PC Bios source code?
On 08/11/2007, Avi Kivity [EMAIL PROTECTED] wrote: Andreas Färber wrote: Hi, Am 08.11.2007 um 02:34 schrieb Jun Koi: In pc-bios/ directory, we have bios.bin and bios.diff. As I understand, qemu's bios is modified from bochs bios. But what are the differences between our bios.bin and bochs bios.bin? As there are some differences, where is the source code of our bios.bin?? As you said yourself, there's also a .diff file. It should contain all differences between original source code and modified source code. You can apply it to the original source code with patch. But how can he tell what the original source is? At the minimum the version numbers of all source files in the bochs cvs need to be listed. The .diff contains revision numbers for all files. Regards
[Qemu-devel] [PATCH] remove unused parameters from QEMUMachineInitFunc
It appears that fd_filename and snapshot are not needed/used by machine
init functions (QEMUMachineInitFunc).
This patch removes them.
Index: qemu/vl.h
===
--- qemu.orig/vl.h 2007-11-08 16:36:36.0 +0100
+++ qemu/vl.h 2007-11-08 16:37:04.0 +0100
@@ -790,8 +790,7 @@
#ifndef QEMU_TOOL
typedef void QEMUMachineInitFunc(int ram_size, int vga_ram_size,
- const char *boot_device,
- DisplayState *ds, const char **fd_filename, int snapshot,
+ const char *boot_device, DisplayState *ds,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename, const char *cpu_model);
Index: qemu/hw/an5206.c
===
--- qemu.orig/hw/an5206.c 2007-11-08 16:36:35.0 +0100
+++ qemu/hw/an5206.c 2007-11-08 16:37:04.0 +0100
@@ -27,8 +27,8 @@
/* Board init. */
-static void an5206_init(int ram_size, int vga_ram_size, const char *boot_device,
- DisplayState *ds, const char **fd_filename, int snapshot,
+static void an5206_init(int ram_size, int vga_ram_size,
+ const char *boot_device, DisplayState *ds,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename, const char *cpu_model)
{
Index: qemu/hw/etraxfs.c
===
--- qemu.orig/hw/etraxfs.c 2007-11-08 16:36:35.0 +0100
+++ qemu/hw/etraxfs.c 2007-11-08 16:37:04.0 +0100
@@ -107,8 +107,8 @@
}
static
-void bareetraxfs_init (int ram_size, int vga_ram_size, const char *boot_device,
- DisplayState *ds, const char **fd_filename, int snapshot,
+void bareetraxfs_init (int ram_size, int vga_ram_size,
+ const char *boot_device, DisplayState *ds,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename, const char *cpu_model)
{
Index: qemu/hw/integratorcp.c
===
--- qemu.orig/hw/integratorcp.c 2007-11-08 16:36:35.0 +0100
+++ qemu/hw/integratorcp.c 2007-11-08 16:37:04.0 +0100
@@ -464,7 +464,6 @@
static void integratorcp_init(int ram_size, int vga_ram_size,
const char *boot_device, DisplayState *ds,
- const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename, const char *cpu_model)
{
Index: qemu/hw/mcf5208.c
===
--- qemu.orig/hw/mcf5208.c 2007-11-08 16:36:35.0 +0100
+++ qemu/hw/mcf5208.c 2007-11-08 16:37:04.0 +0100
@@ -199,7 +199,6 @@
static void mcf5208evb_init(int ram_size, int vga_ram_size,
const char *boot_device, DisplayState *ds,
- const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename, const char *cpu_model)
{
Index: qemu/hw/mips_malta.c
===
--- qemu.orig/hw/mips_malta.c 2007-11-08 16:36:35.0 +0100
+++ qemu/hw/mips_malta.c 2007-11-08 16:37:04.0 +0100
@@ -740,8 +740,8 @@
}
static
-void mips_malta_init (int ram_size, int vga_ram_size, const char *boot_device,
- DisplayState *ds, const char **fd_filename, int snapshot,
+void mips_malta_init (int ram_size, int vga_ram_size,
+ const char *boot_device, DisplayState *ds,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename, const char *cpu_model)
{
Index: qemu/hw/mips_mipssim.c
===
--- qemu.orig/hw/mips_mipssim.c 2007-11-08 16:36:35.0 +0100
+++ qemu/hw/mips_mipssim.c 2007-11-08 16:37:04.0 +0100
@@ -94,8 +94,8 @@
}
static void
-mips_mipssim_init (int ram_size, int vga_ram_size, const char *boot_device,
- DisplayState *ds, const char **fd_filename, int snapshot,
+mips_mipssim_init (int ram_size, int vga_ram_size,
+ const char *boot_device, DisplayState *ds,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename, const char *cpu_model)
{
Index: qemu/hw/palm.c
===
--- qemu.orig/hw/palm.c 2007-11-08 16:36:35.0 +0100
+++ qemu/hw/palm.c 2007-11-08 16:37:04.0 +0100
@@ -179,7 +179,6 @@
static void palmte_init(int ram_size, int vga_ram_size,
Re: [Qemu-devel] fake device to access to host fs
2007/11/8, Tristan Gingold [EMAIL PROTECTED]: Hi, has anyone already implemented a fake device to access to the host FS ? I am planning to implement one soon, but if it is already available... Thanks, Tristan. Hi, Have a look to the vvfat block device. Regards, Edu
Re: [Qemu-devel] fake device to access to host fs
Tristan Gingold wrote: Hi, has anyone already implemented a fake device to access to the host FS ? 9p in Linux has a virtio transport. I've just published a PCI virtio layer and have an initial implementation for QEMU. My plan is to combine 9p, virtio, and a 9p server in QEMU to allow a hostfs for QEMU. Of course, this only solves the problem for Linux but that's all I really care about. Regards, Anthony Liguori I am planning to implement one soon, but if it is already available... Thanks, Tristan.
[Qemu-devel] qemu configure linux-user/main.c linux-user/sig...
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/11/08 18:05:37 Modified files: . : configure linux-user : main.c signal.c syscall_defs.h target-mips: exec.h helper.c mips-defs.h op.c op_helper.c op_mem.c op_template.c translate.c translate_init.c Log message: Clean out the N32 macros from target-mips, and introduce MIPS ABI specific defines for linux-user. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemur1=1.168r2=1.169 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemur1=1.143r2=1.144 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/signal.c?cvsroot=qemur1=1.48r2=1.49 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall_defs.h?cvsroot=qemur1=1.43r2=1.44 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/exec.h?cvsroot=qemur1=1.41r2=1.42 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/helper.c?cvsroot=qemur1=1.57r2=1.58 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/mips-defs.h?cvsroot=qemur1=1.18r2=1.19 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemur1=1.84r2=1.85 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_helper.c?cvsroot=qemur1=1.70r2=1.71 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_mem.c?cvsroot=qemur1=1.15r2=1.16 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_template.c?cvsroot=qemur1=1.9r2=1.10 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemur1=1.111r2=1.112 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate_init.c?cvsroot=qemur1=1.26r2=1.27
Re: [Qemu-devel] fake device to access to host fs
On Nov 8, 2007, at 5:35 PM, Eduardo Felipe wrote: Have a look to the vvfat block device. Thanks, I was not aware of it. I think it will fill my requirements.
[Qemu-devel] qemu/target-mips translate.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/11/08 16:44:01 Modified files: target-mips: translate.c Log message: Formatting fix. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemur1=1.110r2=1.111
[Qemu-devel] qemu/hw ide.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/11/08 16:38:17 Modified files: hw : ide.c Log message: Revert Last AIO Patch as requested by Fabrice, it is incomplete and breaks other (non-Windows) systems. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ide.c?cvsroot=qemur1=1.69r2=1.70
[Qemu-devel] qemu .cvsignore
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/11/08 16:43:05 Modified files: . : .cvsignore Log message: .cvsignore dependency files. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/.cvsignore?cvsroot=qemur1=1.22r2=1.23
[Qemu-devel] qemu audio/.cvsignore slirp/.cvsignore
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/11/08 16:44:36 Added files: audio : .cvsignore slirp : .cvsignore Log message: More .cvsignore. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/audio/.cvsignore?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/slirp/.cvsignore?cvsroot=qemurev=1.1
[Qemu-devel] [PATCH] multiboot support
Hi, this patch adds very simple multiboot support for x86 as defined in http://www.gnu.org/software/grub/manual/multiboot/ using the -kernel switch. There is no support for modules or command line parsing, as it would be required by XEN or HURD, but simple OSs already work when used in conjunction with this patch. Adding module support should be as simple as writing the modules into RAM and setting some information fields in the bootinfo structure (if anyone's interested in booting more than linux without a full-blown bootloader). The only one I have tested so far is the boot2 darwin bootloader modified to work using multiboot by David F. Elliott, which worked fine bringing up first parts of a stock osx kernel. I believe this patch does not break anything and is safe to be applied, whereas comments are (as always) welcome though. Cheers, Alex qemu-multiboot.patch Description: Binary data
[Qemu-devel] ES1370 problems with Win98SE
Hello. First, let me say that I realize this is not exactly the place for this. Non-developer problems with Qemu should go on the Qemu forum... But they're down right now, so please bear with me here. I apologize for taking up all you developers' time. I have a Windows Vista host (I know, mistake # 1) running Win98SE as a guest. I launch QEMU with QEMU Manager instead of the command line. The only problem I have is the sound. Win98SE correctly recognizes the SB16 emulated card and it works... But there's a lot of interference in the wave sound (haven't tried midi yet). Not to say that the SB16 emulation is bad or anything, it's probably that Vista's revamped sound system is screwing things up. But anyway, I went into Qemu manager and disabled the SB16 emulation and activated the ES1370 emulation... But Win98 will not recognize the emulated ES1370 card, it doesn't even see it. I tried downloading the corresponding driver from Creative's site, and while the driver appeared to install correctly, Win98 still does not see the card. What am I doing wrong?
