[Qemu-devel] Trouble getting Ubuntu 64-bit working
I recently downloaded the qemu binary for Windows. I'm using Vista 32 bit as the host and I'm trying to run Ubuntu 64-bit in it. The splash screen works, but when it boots, I am left staring at a blank screen. I let it sit for half an hour before giving up. Am I doing something wrong? I launched the qemu-system-x86_64 exec. - George _ Windows Live: Make it easier for your friends to see what you’re up to on Facebook. http://go.microsoft.com/?linkid=9691816
[Qemu-devel] Re: [PATCH 01/15] Introduce qemu_write_full()
On 01/02/2010 04:45 AM, Kirill A. Shutemov wrote: A variant of write(2) which handles partial write. Next time please add a cover letter 00/15 to explain what you changed, and a v3 (or v4?) marker in the subjects. Thanks for this work though! Paolo
[Qemu-devel] Extended deadline for proposals for the Alt-OS devroom at FOSDEM
Hello, I have been unavailable for a week, and it seems a lot of people were cut off the Net last month busy with family... The deadline for the propositions for the Alt-OS devroom at FOSDEM has been extended to 2010-01-05, to allow at least one talk per project. The shedule must be sent rapidly to the FOSDEM team so we can't stretch it much more. I'd really like to have a talk about some alternative OS project using QEMU for their development. I might talk about my own usage for Haiku but I'll be quite busy, so it'd be nice to hear someone else. Things like USB stack debugging with the USB passthrough for ex. would be topics of interest. I't also be nice to have a summary of QEMU support of guest and host OSes. Anyone wants to talk about the darwin-user target ? (is it still maintained ? :p) For the record, the original call for contributions with all the details: http://groups.google.com/group/rosetta-os/browse_thread/thread/16964e21bef27116 François.
Re: [Qemu-devel] [PATCH] debugcon: support for debugging consoles (e.g. Bochs port 0xe9)
On Fri, Jan 01, 2010 at 07:02:59PM -0800, H. Peter Anvin wrote: On 12/30/2009 08:49 AM, Kevin O'Connor wrote: SeaBIOS writes debugging info to port 0x0402. Unfortunately, qemu has to be recompiled in order to display this info. Will your patch enable one to get at the 0x0402 data without recompiling? Incidentally, it's somewhat unusual choice of ports... port 0x80 is the normal port for BIOSes to display debugging information on. Port 0x0402 is a carry over from Bochs bios. Port 0x80 isn't generally used to emit a stream of ascii data, and it can be used by other programs besides the bios. I'd guess that's why Bochs chose a different port. -Kevin
[Qemu-devel] call insn not truncated on x86_64
I'm running into an issue with SeaBIOS compiled with older versions of gcc. I'm seeing: $ qemu-system-x86_64 -d in_asm,int,exec,cpu,pcall IN: 0x000f1096: mov%ebx,%eax 0x000f1098: call 0x0f80 qemu: fatal: Trying to execute code outside RAM or ROM at 0x0f80 The emulator dies at this point. This code sequence is used to jump into the copy of SeaBIOS at the permanent rom location (at 0xfffe-0x) so it can safely enable ram in the 0xe-0x10 memory area. The call insn looks okay to me: f1098: e8 e3 fe ef ff calll 0f80 So, I'm not sure why qemu dies. This is what I see on the i386 version of qemu: $ qemu -d in_asm,int,exec,cpu,pcall IN: 0x000f1096: mov%ebx,%eax 0x000f1098: call 0x0f80 IN: 0x0f80: push %ebp 0x0f81: push %edi [...] Newer versions of gcc emit code a little different and thus don't run into the issue - I see: $ qemu-system-x86_64 -d in_asm,int,exec,cpu,pcall IN: 0x000f365e: mov%ecx,%eax 0x000f3660: mov$0xfffeddea,%edx 0x000f3665: call *%edx IN: 0xfffeddea: push %ebp 0xfffeddeb: push %edi [...] and: $ qemu -d in_asm,int,exec,cpu,pcall IN: 0x000f365e: mov%ecx,%eax 0x000f3660: mov$0xfffeddea,%edx 0x000f3665: call *%edx IN: 0xfffeddea: push %ebp 0xfffeddeb: push %edi [...] As a guess, qemu is not truncating the instruction pointer to 32bits in the 64bit emulator. In all of the above cases, the machine was in 32bit mode and running 32bit only code. It should be possible to reproduce this problem by downloading SeaBIOS and compiling with gcc34: git clone git://git.linuxtogo.org/home/kevin/seabios.git cd seabios CC=gcc34 make cp out/bios.bin /path/to/qemu/bios/ -Kevin
Re: [Qemu-devel] [PATCH] debugcon: support for debugging consoles (e.g. Bochs port 0xe9)
On 01/02/2010 09:53 AM, Kevin O'Connor wrote: On Fri, Jan 01, 2010 at 07:02:59PM -0800, H. Peter Anvin wrote: On 12/30/2009 08:49 AM, Kevin O'Connor wrote: SeaBIOS writes debugging info to port 0x0402. Unfortunately, qemu has to be recompiled in order to display this info. Will your patch enable one to get at the 0x0402 data without recompiling? Incidentally, it's somewhat unusual choice of ports... port 0x80 is the normal port for BIOSes to display debugging information on. Port 0x0402 is a carry over from Bochs bios. Port 0x80 isn't generally used to emit a stream of ascii data, and it can be used by other programs besides the bios. I'd guess that's why Bochs chose a different port. -Kevin Makes sense. Either way, it works with my patch looking something like: -chardev stdio,id=seabios \ -device isa-debugcon,iobase=0x402,chardev=seabios ... should do the job. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
Re: [Qemu-devel] call insn not truncated on x86_64
On Sat, Jan 02, 2010 at 01:26:54PM -0500, Kevin O'Connor wrote: I'm running into an issue with SeaBIOS compiled with older versions of gcc. I'm seeing: $ qemu-system-x86_64 -d in_asm,int,exec,cpu,pcall IN: 0x000f1096: mov%ebx,%eax 0x000f1098: call 0x0f80 qemu: fatal: Trying to execute code outside RAM or ROM at 0x0f80 The emulator dies at this point. This code sequence is used to jump into the copy of SeaBIOS at the permanent rom location (at 0xfffe-0x) so it can safely enable ram in the 0xe-0x10 memory area. The call insn looks okay to me: f1098: e8 e3 fe ef ff calll 0f80 So, I'm not sure why qemu dies. This is what I see on the i386 version of qemu: $ qemu -d in_asm,int,exec,cpu,pcall IN: 0x000f1096: mov%ebx,%eax 0x000f1098: call 0x0f80 IN: 0x0f80: push %ebp 0x0f81: push %edi [...] Newer versions of gcc emit code a little different and thus don't run into the issue - I see: $ qemu-system-x86_64 -d in_asm,int,exec,cpu,pcall IN: 0x000f365e: mov%ecx,%eax 0x000f3660: mov$0xfffeddea,%edx 0x000f3665: call *%edx IN: 0xfffeddea: push %ebp 0xfffeddeb: push %edi [...] and: $ qemu -d in_asm,int,exec,cpu,pcall IN: 0x000f365e: mov%ecx,%eax 0x000f3660: mov$0xfffeddea,%edx 0x000f3665: call *%edx IN: 0xfffeddea: push %ebp 0xfffeddeb: push %edi [...] As a guess, qemu is not truncating the instruction pointer to 32bits in the 64bit emulator. In all of the above cases, the machine was in 32bit mode and running 32bit only code. The problem has been fixed in 32938e127f50a40844a0fb9c5abb8691aeeccf7e for jmp imm. I guess the same patch applies for call. Could you confirm? diff --git a/pc-bios/openbios-sparc64 b/pc-bios/openbios-sparc64 index 0e91cab..ec47b5f 100644 Binary files a/pc-bios/openbios-sparc64 and b/pc-bios/openbios-sparc64 differ diff --git a/target-i386/translate.c b/target-i386/translate.c index 64bc0a3..511a4ea 100644 --- a/target-i386/translate.c +++ b/target-i386/translate.c @@ -6259,6 +6259,8 @@ static target_ulong disas_insn(DisasContext *s, target_ulong pc_start) tval += next_eip; if (s-dflag == 0) tval = 0x; +else if(!CODE64(s)) +tval = 0x; gen_movtl_T0_im(next_eip); gen_push_T0(s); gen_jmp(s, tval); -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] call insn not truncated on x86_64
On Sat, Jan 02, 2010 at 09:35:38PM +0100, Aurelien Jarno wrote: On Sat, Jan 02, 2010 at 01:26:54PM -0500, Kevin O'Connor wrote: I'm running into an issue with SeaBIOS compiled with older versions of gcc. I'm seeing: $ qemu-system-x86_64 -d in_asm,int,exec,cpu,pcall IN: 0x000f1096: mov%ebx,%eax 0x000f1098: call 0x0f80 qemu: fatal: Trying to execute code outside RAM or ROM at 0x0f80 The problem has been fixed in 32938e127f50a40844a0fb9c5abb8691aeeccf7e for jmp imm. I guess the same patch applies for call. Could you confirm? Your patch fixes the problem. Thanks, -Kevin
[Qemu-devel] [PATCH 4/6] Include dump of lspci -nn on real G5
To ease debugging and to know what we're lacking, I found it really useful to
have an lspci dump of a real U3 based G5 around. So I added a comment for it.
If people don't think it's important enough to include this information in the
sources, just don't apply this patch.
Signed-off-by: Alexander Graf ag...@suse.de
---
hw/unin_pci.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/hw/unin_pci.c b/hw/unin_pci.c
index 829c4cb..8060749 100644
--- a/hw/unin_pci.c
+++ b/hw/unin_pci.c
@@ -248,6 +248,31 @@ PCIBus *pci_pmac_init(qemu_irq *pic)
return d-host_state.bus;
}
+/*
+ * PCI bus layout on a real G5 (U3 based):
+ *
+ * :f0:0b.0 Host bridge [0600]: Apple Computer Inc. U3 AGP [106b:004b]
+ * :f0:10.0 VGA compatible controller [0300]: ATI Technologies Inc RV350
AP [Radeon 9600] [1002:4150]
+ * 0001:00:00.0 Host bridge [0600]: Apple Computer Inc. CPC945 HT Bridge
[106b:004a]
+ * 0001:00:01.0 PCI bridge [0604]: Advanced Micro Devices [AMD] AMD-8131 PCI-X
Bridge [1022:7450] (rev 12)
+ * 0001:00:02.0 PCI bridge [0604]: Advanced Micro Devices [AMD] AMD-8131 PCI-X
Bridge [1022:7450] (rev 12)
+ * 0001:00:03.0 PCI bridge [0604]: Apple Computer Inc. K2 HT-PCI Bridge
[106b:0045]
+ * 0001:00:04.0 PCI bridge [0604]: Apple Computer Inc. K2 HT-PCI Bridge
[106b:0046]
+ * 0001:00:05.0 PCI bridge [0604]: Apple Computer Inc. K2 HT-PCI Bridge
[106b:0047]
+ * 0001:00:06.0 PCI bridge [0604]: Apple Computer Inc. K2 HT-PCI Bridge
[106b:0048]
+ * 0001:00:07.0 PCI bridge [0604]: Apple Computer Inc. K2 HT-PCI Bridge
[106b:0049]
+ * 0001:01:07.0 Class [ff00]: Apple Computer Inc. K2 KeyLargo Mac/IO
[106b:0041] (rev 20)
+ * 0001:01:08.0 USB Controller [0c03]: Apple Computer Inc. K2 KeyLargo USB
[106b:0040]
+ * 0001:01:09.0 USB Controller [0c03]: Apple Computer Inc. K2 KeyLargo USB
[106b:0040]
+ * 0001:02:0b.0 USB Controller [0c03]: NEC Corporation USB [1033:0035] (rev 43)
+ * 0001:02:0b.1 USB Controller [0c03]: NEC Corporation USB [1033:0035] (rev 43)
+ * 0001:02:0b.2 USB Controller [0c03]: NEC Corporation USB 2.0 [1033:00e0]
(rev 04)
+ * 0001:03:0d.0 Class [ff00]: Apple Computer Inc. K2 ATA/100 [106b:0043]
+ * 0001:03:0e.0 FireWire (IEEE 1394) [0c00]: Apple Computer Inc. K2 FireWire
[106b:0042]
+ * 0001:04:0f.0 Ethernet controller [0200]: Apple Computer Inc. K2 GMAC (Sun
GEM) [106b:004c]
+ * 0001:05:0c.0 IDE interface [0101]: Broadcom K2 SATA [1166:0240]
+ *
+ */
PCIBus *pci_pmac_u3_init(qemu_irq *pic)
{
DeviceState *dev;
--
1.6.0.2
[Qemu-devel] [PATCH 2/6] Add config space conversion function for uni_north
As stated in the previous patch, the Uninorth PCI bridge requires different
layouts in its PCI config space accessors.
This patch introduces a conversion function that makes it compatible with
the way Linux accesses it.
I also kept an OpenBIOS compatibility hack in. I think it'd be better to
take small steps here and do the config space access rework in OpenBIOS
later on. When that's done we can remove that hack.
Signed-off-by: Alexander Graf ag...@suse.de
---
hw/unin_pci.c | 35 +++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/hw/unin_pci.c b/hw/unin_pci.c
index fdb9401..1c49008 100644
--- a/hw/unin_pci.c
+++ b/hw/unin_pci.c
@@ -75,6 +75,40 @@ static void pci_unin_reset(void *opaque)
{
}
+static uint32_t unin_get_config_reg(PCIHostState *s, uint32_t addr)
+{
+uint32_t retval;
+uint32_t reg = s-config_reg;
+
+if (reg (1u 31)) {
+/* XXX OpenBIOS compatibility hack */
+retval = reg;
+addr |= reg 7;
+} else if (reg 1) {
+/* Set upper valid bit and remove lower one */
+retval = (reg ~3u) | (1u 31);
+} else {
+uint32_t slot, func;
+uint32_t devfn;
+
+/* Grab CFA0 style values */
+slot = ffs(reg 0xf800) - 1;
+func = (reg 8) 7;
+devfn = PCI_DEVFN(slot, func);
+
+/* ... and then convert them to x86 format */
+retval = (reg 0xfc) | (devfn 8) | (1u 31);
+}
+
+retval = ~3u;
+retval |= (addr 7);
+
+UNIN_DPRINTF(Converted config space accessor %08x/%08x - %08x\n,
+ reg, addr, retval);
+
+return retval;
+}
+
static int pci_unin_main_init_device(SysBusDevice *dev)
{
UNINState *s;
@@ -85,6 +119,7 @@ static int pci_unin_main_init_device(SysBusDevice *dev)
s = FROM_SYSBUS(UNINState, dev);
pci_host_init(s-host_state);
+s-host_state.get_config_reg = unin_get_config_reg;
pci_mem_config = pci_host_conf_register_mmio(s-host_state);
pci_mem_data = pci_host_data_register_mmio(s-host_state);
sysbus_init_mmio(dev, 0x1000, pci_mem_config);
--
1.6.0.2
[Qemu-devel] [PATCH 6/6] Enable secondary cmd64x
We're not using any macio IDE devices, so let's enable the secondary cmd64x IDE device, so we get all four possible IDE devices exposed to the guest. Later we definitely need to enable macio or any other device that Linux understands in default configurations. Signed-off-by: Alexander Graf ag...@suse.de --- hw/ppc_newworld.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/ppc_newworld.c b/hw/ppc_newworld.c index 308e102..d66860b 100644 --- a/hw/ppc_newworld.c +++ b/hw/ppc_newworld.c @@ -343,7 +343,7 @@ static void ppc_core99_init (ram_addr_t ram_size, hd[i] = drive_get(IF_IDE, i / MAX_IDE_DEVS, i % MAX_IDE_DEVS); } dbdma = DBDMA_init(dbdma_mem_index); -pci_cmd646_ide_init(pci_bus, hd, 0); +pci_cmd646_ide_init(pci_bus, hd, 1); /* cuda also initialize ADB */ cuda_init(cuda_mem_index, pic[0x19]); -- 1.6.0.2
[Qemu-devel] [PATCH 0/6] PPC NewWorld fixery
I'm trying to get the PPC64 system emulation target working finally. While doing so, I ran into several issues, all related to PCI this time. This patchset fixes all the PCI config space access and PCI interrupt mapping issues I've found on PPC64. Using this and a patched OpenBIOS version, I can successfully access IDE devices and was booting a guest into the shell from IDE using serial console. To leverage this patch, you also need a few patches to OpenBIOS. I'll present them to the OpenBIOS list, but in general getting patches into Qemu is harder than getting them into OpenBIOS. So I want to wait for the rewiew process here first. Find the patch at: http://alex.csgraf.de/openbios-ppc-u3.patch Alexander Graf (6): Make config space accessor host bus trapable Add config space conversion function for uni_north Use Mac99_U3 type on ppc64 Include dump of lspci -nn on real G5 Make interrupts work Enable secondary cmd64x hw/apb_pci.c |1 + hw/grackle_pci.c |1 + hw/gt64xxx.c |1 + hw/pci_host.c | 11 hw/pci_host.h |5 ++ hw/pci_host_template.h | 30 ++ hw/pci_ids.h |1 + hw/piix_pci.c |1 + hw/ppc.h |1 + hw/ppc4xx_pci.c|1 + hw/ppc_mac.h |1 + hw/ppc_newworld.c | 14 - hw/ppce500_pci.c |1 + hw/unin_pci.c | 145 +++- 14 files changed, 196 insertions(+), 18 deletions(-)
[Qemu-devel] [PATCH 5/6] Make interrupts work
The interrupt code as is didn't really work for me. I couldn't even convince
Linux to take interrupt 9 in an interrupt-map.
So let's do this right. Let's map all PCI interrupts to 0x1b - 0x1e. That way
we're at least a small step closer to what real hardware does.
I also took the interrupt pin to line conversion from OpenBIOS, which at least
assures us we're compatible with our firmware :-).
A dump of the PCI interrupt-map from a U2 (iBook):
9000 ff97c528 0034 0001
d800 ff97c528 003f 0001
c000 ff97c528 001b 0001
c800 ff97c528 001c 0001
d000 ff97c528 001d 0001
Signed-off-by: Alexander Graf ag...@suse.de
---
hw/unin_pci.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/hw/unin_pci.c b/hw/unin_pci.c
index 8060749..a334adb 100644
--- a/hw/unin_pci.c
+++ b/hw/unin_pci.c
@@ -36,22 +36,30 @@
#define UNIN_DPRINTF(fmt, ...)
#endif
+static const int unin_irq_line[] = { 0x1b, 0x1c, 0x1d, 0x1e };
+
typedef struct UNINState {
SysBusDevice busdev;
PCIHostState host_state;
} UNINState;
-/* Don't know if this matches real hardware, but it agrees with OHW. */
static int pci_unin_map_irq(PCIDevice *pci_dev, int irq_num)
{
-return (irq_num + (pci_dev-devfn 3)) 3;
+int retval;
+int devfn = pci_dev-devfn 0x00FF;
+
+retval = (((devfn 11) 0x1F) + irq_num) 3;
+
+return retval;
}
static void pci_unin_set_irq(void *opaque, int irq_num, int level)
{
qemu_irq *pic = opaque;
-qemu_set_irq(pic[irq_num + 8], level);
+UNIN_DPRINTF(%s: setting INT %d = %d\n, __func__,
+ unin_irq_line[irq_num], level);
+qemu_set_irq(pic[unin_irq_line[irq_num]], level);
}
static void pci_unin_save(QEMUFile* f, void *opaque)
--
1.6.0.2
[Qemu-devel] [PATCH 1/6] Make config space accessor host bus trapable
Different host buses may have different layouts for config space accessors.
The Mac U3 for example uses the following define to access Type 0 (directly
attached) devices:
#define MACRISC_CFA0(devfn, off)\
((1 (unsigned int)PCI_SLOT(dev_fn)) \
| (((unsigned int)PCI_FUNC(dev_fn)) 8) \
| (((unsigned int)(off)) 0xFCUL))
Obviously, this is different from the encoding we interpret in qemu. In
order to let host controllers take some influence there, we can just
introduce a converter function that takes whatever accessor we have and
makes a qemu understandable one out of it.
This patch is the groundwork for Uninorth PCI config space fixes.
Signed-off-by: Alexander Graf ag...@suse.de
CC: Michael S. Tsirkin m...@redhat.com
---
hw/apb_pci.c |1 +
hw/grackle_pci.c |1 +
hw/gt64xxx.c |1 +
hw/pci_host.c | 11 +++
hw/pci_host.h |5 +
hw/pci_host_template.h | 30 ++
hw/piix_pci.c |1 +
hw/ppc4xx_pci.c|1 +
hw/ppce500_pci.c |1 +
hw/unin_pci.c |1 +
10 files changed, 41 insertions(+), 12 deletions(-)
diff --git a/hw/apb_pci.c b/hw/apb_pci.c
index f05308b..fedb84c 100644
--- a/hw/apb_pci.c
+++ b/hw/apb_pci.c
@@ -222,6 +222,7 @@ PCIBus *pci_apb_init(target_phys_addr_t special_base,
/* mem_data */
sysbus_mmio_map(s, 3, mem_base);
d = FROM_SYSBUS(APBState, s);
+pci_host_init(d-host_state);
d-host_state.bus = pci_register_bus(d-busdev.qdev, pci,
pci_apb_set_irq, pci_pbm_map_irq, pic,
0, 32);
diff --git a/hw/grackle_pci.c b/hw/grackle_pci.c
index ee4fed5..7feba63 100644
--- a/hw/grackle_pci.c
+++ b/hw/grackle_pci.c
@@ -88,6 +88,7 @@ PCIBus *pci_grackle_init(uint32_t base, qemu_irq *pic)
qdev_init_nofail(dev);
s = sysbus_from_qdev(dev);
d = FROM_SYSBUS(GrackleState, s);
+pci_host_init(d-host_state);
d-host_state.bus = pci_register_bus(d-busdev.qdev, pci,
pci_grackle_set_irq,
pci_grackle_map_irq,
diff --git a/hw/gt64xxx.c b/hw/gt64xxx.c
index fb7f5bd..8cf93ca 100644
--- a/hw/gt64xxx.c
+++ b/hw/gt64xxx.c
@@ -1120,6 +1120,7 @@ PCIBus *pci_gt64120_init(qemu_irq *pic)
s = qemu_mallocz(sizeof(GT64120State));
s-pci = qemu_mallocz(sizeof(GT64120PCIState));
+pci_host_init(s-pci);
s-pci-bus = pci_register_bus(NULL, pci,
pci_gt64120_set_irq, pci_gt64120_map_irq,
pic, 144, 4);
diff --git a/hw/pci_host.c b/hw/pci_host.c
index eeb8dee..2d12887 100644
--- a/hw/pci_host.c
+++ b/hw/pci_host.c
@@ -228,3 +228,14 @@ void pci_host_data_register_ioport(pio_addr_t ioport,
PCIHostState *s)
register_ioport_read(ioport, 4, 2, pci_host_data_readw_ioport, s);
register_ioport_read(ioport, 4, 4, pci_host_data_readl_ioport, s);
}
+
+/* This implements the default x86 way of interpreting the config register */
+static uint32_t pci_host_get_config_reg(PCIHostState *s, uint32_t addr)
+{
+return s-config_reg | (addr 3);
+}
+
+void pci_host_init(PCIHostState *s)
+{
+s-get_config_reg = pci_host_get_config_reg;
+}
diff --git a/hw/pci_host.h b/hw/pci_host.h
index a006687..90a4c63 100644
--- a/hw/pci_host.h
+++ b/hw/pci_host.h
@@ -30,14 +30,19 @@
#include sysbus.h
+/* for config space access */
+typedef uint32_t (*pci_config_reg_fn)(PCIHostState *s, uint32_t addr);
+
struct PCIHostState {
SysBusDevice busdev;
+pci_config_reg_fn get_config_reg;
uint32_t config_reg;
PCIBus *bus;
};
void pci_data_write(PCIBus *s, uint32_t addr, uint32_t val, int len);
uint32_t pci_data_read(PCIBus *s, uint32_t addr, int len);
+void pci_host_init(PCIHostState *s);
/* for mmio */
int pci_host_conf_register_mmio(PCIHostState *s);
diff --git a/hw/pci_host_template.h b/hw/pci_host_template.h
index 11e6c88..55aa85e 100644
--- a/hw/pci_host_template.h
+++ b/hw/pci_host_template.h
@@ -29,48 +29,52 @@ static void glue(pci_host_data_writeb, PCI_HOST_SUFFIX)(
void* opaque, PCI_ADDR_T addr, uint32_t val)
{
PCIHostState *s = opaque;
+uint32_t config_reg = s-get_config_reg(s, (uint32_t)addr);
PCI_DPRINTF(writeb addr TARGET_FMT_plx val %x\n,
(target_phys_addr_t)addr, val);
-if (s-config_reg (1u 31))
-pci_data_write(s-bus, s-config_reg | (addr 3), val, 1);
+if (config_reg (1u 31))
+pci_data_write(s-bus, config_reg, val, 1);
}
static void glue(pci_host_data_writew, PCI_HOST_SUFFIX)(
void* opaque, PCI_ADDR_T addr, uint32_t val)
{
PCIHostState *s = opaque;
+uint32_t config_reg = s-get_config_reg(s, (uint32_t)addr);
#ifdef TARGET_WORDS_BIGENDIAN
val = bswap16(val);
#endif
PCI_DPRINTF(writew addr TARGET_FMT_plx val %x\n,
Re: [Qemu-devel] [PATCH] debugcon: support for debugging consoles (e.g. Bochs port 0xe9)
Makes sense. Either way, it works with my patch looking something like: -chardev stdio,id=seabios \ -device isa-debugcon,iobase=0x402,chardev=seabios ... should do the job. Btw, I once added another method of debug output to ZETA, that was using the low-level protocol used by laplink (nibble mode). I needed this for a laptop that didn't have a serial port but still had a // one. This allowed bidirectionnal debugging (including sending kernel debugger commands) with a null-printer cable. I also wrote code to support it in Haiku, though I'm not sure I've added the receiving driver yet. See: http://dev.haiku-os.org/browser/haiku/trunk/src/add-ons/kernel/debugger/laplinkll I don't know if the parallel port emulation in QEMU supports dumping bytes at nibble mode yet, it might be interesting to add this anyway. Though it should also be possible to just use 8bit mode and dump data straight to it as with the 0x402 port. François.
