[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
On 19.12.2010, at 20:12, Andreas Färber wrote: Am 19.12.2010 um 16:34 schrieb Alexander Graf: On 19.12.2010, at 16:04, Andreas Färber wrote: Am 19.12.2010 um 10:54 schrieb Alexander Graf: On 14.12.2010, at 01:49, Andreas Färber wrote: Hello, Based on an earlier attempt of mine to make OpenBIOS work with -M prep, with kind support from Hervé Poussineau here's an initial stab at fixing the long-broken PReP emulation and preparing migration from abandoned OpenHack'Ware to OpenBIOS as default FOSS firmware. In particular a number of hw_error()s are resolved, so that the BIOS can be entered at all. It is not yet working in terms of serial and VGA support etc. This series is also available from: git://repo.or.cz/qemu/afaerber.git prep-queue Some more work-in-progress for the curious is on my prep branch [2]. The corresponding work-in-progress OpenBIOS changes are at [3]. Unfortunately the prep machine is lacking documentation what exactly it tries to emulate. The plan thus is to merge emulation of a second, real IBM 40p machine based on Hervé's work at [1], for use with original binary firmware. Also upcoming are new ppc_chrp machines, forked from ppc_newworld, emulating the 970-based IBM JS20 (using Apple U3) [4] and possibly the POWER5-based IntelliStation 285. These depend on the ongoing ppc64 port of OpenBIOS to be completed though. This relates to PReP in that the machine IDs will need to be coordinated. Does this series actually make anything work, or is it just a first step set to get your development rolling? IOW, would users benefit from having the patches upstream yet? As indicated above, it lets you enter a BIOS, which is a user-visible improvement. User-supplied binary firmware works with 1 + 3-4, ELF firmware with 1-4. Patch 3 depends on review comments. Patch 4 was just an FYI for testing the preceding patches and still needs investigation. For OpenBIOS to work, we need fw_cfg in ppc_prep.c and, independently, patches to OpenBIOS. Unless of course we want to use another firmware like OFW from the start. The main interest in PReP nowadays will be proprietary firmware anyway. I thought Rob (cc'ed) had PReP Linux kernel patches for QEMU at some point but I couldn't locate them in the Aboriginal Linux tree. I'm not sure on the copyright problems we might run into when delivering binary firmware. No one suggested shipping proprietary firmware. I was advocating enabling users to use the available firmware rather than holding fixes back just because there is no fully-working FOSS alternative firmware yet. Hrm, I only partially agree. If you ship a target in qemu that people can't test out of the box, it won't receive testing from contributers. I doubt that RH people will go in and download proprietary firmware just to check that prep didn't break. I do hope however, that they test targets that just work. I have this very issue with s390. The only host to run (and compile) this on is an s390. And few people have those. So it breaks from time to time. Since prep would at least get built for everyone, there's less of an issue, yes. So we certainly do need some open source firmware solution for prep to at least have Linux running. For other guests, I don't see a reason why users shouldn't try to fetch a real firmware blob separately :). We're not shipping any firmware for ppcemb either, so that argument seems moot. OpenBIOS, SeaBIOS and ZIPL are the only ones currently. Feel free to supply additional blobs for U-Boot etc. IIUC you don't need u-boot for the embedded targets. You just pass in a kernel and the rest is magic. Recent vanilla Linux kernels wouldn't run on PReP. So what Linux do you want to run using open source firmware? I certainly do not intend to write firmware for the upcoming 40p machine. If Linux runs on real 40p hardware then it should run with real firmware under emulation, too. QEMU is an emulation project, not a Linux testing framework. I completely agree. Linux is usually easy because it's fully open source and supports a lot of targets. If you feel like running NetBSD or Haiku instead, feel free to do so. I'd even be willing to say that running any OS with a proprietary firmware blob is enough to pull stuff in. And really, I mean _any_ OS. I just really want to see some value for users, so in case the whole system just doesn't work at all, we can rather apply a big bunch of removal commits instead of fixes that won't end up in anything working either. Having said that, I have faith in your skills to get this working. So I assume you'll have something that meets the something runs criteria in at most a couple of weeks. Shouldn't be too bad, no? :) Alex
Re: [Qemu-devel] [PATCH, RFC 3/4] prep: Fix duplicate ISA IDE IRQ
On 20.12.2010, at 07:37, Andreas Färber wrote: Am 14.12.2010 um 01:49 schrieb Andreas Färber: Calling isa_ide_init() twice with the same IRQ 13 fails: qemu: hardware error: isa irq 13 already assigned Use a different IRQ (14) for the second one to avoid this. Signed-off-by: Hervé Poussineau hpous...@reactos.org Cc: Alexander Graf ag...@suse.de Signed-off-by: Andreas Färber andreas.faer...@web.de The implied question behind RFC is, has this been a dormant bug in ppc_prep.c or would this need to be fixed at ISA level (allowing two devices to share the same IRQ) in isa-bus.c where the above error message is raised? That depends on the hardware. Usually ISA can't share IRQs. There are some exceptions though, where ISA controllers have some built in magic to enable sharing along identical devices. Not sure which case we're looking at here, but having them separate is certainly the safe choice. Alex
[Qemu-devel] Re: [SeaBIOS] seabios: acpi: add _RMV control method for PCI devices
On Sun, Dec 12, 2010 at 02:57:45PM -0500, Kevin O'Connor wrote: On Sun, Dec 12, 2010 at 09:49:16PM +0200, Gleb Natapov wrote: On Sun, Dec 12, 2010 at 02:11:29PM -0500, Kevin O'Connor wrote: On Wed, Dec 08, 2010 at 03:08:59PM -0200, Marcelo Tosatti wrote: Use _RMV method to indicate whether device can be removed. Data is retrieved from QEMU via I/O port 0xae0c. Signed-off-by: Marcelo Tosatti mtosa...@redhat.com Thanks Marcelo, Can you add acked-bys from the qemu/kvm maintaners? Marcelo is kvm maintainer ;) FWIW I tested this with Windows 7 XP and it works as expected. The patch relies on patch not yes excepted to qemu though. Yeah - I know - but I figured I'd ask for concensus before committing. :-) The committing of seabios patches that have a dependency on qemu/kvm is an area that I think could be better clarified. I'm thinking that if the seabios part depends on something in qemu/kvm then we should have the corresponding kvm/qemu maintaners ack it. -Kevin Avi, are you OK with this patch ? Yes, perhaps it all (including PCI hotplug controller) should be using something else than hardcoded IO ports, but thats what we have now.
[Qemu-devel] Re: [SeaBIOS] seabios: acpi: add _RMV control method for PCI devices
On 12/20/2010 10:49 AM, Marcelo Tosatti wrote: On Sun, Dec 12, 2010 at 02:57:45PM -0500, Kevin O'Connor wrote: On Sun, Dec 12, 2010 at 09:49:16PM +0200, Gleb Natapov wrote: On Sun, Dec 12, 2010 at 02:11:29PM -0500, Kevin O'Connor wrote: On Wed, Dec 08, 2010 at 03:08:59PM -0200, Marcelo Tosatti wrote: Use _RMV method to indicate whether device can be removed. Data is retrieved from QEMU via I/O port 0xae0c. Signed-off-by: Marcelo Tosattimtosa...@redhat.com Thanks Marcelo, Can you add acked-bys from the qemu/kvm maintaners? Marcelo is kvm maintainer ;) FWIW I tested this with Windows 7 XP and it works as expected. The patch relies on patch not yes excepted to qemu though. Yeah - I know - but I figured I'd ask for concensus before committing. :-) The committing of seabios patches that have a dependency on qemu/kvm is an area that I think could be better clarified. I'm thinking that if the seabios part depends on something in qemu/kvm then we should have the corresponding kvm/qemu maintaners ack it. -Kevin Avi, are you OK with this patch ? Yes, perhaps it all (including PCI hotplug controller) should be using something else than hardcoded IO ports, but thats what we have now. At least it should be documented. What's the behaviour with a qemu that doesn't support the new port? We don't strictly support it, but let's do so if we can. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH 5/6] [RFC] Emulation of Leon3.
On 12/17/2010 08:14 PM, Blue Swirl wrote:
On Wed, Dec 15, 2010 at 5:47 PM, Fabien Chouteauchout...@adacore.com wrote:
On 12/13/2010 07:18 PM, Blue Swirl wrote:
On Mon, Dec 13, 2010 at 3:51 PM, Fabien Chouteauchout...@adacore.com
wrote:
On 12/11/2010 10:56 AM, Blue Swirl wrote:
On Tue, Dec 7, 2010 at 11:40 AM, Fabien Chouteauchout...@adacore.com
wrote:
On 12/06/2010 06:53 PM, Blue Swirl wrote:
On Mon, Dec 6, 2010 at 9:26 AM, Fabien Chouteauchout...@adacore.com
wrote:
+#if !defined(CONFIG_USER_ONLY)
+/* Leon3 shutdown */
+if (intno == 0x80env-version == 0xf300) {
+leon3_shutdown();
+}
This looks like a hack. Should a trap instruction initiate a shutdown?
Yes, on Leon3 ta 0x0 initiates a shutdown.
Then this should be handled during translation. A Leon3 specific CPU
feature should be added and used much like CHECK_IU_FEATURE (in
translate.c). Then execution speed would not be affected for non-Leon3
CPUs.
OK, but I don't see how to request a shutdown during translation.
Just create a helper which calls shutdown, translator should insert a
call to that.
I think I understand what you mean, but I don't see why this would be faster
than my solution.
Shutdown is not performance critical, but interrupt handling is.
I understand that, but why is it faster to do it during translation?
I don't see how one if statement in do_interrupt will even slightly
impact
the performances, and why it will be slower than the same if' statement
in the translation.
BTW, I didn't use the unlikely function, but this will even more
reduce the impact...
--
Fabien Chouteau
Re: [Qemu-devel] [PATCH 5/6] [RFC] Emulation of Leon3.
On 12/20/2010 07:46 AM, Edgar E. Iglesias wrote:
On Fri, Dec 17, 2010 at 07:14:20PM +, Blue Swirl wrote:
On Wed, Dec 15, 2010 at 5:47 PM, Fabien Chouteauchout...@adacore.com wrote:
On 12/13/2010 07:18 PM, Blue Swirl wrote:
On Mon, Dec 13, 2010 at 3:51 PM, Fabien Chouteauchout...@adacore.com
wrote:
On 12/11/2010 10:56 AM, Blue Swirl wrote:
On Tue, Dec 7, 2010 at 11:40 AM, Fabien Chouteauchout...@adacore.com
wrote:
On 12/06/2010 06:53 PM, Blue Swirl wrote:
On Mon, Dec 6, 2010 at 9:26 AM, Fabien Chouteauchout...@adacore.com
wrote:
Signed-off-by: Fabien Chouteauchout...@adacore.com
---
...
#ifdef DEBUG_PCALL
if (qemu_loglevel_mask(CPU_LOG_INT)) {
static int count;
@@ -4135,6 +4153,14 @@ void do_interrupt(CPUState *env)
env-pc = env-tbr;
env-npc = env-pc + 4;
env-exception_index = -1;
+
+#if !defined(CONFIG_USER_ONLY)
+/* IRQ acknowledgment for Leon3 */
+if (env-version == 0xf300(intno~15) ==
TT_EXTINT)
{
+grlib_irqmp_ack (env, intno);
+leon3_cache_control_int();
+}
Like this. I don't think a CPU should immediately ack any incoming
interrupts.
Leon3 does...
Strange. Then this should be handled at board level (leon3.c).
Well, it's a CPU feature not a board feature.
Maybe, but we don't want to clutter interrupt handling with this.
I don't see what you expect here... How can I get the acknowledgment
information without changing the do_interrupt function?
Board can acknowledge the interrupt just before calling cpu_interrupt().
Hi,
I don't think that will work properly. IIUC, the leon acks the irq when it
is actually taken by the CPU. Due to CPU internal masking, that may be at
a later point than when the irq is signalled to the CPU.
Exactly I've forget to mention that. Raising the interrupt do not mean
that the
CPU will handle it directly, for example if traps are disabled or if the CPU
handles an higher priority interrupt at the moment.
IMO, what is needed is something along the lines of what Fabien coded but
with some level of indirection so that the CPU doesn't call directly into
the irqmp model. Maybe through ack function pointers or through a
qemu_irq ack line or some other way. The board should then setup the
connection between the ack mechanism and the irqmp model.
The function pointer is a good idea, something like:
if (env-qemu_irq_ack != NULL) {
env-qemu_irq_ack(intno);
}
And actually this will help me to implement others machines (erc32 and
leon2).
Are you OK with that?
--
Fabien Chouteau
Re: [Qemu-devel] Re: [PATCH] sparc32: ledma extra registers
On Sun, Dec 19, 2010 at 8:37 PM, Bob Breuer breu...@mc.net wrote:
Andreas Färber wrote:
Am 18.12.2010 um 19:53 schrieb Blue Swirl:
On Sat, Dec 18, 2010 at 5:09 PM, Bob Breuer breu...@mc.net wrote:
ledma has 0x20 bytes of registers according to OBP, and at least
Solaris9
reads the 5th register which is beyond what we've mapped. So let's
setup
a flag (inspired by a previous patch from Blue Swirl) to identify ledma
from espdma, and map another 16 bytes of registers which return 0.
Signed-off-by: Bob Breuer breu...@mc.net
I'm not familar with that part of code but...
diff --git a/hw/sparc32_dma.c b/hw/sparc32_dma.c
index e78f025..56be8c8 100644
--- a/hw/sparc32_dma.c
+++ b/hw/sparc32_dma.c
@@ -165,6 +169,9 @@ static uint32_t dma_mem_readl(void *opaque,
target_phys_addr_t addr)
DMAState *s = opaque;
uint32_t saddr;
+ if (s-is_ledma (addr DMA_MAX_REG_OFFSET)) {
+ return 0; /* extra mystery register(s) */
Wouldn't it be a good idea to trace these mystery reads...
+ }
saddr = (addr DMA_MASK) 2;
trace_sparc32_dma_mem_readl(addr, s-dmaregs[saddr]);
return s-dmaregs[saddr];
@@ -175,6 +182,9 @@ static void dma_mem_writel(void *opaque,
target_phys_addr_t addr, uint32_t val)
DMAState *s = opaque;
uint32_t saddr;
+ if (s-is_ledma (addr DMA_MAX_REG_OFFSET)) {
+ return; /* extra mystery register(s) */
...and writes? We return just before the tracepoints fire.
Ok, I'll put together a patch to add the trace calls just before the
returns. How about I also call it undocumented instead of mystery.
None of the BSD's or Linux know about or use anything beyond the 4
registers.
I'd use aliased instead of mystery. On a real SS-5:
ok 78400020 20 spacel@ .
a4240050
ok 7840 20 spacel@ .
a4240050
ok 78400024 20 spacel@ .
fc004000
ok 7844 20 spacel@ .
fc004000
Addresses 0x7840002x are aliases for 0x784x. As well as
0x7840004x. And so on up to
ok 787fffe4 20 spacel@ .
fc004000
7884 20 spacel@ .
0
Or a real SS-20 ef040 is aliased up to ef37fffe0
Fwiw I think it's a bug in the later Solaris versions:
http://tyom.blogspot.com/2010/10/bug-in-all-solaris-versions-after-57.html
On the bare metal it works because of address aliasing. If you want to
emulate the hw precisely, the Blue's generic aliasing patch can be
used here. The question is though do we want to do a generic aliasing
for all the SBUS devices, or just in the single case(es) where we know
is necessary.
On the other hand Solaris seems to be fine with a 0 stub too.
--
Regards,
Artyom Tarasenko
solaris/sparc under qemu blog: http://tyom.blogspot.com/
[Qemu-devel] Re: [PATCH V2] qemu, kvm: Enable user space NMI injection for kvm guest
On Fri, Dec 10, 2010 at 03:42:53PM +0800, Lai Jiangshan wrote: Make use of the new KVM_NMI IOCTL to send NMIs into the KVM guest if the user space raised them. (example: qemu monitor's nmi command) Signed-off-by: Lai Jiangshan la...@cn.fujitsu.com Applied to uq/master, thanks.
Re: [Qemu-devel] [PATCH v2] win32: Fix CRLF problem in make_device_config.sh
On 12/19/2010 05:06 PM, Andreas Färber wrote:
Andreas, may I ask you for one more test?
$ echo -e 'include xy\r' | tr -d '\r' | awk '/^include / {ORS=; print
$2}' | od -c
I'd not bother with ORS and use '$1 == include { printf %s, $2 }'
instead.
Paolo
[Qemu-devel] Re: [PATCH v2 2/2] qemu, qmp: convert do_inject_nmi() to QObject, QError
On Fri, Dec 10, 2010 at 09:20:26AM -0200, Luiz Capitulino wrote:
On Fri, 10 Dec 2010 14:36:08 +0800
Lai Jiangshan la...@cn.fujitsu.com wrote:
+SQMP
+inject_nmi
+--
+
+Inject an NMI on the given CPU (x86 only).
+
+Arguments:
+
+- cpu_index: the index of the CPU to be injected NMI (json-int)
+
+Example:
+
+- { execute: inject_nmi, arguments: { cpu_index: 0 } }
+- { return: {} }
+
+EQMP
+
Avi, Anthony, can you please review this? Do we expect some kind of ack from
the guest? Do we expect it respond in some way?
Looks good to me. Don't except any response from the guest.
Also note that the current series defines only one error condition: invalid
cpu index. Can this fail in other ways?
--
Not really. An NMI can be pending already (which means the current
command has no effect), but i don't see the need to report that.
[Qemu-devel] Re: Re: [PATCH 0/4] ppc: Fix PReP emulation
So we certainly do need some open source firmware solution for prep to at least have Linux running. For other guests, I don't see a reason why users shouldn't try to fetch a real firmware blob separately :). We're not shipping any firmware for ppcemb either, so that argument seems moot. OpenBIOS, SeaBIOS and ZIPL are the only ones currently. Feel free to supply additional blobs for U-Boot etc. IIUC you don't need u-boot for the embedded targets. You just pass in a kernel and the rest is magic. This holds only for Linux which imposes its own startup API to bootloaders and go with kernel drivers directly. Other OS like Haiku use a 2nd stage bootloader which assumes a working callable BIOS (OF on ppc), and getting it to run on U-Boot is already tricky on its own. Recent vanilla Linux kernels wouldn't run on PReP. So what Linux do you want to run using open source firmware? I certainly do not intend to write firmware for the upcoming 40p machine. If Linux runs on real 40p hardware then it should run with real firmware under emulation, too. QEMU is an emulation project, not a Linux testing framework. I completely agree. Linux is usually easy because it's fully open source and supports a lot of targets. If you feel like running NetBSD or Haiku instead, feel free to do so. Thanks for thinking about Haiku ;) Btw there are other existing targets, like AROS, MorphOS, or AmigaOS which uses a modified U-Boot with a 'boota' command that passes their 2nd stage Parthenope bootloader a list of BIOS-like callbacks into U-Boot, cf. : http://www.acube-systems.biz/index.php?page=hardwarepid=2 http://www.acube-systems.biz/download/u-boot-1.3.1c_20101206_prod.tar.gz Though they probably won't run on PReP, and PReP support in Haiku might come only for the sake of supporting the BeBox, which had its own dumb firmware (MAME seems to have some emulation support for BeBox). OTOH, I've been thinking about adding a Sam440 target, but it'd still require the custom U-Boot to start AmigaOS for example. François.
[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
On 20.12.2010, at 13:19, François Revol wrote: So we certainly do need some open source firmware solution for prep to at least have Linux running. For other guests, I don't see a reason why users shouldn't try to fetch a real firmware blob separately :). We're not shipping any firmware for ppcemb either, so that argument seems moot. OpenBIOS, SeaBIOS and ZIPL are the only ones currently. Feel free to supply additional blobs for U-Boot etc. IIUC you don't need u-boot for the embedded targets. You just pass in a kernel and the rest is magic. This holds only for Linux which imposes its own startup API to bootloaders and go with kernel drivers directly. Other OS like Haiku use a 2nd stage bootloader which assumes a working callable BIOS (OF on ppc), and getting it to run on U-Boot is already tricky on its own. That was my point :). I'm not aware of us supporting firmware on ppcemb, so it's capable of running an OS all by itself already. Recent vanilla Linux kernels wouldn't run on PReP. So what Linux do you want to run using open source firmware? I certainly do not intend to write firmware for the upcoming 40p machine. If Linux runs on real 40p hardware then it should run with real firmware under emulation, too. QEMU is an emulation project, not a Linux testing framework. I completely agree. Linux is usually easy because it's fully open source and supports a lot of targets. If you feel like running NetBSD or Haiku instead, feel free to do so. Thanks for thinking about Haiku ;) Btw there are other existing targets, like AROS, MorphOS, or AmigaOS which uses a modified U-Boot with a 'boota' command that passes their 2nd stage Parthenope bootloader a list of BIOS-like callbacks into U-Boot, cf. : http://www.acube-systems.biz/index.php?page=hardwarepid=2 http://www.acube-systems.biz/download/u-boot-1.3.1c_20101206_prod.tar.gz Though they probably won't run on PReP, and PReP support in Haiku might come only for the sake of supporting the BeBox, which had its own dumb firmware (MAME seems to have some emulation support for BeBox). OTOH, I've been thinking about adding a Sam440 target, but it'd still require the custom U-Boot to start AmigaOS for example. I'd call U-Boot the firmware that we can ship with Qemu then because it's open source :). I'm not advocate for openBIOS. If it works, great. If something else works better, let's take that. The only thing I really want to see is a target that does something useful. That's it :). A target that loads proprietary firmware halfway through is not valuable to users IMHO. A target that loads proprietary firmware and boots an OS is valuable. A target that doesn't need firmware and loads an OS is valuable. Maybe a target that doesn't boot an OS quite yet, but loads open source firmware pretty well is valuable too. Alex
[Qemu-devel] [PATCH 1/3] ide: factor dma handling helpers
Factor the DMA I/O path that is duplicated between read and write
commands, into common helpers using the s-is_read flag added for
the macio ATA controller.
Signed-off-by: Christoph Hellwig h...@lst.de
Index: qemu/hw/ide/core.c
===
--- qemu.orig/hw/ide/core.c 2010-12-17 11:38:48.992003425 +0100
+++ qemu/hw/ide/core.c 2010-12-17 11:48:43.252255415 +0100
@@ -487,16 +487,18 @@ static int ide_handle_rw_error(IDEState
return 1;
}
-void ide_read_dma_cb(void *opaque, int ret)
+void ide_dma_cb(void *opaque, int ret)
{
IDEState *s = opaque;
int n;
int64_t sector_num;
if (ret 0) {
-if (ide_handle_rw_error(s, -ret,
-BM_STATUS_DMA_RETRY | BM_STATUS_RETRY_READ))
-{
+int op = BM_STATUS_DMA_RETRY;
+
+if (s-is_read)
+op |= BM_STATUS_RETRY_READ;
+if (ide_handle_rw_error(s, -ret, op)) {
return;
}
}
@@ -504,7 +506,7 @@ void ide_read_dma_cb(void *opaque, int r
n = s-io_buffer_size 9;
sector_num = ide_get_sector(s);
if (n 0) {
-dma_buf_commit(s, 1);
+dma_buf_commit(s, s-is_read);
sector_num += n;
ide_set_sector(s, sector_num);
s-nsector -= n;
@@ -514,32 +516,44 @@ void ide_read_dma_cb(void *opaque, int r
if (s-nsector == 0) {
s-status = READY_STAT | SEEK_STAT;
ide_set_irq(s-bus);
-eot:
-s-bus-dma-ops-add_status(s-bus-dma, BM_STATUS_INT);
-ide_set_inactive(s);
-return;
+goto eot;
}
/* launch next transfer */
n = s-nsector;
-s-io_buffer_index = 0;
+if (s-is_read)
+s-io_buffer_index = 0;
s-io_buffer_size = n * 512;
-if (s-bus-dma-ops-prepare_buf(s-bus-dma, 1) == 0)
+if (s-bus-dma-ops-prepare_buf(s-bus-dma, s-is_read) == 0)
goto eot;
+
#ifdef DEBUG_AIO
-printf(aio_read: sector_num=% PRId64 n=%d\n, sector_num, n);
+printf(ide_dma_cb: sector_num=% PRId64 n=%d, is_read=%d\n,
+ sector_num, n, s-is_read);
#endif
-s-bus-dma-aiocb = dma_bdrv_read(s-bs, s-sg, sector_num,
ide_read_dma_cb, s);
-ide_dma_submit_check(s, ide_read_dma_cb);
+
+if (s-is_read) {
+s-bus-dma-aiocb = dma_bdrv_read(s-bs, s-sg, sector_num,
+ ide_dma_cb, s);
+} else {
+s-bus-dma-aiocb = dma_bdrv_write(s-bs, s-sg, sector_num,
+ide_dma_cb, s);
+}
+ide_dma_submit_check(s, ide_dma_cb);
+return;
+
+eot:
+ s-bus-dma-ops-add_status(s-bus-dma, BM_STATUS_INT);
+ ide_set_inactive(s);
}
-static void ide_sector_read_dma(IDEState *s)
+static void ide_sector_start_dma(IDEState *s, int is_read)
{
s-status = READY_STAT | SEEK_STAT | DRQ_STAT | BUSY_STAT;
s-io_buffer_index = 0;
s-io_buffer_size = 0;
-s-is_read = 1;
-s-bus-dma-ops-start_dma(s-bus-dma, s, ide_read_dma_cb);
+s-is_read = is_read;
+s-bus-dma-ops-start_dma(s-bus-dma, s, ide_dma_cb);
}
static void ide_sector_write_timer_cb(void *opaque)
@@ -594,57 +608,6 @@ void ide_sector_write(IDEState *s)
}
}
-void ide_write_dma_cb(void *opaque, int ret)
-{
-IDEState *s = opaque;
-int n;
-int64_t sector_num;
-
-if (ret 0) {
-if (ide_handle_rw_error(s, -ret, BM_STATUS_DMA_RETRY))
-return;
-}
-
-n = s-io_buffer_size 9;
-sector_num = ide_get_sector(s);
-if (n 0) {
-dma_buf_commit(s, 0);
-sector_num += n;
-ide_set_sector(s, sector_num);
-s-nsector -= n;
-}
-
-/* end of transfer ? */
-if (s-nsector == 0) {
-s-status = READY_STAT | SEEK_STAT;
-ide_set_irq(s-bus);
-eot:
-s-bus-dma-ops-add_status(s-bus-dma, BM_STATUS_INT);
-ide_set_inactive(s);
-return;
-}
-
-n = s-nsector;
-s-io_buffer_size = n * 512;
-/* launch next transfer */
-if (s-bus-dma-ops-prepare_buf(s-bus-dma, 0) == 0)
-goto eot;
-#ifdef DEBUG_AIO
-printf(aio_write: sector_num=% PRId64 n=%d\n, sector_num, n);
-#endif
-s-bus-dma-aiocb = dma_bdrv_write(s-bs, s-sg, sector_num,
ide_write_dma_cb, s);
-ide_dma_submit_check(s, ide_write_dma_cb);
-}
-
-static void ide_sector_write_dma(IDEState *s)
-{
-s-status = READY_STAT | SEEK_STAT | DRQ_STAT | BUSY_STAT;
-s-io_buffer_index = 0;
-s-io_buffer_size = 0;
-s-is_read = 0;
-s-bus-dma-ops-start_dma(s-bus-dma, s, ide_write_dma_cb);
-}
-
void ide_atapi_cmd_ok(IDEState *s)
{
s-error = 0;
@@ -1858,7 +1821,7 @@ void ide_exec_cmd(IDEBus *bus, uint32_t
if (!s-bs)
goto abort_cmd;
ide_cmd_lba48_transform(s, lba48);
-ide_sector_read_dma(s);
+ide_sector_start_dma(s, 1);
break;
case WIN_WRITEDMA_EXT:
lba48 = 1;
@@ -1867,7 +1830,7 @@ void ide_exec_cmd(IDEBus *bus, uint32_t
if (!s-bs)
goto abort_cmd;
[Qemu-devel] [PATCH 2/3] ide: also reset io_buffer_index for writes
Currenly the code only resets the io_buffer_index field for reads, but the code seems to expect this for all types of I/O. I guess we simply don't hit large enough transfers that would require this often enough. Signed-off-by: Christoph Hellwig h...@lst.de Index: qemu/hw/ide/core.c === --- qemu.orig/hw/ide/core.c 2010-12-17 12:03:27.737004194 +0100 +++ qemu/hw/ide/core.c 2010-12-17 12:03:41.485004404 +0100 @@ -521,8 +521,7 @@ void ide_dma_cb(void *opaque, int ret) /* launch next transfer */ n = s-nsector; -if (s-is_read) -s-io_buffer_index = 0; +s-io_buffer_index = 0; s-io_buffer_size = n * 512; if (s-bus-dma-ops-prepare_buf(s-bus-dma, s-is_read) == 0) goto eot;
[Qemu-devel] [PATCH 3/3] ide: kill ide_dma_submit_check
Merge ide_dma_submit_check into it's only caller. Also use tail recursion
using a goto instead of a real recursion - this avoid overflowing the
stack in the pathological situation of an recurring error that is ignored.
We'll still be busy looping in ide_dma_cb, but at least won't eat up
all stack space after this.
Signed-off-by: Christoph Hellwig h...@lst.de
Index: qemu/hw/ide/core.c
===
--- qemu.orig/hw/ide/core.c 2010-12-20 13:16:11.379004054 +0100
+++ qemu/hw/ide/core.c 2010-12-20 13:16:11.0 +0100
@@ -321,14 +321,6 @@ static inline void ide_abort_command(IDE
s-error = ABRT_ERR;
}
-static inline void ide_dma_submit_check(IDEState *s,
- BlockDriverCompletionFunc *dma_cb)
-{
-if (s-bus-dma-aiocb)
- return;
-dma_cb(s, -1);
-}
-
/* prepare data transfer and tell what to do after */
static void ide_transfer_start(IDEState *s, uint8_t *buf, int size,
EndTransferFunc *end_transfer_func)
@@ -493,6 +485,7 @@ void ide_dma_cb(void *opaque, int ret)
int n;
int64_t sector_num;
+handle_rw_error:
if (ret 0) {
int op = BM_STATUS_DMA_RETRY;
@@ -538,7 +531,11 @@ void ide_dma_cb(void *opaque, int ret)
s-bus-dma-aiocb = dma_bdrv_write(s-bs, s-sg, sector_num,
ide_dma_cb, s);
}
-ide_dma_submit_check(s, ide_dma_cb);
+
+if (!s-bus-dma-aiocb) {
+ret = -1;
+goto handle_rw_error;
+}
return;
eot:
Re: [Qemu-devel] [PATCH v2 2/6] qdev: reset qdev along with qdev tree
Anthony Liguori aligu...@linux.vnet.ibm.com writes: On 12/17/2010 08:45 AM, Peter Maydell wrote: On 17 December 2010 00:24, Anthony Liguorialigu...@linux.vnet.ibm.com wrote: On 12/16/2010 05:48 PM, Michael S. Tsirkin wrote: Ugh, I keep forgetting about the non-qdev systems. Maybe it's a good way to finally make everyone to convert? If a system maintainer can't be bothered to convert to qdev we can declare the system unsupported :) Honestly, I think that's a fair thing to do. I'm guessing that would be a transition/conversion to make for the 0.15 release, right? Yes. Let's do it.
[Qemu-devel] Re: [PATCH v2] qbus: register reset handler for qbus whose parent is NULL
On Mon, Dec 20, 2010 at 02:33:35PM +0900, Isaku Yamahata wrote:
Stefan Weil reported the regression caused by
ec990eb622ad46df5ddcb1e94c418c271894d416 as follows
The second regression also occurs with MIPS malta.
Networking no longer works with the default pcnet nic.
This is caused because the reset function for pcnet is no
longer called during system boot. The result in an invalid
mac address (all zero) and a non-working nic.
For this second regression I still have no simple solution.
Of course mips_malta.c should be converted to qdev which
would fix both problems (but only for malta system emulation).
The issue is, it is assumed that all qbuses, qdeves are under
main_system_bus. But there are qbuses whose parent is NULL. So it
is necessary to trigger reset for those qbuses.
(On the other hand, if NULL is passed to qdev_create(), its parent bus
is main_system_bus.)
Ideally those buses should be moved under bus controller
device which is qdev. But it's not done yet.
So register qbus reset handler for qbus whose parent is NULL.
Reported-by: Stefan Weil w...@mail.berlios.de
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp
Applied, thanks!
---
Changes v1 - v2:
- unregister reset handler in qbus_free()
- update the comment
- remove ugly void* cast with wrapper
- assert() in qbus_free() because main_system_bus is never freed
---
hw/qdev.c | 14 +-
hw/qdev.h |2 ++
vl.c |4 +++-
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/hw/qdev.c b/hw/qdev.c
index 6fc9b02..d93a6c4 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -333,6 +333,12 @@ void qbus_reset_all(BusState *bus)
qbus_walk_children(bus, qdev_reset_one, qbus_reset_one, NULL);
}
+void qbus_reset_all_fn(void *opaque)
+{
+BusState *bus = opaque;
+qbus_reset_all(bus);
+}
+
/* can be used as -unplug() callback for the simple cases */
int qdev_simple_unplug_cb(DeviceState *dev)
{
@@ -754,8 +760,11 @@ void qbus_create_inplace(BusState *bus, BusInfo *info,
if (parent) {
QLIST_INSERT_HEAD(parent-child_bus, bus, sibling);
parent-num_child_bus++;
+} else if (bus != main_system_bus) {
+/* TODO: once all bus devices are qdevified,
+ only reset handler for main_system_bus should be registered here.
*/
+qemu_register_reset(qbus_reset_all_fn, bus);
}
-
}
BusState *qbus_create(BusInfo *info, DeviceState *parent, const char *name)
@@ -778,6 +787,9 @@ void qbus_free(BusState *bus)
if (bus-parent) {
QLIST_REMOVE(bus, sibling);
bus-parent-num_child_bus--;
+} else {
+assert(bus != main_system_bus); /* main_system_bus is never freed */
+qemu_unregister_reset(qbus_reset_all_fn, bus);
}
qemu_free((void*)bus-name);
if (bus-qdev_allocated) {
diff --git a/hw/qdev.h b/hw/qdev.h
index aaaf55a..b239bb4 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -199,6 +199,8 @@ int qdev_walk_children(DeviceState *dev, qdev_walkerfn
*devfn,
qbus_walkerfn *busfn, void *opaque);
void qdev_reset_all(DeviceState *dev);
void qbus_reset_all(BusState *bus);
+void qbus_reset_all_fn(void *opaque);
+
void qbus_free(BusState *bus);
#define FROM_QBUS(type, dev) DO_UPCAST(type, qbus, dev)
diff --git a/vl.c b/vl.c
index c4d3fc0..8d6bab4 100644
--- a/vl.c
+++ b/vl.c
@@ -3088,7 +3088,9 @@ int main(int argc, char **argv, char **envp)
exit(1);
}
-qemu_register_reset((void *)qbus_reset_all, sysbus_get_default());
+/* TODO: once all bus devices are qdevified, this should be done
+ * when bus is created by qdev.c */
+qemu_register_reset(qbus_reset_all_fn, sysbus_get_default());
qemu_run_machine_init_done_notifiers();
qemu_system_reset();
--
1.7.1.1
[Qemu-devel] [Bug 502107] Re: qemu-kvm 0.12.1.2 crashes booting Ubuntu 9.10 with -vga std
still not resolved: guest=Ubuntu 10.10, host=Fedora14 crashes with -vga std or -vga vmware works with -vga cirrus -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/502107 Title: qemu-kvm 0.12.1.2 crashes booting Ubuntu 9.10 with -vga std Status in QEMU: Confirmed Bug description: I have an Ubuntu VM that works fine without -vga std but crashes if I add -vga std. This is the full command line: qemu-system-x86_64 -vga std -drive cache=writeback,index=0,media=disk,file=ubuntu.img -k en-us -m 2048 -smp 2 -vnc :3102 -usbdevice tablet -enable-kvm I get this error: KVM internal error. Suberror: 1 rax 7f789177e000 rbx rcx rdx rsi rdi 7f789177e000 rsp 7fff361775e8 rbp 7fff36177600 r8 ff80 r9 0020 r10 r11 7f789100a3f0 r12 004017c0 r13 7fff36178cf0 r14 r15 rip 7f789100aa7b rflags 00013206 cs 0033 (/ p 1 dpl 3 db 0 s 1 type b l 1 g 1 avl 0) ds (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) es (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) ss 002b (/ p 1 dpl 3 db 1 s 1 type 3 l 0 g 1 avl 0) fs (7f78917906f0/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) gs (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) tr 0040 (880001a09440/2087 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) gdt 8800019fa000/7f idt 818fd000/fff cr0 80050033 cr2 2408000 cr3 379d4000 cr4 6f0 cr8 0 efer d01 emulation failure, check dmesg for details I'm running kernel 2.6.32, and I have the kvm stuff compiled directly into the kernel. There's nothing in dmesg about kvm at all. Note that in the VM grub comes up, but the VM dies when I boot the kernel. This command line works: qemu-system-x86_64 -drive cache=writeback,index=0,media=disk,file=ubuntu.img -k en-us -m 2048 -smp 2 -vnc :3102 -usbdevice tablet -enable-kvm That is, removing -vga std fixes the problem. I recently added this option to both my Ubuntu and Windows XP VMs. The Windows VM still works fine. If Windows can detect that the graphics card has changed, then Ubuntu should also have no problem. That being said, I added the std option when using 0.12.1.1, so there may be a qemu regression. I have reported this bug elsewhere: http://bugs.gentoo.org/show_bug.cgi?id=299211
[Qemu-devel] [Bug 670883] Re: ARM : ldrexd and strexd implementation flawed
The patch has now been merged into qemu's master git repo:
http://git.qemu.org/qemu.git/commit/?id=2c9adbda721c9996ec6b371cac4a00c1164b818e
(and so this bug should be fixed in the 0.14 release since that has not
yet branched.)
** Changed in: qemu
Status: New = Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/670883
Title:
ARM : ldrexd and strexd implementation flawed
Status in QEMU:
Fix Committed
Bug description:
The ldrexd / strexd instructions have a flawed implementation : it never
works properly. For example, the most simple code something like:
ldrexd r0, r1, [r2]
strexd r4, r0, r1, [r2]
which should usually have r4 as zero (successfully done the exclusive store).
However, the current implementation always returns one (unsuccessfully done the
exclusive store).
The current trunk (function gen_load_exclusive, gen_store_exclusive, both from
target-arm/translate.c) looks like an incorrect implementation:
static void gen_load_exclusive(DisasContext *s, int rt, int rt2,
TCGv addr, int size)
{
TCGv tmp;
switch (size) {
case 0:
tmp = gen_ld8u(addr, IS_USER(s));
break;
case 1:
tmp = gen_ld16u(addr, IS_USER(s));
break;
case 2:
case 3:
tmp = gen_ld32(addr, IS_USER(s));
break;
default:
abort();
}
tcg_gen_mov_i32(cpu_exclusive_val, tmp);
store_reg(s, rt, tmp);
if (size == 3) {
tcg_gen_addi_i32(addr, addr, 4);
tmp = gen_ld32(addr, IS_USER(s));
tcg_gen_mov_i32(cpu_exclusive_high, tmp);
store_reg(s, rt2, tmp);
}
tcg_gen_mov_i32(cpu_exclusive_addr, addr);
}
The problem lies when size is 3 (=ldrexd) : normally, cpu_exclusive_addr should
be set as addr, but since the current implementation increments addr by 4 (when
size is 3) before cpu_exclusive_addr is updated, it results in a wrong value
stored on cpu_exclusive_addr.
Another error on gen_store_exclusive():
...
if (size == 3) {
TCGv tmp2 = new_tmp();
tcg_gen_addi_i32(tmp2, addr, 4);
tmp = gen_ld32(addr, IS_USER(s));
dead_tmp(tmp2);
tcg_gen_brcond_i32(TCG_COND_NE, tmp, cpu_exclusive_high, fail_label);
dead_tmp(tmp);
}
the current code assigns tmp2 as addr + 4, but loads from addr on the next
line, not from tmp2(=addr+4).
[Qemu-devel] [Bug 502107] Re: qemu-kvm 0.12.1.2 crashes booting Ubuntu 9.10 with -vga std
PS: qemu-kvm -version = 0.13.0 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/502107 Title: qemu-kvm 0.12.1.2 crashes booting Ubuntu 9.10 with -vga std Status in QEMU: Confirmed Bug description: I have an Ubuntu VM that works fine without -vga std but crashes if I add -vga std. This is the full command line: qemu-system-x86_64 -vga std -drive cache=writeback,index=0,media=disk,file=ubuntu.img -k en-us -m 2048 -smp 2 -vnc :3102 -usbdevice tablet -enable-kvm I get this error: KVM internal error. Suberror: 1 rax 7f789177e000 rbx rcx rdx rsi rdi 7f789177e000 rsp 7fff361775e8 rbp 7fff36177600 r8 ff80 r9 0020 r10 r11 7f789100a3f0 r12 004017c0 r13 7fff36178cf0 r14 r15 rip 7f789100aa7b rflags 00013206 cs 0033 (/ p 1 dpl 3 db 0 s 1 type b l 1 g 1 avl 0) ds (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) es (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) ss 002b (/ p 1 dpl 3 db 1 s 1 type 3 l 0 g 1 avl 0) fs (7f78917906f0/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) gs (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) tr 0040 (880001a09440/2087 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) gdt 8800019fa000/7f idt 818fd000/fff cr0 80050033 cr2 2408000 cr3 379d4000 cr4 6f0 cr8 0 efer d01 emulation failure, check dmesg for details I'm running kernel 2.6.32, and I have the kvm stuff compiled directly into the kernel. There's nothing in dmesg about kvm at all. Note that in the VM grub comes up, but the VM dies when I boot the kernel. This command line works: qemu-system-x86_64 -drive cache=writeback,index=0,media=disk,file=ubuntu.img -k en-us -m 2048 -smp 2 -vnc :3102 -usbdevice tablet -enable-kvm That is, removing -vga std fixes the problem. I recently added this option to both my Ubuntu and Windows XP VMs. The Windows VM still works fine. If Windows can detect that the graphics card has changed, then Ubuntu should also have no problem. That being said, I added the std option when using 0.12.1.1, so there may be a qemu regression. I have reported this bug elsewhere: http://bugs.gentoo.org/show_bug.cgi?id=299211
[Qemu-devel] [Bug 692570] [NEW] APIC Latency causing BSOD.
Public bug reported: I have a Proxmox Server with the following specs: Version: pve-manager: 1.7-10 (pve-manager/1.7/5323) running kernel: 2.6.32-4-pve proxmox-ve-2.6.32: 1.7-28 pve-kernel-2.6.32-4-pve: 2.6.32-28 qemu-server: 1.1-25 pve-firmware: 1.0-9 libpve-storage-perl: 1.0-16 vncterm: 0.9-2 vzctl: 3.0.24-1pve4 vzdump: 1.2-9 vzprocps: 2.0.11-1dso2 vzquota: 3.0.11-1 pve-qemu-kvm: 0.13.0-2 ksm-control-daemon: 1.0-4 VM Configuration: name: TS64 ide2: none,media=cdrom bootdisk: ide0 ostype: w2k3 ide0: data:vm-104-disk-1 memory: 10240 sockets: 1 vlan0: virtio=C6:4C:B3:BB:AD:67 onboot: 1 cores: 4 boot: cad freeze: 0 cpuunits: 1000 acpi: 1 kvm: 1 CPU 2x Xeon Quad Core E5620 2.4GHZ Processors: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 44 model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz stepping : 2 cpu MHz : 2400.323 cache size : 12288 KB physical id : 0 siblings : 8 core id : 9 cpu cores : 4 apicid : 19 initial apicid : 19 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm ida arat tpr_shadow vnmi flexpriority ept vpid bogomips : 4800.19 clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: Performance: CPU BOGOMIPS: 76803.21 REGEX/SECOND: 850066 HD SIZE: 33.96 GB (/dev/mapper/pve-root) BUFFERED READS: 333.03 MB/sec AVERAGE SEEK TIME: 6.10 ms FSYNCS/SECOND: 2948.85 DNS EXT: 131.42 ms DNS INT: 1.28 ms I've been successfully running 2 Windows 2003 32-Bit Standard Edition Servers on this server for over a month now. Both were migrations from actual physical servers. However, I've continued to receive random crashes on a Windows 2003 64-bit standard edition running terminal services, which was a fresh install. The server runs fine for hours under a decent load (20 users) and then will crash with a 3B bug check code (System_Service_Exception). I opened a ticket with Microsoft and submitted multiple memory dumps and their engineers suggested the following: Dump Analyses Result: === What happened is that the OS initiated an APIC /software interrupt. This is handled by the APIC in real hardware. In your Virtual Environment case where you are using Linux based VM – Proxmox, the VM implementation somehow has to make it happen on a virtual machine with the same latency in the virtual APIC. The problem is that there is a latency between when it was initiated and when it happened. Below are the details for understanding the process or concept of APIC interrupts: What the Local APIC Is The Local APIC (LAPIC) is a circuit that is part of the CPU chip. It contains these basic elements: A mechanism for generating 1. interrupts 2. A mechanism for accepting interrupts 3. A timer If you have a multiprocessor system, the APIC's are wired together so they can communicate. So the LAPIC on CPU 0 can communicate with the LAPIC on CPU 1, etc. What the IO APIC Is This is a separate chip that is wired to the Local APIC's so it can forward interrupts on to the CPU chips. It is programmed similar to the 8259's but has more flexibility. It is wired to the same bus as the Local APIC's so it can communicate with them. Note:- In our scenario, it’s all Virtualized interrupts or calls because of hypervisor in picture and thus we need to contact the VM application vendor to get a check of this latency issue in APIC interrupt. End of Message-- Their engineers are saying that there is a latency issue with APIC. I'm not exactly sure how this can be corrected. Is this a known issue and is their a solution to this problem. I love Proxmox, but my main reason for using it was to upgrade my terminal server to better hardware, while leveraging it for other virtual machines as well. The forum administrator for Proxmox, suggested I bring this issue to your attention. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/692570 Title: APIC Latency causing BSOD. Status in QEMU: New Bug description: I have a Proxmox Server with the following specs: Version: pve-manager: 1.7-10 (pve-manager/1.7/5323) running kernel: 2.6.32-4-pve proxmox-ve-2.6.32: 1.7-28 pve-kernel-2.6.32-4-pve: 2.6.32-28 qemu-server: 1.1-25 pve-firmware: 1.0-9 libpve-storage-perl: 1.0-16 vncterm: 0.9-2 vzctl: 3.0.24-1pve4 vzdump: 1.2-9 vzprocps: 2.0.11-1dso2 vzquota: 3.0.11-1 pve-qemu-kvm: 0.13.0-2 ksm-control-daemon: 1.0-4 VM Configuration: name: TS64 ide2: none,media=cdrom bootdisk: ide0 ostype:
[Qemu-devel] [Bug 502107] Re: qemu-kvm 0.12.1.2 crashes booting Ubuntu 9.10 with -vga std
PPS: Ubuntu 10.10 crashes also with qemu-kvm -vga qxl -spice ... -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/502107 Title: qemu-kvm 0.12.1.2 crashes booting Ubuntu 9.10 with -vga std Status in QEMU: Confirmed Bug description: I have an Ubuntu VM that works fine without -vga std but crashes if I add -vga std. This is the full command line: qemu-system-x86_64 -vga std -drive cache=writeback,index=0,media=disk,file=ubuntu.img -k en-us -m 2048 -smp 2 -vnc :3102 -usbdevice tablet -enable-kvm I get this error: KVM internal error. Suberror: 1 rax 7f789177e000 rbx rcx rdx rsi rdi 7f789177e000 rsp 7fff361775e8 rbp 7fff36177600 r8 ff80 r9 0020 r10 r11 7f789100a3f0 r12 004017c0 r13 7fff36178cf0 r14 r15 rip 7f789100aa7b rflags 00013206 cs 0033 (/ p 1 dpl 3 db 0 s 1 type b l 1 g 1 avl 0) ds (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) es (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) ss 002b (/ p 1 dpl 3 db 1 s 1 type 3 l 0 g 1 avl 0) fs (7f78917906f0/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) gs (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) tr 0040 (880001a09440/2087 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) gdt 8800019fa000/7f idt 818fd000/fff cr0 80050033 cr2 2408000 cr3 379d4000 cr4 6f0 cr8 0 efer d01 emulation failure, check dmesg for details I'm running kernel 2.6.32, and I have the kvm stuff compiled directly into the kernel. There's nothing in dmesg about kvm at all. Note that in the VM grub comes up, but the VM dies when I boot the kernel. This command line works: qemu-system-x86_64 -drive cache=writeback,index=0,media=disk,file=ubuntu.img -k en-us -m 2048 -smp 2 -vnc :3102 -usbdevice tablet -enable-kvm That is, removing -vga std fixes the problem. I recently added this option to both my Ubuntu and Windows XP VMs. The Windows VM still works fine. If Windows can detect that the graphics card has changed, then Ubuntu should also have no problem. That being said, I added the std option when using 0.12.1.1, so there may be a qemu regression. I have reported this bug elsewhere: http://bugs.gentoo.org/show_bug.cgi?id=299211
Re: [Qemu-devel] [PATCH 00/15] Megasas HBA emulation and SCSI update v.3
Any chance you could resubmit the remaining patches after addressing the outstanding comments? We'll really need the scsi changes to move forward without introducing conflicts.
Re: [Qemu-devel] [PATCH 00/15] Megasas HBA emulation and SCSI update v.3
On 12/20/2010 03:59 PM, Christoph Hellwig wrote: Any chance you could resubmit the remaining patches after addressing the outstanding comments? We'll really need the scsi changes to move forward without introducing conflicts. Yes, I'm currently rebasing my patchset relative to Kevin's git tree. Hopefully I'll be finished sometime this week. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg)
[Qemu-devel] KVM call agenda for Dec 21
Please send in any agenda items you are interested in covering. thanks, -chris
Re: [Qemu-devel] [PATCH 2/3] nmi: make cpu-index argument optional
Lai Jiangshan la...@cn.fujitsu.com writes:
When the argument cpu-index is not given,
then nmi command will inject NMI on all CPUs.
This simulate the nmi button on physical machine.
Signed-off-by: Lai Jiangshan la...@cn.fujitsu.com
---
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 8de7aa3..d8fe4c0 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -721,9 +721,9 @@ ETEXI
#if defined(TARGET_I386)
{
.name = nmi,
-.args_type = cpu-index:i,
-.params = cpu,
-.help = inject an NMI on the given CPU,
+.args_type = cpu-index:i?,
+.params = [cpu],
+.help = inject an NMI on all CPUs or the given CPU,
.mhandler.cmd = do_inject_nmi,
},
#endif
diff --git a/monitor.c b/monitor.c
index c16b39d..45a8dc2 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2410,7 +2410,13 @@ static void do_wav_capture(Monitor *mon, const QDict
*qdict)
static void do_inject_nmi(Monitor *mon, const QDict *qdict)
{
CPUState *env;
-int cpu_index = qdict_get_int(qdict, cpu-index);
+int cpu_index = qdict_get_try_int(qdict, cpu-index, -1);
Note that we interpret nmi -1 as nmi (no argument). Doesn't matter
now. Does matter after the next patch, because that patch makes the
command when the argument doesn't make sense. Except it doesn't for the
non-sensical argument -1. Same problem with every existing use of
qdict_get_try_int() in the monitor. Do we care?
+
+if (cpu_index == -1) {
+for (env = first_cpu; env != NULL; env = env-next_cpu)
+cpu_interrupt(env, CPU_INTERRUPT_NMI);
+return;
+}
for (env = first_cpu; env != NULL; env = env-next_cpu)
if (env-cpu_index == cpu_index) {
Re: [Qemu-devel] [PATCH V4 3/3] qmp, nmi: convert do_inject_nmi() to QObject, QError
Lai Jiangshan la...@cn.fujitsu.com writes: Make we can inject NMI via qemu-monitor-protocol. We use inject-nmi for the qmp command name, the meaning is clearer. When cpu-index is found invalid in runtime, it will report QERR_INVALID_PARAMETER_VALUE. This patch does two separate things: 1. Fix do_inject_nmi() to detect invalid arguments. 2. Convert it to QObject. If you have to respin anyway, please split the patch to keep the two separate.
[Qemu-devel] Re: [SeaBIOS] seabios: acpi: add _RMV control method for PCI devices
On 12/20/2010 07:05 PM, Marcelo Tosatti wrote: Yes, perhaps it all (including PCI hotplug controller) should be using something else than hardcoded IO ports, but thats what we have now. At least it should be documented. What's the behaviour with a qemu that doesn't support the new port? We don't strictly support it, but let's do so if we can. All slots will be marked as hotpluggable (since the removability IO port will not be registered and return all 1's). Good, so compatibility is retained. seabios will know not to allocate this address to pci bars? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
[Qemu-devel] [PATCH v2] sparc32: ledma extra registers need tracing too
Also trace the extra registers, and update the comments with new
info from Artyom Tarasenko.
Signed-off-by: Bob Breuer breu...@mc.net
---
Since the extra registers are aliased, we could instead alias them at
a higher level. Solaris9 boots to single-user with either option.
diff --git a/hw/sparc32_dma.c b/hw/sparc32_dma.c
index 56be8c8..e75694b 100644
--- a/hw/sparc32_dma.c
+++ b/hw/sparc32_dma.c
@@ -44,7 +44,7 @@
/* We need the mask, because one instance of the device is not page
aligned (ledma, start address 0x0010) */
#define DMA_MASK (DMA_SIZE - 1)
-/* ledma has more than 4 registers, Solaris reads the 5th one */
+/* OBP says 0x20 bytes for ledma, the extras are aliased to espdma */
#define DMA_ETH_SIZE (8 * sizeof(uint32_t))
#define DMA_MAX_REG_OFFSET (2 * DMA_SIZE - 1)
@@ -170,7 +170,10 @@ static uint32_t dma_mem_readl(void *opaque,
target_phys_addr_t addr)
uint32_t saddr;
if (s-is_ledma (addr DMA_MAX_REG_OFFSET)) {
-return 0; /* extra mystery register(s) */
+/* aliased to espdma, but we can't get there from here */
+/* buggy driver if using undocumented behavior, just return 0 */
+trace_sparc32_dma_mem_readl(addr, 0);
+return 0;
}
saddr = (addr DMA_MASK) 2;
trace_sparc32_dma_mem_readl(addr, s-dmaregs[saddr]);
@@ -183,7 +186,9 @@ static void dma_mem_writel(void *opaque, target_phys_addr_t
addr, uint32_t val)
uint32_t saddr;
if (s-is_ledma (addr DMA_MAX_REG_OFFSET)) {
-return; /* extra mystery register(s) */
+/* aliased to espdma, but we can't get there from here */
+trace_sparc32_dma_mem_writel(addr, 0, val);
+return;
}
saddr = (addr DMA_MASK) 2;
trace_sparc32_dma_mem_writel(addr, s-dmaregs[saddr], val);
[Qemu-devel] document QEMU-ACPIBIOS PCI hotplug interface
Document how QEMU communicates with ACPI BIOS for PCI hotplug. Signed-off-by: Marcelo Tosatti mtosa...@redhat.com --- /dev/null 2010-12-14 09:23:48.414180082 -0200 +++ qemu/docs/specs/acpi_pci_hotplug.txt2010-12-20 15:00:26.0 -0200 @@ -0,0 +1,39 @@ +QEMU-ACPI BIOS PCI hotplug interface +-- + +QEMU supports PCI hotplug via ACPI, for PCI bus 0. This document +describes the interface between QEMU and the ACPI BIOS. + +ACPI GPE block (IO ports 0xafe00-0xafe04): +- + +Generic ACPI GPE block. Bit 1 (GPE.1) used to notify PCI hotplug/eject +event to ACPI BIOS, via SCI interrupt. + +PCI slot injection notification pending (IO port 0xae00-0xae03): +--- +Slot injection notification pending. One bit per slot. + +Read by ACPI BIOS GPE.1 handler to notify OS of injection +events. + +PCI slot removal notification (IO port 0xae04-0xae07): +- +Slot removal notification pending. One bit per slot. + +Read by ACPI BIOS GPE.1 handler to notify OS of removal +events. + +PCI device eject (IO port 0xae08-0xae0b): + + +Used by ACPI BIOS _EJ0 method to request device removal. One bit per slot. +Reads return 0. + +PCI removability status (IO port 0xae0c-0xae0f): +--- + +Used by ACPI BIOS _RMV method to indicate removability status to OS. One +bit per slot. + +
[Qemu-devel] Re: [SeaBIOS] seabios: acpi: add _RMV control method for PCI devices
On Mon, Dec 20, 2010 at 11:15:40AM +0200, Avi Kivity wrote: On 12/20/2010 10:49 AM, Marcelo Tosatti wrote: On Sun, Dec 12, 2010 at 02:57:45PM -0500, Kevin O'Connor wrote: On Sun, Dec 12, 2010 at 09:49:16PM +0200, Gleb Natapov wrote: On Sun, Dec 12, 2010 at 02:11:29PM -0500, Kevin O'Connor wrote: On Wed, Dec 08, 2010 at 03:08:59PM -0200, Marcelo Tosatti wrote: Use _RMV method to indicate whether device can be removed. Data is retrieved from QEMU via I/O port 0xae0c. Signed-off-by: Marcelo Tosattimtosa...@redhat.com Thanks Marcelo, Can you add acked-bys from the qemu/kvm maintaners? Marcelo is kvm maintainer ;) FWIW I tested this with Windows 7 XP and it works as expected. The patch relies on patch not yes excepted to qemu though. Yeah - I know - but I figured I'd ask for concensus before committing. :-) The committing of seabios patches that have a dependency on qemu/kvm is an area that I think could be better clarified. I'm thinking that if the seabios part depends on something in qemu/kvm then we should have the corresponding kvm/qemu maintaners ack it. -Kevin Avi, are you OK with this patch ? Yes, perhaps it all (including PCI hotplug controller) should be using something else than hardcoded IO ports, but thats what we have now. At least it should be documented. What's the behaviour with a qemu that doesn't support the new port? We don't strictly support it, but let's do so if we can. All slots will be marked as hotpluggable (since the removability IO port will not be registered and return all 1's).
Re: [Qemu-devel] [PATCH 1/3] nmi: convert cpu_index to cpu-index
Lai Jiangshan la...@cn.fujitsu.com writes:
cpu-index is better name.
Signed-off-by: Lai Jiangshan la...@cn.fujitsu.com
---
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 4befbe2..8de7aa3 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -721,7 +721,7 @@ ETEXI
#if defined(TARGET_I386)
{
.name = nmi,
-.args_type = cpu_index:i,
+.args_type = cpu-index:i,
.params = cpu,
.help = inject an NMI on the given CPU,
.mhandler.cmd = do_inject_nmi,
diff --git a/monitor.c b/monitor.c
index 5d74fe3..c16b39d 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2410,7 +2410,7 @@ static void do_wav_capture(Monitor *mon, const QDict
*qdict)
static void do_inject_nmi(Monitor *mon, const QDict *qdict)
{
CPUState *env;
-int cpu_index = qdict_get_int(qdict, cpu_index);
+int cpu_index = qdict_get_int(qdict, cpu-index);
for (env = first_cpu; env != NULL; env = env-next_cpu)
if (env-cpu_index == cpu_index) {
Fine with me, but it would be nice if we could make up our mind once and
for all whether to use dash or underscore in monitor commands and
arguments.
Re: [Qemu-devel] Re: [PATCH] sparc32: ledma extra registers
Artyom Tarasenko wrote:
On Sun, Dec 19, 2010 at 8:37 PM, Bob Breuer breu...@mc.net wrote:
Andreas Färber wrote:
Am 18.12.2010 um 19:53 schrieb Blue Swirl:
On Sat, Dec 18, 2010 at 5:09 PM, Bob Breuer breu...@mc.net wrote:
ledma has 0x20 bytes of registers according to OBP, and at least
Solaris9
reads the 5th register which is beyond what we've mapped. So let's
setup
a flag (inspired by a previous patch from Blue Swirl) to identify ledma
from espdma, and map another 16 bytes of registers which return 0.
Signed-off-by: Bob Breuer breu...@mc.net
I'm not familar with that part of code but...
diff --git a/hw/sparc32_dma.c b/hw/sparc32_dma.c
index e78f025..56be8c8 100644
--- a/hw/sparc32_dma.c
+++ b/hw/sparc32_dma.c
@@ -165,6 +169,9 @@ static uint32_t dma_mem_readl(void *opaque,
target_phys_addr_t addr)
DMAState *s = opaque;
uint32_t saddr;
+if (s-is_ledma (addr DMA_MAX_REG_OFFSET)) {
+return 0; /* extra mystery register(s) */
Wouldn't it be a good idea to trace these mystery reads...
+}
saddr = (addr DMA_MASK) 2;
trace_sparc32_dma_mem_readl(addr, s-dmaregs[saddr]);
return s-dmaregs[saddr];
@@ -175,6 +182,9 @@ static void dma_mem_writel(void *opaque,
target_phys_addr_t addr, uint32_t val)
DMAState *s = opaque;
uint32_t saddr;
+if (s-is_ledma (addr DMA_MAX_REG_OFFSET)) {
+return; /* extra mystery register(s) */
...and writes? We return just before the tracepoints fire.
Ok, I'll put together a patch to add the trace calls just before the
returns. How about I also call it undocumented instead of mystery.
None of the BSD's or Linux know about or use anything beyond the 4
registers.
I'd use aliased instead of mystery. On a real SS-5:
ok 78400020 20 spacel@ .
a4240050
ok 7840 20 spacel@ .
a4240050
ok 78400024 20 spacel@ .
fc004000
ok 7844 20 spacel@ .
fc004000
Verified that it also aliases on an SS-20.
Addresses 0x7840002x are aliases for 0x784x. As well as
0x7840004x. And so on up to
ok 787fffe4 20 spacel@ .
fc004000
7884 20 spacel@ .
0
Or a real SS-20 ef040 is aliased up to ef37fffe0
Fwiw I think it's a bug in the later Solaris versions:
http://tyom.blogspot.com/2010/10/bug-in-all-solaris-versions-after-57.html
On the bare metal it works because of address aliasing. If you want to
emulate the hw precisely, the Blue's generic aliasing patch can be
used here. The question is though do we want to do a generic aliasing
for all the SBUS devices, or just in the single case(es) where we know
is necessary.
On the other hand Solaris seems to be fine with a 0 stub too.
I'll send a patch to update the comments. If it's accessing a wrong
register because of a bug, then it may not matter what value is returned.
Bob
[Qemu-devel] Re: [SeaBIOS] seabios: acpi: add _RMV control method for PCI devices
On Mon, Dec 20, 2010 at 07:44:12PM +0200, Avi Kivity wrote: On 12/20/2010 07:05 PM, Marcelo Tosatti wrote: Yes, perhaps it all (including PCI hotplug controller) should be using something else than hardcoded IO ports, but thats what we have now. At least it should be documented. What's the behaviour with a qemu that doesn't support the new port? We don't strictly support it, but let's do so if we can. All slots will be marked as hotpluggable (since the removability IO port will not be registered and return all 1's). Good, so compatibility is retained. seabios will know not to allocate this address to pci bars? seabios starts allocating at 0xc000, which is past the hardcoded addresses. In any case, qemu will abort on registration if there are conflicts.
[Qemu-devel] Re: [PATCH 2/2] serial: Declare as little endian
On Sun, Dec 19, 2010 at 3:25 PM, Alexander Graf ag...@suse.de wrote:
On 19.12.2010, at 11:46, Blue Swirl wrote:
This patch replaces explicit bswaps with endianness hints to the
mmio layer.
CC: Alexander Graf ag...@suse.de
Signed-off-by: Blue Swirl blauwir...@gmail.com
---
hw/serial.c | 86 --
1 files changed, 18 insertions(+), 68 deletions(-)
diff --git a/hw/serial.c b/hw/serial.c
index 2c4af61..70ae26a 100644
--- a/hw/serial.c
+++ b/hw/serial.c
@@ -839,53 +839,24 @@ static void serial_mm_writeb(void *opaque,
target_phys_addr_t addr,
serial_ioport_write(s, addr s-it_shift, value 0xFF);
}
-static uint32_t serial_mm_readw_be(void *opaque, target_phys_addr_t addr)
+static uint32_t serial_mm_readw(void *opaque, target_phys_addr_t addr)
{
SerialState *s = opaque;
uint32_t val;
val = serial_ioport_read(s, addr s-it_shift) 0x;
- val = bswap16(val);
return val;
}
-static uint32_t serial_mm_readw_le(void *opaque, target_phys_addr_t addr)
-{
- SerialState *s = opaque;
- uint32_t val;
-
- val = serial_ioport_read(s, addr s-it_shift) 0x;
- return val;
-}
-
-static void serial_mm_writew_be(void *opaque, target_phys_addr_t addr,
- uint32_t value)
-{
- SerialState *s = opaque;
-
- value = bswap16(value);
- serial_ioport_write(s, addr s-it_shift, value 0x);
-}
-
-static void serial_mm_writew_le(void *opaque, target_phys_addr_t addr,
- uint32_t value)
+static void serial_mm_writew(void *opaque, target_phys_addr_t addr,
+ uint32_t value)
{
SerialState *s = opaque;
serial_ioport_write(s, addr s-it_shift, value 0x);
}
-static uint32_t serial_mm_readl_be(void *opaque, target_phys_addr_t addr)
-{
- SerialState *s = opaque;
- uint32_t val;
-
- val = serial_ioport_read(s, addr s-it_shift);
- val = bswap32(val);
- return val;
-}
-
-static uint32_t serial_mm_readl_le(void *opaque, target_phys_addr_t addr)
+static uint32_t serial_mm_readl(void *opaque, target_phys_addr_t addr)
{
SerialState *s = opaque;
uint32_t val;
@@ -894,45 +865,24 @@ static uint32_t serial_mm_readl_le(void *opaque,
target_phys_addr_t addr)
return val;
}
-static void serial_mm_writel_be(void *opaque, target_phys_addr_t addr,
- uint32_t value)
-{
- SerialState *s = opaque;
-
- value = bswap32(value);
- serial_ioport_write(s, addr s-it_shift, value);
-}
-
-static void serial_mm_writel_le(void *opaque, target_phys_addr_t addr,
- uint32_t value)
+static void serial_mm_writel(void *opaque, target_phys_addr_t addr,
+ uint32_t value)
{
SerialState *s = opaque;
serial_ioport_write(s, addr s-it_shift, value);
}
-static CPUReadMemoryFunc * const serial_mm_read_be[] = {
- serial_mm_readb,
- serial_mm_readw_be,
- serial_mm_readl_be,
-};
-
-static CPUWriteMemoryFunc * const serial_mm_write_be[] = {
- serial_mm_writeb,
- serial_mm_writew_be,
- serial_mm_writel_be,
-};
-
-static CPUReadMemoryFunc * const serial_mm_read_le[] = {
+static CPUReadMemoryFunc * const serial_mm_read[] = {
serial_mm_readb,
- serial_mm_readw_le,
- serial_mm_readl_le,
+ serial_mm_readw,
+ serial_mm_readl,
};
-static CPUWriteMemoryFunc * const serial_mm_write_le[] = {
+static CPUWriteMemoryFunc * const serial_mm_write[] = {
serial_mm_writeb,
- serial_mm_writew_le,
- serial_mm_writel_le,
+ serial_mm_writew,
+ serial_mm_writel,
};
SerialState *serial_mm_init (target_phys_addr_t base, int it_shift,
@@ -955,13 +905,13 @@ SerialState *serial_mm_init (target_phys_addr_t
base, int it_shift,
if (ioregister) {
if (be) {
- s_io_memory = cpu_register_io_memory(serial_mm_read_be,
- serial_mm_write_be, s,
- DEVICE_NATIVE_ENDIAN);
+ s_io_memory = cpu_register_io_memory(serial_mm_read,
+ serial_mm_write, s,
+ DEVICE_BIG_ENDIAN);
Have you verified that this works as intended? Usually the be flags in init
code are bogus and define the guest endianness.
At least the serial console on Sparc64 still works.
Re: [Qemu-devel] libqemu.a not made with version 0.13
On Sun, Dec 19, 2010 at 7:53 PM, Stefano Bonifazi stefboombas...@gmail.com wrote: On 12/19/2010 05:51 PM, Andreas Färber wrote: Am 19.12.2010 um 17:32 schrieb Stefano Bonifazi: I need to create an application that execute a PPC binary on a i386 host with some input, and get the result from that binary.. I thought I could use libqemu in some user mode way (i do not need the full system emulation) .. I can't simply call qemu-ppc, as I need everything to be in the same process .. Why? Can't you just pass the input via command line? Regards, Andreas No I can't! First of all it is a specification of my project .. this application would be a SystemC TLM2 loosely timed module so it should be as fast as possible, it can't rely on process intercommunication all should be part of the same SystemC process.. moreover the inputs to be passed to the binary may be complex structs .. I'll need full access to the binaries address space for passing them someway the inputs .. Are you aware of QEMU-SystemC: http://www.greensocs.com/projects/QEMUSystemC Perhaps that would be a better starting point than plain QEMU.
Re: [Qemu-devel] [PATCH 5/6] [RFC] Emulation of Leon3.
On Mon, Dec 20, 2010 at 9:25 AM, Fabien Chouteau chout...@adacore.com wrote:
On 12/17/2010 08:14 PM, Blue Swirl wrote:
On Wed, Dec 15, 2010 at 5:47 PM, Fabien Chouteauchout...@adacore.com
wrote:
On 12/13/2010 07:18 PM, Blue Swirl wrote:
On Mon, Dec 13, 2010 at 3:51 PM, Fabien Chouteauchout...@adacore.com
wrote:
On 12/11/2010 10:56 AM, Blue Swirl wrote:
On Tue, Dec 7, 2010 at 11:40 AM, Fabien Chouteauchout...@adacore.com
wrote:
On 12/06/2010 06:53 PM, Blue Swirl wrote:
On Mon, Dec 6, 2010 at 9:26 AM, Fabien
Chouteauchout...@adacore.com
wrote:
+#if !defined(CONFIG_USER_ONLY)
+ /* Leon3 shutdown */
+ if (intno == 0x80 env-version == 0xf300) {
+ leon3_shutdown();
+ }
This looks like a hack. Should a trap instruction initiate a
shutdown?
Yes, on Leon3 ta 0x0 initiates a shutdown.
Then this should be handled during translation. A Leon3 specific CPU
feature should be added and used much like CHECK_IU_FEATURE (in
translate.c). Then execution speed would not be affected for non-Leon3
CPUs.
OK, but I don't see how to request a shutdown during translation.
Just create a helper which calls shutdown, translator should insert a
call to that.
I think I understand what you mean, but I don't see why this would be
faster
than my solution.
Shutdown is not performance critical, but interrupt handling is.
I understand that, but why is it faster to do it during translation?
I don't see how one if statement in do_interrupt will even slightly
impact
the performances, and why it will be slower than the same if' statement in
the translation.
Because the whole point of translation is that the translated block
will be executed many times but the translation only once. Therefore
computing should be performed during translation instead of TB
execution time, if possible.
Re: [Qemu-devel] [PATCH v2 2/6] qdev: reset qdev along with qdev tree
Am 20.12.2010 13:58, schrieb Markus Armbruster: Anthony Liguori aligu...@linux.vnet.ibm.com writes: On 12/17/2010 08:45 AM, Peter Maydell wrote: On 17 December 2010 00:24, Anthony Liguorialigu...@linux.vnet.ibm.com wrote: On 12/16/2010 05:48 PM, Michael S. Tsirkin wrote: Ugh, I keep forgetting about the non-qdev systems. Maybe it's a good way to finally make everyone to convert? If a system maintainer can't be bothered to convert to qdev we can declare the system unsupported :) Honestly, I think that's a fair thing to do. I'm guessing that would be a transition/conversion to make for the 0.15 release, right? Yes. Let's do it. I already tried to convert malta / gt64xxx to qdev. While simple devices are easily converted, I'm still struggling with gt64xxx. There is some qdev documentation for end users (command line parameters), but is there qdev documentation for developers, too? If not, adding a qdev chapter to qemu-tech.texi (preferred), writing a qdev wiki page, code templates (for systems / buses / bus controllers / bus devices) or some other form of documentation would be a good start for release 0.15 (imho). Regards Stefan
Re: [Qemu-devel] [PATCH 5/6] [RFC] Emulation of Leon3.
On Mon, Dec 20, 2010 at 9:40 AM, Fabien Chouteau chout...@adacore.com wrote:
On 12/20/2010 07:46 AM, Edgar E. Iglesias wrote:
On Fri, Dec 17, 2010 at 07:14:20PM +, Blue Swirl wrote:
On Wed, Dec 15, 2010 at 5:47 PM, Fabien Chouteauchout...@adacore.com
wrote:
On 12/13/2010 07:18 PM, Blue Swirl wrote:
On Mon, Dec 13, 2010 at 3:51 PM, Fabien Chouteauchout...@adacore.com
wrote:
On 12/11/2010 10:56 AM, Blue Swirl wrote:
On Tue, Dec 7, 2010 at 11:40 AM, Fabien
Chouteauchout...@adacore.com
wrote:
On 12/06/2010 06:53 PM, Blue Swirl wrote:
On Mon, Dec 6, 2010 at 9:26 AM, Fabien
Chouteauchout...@adacore.com
wrote:
Signed-off-by: Fabien Chouteauchout...@adacore.com
---
...
#ifdef DEBUG_PCALL
if (qemu_loglevel_mask(CPU_LOG_INT)) {
static int count;
@@ -4135,6 +4153,14 @@ void do_interrupt(CPUState *env)
env-pc = env-tbr;
env-npc = env-pc + 4;
env-exception_index = -1;
+
+#if !defined(CONFIG_USER_ONLY)
+ /* IRQ acknowledgment for Leon3 */
+ if (env-version == 0xf300 (intno ~15)
==
TT_EXTINT)
{
+ grlib_irqmp_ack (env, intno);
+ leon3_cache_control_int();
+ }
Like this. I don't think a CPU should immediately ack any incoming
interrupts.
Leon3 does...
Strange. Then this should be handled at board level (leon3.c).
Well, it's a CPU feature not a board feature.
Maybe, but we don't want to clutter interrupt handling with this.
I don't see what you expect here... How can I get the acknowledgment
information without changing the do_interrupt function?
Board can acknowledge the interrupt just before calling cpu_interrupt().
Hi,
I don't think that will work properly. IIUC, the leon acks the irq when it
is actually taken by the CPU. Due to CPU internal masking, that may be at
a later point than when the irq is signalled to the CPU.
Exactly I've forget to mention that. Raising the interrupt do not mean that
the
CPU will handle it directly, for example if traps are disabled or if the CPU
handles an higher priority interrupt at the moment.
I think there is no way to avoid the performance penalty then.
IMO, what is needed is something along the lines of what Fabien coded but
with some level of indirection so that the CPU doesn't call directly into
the irqmp model. Maybe through ack function pointers or through a
qemu_irq ack line or some other way. The board should then setup the
connection between the ack mechanism and the irqmp model.
The function pointer is a good idea, something like:
if (env-qemu_irq_ack != NULL) {
env-qemu_irq_ack(intno);
}
And actually this will help me to implement others machines (erc32 and
leon2).
OK. Alternatively there could be a stub function which is used in
place of NULL, so that the if () can be avoided, but maybe this is
better.
If direct interrupt acks would be interesting also for x86 LAPIC, then
a more generic solution could be to introduce a new
env-interrupt_request flag, CPU_INTERRUPT_ACK, which could be tested
in common code of cpu-exec.c.
Re: [Qemu-devel] document QEMU-ACPIBIOS PCI hotplug interface
On Mon, Dec 20, 2010 at 5:09 PM, Marcelo Tosatti mtosa...@redhat.com wrote: Document how QEMU communicates with ACPI BIOS for PCI hotplug. Signed-off-by: Marcelo Tosatti mtosa...@redhat.com --- /dev/null 2010-12-14 09:23:48.414180082 -0200 +++ qemu/docs/specs/acpi_pci_hotplug.txt 2010-12-20 15:00:26.0 -0200 @@ -0,0 +1,39 @@ +QEMU-ACPI BIOS PCI hotplug interface +-- + +QEMU supports PCI hotplug via ACPI, for PCI bus 0. This document +describes the interface between QEMU and the ACPI BIOS. + +ACPI GPE block (IO ports 0xafe00-0xafe04): 0xae00-0xae0f?
Re: [Qemu-devel] [PATCH] libiscsi
Thanks.
I have implemented all of your suggestions and will submit version 2
of the patch shortly.
regards
ronnie sahlberg
On Tue, Dec 14, 2010 at 7:47 AM, Blue Swirl blauwir...@gmail.com wrote:
On Mon, Dec 13, 2010 at 8:05 AM, Ronnie Sahlberg
ronniesahlb...@gmail.com wrote:
This patch adds a new block driver : block.iscsi.c
This driver interfaces with the multiplatform posix library
for iscsi initiator/client access to iscsi devices hosted at
git://github.com/sahlberg/libiscsi.git
The patch adds the driver to interface with the iscsi library.
It also updated the configure script to
* by default, probe is libiscsi is available and if so, build
qemu against libiscsi.
* --enable-libiscsi
Force a build against libiscsi. If libiscsi is not available
the build will fail.
* --disable-libiscsi
Do not link against libiscsi, even if it is available.
When linked with libiscsi, qemu gains support to access iscsi resources
such as disks and cdrom directly, without having to make the devices visible
to the host.
You can specify devices using a iscsi url of the form :
iscsi://host[:port]/target-iqn-name/lun
Example:
-drive file=iscsi://10.1.1.1:3260/iqn.ronnie.test/1
-cdrom iscsi://10.1.1.1:3260/iqn.ronnie.test/2
Signed-off-by: Ronnie Sahlberg ronniesahlb...@gmail.com
---
Makefile.objs | 2 +-
block/iscsi.c | 528
+
configure | 29 +++
3 files changed, 558 insertions(+), 1 deletions(-)
create mode 100644 block/iscsi.c
diff --git a/Makefile.objs b/Makefile.objs
index cebb945..81731c5 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -22,7 +22,7 @@ block-nested-y += raw.o cow.o qcow.o vdi.o vmdk.o cloop.o
dmg.o bochs.o vpc.o vv
block-nested-y += qcow2.o qcow2-refcount.o qcow2-cluster.o qcow2-snapshot.o
block-nested-y += parallels.o nbd.o blkdebug.o sheepdog.o blkverify.o
block-nested-$(CONFIG_WIN32) += raw-win32.o
-block-nested-$(CONFIG_POSIX) += raw-posix.o
+block-nested-$(CONFIG_POSIX) += raw-posix.o iscsi.o
Please use CONFIG_ISCSI...
block-nested-$(CONFIG_CURL) += curl.o
block-obj-y += $(addprefix block/, $(block-nested-y))
diff --git a/block/iscsi.c b/block/iscsi.c
new file mode 100644
index 000..fba5ee6
--- /dev/null
+++ b/block/iscsi.c
@@ -0,0 +1,528 @@
+/*
+ * QEMU Block driver for iSCSI images
+ *
+ * Copyright (c) 2010 Ronnie Sahlberg ronniesahlb...@gmail.com
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the
rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included
in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include config-host.h
+#ifdef CONFIG_LIBISCSI
... then this is not needed.
+
+#include poll.h
+#include sysemu.h
+#include qemu-common.h
+#include qemu-error.h
+#include block_int.h
+
+#include iscsi/iscsi.h
+#include iscsi/scsi-lowlevel.h
+
+
+typedef struct ISCSILUN {
+ struct iscsi_context *iscsi;
+ int lun;
+ int block_size;
+ unsigned long num_blocks;
+} ISCSILUN;
+
+typedef struct ISCSIAIOCB {
+ BlockDriverAIOCB common;
+ QEMUIOVector *qiov;
+ QEMUBH *bh;
+ ISCSILUN *iscsilun;
+ int canceled;
+ int status;
+ size_t read_size;
+} ISCSIAIOCB;
+
+struct iscsi_task {
+ ISCSILUN *iscsilun;
+ int status;
+ int complete;
+};
Please see CODING_STYLE for struct naming and use of typedefs.
+
+static int
+iscsi_is_inserted(BlockDriverState *bs)
+{
+ ISCSILUN *iscsilun = bs-opaque;
+ struct iscsi_context *iscsi = iscsilun-iscsi;
+
+ return iscsi_is_logged_in(iscsi);
+}
+
+
+static void
+iscsi_aio_cancel(BlockDriverAIOCB *blockacb)
+{
+ ISCSIAIOCB *acb = (ISCSIAIOCB *)blockacb;
+
+ acb-status = -EIO;
+ acb-common.cb(acb-common.opaque, acb-status);
+ acb-canceled = 1;
+}
+
+static AIOPool iscsi_aio_pool = {
+ .aiocb_size = sizeof(ISCSIAIOCB),
+ .cancel = iscsi_aio_cancel,
+};
+
+
+static void iscsi_process_read(void *arg);
+static void
Re: [Qemu-devel] Patches for OpenBSD support.
On Sun, Dec 19, 2010 at 8:59 PM, Brad b...@comstyle.com wrote: Here are a few patches for OpenBSD support. Thanks. Could you resend each patch separately and add Signed-off-by: Brad Smith b...@comstyle.com line before '---' line?
Re: [Qemu-devel] [PATCH v2 2/6] qdev: reset qdev along with qdev tree
Stefan Weil w...@mail.berlios.de writes: Am 20.12.2010 13:58, schrieb Markus Armbruster: Anthony Liguori aligu...@linux.vnet.ibm.com writes: On 12/17/2010 08:45 AM, Peter Maydell wrote: On 17 December 2010 00:24, Anthony Liguorialigu...@linux.vnet.ibm.com wrote: On 12/16/2010 05:48 PM, Michael S. Tsirkin wrote: Ugh, I keep forgetting about the non-qdev systems. Maybe it's a good way to finally make everyone to convert? If a system maintainer can't be bothered to convert to qdev we can declare the system unsupported :) Honestly, I think that's a fair thing to do. I'm guessing that would be a transition/conversion to make for the 0.15 release, right? Yes. Let's do it. I already tried to convert malta / gt64xxx to qdev. While simple devices are easily converted, I'm still struggling with gt64xxx. Specific problems? There is some qdev documentation for end users (command line parameters), but is there qdev documentation for developers, too? If not, adding a qdev chapter to qemu-tech.texi (preferred), writing a qdev wiki page, code templates (for systems / buses / bus controllers / bus devices) or some other form of documentation would be a good start for release 0.15 (imho). It's not what you ask for, but perhaps it helps a bit anyway: http://www.linux-kvm.org/wiki/images/f/fe/2010-forum-armbru-qdev.pdf
[Qemu-devel] Re: [PULL 0/3] Prepare removal of SoftFloat integer types
Thanks, applied all. On Sun, Dec 19, 2010 at 4:22 PM, Andreas Färber andreas.faer...@web.de wrote: Hello, The following patches are split off from the softfloat series and updated as requested. The following changes since commit 4fd37a98d1248bae54a9f71ee1c252d2b2f1efd5: Avoid a warning from OpenBSD linker (2010-12-19 14:05:43 +) are available in the git repository at: git://repo.or.cz/qemu/afaerber.git softfloat-for-blue Andreas Färber (3): apic: Fix accidental use of SoftFloat uint32 type wdt_ib700: Fix accidental use of SoftFloat int64 type target-i386: Fix accidental use of SoftFloat uint64 type hw/apic.c | 2 +- hw/wdt_ib700.c | 2 +- target-i386/cpu.h | 8 3 files changed, 6 insertions(+), 6 deletions(-) -- 1.7.3.4
[Qemu-devel] [PATCH 8/8] ahci: fix !msi interrupts
When not using MSI, receiving an interrupt while the interrupt line is active
pulses the interrupt line. Without this, guests don't realize that a new
interrupt occured.
Signed-off-by: Alexander Graf ag...@suse.de
---
hw/ide/ahci.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
index 97aef68..4c920da 100644
--- a/hw/ide/ahci.c
+++ b/hw/ide/ahci.c
@@ -153,11 +153,10 @@ static void ahci_check_irq(AHCIState *s)
}
}
+ahci_irq_lower(s, NULL);
if (s-control_regs.irqstatus
(s-control_regs.ghc HOST_CTL_IRQ_EN)) {
ahci_irq_raise(s, NULL);
-} else {
-ahci_irq_lower(s, NULL);
}
}
--
1.6.0.2
[Qemu-devel] [PATCH 0/8] Some more AHCI work
Clearly, AHCI as is is not perfect yet (intentionally, release early, release often, remember?). This patch set makes it work with SeaBIOS so booting Windows 7 works flawlessly for me. it also adds some speedups and fixes a level based interrupts, rendering ahci useful on PPC targets. In preparation of potential non-ich9 implementations, this set also splits ahci code from concrete ich9 specific code. That way we can later on create other AHCI adapters while reusing a lot of code. Git tree (including BIOS patch to enable booting from AHCI): git://repo.or.cz/qemu/ahci.git ahci Alexander Graf (7): ahci: split ICH and AHCI even more ahci: send init d2h fis on fis enable ahci: use qiov instead of dma helpers ahci: Implement HBA reset ahci: make number of ports runtime determined ahci: free dynamically allocated iovs ahci: fix !msi interrupts Sebastian Herbszt (1): ahci: split ICH9 from core Makefile.objs |1 + hw/ide/ahci.c | 594 +++-- hw/ide/ahci.h | 313 ++ hw/ide/ich.c | 148 ++ 4 files changed, 618 insertions(+), 438 deletions(-) create mode 100644 hw/ide/ahci.h create mode 100644 hw/ide/ich.c
[Qemu-devel] [PATCH 3/8] ahci: send init d2h fis on fis enable
The drive sends a d2h init fis on initialization. Usually, the guest doesn't
receive fises yet at that point though, so the delivery is deferred.
Let's reflect that by sending the init fis on fis receive enablement.
Signed-off-by: Alexander Graf ag...@suse.de
---
hw/ide/ahci.c | 34 +++---
hw/ide/ahci.h |1 +
2 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
index 18187c8..fa97f9b 100644
--- a/hw/ide/ahci.c
+++ b/hw/ide/ahci.c
@@ -48,6 +48,7 @@ static void check_cmd(AHCIState *s, int port);
static int handle_cmd(AHCIState *s,int port,int slot);
static void ahci_reset_port(AHCIState *s, int port);
static void ahci_write_fis_d2h(AHCIDevice *ad, uint8_t *cmd_fis);
+static void ahci_init_d2h(AHCIDevice *ad);
static uint32_t ahci_port_read(AHCIState *s, int port, int offset)
{
@@ -231,6 +232,12 @@ static void ahci_port_write(AHCIState *s, int port, int
offset, uint32_t val)
pr-cmd |= PORT_CMD_FIS_ON;
}
+if ((pr-cmd PORT_CMD_FIS_ON)
+!s-dev[port].init_d2h_sent) {
+ahci_init_d2h(s-dev[port]);
+s-dev[port].init_d2h_sent = 1;
+}
+
check_cmd(s, port);
break;
case PORT_TFDATA:
@@ -463,12 +470,29 @@ static void ahci_check_cmd_bh(void *opaque)
check_cmd(ad-hba, ad-port_no);
}
+static void ahci_init_d2h(AHCIDevice *ad)
+{
+uint8_t init_fis[0x20];
+IDEState *ide_state = ad-port.ifs[0];
+
+memset(init_fis, 0, sizeof(init_fis));
+
+init_fis[4] = 1;
+init_fis[12] = 1;
+
+if (ide_state-drive_kind == IDE_CD) {
+init_fis[5] = ide_state-lcyl;
+init_fis[6] = ide_state-hcyl;
+}
+
+ahci_write_fis_d2h(ad, init_fis);
+}
+
static void ahci_reset_port(AHCIState *s, int port)
{
AHCIDevice *d = s-dev[port];
AHCIPortRegs *pr = d-port_regs;
IDEState *ide_state = d-port.ifs[0];
-uint8_t init_fis[0x20];
int i;
DPRINTF(port, reset port\n);
@@ -483,6 +507,7 @@ static void ahci_reset_port(AHCIState *s, int port)
pr-scr_err = 0;
pr-scr_act = 0;
d-busy_slot = -1;
+d-init_d2h_sent = 0;
ide_state = s-dev[port].port.ifs[0];
if (!ide_state-bs) {
@@ -505,7 +530,6 @@ static void ahci_reset_port(AHCIState *s, int port)
ncq_tfs-used = 0;
}
-memset(init_fis, 0, sizeof(init_fis));
s-dev[port].port_state = STATE_RUN;
if (!ide_state-bs) {
s-dev[port].port_regs.sig = 0;
@@ -515,8 +539,6 @@ static void ahci_reset_port(AHCIState *s, int port)
ide_state-lcyl = 0x14;
ide_state-hcyl = 0xeb;
DPRINTF(port, set lcyl = %d\n, ide_state-lcyl);
-init_fis[5] = ide_state-lcyl;
-init_fis[6] = ide_state-hcyl;
ide_state-status = SEEK_STAT | WRERR_STAT | READY_STAT;
} else {
s-dev[port].port_regs.sig = SATA_SIGNATURE_DISK;
@@ -524,9 +546,7 @@ static void ahci_reset_port(AHCIState *s, int port)
}
ide_state-error = 1;
-init_fis[4] = 1;
-init_fis[12] = 1;
-ahci_write_fis_d2h(d, init_fis);
+ahci_init_d2h(d);
}
static void debug_print_fis(uint8_t *fis, int cmd_len)
diff --git a/hw/ide/ahci.h b/hw/ide/ahci.h
index 63ef785..5f8126a 100644
--- a/hw/ide/ahci.h
+++ b/hw/ide/ahci.h
@@ -259,6 +259,7 @@ struct AHCIDevice {
int dma_status;
int done_atapi_packet;
int busy_slot;
+int init_d2h_sent;
BlockDriverCompletionFunc *dma_cb;
AHCICmdHdr *cur_cmd;
NCQTransferState ncq_tfs[AHCI_MAX_CMDS];
--
1.6.0.2
[Qemu-devel] [PATCH 2/8] ahci: split ICH and AHCI even more
Sebastian's patch already did a pretty good job at splitting up ICH-9
AHCI code and the AHCI core. We need some more though. Copyright was missing,
the lspci dump belongs to ICH-9, we don't need the AHCI core to have its
own qdev device duplicate.
So let's split them a bit more in this patch, making things easier to
read an understand.
Signed-off-by: Alexander Graf ag...@suse.de
---
v1 - v2:
- reflect ich name in init functions
---
hw/ide/ahci.c | 110 -
hw/ide/ich.c | 90 +-
2 files changed, 88 insertions(+), 112 deletions(-)
diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
index 8b6947a..18187c8 100644
--- a/hw/ide/ahci.c
+++ b/hw/ide/ahci.c
@@ -19,47 +19,6 @@
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, see http://www.gnu.org/licenses/.
*
- *
- * lspci dump of a ICH-9 real device in IDE mode (hopefully close enough):
- *
- * 00:1f.2 SATA controller [0106]: Intel Corporation 82801IR/IO/IH
(ICH9R/DO/DH) 6 port SATA AHCI Controller [8086:2922] (rev 02) (prog-if 01
[AHCI 1.0])
- * Subsystem: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port
SATA AHCI Controller [8086:2922]
- * Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
- * Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR- INTx-
- * Latency: 0
- * Interrupt: pin B routed to IRQ 222
- * Region 0: I/O ports at d000 [size=8]
- * Region 1: I/O ports at cc00 [size=4]
- * Region 2: I/O ports at c880 [size=8]
- * Region 3: I/O ports at c800 [size=4]
- * Region 4: I/O ports at c480 [size=32]
- * Region 5: Memory at febf9000 (32-bit, non-prefetchable) [size=2K]
- * Capabilities: [80] Message Signalled Interrupts: Mask- 64bit-
Count=1/16 Enable+
- * Address: fee0f00c Data: 41d9
- * Capabilities: [70] Power Management version 3
- * Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot+,D3cold-)
- * Status: D0 PME-Enable- DSel=0 DScale=0 PME-
- * Capabilities: [a8] SATA HBA ?
- * Capabilities: [b0] Vendor Specific Information ?
- * Kernel driver in use: ahci
- * Kernel modules: ahci
- * 00: 86 80 22 29 07 04 b0 02 02 01 06 01 00 00 00 00
- * 10: 01 d0 00 00 01 cc 00 00 81 c8 00 00 01 c8 00 00
- * 20: 81 c4 00 00 00 90 bf fe 00 00 00 00 86 80 22 29
- * 30: 00 00 00 00 80 00 00 00 00 00 00 00 0f 02 00 00
- * 40: 00 80 00 80 00 00 00 00 00 00 00 00 00 00 00 00
- * 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
- * 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
- * 70: 01 a8 03 40 08 00 00 00 00 00 00 00 00 00 00 00
- * 80: 05 70 09 00 0c f0 e0 fe d9 41 00 00 00 00 00 00
- * 90: 40 00 0f 82 93 01 00 00 00 00 00 00 00 00 00 00
- * a0: ac 00 00 00 0a 00 12 00 12 b0 10 00 48 00 00 00
- * b0: 09 00 06 20 00 00 00 00 00 00 00 00 00 00 00 00
- * c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
- * d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
- * e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
- * f0: 00 00 00 00 00 00 00 00 86 0f 02 00 00 00 00 00
- *
*/
#include hw/hw.h
@@ -1156,72 +1115,3 @@ void ahci_reset(void *opaque)
ahci_reset_port(d-ahci, i);
}
}
-
-static int pci_ahci_init(PCIDevice *dev)
-{
-struct AHCIPCIState *d;
-d = DO_UPCAST(struct AHCIPCIState, card, dev);
-
-pci_config_set_vendor_id(d-card.config, PCI_VENDOR_ID_INTEL);
-pci_config_set_device_id(d-card.config, PCI_DEVICE_ID_INTEL_82801IR);
-
-pci_config_set_class(d-card.config, PCI_CLASS_STORAGE_SATA);
-pci_config_set_revision(d-card.config, 0x02);
-pci_config_set_prog_interface(d-card.config, AHCI_PROGMODE_MAJOR_REV_1);
-
-d-card.config[PCI_CACHE_LINE_SIZE] = 0x08; /* Cache line size */
-d-card.config[PCI_LATENCY_TIMER] = 0x00; /* Latency timer */
-pci_config_set_interrupt_pin(d-card.config, 1);
-
-/* XXX Software should program this register */
-d-card.config[0x90] = 1 6; /* Address Map Register - AHCI mode */
-
-qemu_register_reset(ahci_reset, d);
-
-/* XXX BAR size should be 1k, but that breaks, so bump it to 4k for now */
-pci_register_bar(d-card, 5, 0x1000, PCI_BASE_ADDRESS_SPACE_MEMORY,
- ahci_pci_map);
-
-msi_init(dev, 0x50, 1, true, false);
-
-ahci_init(d-ahci, dev-qdev);
-d-ahci.irq = d-card.irq[0];
-
-return 0;
-}
-
-static int pci_ahci_uninit(PCIDevice *dev)
-{
-struct AHCIPCIState *d;
-d = DO_UPCAST(struct AHCIPCIState, card, dev);
-
-if (msi_enabled(dev)) {
-msi_uninit(dev);
-}
-
-qemu_unregister_reset(ahci_reset, d);
-
-return 0;
-}
-
-static void pci_ahci_write_config(PCIDevice *pci, uint32_t addr,
- uint32_t val,
[Qemu-devel] [PATCH 5/8] ahci: Implement HBA reset
The ahci code was missing its soft reset functionality. This wasn't really an
issue for Linux guests, but Windows gets confused when the controller doesn't
reset when it tells it so.
Using this patch I can now successfully boot Windows 7 from AHCI using AHCI
enabled SeaBIOS.
Signed-off-by: Alexander Graf ag...@suse.de
---
hw/ide/ahci.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
index 7a29925..bd4f8a4 100644
--- a/hw/ide/ahci.c
+++ b/hw/ide/ahci.c
@@ -332,7 +332,7 @@ static void ahci_mem_writel(void *ptr, target_phys_addr_t
addr, uint32_t val)
case HOST_CTL: /* R/W */
if (val HOST_CTL_RESET) {
DPRINTF(-1, HBA Reset\n);
-/* FIXME reset? */
+ahci_reset(container_of(s, AHCIPCIState, ahci));
} else {
s-control_regs.ghc = (val 0x3) | HOST_CTL_AHCI_EN;
ahci_check_irq(s);
@@ -1215,6 +1215,9 @@ void ahci_reset(void *opaque)
struct AHCIPCIState *d = opaque;
int i;
+d-ahci.control_regs.irqstatus = 0;
+d-ahci.control_regs.ghc = 0;
+
for (i = 0; i SATA_PORTS; i++) {
ahci_reset_port(d-ahci, i);
}
--
1.6.0.2
[Qemu-devel] [PATCH 6/8] ahci: make number of ports runtime determined
Different AHCI controllers have a different number of ports, so the core
shouldn't care about the amount of ports available.
This patch makes the number of ports available to the AHCI core runtime
configurable, allowing us to have multiple different AHCI implementations
with different amounts of ports.
Signed-off-by: Alexander Graf ag...@suse.de
---
hw/ide/ahci.c | 29 +++--
hw/ide/ahci.h | 10 +-
hw/ide/ich.c |3 ++-
3 files changed, 26 insertions(+), 16 deletions(-)
diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
index bd4f8a4..c0bc5ff 100644
--- a/hw/ide/ahci.c
+++ b/hw/ide/ahci.c
@@ -146,7 +146,7 @@ static void ahci_check_irq(AHCIState *s)
DPRINTF(-1, check irq %#x\n, s-control_regs.irqstatus);
-for (i = 0; i SATA_PORTS; i++) {
+for (i = 0; i s-ports; i++) {
AHCIPortRegs *pr = s-dev[i].port_regs;
if (pr-irq_stat pr-irq_mask) {
s-control_regs.irqstatus |= (1 i);
@@ -300,7 +300,8 @@ static uint32_t ahci_mem_readl(void *ptr,
target_phys_addr_t addr)
DPRINTF(-1, (addr 0x%08X), val 0x%08X\n, (unsigned) addr, val);
} else if ((addr = AHCI_PORT_REGS_START_ADDR)
- (addr AHCI_PORT_REGS_END_ADDR)) {
+ (addr (AHCI_PORT_REGS_START_ADDR +
+(s-ports * AHCI_PORT_ADDR_OFFSET_LEN {
val = ahci_port_read(s, (addr - AHCI_PORT_REGS_START_ADDR) 7,
addr AHCI_PORT_ADDR_OFFSET_MASK);
}
@@ -352,7 +353,8 @@ static void ahci_mem_writel(void *ptr, target_phys_addr_t
addr, uint32_t val)
DPRINTF(-1, write to unknown register 0x%x\n,
(unsigned)addr);
}
} else if ((addr = AHCI_PORT_REGS_START_ADDR)
- (addr AHCI_PORT_REGS_END_ADDR)) {
+ (addr (AHCI_PORT_REGS_START_ADDR +
+(s-ports * AHCI_PORT_ADDR_OFFSET_LEN {
ahci_port_write(s, (addr - AHCI_PORT_REGS_START_ADDR) 7,
addr AHCI_PORT_ADDR_OFFSET_MASK, val);
}
@@ -375,16 +377,16 @@ static void ahci_reg_init(AHCIState *s)
{
int i;
-s-control_regs.cap = (SATA_PORTS - 1) |
+s-control_regs.cap = (s-ports - 1) |
(AHCI_NUM_COMMAND_SLOTS 8) |
(AHCI_SUPPORTED_SPEED_GEN1 AHCI_SUPPORTED_SPEED) |
HOST_CAP_NCQ | HOST_CAP_AHCI;
-s-control_regs.impl = (1 SATA_PORTS) - 1;
+s-control_regs.impl = (1 s-ports) - 1;
s-control_regs.version = AHCI_VERSION_1_0;
-for (i = 0; i SATA_PORTS; i++) {
+for (i = 0; i s-ports; i++) {
s-dev[i].port_state = STATE_RUN;
}
}
@@ -1177,17 +1179,19 @@ static const IDEDMAOps ahci_dma_ops = {
.reset = ahci_dma_reset,
};
-void ahci_init(AHCIState *s, DeviceState *qdev)
+void ahci_init(AHCIState *s, DeviceState *qdev, int ports)
{
qemu_irq *irqs;
int i;
+s-ports = ports;
+s-dev = qemu_mallocz(sizeof(AHCIDevice) * ports);
ahci_reg_init(s);
s-mem = cpu_register_io_memory(ahci_readfn, ahci_writefn, s,
DEVICE_LITTLE_ENDIAN);
-irqs = qemu_allocate_irqs(ahci_irq_set, s, SATA_PORTS);
+irqs = qemu_allocate_irqs(ahci_irq_set, s, s-ports);
-for (i = 0; i SATA_PORTS; i++) {
+for (i = 0; i s-ports; i++) {
AHCIDevice *ad = s-dev[i];
ide_bus_new(ad-port, qdev, i);
@@ -1201,6 +1205,11 @@ void ahci_init(AHCIState *s, DeviceState *qdev)
}
}
+void ahci_uninit(AHCIState *s)
+{
+qemu_free(s-dev);
+}
+
void ahci_pci_map(PCIDevice *pci_dev, int region_num,
pcibus_t addr, pcibus_t size, int type)
{
@@ -1218,7 +1227,7 @@ void ahci_reset(void *opaque)
d-ahci.control_regs.irqstatus = 0;
d-ahci.control_regs.ghc = 0;
-for (i = 0; i SATA_PORTS; i++) {
+for (i = 0; i d-ahci.ports; i++) {
ahci_reset_port(d-ahci, i);
}
}
diff --git a/hw/ide/ahci.h b/hw/ide/ahci.h
index 0824064..eb87dcd 100644
--- a/hw/ide/ahci.h
+++ b/hw/ide/ahci.h
@@ -165,11 +165,9 @@
#define AHCI_GENERIC_HOST_CONTROL_REGS_MAX_ADDR 0x20
/* Shouldn't this be 0x2c? */
-#define SATA_PORTS 4
-
#define AHCI_PORT_REGS_START_ADDR 0x100
-#define AHCI_PORT_REGS_END_ADDR (AHCI_PORT_REGS_START_ADDR + SATA_PORTS * 0x80)
#define AHCI_PORT_ADDR_OFFSET_MASK 0x7f
+#define AHCI_PORT_ADDR_OFFSET_LEN 0x80
#define AHCI_NUM_COMMAND_SLOTS 31
#define AHCI_SUPPORTED_SPEED 20
@@ -269,9 +267,10 @@ struct AHCIDevice {
};
typedef struct AHCIState {
-AHCIDevice dev[SATA_PORTS];
+AHCIDevice *dev;
AHCIControlRegs control_regs;
int mem;
+int ports;
qemu_irq irq;
} AHCIState;
@@ -303,7 +302,8 @@ typedef struct NCQFrame {
uint8_t reserved10;
} __attribute__ ((packed)) NCQFrame;
-void ahci_init(AHCIState *s, DeviceState *qdev);
+void ahci_init(AHCIState *s, DeviceState
[Qemu-devel] [PATCH 1/8] ahci: split ICH9 from core
From: Sebastian Herbszt herb...@gmx.de
There are multiple ahci devices out there. The currently implemented ich-9
is only one of the many. So let's split that one out into a separate file
to stress the difference.
Signed-off-by: Sebastian Herbszt herb...@gmx.de
Signed-off-by: Alexander Graf ag...@suse.de
---
Makefile.objs |1 +
hw/ide/ahci.c | 305 +---
hw/ide/ahci.h | 309 +
hw/ide/ich.c | 61 +++
4 files changed, 375 insertions(+), 301 deletions(-)
create mode 100644 hw/ide/ahci.h
create mode 100644 hw/ide/ich.c
diff --git a/Makefile.objs b/Makefile.objs
index d6b3d60..d6eb8c8 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -246,6 +246,7 @@ hw-obj-$(CONFIG_IDE_CMD646) += ide/cmd646.o
hw-obj-$(CONFIG_IDE_MACIO) += ide/macio.o
hw-obj-$(CONFIG_IDE_VIA) += ide/via.o
hw-obj-$(CONFIG_AHCI) += ide/ahci.o
+hw-obj-$(CONFIG_AHCI) += ide/ich.o
# SCSI layer
hw-obj-$(CONFIG_LSI_SCSI_PCI) += lsi53c895a.o
diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
index 968fdce..8b6947a 100644
--- a/hw/ide/ahci.c
+++ b/hw/ide/ahci.c
@@ -73,6 +73,7 @@
#include blockdev.h
#include internal.h
#include hw/ide/pci.h
+#include hw/ide/ahci.h
/* #define DEBUG_AHCI */
@@ -84,304 +85,6 @@ do { fprintf(stderr, ahci: %s: [%d] , __FUNCTION__,
port); \
#define DPRINTF(port, fmt, ...) do {} while(0)
#endif
-#define AHCI_PCI_BAR 5
-#define AHCI_MAX_PORTS32
-#define AHCI_MAX_SG 168 /* hardware max is 64K */
-#define AHCI_DMA_BOUNDARY 0x
-#define AHCI_USE_CLUSTERING 0
-#define AHCI_MAX_CMDS 32
-#define AHCI_CMD_SZ 32
-#define AHCI_CMD_SLOT_SZ (AHCI_MAX_CMDS * AHCI_CMD_SZ)
-#define AHCI_RX_FIS_SZ256
-#define AHCI_CMD_TBL_CDB 0x40
-#define AHCI_CMD_TBL_HDR_SZ 0x80
-#define AHCI_CMD_TBL_SZ (AHCI_CMD_TBL_HDR_SZ + (AHCI_MAX_SG * 16))
-#define AHCI_CMD_TBL_AR_SZ(AHCI_CMD_TBL_SZ * AHCI_MAX_CMDS)
-#define AHCI_PORT_PRIV_DMA_SZ (AHCI_CMD_SLOT_SZ + AHCI_CMD_TBL_AR_SZ + \
- AHCI_RX_FIS_SZ)
-
-#define AHCI_IRQ_ON_SG(1 31)
-#define AHCI_CMD_ATAPI(1 5)
-#define AHCI_CMD_WRITE(1 6)
-#define AHCI_CMD_PREFETCH (1 7)
-#define AHCI_CMD_RESET(1 8)
-#define AHCI_CMD_CLR_BUSY (1 10)
-
-#define RX_FIS_D2H_REG0x40 /* offset of D2H Register FIS data */
-#define RX_FIS_SDB0x58 /* offset of SDB FIS data */
-#define RX_FIS_UNK0x60 /* offset of Unknown FIS data */
-
-/* global controller registers */
-#define HOST_CAP 0x00 /* host capabilities */
-#define HOST_CTL 0x04 /* global host control */
-#define HOST_IRQ_STAT 0x08 /* interrupt status */
-#define HOST_PORTS_IMPL 0x0c /* bitmap of implemented ports */
-#define HOST_VERSION 0x10 /* AHCI spec. version compliancy */
-
-/* HOST_CTL bits */
-#define HOST_CTL_RESET(1 0) /* reset controller; self-clear */
-#define HOST_CTL_IRQ_EN (1 1) /* global IRQ enable */
-#define HOST_CTL_AHCI_EN (1 31) /* AHCI enabled */
-
-/* HOST_CAP bits */
-#define HOST_CAP_SSC (1 14) /* Slumber capable */
-#define HOST_CAP_AHCI (1 18) /* AHCI only */
-#define HOST_CAP_CLO (1 24) /* Command List Override support */
-#define HOST_CAP_SSS (1 27) /* Staggered Spin-up */
-#define HOST_CAP_NCQ (1 30) /* Native Command Queueing */
-#define HOST_CAP_64 (1 31) /* PCI DAC (64-bit DMA) support */
-
-/* registers for each SATA port */
-#define PORT_LST_ADDR 0x00 /* command list DMA addr */
-#define PORT_LST_ADDR_HI 0x04 /* command list DMA addr hi */
-#define PORT_FIS_ADDR 0x08 /* FIS rx buf addr */
-#define PORT_FIS_ADDR_HI 0x0c /* FIS rx buf addr hi */
-#define PORT_IRQ_STAT 0x10 /* interrupt status */
-#define PORT_IRQ_MASK 0x14 /* interrupt enable/disable mask */
-#define PORT_CMD 0x18 /* port command */
-#define PORT_TFDATA 0x20 /* taskfile data */
-#define PORT_SIG 0x24 /* device TF signature */
-#define PORT_SCR_STAT 0x28 /* SATA phy register: SStatus */
-#define PORT_SCR_CTL 0x2c /* SATA phy register: SControl */
-#define PORT_SCR_ERR 0x30 /* SATA phy register: SError */
-#define PORT_SCR_ACT 0x34 /* SATA phy register: SActive */
-#define PORT_CMD_ISSUE0x38 /* command issue */
-#define PORT_RESERVED 0x3c /* reserved */
-
-/* PORT_IRQ_{STAT,MASK} bits */
-#define PORT_IRQ_COLD_PRES(1 31) /* cold presence detect */
-#define PORT_IRQ_TF_ERR (1 30) /* task file error */
-#define PORT_IRQ_HBUS_ERR (1 29) /* host bus fatal
[Qemu-devel] [PATCH 4/8] ahci: use qiov instead of dma helpers
The DMA helpers incur additional overhead on data transfers. I'm not
sure we need the additional complexity provided by them. So let's just
use qiovs directly when running in the fast path (ncq).
Signed-off-by: Alexander Graf ag...@suse.de
---
hw/ide/ahci.c | 100
hw/ide/ahci.h |3 ++
2 files changed, 95 insertions(+), 8 deletions(-)
diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
index fa97f9b..7a29925 100644
--- a/hw/ide/ahci.c
+++ b/hw/ide/ahci.c
@@ -642,6 +642,87 @@ static void ahci_write_fis_d2h(AHCIDevice *ad, uint8_t
*cmd_fis)
}
}
+static int ahci_iov_destroy(AHCIDevice *ad, QEMUIOVector *qiov, int is_write)
+{
+int i;
+struct iovec *iov = qiov-iov;
+
+for (i = 0; i qiov-niov; i++) {
+/* flags_size is zero-based */
+cpu_physical_memory_unmap(iov[i].iov_base, !is_write,
+ iov[i].iov_len, iov[i].iov_len);
+}
+
+return 0;
+}
+
+static int ahci_populate_iov(AHCIDevice *ad, NCQTransferState *ncq_tfs,
+ int is_write)
+{
+QEMUIOVector *qiov = ncq_tfs-qiov;
+struct iovec *iov;
+AHCICmdHdr *cmd = ad-cur_cmd;
+uint32_t opts = le32_to_cpu(cmd-opts);
+uint64_t prdt_addr = le64_to_cpu(cmd-tbl_addr) + 0x80;
+int sglist_alloc_hint = opts AHCI_CMD_HDR_PRDT_LEN;
+target_phys_addr_t prdt_len = (sglist_alloc_hint * sizeof(AHCI_SG));
+target_phys_addr_t real_prdt_len = prdt_len;
+uint8_t *prdt;
+int i;
+int r = 0;
+
+if (!sglist_alloc_hint) {
+DPRINTF(ad-port_no, no sg list given by guest: 0x%08x\n, opts);
+return -1;
+}
+
+/* map PRDT */
+if (!(prdt = cpu_physical_memory_map(prdt_addr, prdt_len, 0))){
+DPRINTF(ad-port_no, map failed\n);
+return -1;
+}
+
+if (prdt_len real_prdt_len) {
+DPRINTF(ad-port_no, mapped less than expected\n);
+r = -1;
+goto out;
+}
+
+/* Ensure we have enough space to store the iovecs */
+if (ncq_tfs-iov_max sglist_alloc_hint) {
+ncq_tfs-iov = qemu_realloc(ncq_tfs-iov,
+sglist_alloc_hint * sizeof(struct iovec));
+ncq_tfs-iov_max = sglist_alloc_hint;
+}
+iov = ncq_tfs-iov;
+
+if (!iov) {
+DPRINTF(ad-port_no, out of memory\n);
+ncq_tfs-iov_max = 0;
+goto out;
+}
+
+/* Get entries in the PRDT, init a qemu sglist accordingly */
+if (sglist_alloc_hint 0) {
+AHCI_SG *tbl = (AHCI_SG *)prdt;
+void *p;
+
+for (i = 0; i sglist_alloc_hint; i++) {
+target_phys_addr_t len;
+/* flags_size is zero-based */
+len = iov[i].iov_len = le32_to_cpu(tbl[i].flags_size) + 1;
+p = cpu_physical_memory_map(le64_to_cpu(tbl[i].addr),
+len, !is_write);
+iov[i].iov_base = p;
+}
+qemu_iovec_init_external(qiov, iov, sglist_alloc_hint);
+}
+
+out:
+cpu_physical_memory_unmap(prdt, 0, prdt_len, prdt_len);
+return r;
+}
+
static int ahci_populate_sglist(AHCIDevice *ad, QEMUSGList *sglist)
{
AHCICmdHdr *cmd = ad-cur_cmd;
@@ -711,7 +792,7 @@ static void ncq_cb(void *opaque, int ret)
DPRINTF(ncq_tfs-drive-port_no, NCQ transfer tag %d finished\n,
ncq_tfs-tag);
-qemu_sglist_destroy(ncq_tfs-sglist);
+ahci_iov_destroy(ncq_tfs-drive, ncq_tfs-qiov, !ncq_tfs-is_read);
ncq_tfs-used = 0;
}
@@ -747,7 +828,6 @@ static void process_ncq_command(AHCIState *s, int port,
uint8_t *cmd_fis,
ncq_tfs-lba, ncq_tfs-lba + ncq_tfs-sector_count - 2,
s-dev[port].port.ifs[0].nb_sectors - 1);
-ahci_populate_sglist(s-dev[port], ncq_tfs-sglist);
ncq_tfs-tag = tag;
switch(ncq_fis-command) {
@@ -757,9 +837,11 @@ static void process_ncq_command(AHCIState *s, int port,
uint8_t *cmd_fis,
ncq_tfs-is_read = 1;
DPRINTF(port, tag %d aio read %ld\n, ncq_tfs-tag, ncq_tfs-lba);
-ncq_tfs-aiocb = dma_bdrv_read(ncq_tfs-drive-port.ifs[0].bs,
- ncq_tfs-sglist, ncq_tfs-lba,
- ncq_cb, ncq_tfs);
+ahci_populate_iov(s-dev[port], ncq_tfs, 0);
+ncq_tfs-aiocb = bdrv_aio_readv(ncq_tfs-drive-port.ifs[0].bs,
+ncq_tfs-lba, ncq_tfs-qiov,
+ncq_tfs-sector_count, ncq_cb,
+ncq_tfs);
break;
case WRITE_FPDMA_QUEUED:
DPRINTF(port, NCQ writing %d sectors to LBA %ld, tag %d\n,
@@ -767,9 +849,11 @@ static void process_ncq_command(AHCIState *s, int port,
uint8_t *cmd_fis,
ncq_tfs-is_read = 0;
DPRINTF(port, tag %d aio write %ld\n, ncq_tfs-tag,
ncq_tfs-lba);
-ncq_tfs-aiocb =
[Qemu-devel] [PATCH] piix: use pci_config_set_prog_interface()
Use pci_config_set_prog_interface().
Signed-off-by: Sebastian Herbszt herb...@gmx.de
diff --git a/hw/ide/piix.c b/hw/ide/piix.c
index 1cad906..2772e08 100644
--- a/hw/ide/piix.c
+++ b/hw/ide/piix.c
@@ -135,7 +135,7 @@ static int pci_piix_ide_initfn(PCIIDEState *d)
{
uint8_t *pci_conf = d-dev.config;
-pci_conf[PCI_CLASS_PROG] = 0x80; // legacy ATA mode
+pci_config_set_prog_interface(pci_conf, 0x80); // legacy ATA mode
pci_config_set_class(pci_conf, PCI_CLASS_STORAGE_IDE);
qemu_register_reset(piix3_reset, d);
[Qemu-devel] [PATCH] cmd646: use pci_config_set_prog_interface()
Use pci_config_set_prog_interface(). Signed-off-by: Sebastian Herbszt herb...@gmx.de diff --git a/hw/ide/cmd646.c b/hw/ide/cmd646.c index 5d5464a..e125dfc 100644 --- a/hw/ide/cmd646.c +++ b/hw/ide/cmd646.c @@ -230,7 +230,7 @@ static int pci_cmd646_ide_initfn(PCIDevice *dev) pci_config_set_device_id(pci_conf, PCI_DEVICE_ID_CMD_646); pci_conf[PCI_REVISION_ID] = 0x07; // IDE controller revision -pci_conf[PCI_CLASS_PROG] = 0x8f; +pci_config_set_prog_interface(pci_conf, 0x8f); pci_config_set_class(pci_conf, PCI_CLASS_STORAGE_IDE);
[Qemu-devel] Re: [PATCH v2] sparc32: ledma extra registers need tracing too
Thanks, applied.
On Mon, Dec 20, 2010 at 5:55 PM, Bob Breuer breu...@mc.net wrote:
Also trace the extra registers, and update the comments with new
info from Artyom Tarasenko.
Signed-off-by: Bob Breuer breu...@mc.net
---
Since the extra registers are aliased, we could instead alias them at
a higher level. Solaris9 boots to single-user with either option.
diff --git a/hw/sparc32_dma.c b/hw/sparc32_dma.c
index 56be8c8..e75694b 100644
--- a/hw/sparc32_dma.c
+++ b/hw/sparc32_dma.c
@@ -44,7 +44,7 @@
/* We need the mask, because one instance of the device is not page
aligned (ledma, start address 0x0010) */
#define DMA_MASK (DMA_SIZE - 1)
-/* ledma has more than 4 registers, Solaris reads the 5th one */
+/* OBP says 0x20 bytes for ledma, the extras are aliased to espdma */
#define DMA_ETH_SIZE (8 * sizeof(uint32_t))
#define DMA_MAX_REG_OFFSET (2 * DMA_SIZE - 1)
@@ -170,7 +170,10 @@ static uint32_t dma_mem_readl(void *opaque,
target_phys_addr_t addr)
uint32_t saddr;
if (s-is_ledma (addr DMA_MAX_REG_OFFSET)) {
- return 0; /* extra mystery register(s) */
+ /* aliased to espdma, but we can't get there from here */
+ /* buggy driver if using undocumented behavior, just return 0 */
+ trace_sparc32_dma_mem_readl(addr, 0);
+ return 0;
}
saddr = (addr DMA_MASK) 2;
trace_sparc32_dma_mem_readl(addr, s-dmaregs[saddr]);
@@ -183,7 +186,9 @@ static void dma_mem_writel(void *opaque,
target_phys_addr_t addr, uint32_t val)
uint32_t saddr;
if (s-is_ledma (addr DMA_MAX_REG_OFFSET)) {
- return; /* extra mystery register(s) */
+ /* aliased to espdma, but we can't get there from here */
+ trace_sparc32_dma_mem_writel(addr, 0, val);
+ return;
}
saddr = (addr DMA_MASK) 2;
trace_sparc32_dma_mem_writel(addr, s-dmaregs[saddr], val);
[Qemu-devel] [PATCH] rtl8139: use pci_config_set_revision()
Use pci_config_set_revision(). Signed-off-by: Sebastian Herbszt herb...@gmx.de diff --git a/hw/rtl8139.c b/hw/rtl8139.c index a8aed89..6407ce0 100644 --- a/hw/rtl8139.c +++ b/hw/rtl8139.c @@ -3346,7 +3346,7 @@ static int pci_rtl8139_init(PCIDevice *dev) pci_conf = s-dev.config; pci_config_set_vendor_id(pci_conf, PCI_VENDOR_ID_REALTEK); pci_config_set_device_id(pci_conf, PCI_DEVICE_ID_REALTEK_8139); -pci_conf[PCI_REVISION_ID] = RTL8139_PCI_REVID; /* =0x20 is for 8139C+ */ +pci_config_set_revision(pci_conf, RTL8139_PCI_REVID); /* =0x20 is for 8139C+ */ pci_config_set_class(pci_conf, PCI_CLASS_NETWORK_ETHERNET); pci_conf[PCI_INTERRUPT_PIN] = 1;/* interrupt pin 0 */ /* TODO: start of capability list, but no capability
[Qemu-devel] [PATCH] pcnet-pci: use pci_config_set_revision()
Use pci_config_set_revision(). Signed-off-by: Sebastian Herbszt herb...@gmx.de diff --git a/hw/pcnet-pci.c b/hw/pcnet-pci.c index 339a401..c9811e2 100644 --- a/hw/pcnet-pci.c +++ b/hw/pcnet-pci.c @@ -282,7 +282,7 @@ static int pci_pcnet_init(PCIDevice *pci_dev) pci_config_set_device_id(pci_conf, PCI_DEVICE_ID_AMD_LANCE); pci_set_word(pci_conf + PCI_STATUS, PCI_STATUS_FAST_BACK | PCI_STATUS_DEVSEL_MEDIUM); -pci_conf[PCI_REVISION_ID] = 0x10; +pci_config_set_revision(pci_conf, 0x10); pci_config_set_class(pci_conf, PCI_CLASS_NETWORK_ETHERNET); pci_set_word(pci_conf + PCI_SUBSYSTEM_VENDOR_ID, 0x0);
[Qemu-devel] [PATCH] e1000: use pci_config_set_revision()
Use pci_config_set_revision(). Signed-off-by: Sebastian Herbszt herb...@gmx.de diff --git a/hw/e1000.c b/hw/e1000.c index af101bd..7bad51a 100644 --- a/hw/e1000.c +++ b/hw/e1000.c @@ -1116,7 +1116,7 @@ static int pci_e1000_init(PCIDevice *pci_dev) pci_config_set_device_id(pci_conf, E1000_DEVID); /* TODO: we have no capabilities, so why is this bit set? */ pci_set_word(pci_conf + PCI_STATUS, PCI_STATUS_CAP_LIST); -pci_conf[PCI_REVISION_ID] = 0x03; +pci_config_set_revision(pci_conf, 0x03); pci_config_set_class(pci_conf, PCI_CLASS_NETWORK_ETHERNET); /* TODO: RST# value should be 0, PCI spec 6.2.4 */ pci_conf[PCI_CACHE_LINE_SIZE] = 0x10;
[Qemu-devel] [PATCH] usb-uhci: use pci_config_set_revision()
Use pci_config_set_revision(). Signed-off-by: Sebastian Herbszt herb...@gmx.de diff --git a/hw/usb-uhci.c b/hw/usb-uhci.c index b9b822f..5b3bf21 100644 --- a/hw/usb-uhci.c +++ b/hw/usb-uhci.c @@ -1106,7 +1106,7 @@ static int usb_uhci_common_initfn(UHCIState *s) uint8_t *pci_conf = s-dev.config; int i; -pci_conf[PCI_REVISION_ID] = 0x01; // revision number +pci_config_set_revision(pci_conf, 0x01); // revision number pci_conf[PCI_CLASS_PROG] = 0x00; pci_config_set_class(pci_conf, PCI_CLASS_SERIAL_USB); /* TODO: reset value should be 0. */
Re: [Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
Am 20.12.2010 um 13:30 schrieb Alexander Graf: On 20.12.2010, at 13:19, François Revol wrote: So we certainly do need some open source firmware solution for prep to at least have Linux running. For other guests, I don't see a reason why users shouldn't try to fetch a real firmware blob separately :). We're not shipping any firmware for ppcemb either, so that argument seems moot. OpenBIOS, SeaBIOS and ZIPL are the only ones currently. Feel free to supply additional blobs for U-Boot etc. IIUC you don't need u-boot for the embedded targets. You just pass in a kernel and the rest is magic. This holds only for Linux which imposes its own startup API to bootloaders and go with kernel drivers directly. Other OS like Haiku use a 2nd stage bootloader which assumes a working callable BIOS (OF on ppc), and getting it to run on U-Boot is already tricky on its own. That was my point :). I'm not aware of us supporting firmware on ppcemb, so it's capable of running an OS all by itself already. No, you rather mean: It's capable of running The OS so you don't care about proper firmware there. By the same argument we could just load a Linux kernel directly on PReP and be good with it. Any pointers appreciated. Recent vanilla Linux kernels wouldn't run on PReP. So what Linux do you want to run using open source firmware? I certainly do not intend to write firmware for the upcoming 40p machine. If Linux runs on real 40p hardware then it should run with real firmware under emulation, too. QEMU is an emulation project, not a Linux testing framework. I completely agree. Linux is usually easy because it's fully open source and supports a lot of targets. If you feel like running NetBSD or Haiku instead, feel free to do so. Thanks for thinking about Haiku ;) Btw there are other existing targets, like AROS, MorphOS, or AmigaOS which uses a modified U-Boot with a 'boota' command that passes their 2nd stage Parthenope bootloader a list of BIOS-like callbacks into U-Boot, cf. : http://www.acube-systems.biz/index.php?page=hardwarepid=2 http://www.acube-systems.biz/download/u-boot-1.3.1c_20101206_prod.tar.gz Though they probably won't run on PReP, and PReP support in Haiku might come only for the sake of supporting the BeBox, which had its own dumb firmware (MAME seems to have some emulation support for BeBox). OTOH, I've been thinking about adding a Sam440 target, but it'd still require the custom U-Boot to start AmigaOS for example. I'd call U-Boot the firmware that we can ship with Qemu then because it's open source :). I'm not advocate for openBIOS. If it works, great. If something else works better, let's take that. The only thing I really want to see is a target that does something useful. That's it :). A target that loads proprietary firmware halfway through is not valuable to users IMHO. A target that loads proprietary firmware and boots an OS is valuable. A target that doesn't need firmware and loads an OS is valuable. Maybe a target that doesn't boot an OS quite yet, but loads open source firmware pretty well is valuable too. Then we agree, a target that doesn't load any firmware or kernel is not really valuable. If you look around then you'll find all kinds of starved QEMU branches, e.g., alpha es40, avr32 and z80. They're collecting virtual dust while QEMU grows things like qdev. That's why I'm trying to fix (note: fix) things in upstream, not create another fork to bitrot. Andreas
Re: [Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
On 20.12.2010, at 23:24, Andreas Färber wrote: Am 20.12.2010 um 13:30 schrieb Alexander Graf: On 20.12.2010, at 13:19, François Revol wrote: So we certainly do need some open source firmware solution for prep to at least have Linux running. For other guests, I don't see a reason why users shouldn't try to fetch a real firmware blob separately :). We're not shipping any firmware for ppcemb either, so that argument seems moot. OpenBIOS, SeaBIOS and ZIPL are the only ones currently. Feel free to supply additional blobs for U-Boot etc. IIUC you don't need u-boot for the embedded targets. You just pass in a kernel and the rest is magic. This holds only for Linux which imposes its own startup API to bootloaders and go with kernel drivers directly. Other OS like Haiku use a 2nd stage bootloader which assumes a working callable BIOS (OF on ppc), and getting it to run on U-Boot is already tricky on its own. That was my point :). I'm not aware of us supporting firmware on ppcemb, so it's capable of running an OS all by itself already. No, you rather mean: It's capable of running The OS so you don't care about proper firmware there. By the same argument we could just load a Linux kernel directly on PReP and be good with it. Any pointers appreciated. if that works, yes. If instead loading netbsd or haiku is easier, go for those. Anything that actually runs is good :). Recent vanilla Linux kernels wouldn't run on PReP. So what Linux do you want to run using open source firmware? I certainly do not intend to write firmware for the upcoming 40p machine. If Linux runs on real 40p hardware then it should run with real firmware under emulation, too. QEMU is an emulation project, not a Linux testing framework. I completely agree. Linux is usually easy because it's fully open source and supports a lot of targets. If you feel like running NetBSD or Haiku instead, feel free to do so. Thanks for thinking about Haiku ;) Btw there are other existing targets, like AROS, MorphOS, or AmigaOS which uses a modified U-Boot with a 'boota' command that passes their 2nd stage Parthenope bootloader a list of BIOS-like callbacks into U-Boot, cf. : http://www.acube-systems.biz/index.php?page=hardwarepid=2 http://www.acube-systems.biz/download/u-boot-1.3.1c_20101206_prod.tar.gz Though they probably won't run on PReP, and PReP support in Haiku might come only for the sake of supporting the BeBox, which had its own dumb firmware (MAME seems to have some emulation support for BeBox). OTOH, I've been thinking about adding a Sam440 target, but it'd still require the custom U-Boot to start AmigaOS for example. I'd call U-Boot the firmware that we can ship with Qemu then because it's open source :). I'm not advocate for openBIOS. If it works, great. If something else works better, let's take that. The only thing I really want to see is a target that does something useful. That's it :). A target that loads proprietary firmware halfway through is not valuable to users IMHO. A target that loads proprietary firmware and boots an OS is valuable. A target that doesn't need firmware and loads an OS is valuable. Maybe a target that doesn't boot an OS quite yet, but loads open source firmware pretty well is valuable too. Then we agree, a target that doesn't load any firmware or kernel is not really valuable. If you look around then you'll find all kinds of starved QEMU branches, e.g., alpha es40, avr32 and z80. They're collecting virtual dust while QEMU grows things like qdev. That's why I'm trying to fix (note: fix) things in upstream, not create another fork to bitrot. And I very much appreciate that! In fact, I think we're thinking along the same line here. The only difference is that I'd like to see a full patch set in 2 weeks from now that makes prep do something useful, while you wouldn't mind getting those 2 early patches in upstream right now. Either way, you have my full support on this. If you want to stop working on prep after those patches, let's merge them in now - it's an improvement either way. If instead you're keen on improving it, let's let them mature for a while while you continue to work on them. I'm sure you'll spot even more stuff and maybe even find out that you need to go a completely different route in the end :). Whatever happens, I'm very happy to see you work on this! Alex
Re: [Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
On 20.12.2010, at 23:24, Andreas Färber wrote: Am 20.12.2010 um 13:30 schrieb Alexander Graf: On 20.12.2010, at 13:19, François Revol wrote: So we certainly do need some open source firmware solution for prep to at least have Linux running. For other guests, I don't see a reason why users shouldn't try to fetch a real firmware blob separately :). We're not shipping any firmware for ppcemb either, so that argument seems moot. OpenBIOS, SeaBIOS and ZIPL are the only ones currently. Feel free to supply additional blobs for U-Boot etc. IIUC you don't need u-boot for the embedded targets. You just pass in a kernel and the rest is magic. This holds only for Linux which imposes its own startup API to bootloaders and go with kernel drivers directly. Other OS like Haiku use a 2nd stage bootloader which assumes a working callable BIOS (OF on ppc), and getting it to run on U-Boot is already tricky on its own. That was my point :). I'm not aware of us supporting firmware on ppcemb, so it's capable of running an OS all by itself already. No, you rather mean: It's capable of running The OS so you don't care about proper firmware there. By the same argument we could just load a Linux kernel directly on PReP and be good with it. Any pointers appreciated. Recent vanilla Linux kernels wouldn't run on PReP. So what Linux do you want to run using open source firmware? I certainly do not intend to write firmware for the upcoming 40p machine. If Linux runs on real 40p hardware then it should run with real firmware under emulation, too. QEMU is an emulation project, not a Linux testing framework. I completely agree. Linux is usually easy because it's fully open source and supports a lot of targets. If you feel like running NetBSD or Haiku instead, feel free to do so. Thanks for thinking about Haiku ;) Btw there are other existing targets, like AROS, MorphOS, or AmigaOS which uses a modified U-Boot with a 'boota' command that passes their 2nd stage Parthenope bootloader a list of BIOS-like callbacks into U-Boot, cf. : http://www.acube-systems.biz/index.php?page=hardwarepid=2 http://www.acube-systems.biz/download/u-boot-1.3.1c_20101206_prod.tar.gz Though they probably won't run on PReP, and PReP support in Haiku might come only for the sake of supporting the BeBox, which had its own dumb firmware (MAME seems to have some emulation support for BeBox). OTOH, I've been thinking about adding a Sam440 target, but it'd still require the custom U-Boot to start AmigaOS for example. I'd call U-Boot the firmware that we can ship with Qemu then because it's open source :). I'm not advocate for openBIOS. If it works, great. If something else works better, let's take that. The only thing I really want to see is a target that does something useful. That's it :). A target that loads proprietary firmware halfway through is not valuable to users IMHO. A target that loads proprietary firmware and boots an OS is valuable. A target that doesn't need firmware and loads an OS is valuable. Maybe a target that doesn't boot an OS quite yet, but loads open source firmware pretty well is valuable too. Then we agree, a target that doesn't load any firmware or kernel is not really valuable. If you look around then you'll find all kinds of starved QEMU branches, e.g., alpha es40, avr32 and z80. They're collecting virtual dust while QEMU grows things like qdev. That's why I'm trying to fix (note: fix) things in upstream, not create another fork to bitrot. Also on the other forks. I'm not sure what happened with the Alpha port, but for AVR32 and z80 I have not seen any upstream submissions since I joined qemu. I know that the AVR32 people were eager in learning things, but I haven't seen any code submitted upstream. I don't believe this is what will happen with you. You're well aware of how open source works and will hopefully pester at least me - preferably others too - until stuff gets in :). Alex
Re: [Qemu-devel] [PATCH] Z80 emulation updated again!
On 31.05.2009, at 17:20, Stuart Brady wrote: Hi! Here's an update of the Z80 system emulator, which currently emulates the ZX Spectrum only. Significant changes since Ulrich Hecht's updated version are as follows: * Converted CPU emulation core to TCG * Fixed emulation of 'bright' display attribute * Fixed display output for pixel formats besides 32-bit RGB * Improved keyboard handling, with support for cursor keys, etc. * Removed dead code * Now supports libspectrum 0.5 (for snapshot loading) * Numerous cleanups The emulation has not yet been optimised, but should achieve something between 100 and 200 times the performance of real hardware. Thanks go to Ulrich for adding support for snapshot loading, and for porting the 'HALT' hack from xz80, in his updated version! BTW, I have also written some experimental 128K emulation -- however, this only achieves ~10 times the speed of real hardware, as the 128K makes heavy use of bank switching. I can split the patch up if wanted, although only 44 insertions are in existing files. Since this just came up again - are you still working on this? It's be a shame to see this target bitrot to extinction. Also, do you think it's a valuable target to have in upstream qemu? If so, please create a proper patch set out of it, so it can be reviewed. Alex
Re: [Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
Am 20.12.2010 um 10:04 schrieb Alexander Graf: On 19.12.2010, at 20:12, Andreas Färber wrote: Am 19.12.2010 um 16:34 schrieb Alexander Graf: On 19.12.2010, at 16:04, Andreas Färber wrote: Am 19.12.2010 um 10:54 schrieb Alexander Graf: On 14.12.2010, at 01:49, Andreas Färber wrote: Hello, Based on an earlier attempt of mine to make OpenBIOS work with - M prep, with kind support from Hervé Poussineau here's an initial stab at fixing the long-broken PReP emulation and preparing migration from abandoned OpenHack'Ware to OpenBIOS as default FOSS firmware. In particular a number of hw_error()s are resolved, so that the BIOS can be entered at all. It is not yet working in terms of serial and VGA support etc. This series is also available from: git://repo.or.cz/qemu/afaerber.git prep-queue Some more work-in-progress for the curious is on my prep branch [2]. The corresponding work-in-progress OpenBIOS changes are at [3]. Unfortunately the prep machine is lacking documentation what exactly it tries to emulate. The plan thus is to merge emulation of a second, real IBM 40p machine based on Hervé's work at [1], for use with original binary firmware. Also upcoming are new ppc_chrp machines, forked from ppc_newworld, emulating the 970-based IBM JS20 (using Apple U3) [4] and possibly the POWER5-based IntelliStation 285. These depend on the ongoing ppc64 port of OpenBIOS to be completed though. This relates to PReP in that the machine IDs will need to be coordinated. Does this series actually make anything work, or is it just a first step set to get your development rolling? IOW, would users benefit from having the patches upstream yet? As indicated above, it lets you enter a BIOS, which is a user- visible improvement. User-supplied binary firmware works with 1 + 3-4, ELF firmware with 1-4. Patch 3 depends on review comments. Patch 4 was just an FYI for testing the preceding patches and still needs investigation. For OpenBIOS to work, we need fw_cfg in ppc_prep.c and, independently, patches to OpenBIOS. Unless of course we want to use another firmware like OFW from the start. The main interest in PReP nowadays will be proprietary firmware anyway. I thought Rob (cc'ed) had PReP Linux kernel patches for QEMU at some point but I couldn't locate them in the Aboriginal Linux tree. I'm not sure on the copyright problems we might run into when delivering binary firmware. No one suggested shipping proprietary firmware. I was advocating enabling users to use the available firmware rather than holding fixes back just because there is no fully- working FOSS alternative firmware yet. Hrm, I only partially agree. If you ship a target in qemu that people can't test out of the box, it won't receive testing from contributers. I doubt that RH people will go in and download proprietary firmware just to check that prep didn't break. I do hope however, that they test targets that just work. I have this very issue with s390. The only host to run (and compile) this on is an s390. And few people have those. So it breaks from time to time. Since prep would at least get built for everyone, there's less of an issue, yes. So we certainly do need some open source firmware solution for prep to at least have Linux running. For other guests, I don't see a reason why users shouldn't try to fetch a real firmware blob separately :). We're not shipping any firmware for ppcemb either, so that argument seems moot. OpenBIOS, SeaBIOS and ZIPL are the only ones currently. Feel free to supply additional blobs for U-Boot etc. IIUC you don't need u-boot for the embedded targets. You just pass in a kernel and the rest is magic. Recent vanilla Linux kernels wouldn't run on PReP. So what Linux do you want to run using open source firmware? I certainly do not intend to write firmware for the upcoming 40p machine. If Linux runs on real 40p hardware then it should run with real firmware under emulation, too. QEMU is an emulation project, not a Linux testing framework. I completely agree. Linux is usually easy because it's fully open source and supports a lot of targets. If you feel like running NetBSD or Haiku instead, feel free to do so. I'd even be willing to say that running any OS with a proprietary firmware blob is enough to pull stuff in. And really, I mean _any_ OS. I just really want to see some value for users, so in case the whole system just doesn't work at all, we can rather apply a big bunch of removal commits instead of fixes that won't end up in anything working either. Having said that, I have faith in your skills to get this working. So I assume you'll have something that meets the something runs criteria in at most a couple of weeks. Shouldn't be too bad, no? :) Listen, I won't spend a couple of weeks on a firmware that I don't need just because you want me to. I can't work on QEMU all day
Re: [Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
On 21.12.2010, at 00:00, Andreas Färber wrote: Am 20.12.2010 um 10:04 schrieb Alexander Graf: On 19.12.2010, at 20:12, Andreas Färber wrote: Am 19.12.2010 um 16:34 schrieb Alexander Graf: On 19.12.2010, at 16:04, Andreas Färber wrote: Am 19.12.2010 um 10:54 schrieb Alexander Graf: On 14.12.2010, at 01:49, Andreas Färber wrote: Hello, Based on an earlier attempt of mine to make OpenBIOS work with -M prep, with kind support from Hervé Poussineau here's an initial stab at fixing the long-broken PReP emulation and preparing migration from abandoned OpenHack'Ware to OpenBIOS as default FOSS firmware. In particular a number of hw_error()s are resolved, so that the BIOS can be entered at all. It is not yet working in terms of serial and VGA support etc. This series is also available from: git://repo.or.cz/qemu/afaerber.git prep-queue Some more work-in-progress for the curious is on my prep branch [2]. The corresponding work-in-progress OpenBIOS changes are at [3]. Unfortunately the prep machine is lacking documentation what exactly it tries to emulate. The plan thus is to merge emulation of a second, real IBM 40p machine based on Hervé's work at [1], for use with original binary firmware. Also upcoming are new ppc_chrp machines, forked from ppc_newworld, emulating the 970-based IBM JS20 (using Apple U3) [4] and possibly the POWER5-based IntelliStation 285. These depend on the ongoing ppc64 port of OpenBIOS to be completed though. This relates to PReP in that the machine IDs will need to be coordinated. Does this series actually make anything work, or is it just a first step set to get your development rolling? IOW, would users benefit from having the patches upstream yet? As indicated above, it lets you enter a BIOS, which is a user-visible improvement. User-supplied binary firmware works with 1 + 3-4, ELF firmware with 1-4. Patch 3 depends on review comments. Patch 4 was just an FYI for testing the preceding patches and still needs investigation. For OpenBIOS to work, we need fw_cfg in ppc_prep.c and, independently, patches to OpenBIOS. Unless of course we want to use another firmware like OFW from the start. The main interest in PReP nowadays will be proprietary firmware anyway. I thought Rob (cc'ed) had PReP Linux kernel patches for QEMU at some point but I couldn't locate them in the Aboriginal Linux tree. I'm not sure on the copyright problems we might run into when delivering binary firmware. No one suggested shipping proprietary firmware. I was advocating enabling users to use the available firmware rather than holding fixes back just because there is no fully-working FOSS alternative firmware yet. Hrm, I only partially agree. If you ship a target in qemu that people can't test out of the box, it won't receive testing from contributers. I doubt that RH people will go in and download proprietary firmware just to check that prep didn't break. I do hope however, that they test targets that just work. I have this very issue with s390. The only host to run (and compile) this on is an s390. And few people have those. So it breaks from time to time. Since prep would at least get built for everyone, there's less of an issue, yes. So we certainly do need some open source firmware solution for prep to at least have Linux running. For other guests, I don't see a reason why users shouldn't try to fetch a real firmware blob separately :). We're not shipping any firmware for ppcemb either, so that argument seems moot. OpenBIOS, SeaBIOS and ZIPL are the only ones currently. Feel free to supply additional blobs for U-Boot etc. IIUC you don't need u-boot for the embedded targets. You just pass in a kernel and the rest is magic. Recent vanilla Linux kernels wouldn't run on PReP. So what Linux do you want to run using open source firmware? I certainly do not intend to write firmware for the upcoming 40p machine. If Linux runs on real 40p hardware then it should run with real firmware under emulation, too. QEMU is an emulation project, not a Linux testing framework. I completely agree. Linux is usually easy because it's fully open source and supports a lot of targets. If you feel like running NetBSD or Haiku instead, feel free to do so. I'd even be willing to say that running any OS with a proprietary firmware blob is enough to pull stuff in. And really, I mean _any_ OS. I just really want to see some value for users, so in case the whole system just doesn't work at all, we can rather apply a big bunch of removal commits instead of fixes that won't end up in anything working either. Having said that, I have faith in your skills to get this working. So I assume you'll have something that meets the something runs criteria in at most a couple of weeks. Shouldn't be too bad, no? :) Listen, I won't spend a couple of weeks on a firmware that I don't
Re: [Qemu-devel] [PATCH] Z80 emulation updated again!
Am 20.12.2010 um 23:45 schrieb Alexander Graf: On 31.05.2009, at 17:20, Stuart Brady wrote: Here's an update of the Z80 system emulator, which currently emulates the ZX Spectrum only. [...] [...] do you think it's a valuable target to have in upstream qemu? The z80 was also used in the more modern TI-83 Plus programmable calculator [1], for instance (chosen for school use in Baden- Württemberg in the early 2000s). There was an assembler toolchain integrated with Zilog Studio on Windows iirc. Apparently there's also an open source C compiler toolchain at [2] for these and other targets. No Linux that I'm aware of. ;) Cheers, Andreas [1] http://en.wikipedia.org/wiki/TI-83_series [2] http://www.z88dk.org/
Re: [Qemu-devel] [PATCH] Z80 emulation updated again!
On 21.12.2010, at 01:06, Andreas Färber wrote: Am 20.12.2010 um 23:45 schrieb Alexander Graf: On 31.05.2009, at 17:20, Stuart Brady wrote: Here's an update of the Z80 system emulator, which currently emulates the ZX Spectrum only. [...] [...] do you think it's a valuable target to have in upstream qemu? The z80 was also used in the more modern TI-83 Plus programmable calculator [1], for instance (chosen for school use in Baden-Württemberg in the early 2000s). There was an assembler toolchain integrated with Zilog Studio on Windows iirc. Apparently there's also an open source C compiler toolchain at [2] for these and other targets. No Linux that I'm aware of. ;) Heh ;). You make it sound as if qemu was a Linux emulator. The general I/O framework is heavily geared towards server and desktop use. The main use case of the Z80 that I'm aware of is the GameBoy. Not sure that one fits in there too well :). The Spectrum however does fit the desktop case, so it certainly has my blessings. Alex
Re: [Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
Am 21.12.2010 um 00:07 schrieb Alexander Graf: On 21.12.2010, at 00:00, Andreas Färber wrote: Am 20.12.2010 um 10:04 schrieb Alexander Graf: On 19.12.2010, at 20:12, Andreas Färber wrote: Am 19.12.2010 um 16:34 schrieb Alexander Graf: On 19.12.2010, at 16:04, Andreas Färber wrote: Am 19.12.2010 um 10:54 schrieb Alexander Graf: On 14.12.2010, at 01:49, Andreas Färber wrote: Hello, Based on an earlier attempt of mine to make OpenBIOS work with -M prep, with kind support from Hervé Poussineau here's an initial stab at fixing the long-broken PReP emulation and preparing migration from abandoned OpenHack'Ware to OpenBIOS as default FOSS firmware. In particular a number of hw_error()s are resolved, so that the BIOS can be entered at all. It is not yet working in terms of serial and VGA support etc. This series is also available from: git://repo.or.cz/qemu/afaerber.git prep-queue Some more work-in-progress for the curious is on my prep branch [2]. The corresponding work-in-progress OpenBIOS changes are at [3]. Unfortunately the prep machine is lacking documentation what exactly it tries to emulate. The plan thus is to merge emulation of a second, real IBM 40p machine based on Hervé's work at [1], for use with original binary firmware. Also upcoming are new ppc_chrp machines, forked from ppc_newworld, emulating the 970-based IBM JS20 (using Apple U3) [4] and possibly the POWER5-based IntelliStation 285. These depend on the ongoing ppc64 port of OpenBIOS to be completed though. This relates to PReP in that the machine IDs will need to be coordinated. Does this series actually make anything work, or is it just a first step set to get your development rolling? IOW, would users benefit from having the patches upstream yet? As indicated above, it lets you enter a BIOS, which is a user- visible improvement. User-supplied binary firmware works with 1 + 3-4, ELF firmware with 1-4. Patch 3 depends on review comments. Patch 4 was just an FYI for testing the preceding patches and still needs investigation. For OpenBIOS to work, we need fw_cfg in ppc_prep.c and, independently, patches to OpenBIOS. Unless of course we want to use another firmware like OFW from the start. The main interest in PReP nowadays will be proprietary firmware anyway. I thought Rob (cc'ed) had PReP Linux kernel patches for QEMU at some point but I couldn't locate them in the Aboriginal Linux tree. I'm not sure on the copyright problems we might run into when delivering binary firmware. No one suggested shipping proprietary firmware. I was advocating enabling users to use the available firmware rather than holding fixes back just because there is no fully- working FOSS alternative firmware yet. Hrm, I only partially agree. If you ship a target in qemu that people can't test out of the box, it won't receive testing from contributers. I doubt that RH people will go in and download proprietary firmware just to check that prep didn't break. I do hope however, that they test targets that just work. I have this very issue with s390. The only host to run (and compile) this on is an s390. And few people have those. So it breaks from time to time. Since prep would at least get built for everyone, there's less of an issue, yes. So we certainly do need some open source firmware solution for prep to at least have Linux running. For other guests, I don't see a reason why users shouldn't try to fetch a real firmware blob separately :). We're not shipping any firmware for ppcemb either, so that argument seems moot. OpenBIOS, SeaBIOS and ZIPL are the only ones currently. Feel free to supply additional blobs for U-Boot etc. IIUC you don't need u-boot for the embedded targets. You just pass in a kernel and the rest is magic. Recent vanilla Linux kernels wouldn't run on PReP. So what Linux do you want to run using open source firmware? I certainly do not intend to write firmware for the upcoming 40p machine. If Linux runs on real 40p hardware then it should run with real firmware under emulation, too. QEMU is an emulation project, not a Linux testing framework. I completely agree. Linux is usually easy because it's fully open source and supports a lot of targets. If you feel like running NetBSD or Haiku instead, feel free to do so. I'd even be willing to say that running any OS with a proprietary firmware blob is enough to pull stuff in. And really, I mean _any_ OS. I just really want to see some value for users, so in case the whole system just doesn't work at all, we can rather apply a big bunch of removal commits instead of fixes that won't end up in anything working either. Having said that, I have faith in your skills to get this working. So I assume you'll have something that meets the something runs criteria in at most a couple of weeks. Shouldn't be too bad, no? :) Listen, I won't spend a couple of
Re: [Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
On 21.12.2010, at 01:33, Andreas Färber wrote: Am 21.12.2010 um 00:07 schrieb Alexander Graf: On 21.12.2010, at 00:00, Andreas Färber wrote: Am 20.12.2010 um 10:04 schrieb Alexander Graf: On 19.12.2010, at 20:12, Andreas Färber wrote: Am 19.12.2010 um 16:34 schrieb Alexander Graf: On 19.12.2010, at 16:04, Andreas Färber wrote: Am 19.12.2010 um 10:54 schrieb Alexander Graf: On 14.12.2010, at 01:49, Andreas Färber wrote: Hello, Based on an earlier attempt of mine to make OpenBIOS work with -M prep, with kind support from Hervé Poussineau here's an initial stab at fixing the long-broken PReP emulation and preparing migration from abandoned OpenHack'Ware to OpenBIOS as default FOSS firmware. In particular a number of hw_error()s are resolved, so that the BIOS can be entered at all. It is not yet working in terms of serial and VGA support etc. This series is also available from: git://repo.or.cz/qemu/afaerber.git prep-queue Some more work-in-progress for the curious is on my prep branch [2]. The corresponding work-in-progress OpenBIOS changes are at [3]. Unfortunately the prep machine is lacking documentation what exactly it tries to emulate. The plan thus is to merge emulation of a second, real IBM 40p machine based on Hervé's work at [1], for use with original binary firmware. Also upcoming are new ppc_chrp machines, forked from ppc_newworld, emulating the 970-based IBM JS20 (using Apple U3) [4] and possibly the POWER5-based IntelliStation 285. These depend on the ongoing ppc64 port of OpenBIOS to be completed though. This relates to PReP in that the machine IDs will need to be coordinated. Does this series actually make anything work, or is it just a first step set to get your development rolling? IOW, would users benefit from having the patches upstream yet? As indicated above, it lets you enter a BIOS, which is a user-visible improvement. User-supplied binary firmware works with 1 + 3-4, ELF firmware with 1-4. Patch 3 depends on review comments. Patch 4 was just an FYI for testing the preceding patches and still needs investigation. For OpenBIOS to work, we need fw_cfg in ppc_prep.c and, independently, patches to OpenBIOS. Unless of course we want to use another firmware like OFW from the start. The main interest in PReP nowadays will be proprietary firmware anyway. I thought Rob (cc'ed) had PReP Linux kernel patches for QEMU at some point but I couldn't locate them in the Aboriginal Linux tree. I'm not sure on the copyright problems we might run into when delivering binary firmware. No one suggested shipping proprietary firmware. I was advocating enabling users to use the available firmware rather than holding fixes back just because there is no fully-working FOSS alternative firmware yet. Hrm, I only partially agree. If you ship a target in qemu that people can't test out of the box, it won't receive testing from contributers. I doubt that RH people will go in and download proprietary firmware just to check that prep didn't break. I do hope however, that they test targets that just work. I have this very issue with s390. The only host to run (and compile) this on is an s390. And few people have those. So it breaks from time to time. Since prep would at least get built for everyone, there's less of an issue, yes. So we certainly do need some open source firmware solution for prep to at least have Linux running. For other guests, I don't see a reason why users shouldn't try to fetch a real firmware blob separately :). We're not shipping any firmware for ppcemb either, so that argument seems moot. OpenBIOS, SeaBIOS and ZIPL are the only ones currently. Feel free to supply additional blobs for U-Boot etc. IIUC you don't need u-boot for the embedded targets. You just pass in a kernel and the rest is magic. Recent vanilla Linux kernels wouldn't run on PReP. So what Linux do you want to run using open source firmware? I certainly do not intend to write firmware for the upcoming 40p machine. If Linux runs on real 40p hardware then it should run with real firmware under emulation, too. QEMU is an emulation project, not a Linux testing framework. I completely agree. Linux is usually easy because it's fully open source and supports a lot of targets. If you feel like running NetBSD or Haiku instead, feel free to do so. I'd even be willing to say that running any OS with a proprietary firmware blob is enough to pull stuff in. And really, I mean _any_ OS. I just really want to see some value for users, so in case the whole system just doesn't work at all, we can rather apply a big bunch of removal commits instead of fixes that won't end up in anything working either. Having said that, I have faith in your skills to get this working. So I assume you'll have something that meets the something runs criteria in at most a couple of
Re: [Qemu-devel] [PATCH] Z80 emulation updated again!
Am 21.12.2010 um 01:10 schrieb Alexander Graf: On 21.12.2010, at 01:06, Andreas Färber wrote: Am 20.12.2010 um 23:45 schrieb Alexander Graf: On 31.05.2009, at 17:20, Stuart Brady wrote: Here's an update of the Z80 system emulator, which currently emulates the ZX Spectrum only. [...] [...] do you think it's a valuable target to have in upstream qemu? The z80 was also used in the more modern TI-83 Plus programmable calculator [1], for instance The general I/O framework is heavily geared towards server and desktop use. The main use case of the Z80 that I'm aware of is the GameBoy. Not sure that one fits in there too well :). The Spectrum however does fit the desktop case, so it certainly has my blessings. Knowing the ZX Spectrum only from the attic, I agree that emulating game consoles is not the primary purpose or strength of QEMU. (Although I wouldn't mind if someone wanted to contribute a PS3 machine for Cell B.E. emulation!) Fwiw mips, arm, m68k, cris, microblaze seem to form a growing third category of QEMU targets though, embedded systems. Andreas
Re: [Qemu-devel] Re: [PATCH] scsi-generic: bugfixes for 'SCSIRequest' conversion
Yep, so it appears that commit 89c0f6438d16 did introduce the bogus 'double complete' in scsi_read_complete, which I think was intended to handle residual counts for TYPE_TYPE... /* Cancel a pending data transfer. */ @@ -251,6 +257,8 @@ static void scsi_read_complete(void * opaque, int ret) r-len = -1; s-completion(s-opaque, SCSI_REASON_DATA, r-tag, len); +if (len == 0) +scsi_command_complete(r, 0); } I am currently under the assumption for this and bsg_read_complete that s-completion(..., len) is handling the residual count back to block. Is this correct..? So I just debugged a crash where loading my vscsi driver kills qemu (segfault) after trying to complete a command twice with scsi-generic. Removing the above hunk fixes it. So this is a genuine fix that should be applied (asap even :-) I still have an odd problem with scsi-disk.c where reading from an empty cdrom drive crashes it, I'll debug that later. Cheers, Ben.
[Qemu-devel] [PATCH 1/3] Add support for OpenBSD to QEMU's tap driver.
Signed-off-by: Brad Smith b...@comstyle.com
---
net/tap-bsd.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/tap-bsd.c b/net/tap-bsd.c
index efccfe0..2f3efde 100644
--- a/net/tap-bsd.c
+++ b/net/tap-bsd.c
@@ -43,8 +43,8 @@ int tap_open(char *ifname, int ifname_size, int *vnet_hdr,
int vnet_hdr_required
char *dev;
struct stat s;
-#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
-/* if no ifname is given, always start the search from tap0. */
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) || defined(__OpenBSD__)
+/* if no ifname is given, always start the search from tap0/tun0. */
int i;
char dname[100];
@@ -52,7 +52,11 @@ int tap_open(char *ifname, int ifname_size, int *vnet_hdr,
int vnet_hdr_required
if (*ifname) {
snprintf(dname, sizeof dname, /dev/%s, ifname);
} else {
+#if defined(__OpenBSD__)
+snprintf(dname, sizeof dname, /dev/tun%d, i);
+#else
snprintf(dname, sizeof dname, /dev/tap%d, i);
+#endif
}
TFR(fd = open(dname, O_RDWR));
if (fd = 0) {
--
1.7.3.2
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
[Qemu-devel] [PATCH 2/3] Add OpenBSD to ifdef list since it has CLOCK_MONOTONIC.
Signed-off-by: Brad Smith b...@comstyle.com
---
qemu-timer-common.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/qemu-timer-common.c b/qemu-timer-common.c
index fff4399..755e300 100644
--- a/qemu-timer-common.c
+++ b/qemu-timer-common.c
@@ -50,7 +50,8 @@ static void __attribute__((constructor)) init_get_clock(void)
{
use_rt_clock = 0;
#if defined(__linux__) || (defined(__FreeBSD__) __FreeBSD_version =
50) \
-|| defined(__DragonFly__) || defined(__FreeBSD_kernel__)
+|| defined(__DragonFly__) || defined(__FreeBSD_kernel__) \
+|| defined(__OpenBSD__)
{
struct timespec ts;
if (clock_gettime(CLOCK_MONOTONIC, ts) == 0) {
--
1.7.3.2
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
[Qemu-devel] [PATCH 3/3] Use mmap() within code_gen_alloc() for OpenBSD.
Signed-off-by: Brad Smith b...@comstyle.com
---
exec.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/exec.c b/exec.c
index 42a35e0..e513d16 100644
--- a/exec.c
+++ b/exec.c
@@ -517,7 +517,8 @@ static void code_gen_alloc(unsigned long tb_size)
exit(1);
}
}
-#elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) ||
defined(__DragonFly__)
+#elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) \
+|| defined(__DragonFly__) || defined(__OpenBSD__)
{
int flags;
void *addr = NULL;
--
1.7.3.2
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: [Qemu-devel] [PATCH] Z80 emulation updated again!
Hi all, The Z80 CPU and its variants and clones are not only used in dozens of computers (ranging from a full range of CP/M compatible ones, and minicomputers mostly seen as general public as gaming devices -Amstrad, Speccy-), but also in hunders of embedded systems and even on Adaptec SCSI cards. I vote for inclusion on mainstream 100%, and maybe from that code an i8080 emulation can be easily extracted to cover the rest of 80s desktop/minis/micros ? Regards, Natalia Portillo
Re: [Qemu-devel] [PATCH] disable sigcld handling before calling pclose()
At 12/20/2010 02:33 PM, Andreas Färber Write: Am 20.12.2010 um 02:25 schrieb Wen Congyang: At 12/14/2010 05:23 PM, Wen Congyang Write: At 2010-12-09 11:41, Wen Congyang Write: When I use the command 'virsh save' to save the domain state, I receive the following error message: operation failed: Migration unexpectedly failed. I debug the qemu by adding some printf(), and find the function pclose() returns -1. I use strace to trace qemu, the log is as the following: == close(17) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- wait4(-1, NULL, WNOHANG, NULL) = 22016 rt_sigreturn(0) = 0 wait4(22016, 0x7fff7f1034fc, 0, NULL) = -1 ECHILD (No child processes) == We wait the child twice: one is in signal SIGCHLD handling and the other one is in pclose(). We should disable sigcld handling before calling pclose(). Signed-off-by: Wen Congyang we...@cn.fujitsu.com Ping :) Ping Again... :) os-posix.c part looks sane to me, but what about Win32? Wouldn't it need stub functions? I do not know whether there is same BUG on Windows. I will add stub functions for Win32. Andreas
Re: [Qemu-devel] [PATCH] Z80 emulation updated again!
On Tue, Dec 21, 2010 at 12:38 PM, Natalia Portillo clau...@claunia.comwrote: Hi all, The Z80 CPU and its variants and clones are not only used in dozens of computers (ranging from a full range of CP/M compatible ones, and minicomputers mostly seen as general public as gaming devices -Amstrad, Speccy-), but also in hunders of embedded systems and even on Adaptec SCSI cards. I vote for inclusion on mainstream 100%, and maybe from that code an i8080 emulation can be easily extracted to cover the rest of 80s desktop/minis/micros ? This is a really interesting discussion which goes to the heart of QEMU's identity. A contemporary emulation and virtualisation platform (modern embedded, KVM etc)? An emulation platform for retro-computing nostalgia? How about as a unifying platform for MAME? No reason of course it can't be both, unless those roles start pulling in competing directions. Commercially my company is an active user and supporter of MicroBlaze and PPC440 platforms, while personally the Sinclair Spectrum was my first ever home computing experience and will always have a special place in my geek heart. So, I vote 'both'! John -- John Williams, PhD, B.Eng, B.IT PetaLogix - Linux Solutions for a Reconfigurable World w: www.petalogix.com p: +61-7-30090663 f: +61-7-30090663
[Qemu-devel] scsi-generic and max request size
Hi folks ! There's an odd problem I've encountered with my scsi host (basically an powerpc vscsi compatible with IBM PAPR). When using /dev/sg (ie, scsi-generic), there seem to be no way I can find to retrieve the underlying driver's max request transfer size. This can normally be obtained with the BLKSECTGET ioctl under Linux (I'm not familiar with other OSes here). However, this is a bit buggy as well, ie, afaik, this doesn't work with 32-bit binaries on 64-bit kernels (the compat ioctl doesn't seem to work on /dev/sg). For now, qemu doesn't pass that from its bdev layer, which means that scsi-generic doesn't pass it to its own upper layer neither. What that means is two fold I suppose: - For real SCSI HBAs, how do you limit the transfer size anyways ? You can't start breaking up user requests without taking risks with tags etc... - For vscsi, I can expose the limit I want via the SRP interface, but scsi-generic doesn't tell me what it is :-) This is a real problem in practice. IE. the USB CD-ROM on this POWER7 blade limits transfers to 0x1e000 bytes for example and the Linux sr driver on the guest is going to try to give me bigger requests than that if I don't start limiting them, which will cause all sort of errors. Cheers, Ben.
Re: [Qemu-devel] scsi-generic and max request size
Ben, Since it is a scsi device you can try the Inquiry command with pagecode 0xb0 : Block Limit VPD Page. That pages show optimal and maximum request sizes. This is for SBC, in the Vital Product Data chapter. Unfortunately this page is not mandatory so some devices might not understand it. :-( sg_inq --page=0x00 /dev/sg? will show you what inq pages your device supports. regards ronnie sahlberg On Tue, Dec 21, 2010 at 2:25 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: Hi folks ! There's an odd problem I've encountered with my scsi host (basically an powerpc vscsi compatible with IBM PAPR). When using /dev/sg (ie, scsi-generic), there seem to be no way I can find to retrieve the underlying driver's max request transfer size. This can normally be obtained with the BLKSECTGET ioctl under Linux (I'm not familiar with other OSes here). However, this is a bit buggy as well, ie, afaik, this doesn't work with 32-bit binaries on 64-bit kernels (the compat ioctl doesn't seem to work on /dev/sg). For now, qemu doesn't pass that from its bdev layer, which means that scsi-generic doesn't pass it to its own upper layer neither. What that means is two fold I suppose: - For real SCSI HBAs, how do you limit the transfer size anyways ? You can't start breaking up user requests without taking risks with tags etc... - For vscsi, I can expose the limit I want via the SRP interface, but scsi-generic doesn't tell me what it is :-) This is a real problem in practice. IE. the USB CD-ROM on this POWER7 blade limits transfers to 0x1e000 bytes for example and the Linux sr driver on the guest is going to try to give me bigger requests than that if I don't start limiting them, which will cause all sort of errors. Cheers, Ben.
Re: [Qemu-devel] scsi-generic and max request size
On Tue, 2010-12-21 at 14:38 +1100, ronnie sahlberg wrote: Ben, Since it is a scsi device you can try the Inquiry command with pagecode 0xb0 : Block Limit VPD Page. That pages show optimal and maximum request sizes. This is for SBC, in the Vital Product Data chapter. Unfortunately this page is not mandatory so some devices might not understand it. :-( sg_inq --page=0x00 /dev/sg? will show you what inq pages your device supports. Well, that won't help much figuring what the limit is since in most case the limit seems to come from the host linux HBA (ie, usb-storage for example artificially clamps the max request size to deal with bogus USB-ATA bridges). As for using this to try to inform the guest OS as to what the limit is, this could be done by patching the result of that command on the fly in qemu, but that is nasty, and would only work if the guest OS actually uses the said command in the first place. AFAIK, neither sr.c nor sd.c do in Linux. So back to square 1 ... my vscsi (and virtio-blk too btw) can technically pass a max size to the guest, but we don't have a way to interrogate scsi-generic (and the underlying block driver) which is the main issue (that plus the fact that the ioctl seems to be broken in compat mode for /dev/sg specifically)... Cheers, Ben. regards ronnie sahlberg On Tue, Dec 21, 2010 at 2:25 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: Hi folks ! There's an odd problem I've encountered with my scsi host (basically an powerpc vscsi compatible with IBM PAPR). When using /dev/sg (ie, scsi-generic), there seem to be no way I can find to retrieve the underlying driver's max request transfer size. This can normally be obtained with the BLKSECTGET ioctl under Linux (I'm not familiar with other OSes here). However, this is a bit buggy as well, ie, afaik, this doesn't work with 32-bit binaries on 64-bit kernels (the compat ioctl doesn't seem to work on /dev/sg). For now, qemu doesn't pass that from its bdev layer, which means that scsi-generic doesn't pass it to its own upper layer neither. What that means is two fold I suppose: - For real SCSI HBAs, how do you limit the transfer size anyways ? You can't start breaking up user requests without taking risks with tags etc... - For vscsi, I can expose the limit I want via the SRP interface, but scsi-generic doesn't tell me what it is :-) This is a real problem in practice. IE. the USB CD-ROM on this POWER7 blade limits transfers to 0x1e000 bytes for example and the Linux sr driver on the guest is going to try to give me bigger requests than that if I don't start limiting them, which will cause all sort of errors. Cheers, Ben.
[Qemu-devel] [PATCH v2] disable sigcld handling before calling pclose()
When I use the command 'virsh save' to save the domain state,
I receive the following error message:
operation failed: Migration unexpectedly failed.
I debug the qemu by adding some printf(), and find the function
pclose() returns -1.
I use strace to trace qemu, the log is as the following:
==
close(17) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
wait4(-1, NULL, WNOHANG, NULL) = 22016
rt_sigreturn(0) = 0
wait4(22016, 0x7fff7f1034fc, 0, NULL) = -1 ECHILD (No child processes)
==
We wait the child twice: one is in signal SIGCHLD handling and the other
one is in pclose().
We should disable sigcld handling before calling pclose().
v2:
- Add stub functions for Win32
Signed-off-by: Wen Congyang we...@cn.fujitsu.com
---
os-posix.c | 19 +++
qemu-os-posix.h |2 ++
qemu-os-win32.h |2 ++
savevm.c|2 ++
4 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/os-posix.c b/os-posix.c
index 38c29d1..b163995 100644
--- a/os-posix.c
+++ b/os-posix.c
@@ -86,6 +86,25 @@ void os_setup_signal_handling(void)
sigaction(SIGCHLD, act, NULL);
}
+void os_stop_sigchld_handling(void)
+{
+struct sigaction act;
+
+memset(act, 0, sizeof(act));
+act.sa_handler = SIG_DFL;
+sigaction(SIGCHLD, act, NULL);
+}
+
+void os_resume_sigchld_handling(void)
+{
+struct sigaction act;
+
+memset(act, 0, sizeof(act));
+act.sa_handler = sigchld_handler;
+act.sa_flags = SA_NOCLDSTOP;
+sigaction(SIGCHLD, act, NULL);
+}
+
/* Find a likely location for support files using the location of the binary.
For installed binaries this will be $bindir/../share/qemu. When
running from the build tree this will be $bindir/../pc-bios. */
diff --git a/qemu-os-posix.h b/qemu-os-posix.h
index 81fd9ab..1c317f1 100644
--- a/qemu-os-posix.h
+++ b/qemu-os-posix.h
@@ -33,6 +33,8 @@ static inline void os_host_main_loop_wait(int *timeout)
void os_set_line_buffering(void);
void os_set_proc_name(const char *s);
void os_setup_signal_handling(void);
+void os_stop_sigchld_handling(void);
+void os_resume_sigchld_handling(void);
void os_daemonize(void);
void os_setup_post(void);
diff --git a/qemu-os-win32.h b/qemu-os-win32.h
index 1a07e5e..f31c5ef 100644
--- a/qemu-os-win32.h
+++ b/qemu-os-win32.h
@@ -43,6 +43,8 @@ void qemu_del_wait_object(HANDLE handle, WaitObjectFunc
*func, void *opaque);
void os_host_main_loop_wait(int *timeout);
static inline void os_setup_signal_handling(void) {}
+static inline void os_stop_sigchld_handling(void) {}
+static inline void os_resume_sigchld_handling(void) {}
static inline void os_daemonize(void) {}
static inline void os_setup_post(void) {}
void os_set_line_buffering(void);
diff --git a/savevm.c b/savevm.c
index 90aa237..387b70b 100644
--- a/savevm.c
+++ b/savevm.c
@@ -234,7 +234,9 @@ static int stdio_pclose(void *opaque)
{
QEMUFileStdio *s = opaque;
int ret;
+os_stop_sigchld_handling();
ret = pclose(s-stdio_file);
+os_resume_sigchld_handling();
qemu_free(s);
return ret;
}
--
1.7.1
[Qemu-devel] [PATCH v2] hw/virtio-9p-local.c: Remove unnecessary null char in symlink file
This patch removes the addition of null char in symlink file
which is being appended to file in case of mapped security model.
Without this patch, the extra null char causes LTP testcase lstat03
to fail and hence this fix is required.
v2:
- Description updated to mention about LTP lstat testcase
failure without this patch.
Signed-off-by: Harsh Prateek Bora ha...@linux.vnet.ibm.com
---
hw/virtio-9p-local.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c
index 656bfb3..3b6447d 100644
--- a/hw/virtio-9p-local.c
+++ b/hw/virtio-9p-local.c
@@ -370,7 +370,7 @@ static int local_symlink(FsContext *fs_ctx, const char
*oldpath,
return fd;
}
/* Write the oldpath (target) to the file. */
-oldpath_size = strlen(oldpath) + 1;
+oldpath_size = strlen(oldpath);
do {
write_size = write(fd, (void *)oldpath, oldpath_size);
} while (write_size == -1 errno == EINTR);
--
1.7.1.1
Re: [Qemu-devel] [PATCH 1/3] nmi: convert cpu_index to cpu-index
On 12/21/2010 01:00 AM, Markus Armbruster wrote:
Lai Jiangshan la...@cn.fujitsu.com writes:
cpu-index is better name.
Signed-off-by: Lai Jiangshan la...@cn.fujitsu.com
---
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 4befbe2..8de7aa3 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -721,7 +721,7 @@ ETEXI
#if defined(TARGET_I386)
{
.name = nmi,
-.args_type = cpu_index:i,
+.args_type = cpu-index:i,
.params = cpu,
.help = inject an NMI on the given CPU,
.mhandler.cmd = do_inject_nmi,
diff --git a/monitor.c b/monitor.c
index 5d74fe3..c16b39d 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2410,7 +2410,7 @@ static void do_wav_capture(Monitor *mon, const QDict
*qdict)
static void do_inject_nmi(Monitor *mon, const QDict *qdict)
{
CPUState *env;
-int cpu_index = qdict_get_int(qdict, cpu_index);
+int cpu_index = qdict_get_int(qdict, cpu-index);
for (env = first_cpu; env != NULL; env = env-next_cpu)
if (env-cpu_index == cpu_index) {
Fine with me, but it would be nice if we could make up our mind once and
for all whether to use dash or underscore in monitor commands and
arguments.
Currently, I focus on this nmi command, our customers hope they
can inject nmi via libvirt. I may also fix other underscore
when these patches applied.
Thanks,
Lai
Re: [Qemu-devel] [PATCH 2/3] nmi: make cpu-index argument optional
On 12/21/2010 12:58 AM, Markus Armbruster wrote:
Lai Jiangshan la...@cn.fujitsu.com writes:
When the argument cpu-index is not given,
then nmi command will inject NMI on all CPUs.
This simulate the nmi button on physical machine.
Signed-off-by: Lai Jiangshan la...@cn.fujitsu.com
---
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 8de7aa3..d8fe4c0 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -721,9 +721,9 @@ ETEXI
#if defined(TARGET_I386)
{
.name = nmi,
-.args_type = cpu-index:i,
-.params = cpu,
-.help = inject an NMI on the given CPU,
+.args_type = cpu-index:i?,
+.params = [cpu],
+.help = inject an NMI on all CPUs or the given CPU,
.mhandler.cmd = do_inject_nmi,
},
#endif
diff --git a/monitor.c b/monitor.c
index c16b39d..45a8dc2 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2410,7 +2410,13 @@ static void do_wav_capture(Monitor *mon, const QDict
*qdict)
static void do_inject_nmi(Monitor *mon, const QDict *qdict)
{
CPUState *env;
-int cpu_index = qdict_get_int(qdict, cpu-index);
+int cpu_index = qdict_get_try_int(qdict, cpu-index, -1);
Note that we interpret nmi -1 as nmi (no argument). Doesn't matter
now. Does matter after the next patch, because that patch makes the
command when the argument doesn't make sense. Except it doesn't for the
non-sensical argument -1. Same problem with every existing use of
qdict_get_try_int() in the monitor. Do we care?
Good catch!! I will fix it.
Tanks,
Lai.
[Qemu-devel] NPTL support
hi I 'm working with fedora core 13(64 bit) x86_64 platform. I configured QEMU with --enable-nptl switch but I'm not able to run programs containing POSIX threads or fork system call. I run this commandqemu-x86_64 thread it gives system call errorand qemu-x86_64 forkfno child process createdwhat is reason behind it? is nptl support is in its progressive mode or it is not for x86_64. Regards
Re: [Qemu-devel] [PATCH v2] hw/virtio-9p-local.c: Remove unnecessary null char in symlink file
On Tue, Dec 21, 2010 at 5:20 AM, Harsh Prateek Bora ha...@linux.vnet.ibm.com wrote: This patch removes the addition of null char in symlink file which is being appended to file in case of mapped security model. Without this patch, the extra null char causes LTP testcase lstat03 to fail and hence this fix is required. Looks good. Related note: local_readlink() with fs_sm == SM_MAPPED reads the contents of *any* file. I don't see a check that the file is actually a symlink. What if an application relies on the EINVAL return value when calling readlink() on something that is not a file (not sure how this maps through to 9p though)? Stefan
