Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
On Sat, May 29, 2010 at 09:21:14PM +, Blue Swirl wrote: On Sat, May 29, 2010 at 4:37 PM, Gleb Natapov g...@redhat.com wrote: On Sat, May 29, 2010 at 04:13:22PM +, Blue Swirl wrote: On Sat, May 29, 2010 at 2:46 PM, Gleb Natapov g...@redhat.com wrote: On Sat, May 29, 2010 at 09:35:30AM +, Blue Swirl wrote: I still don't see how the alternative is supposed to simplify our life or improve the efficiency of the de-coalescing workaround. It's rather problematic like Gleb pointed out: The de-coalescing logic needs to be informed about periodicity changes that can only be delivered along IRQs. So what to do with the backlog when the timer is stopped? What happens with the current design? Gleb only mentioned the frequency change, I thought that was not so big problem. But I don't think this case should be allowed happen at all, it can't exist on real HW. Hm, why it can't exist on real HW? Do simple exercise. Run WindowsXP inside QEMU, connect with gdb to QEMU process and check what frequency RTC configured with (hint: it will be 64Hz), now run video inside the guest and check frequency again (hint: it will be 1Khz). You missed the key word 'stopped'. If the timer is really stopped, no IRQs should ever come out afterwards, just like on real HW. For the emulation, this means loss of ticks which should have been delivered before the change. I haven't missed it. I describe to you reality of the situation. You want to change reality to be more close to what you want it to be by adding words to my description. Quoting Jan: 'So what to do with the backlog when the timer is stopped?' I didn't add any words to your description, please be more careful with your attributions. Why do you think I want to change the reality? Please refer to my words when you answer to my quote. You quoted my answer to you statement: Gleb only mentioned the frequency change, I thought that was not so big problem. But I don't think this case should be allowed happen at all, it can't exist on real HW. No 'stopped' was under discussion nowhere. FWIW 'stopped' is just a case of frequency change. XP frequency change isn't the same case as timer being stopped. And what is the big difference exactly? Please just go write code, experiment, debug and _then_ come here with design. I added some debugging to RTC, PIC and APIC. I also built a small guest in x86 assembly to test the coalescing. However, in the tests with this guest and others I noticed that the coalescing only happens in some obscure conditions. So try with real guest and with real load. By default the APIC's delivery method for IRQs is ExtInt and coalescing counting happens only with Fixed. This means that the guest needs to reprogram APIC. It also looks like RTC interrupts need to be triggered. But I didn't see both of these to happen simultaneously in my tests with Linux and Windows guests. Of course, -rtc-td-hack flag must be used and I also disabled HPET to be sure that RTC would be used. With DEBUG_COALESCING enabled, I just get increasing numbers for apic_irq_delivered: apic: apic_set_irq: coalescing 67123 apic: apic_set_irq: coalescing 67124 apic: apic_set_irq: coalescing 67125 So have you actually used -rtc-td-hack option? I compiled head of qemu.git with DEBUG_COALESCING and run WindowsXP guest with -rtc-td-hack and I get: apic: apic_reset_irq_delivered: old coalescing 3 apic: apic_set_irq: coalescing 1 apic: apic_get_irq_delivered: returning coalescing 1 apic: apic_set_irq: coalescing 2 apic: apic_set_irq: coalescing 3 apic: apic_set_irq: coalescing 4 apic: apic_set_irq: coalescing 5 apic: apic_set_irq: coalescing 6 apic: apic_reset_irq_delivered: old coalescing 6 apic: apic_set_irq: coalescing 1 apic: apic_get_irq_delivered: returning coalescing 1 If the hack were active, the numbers would be close to zero (or at least some point) because apic_reset_irq_delivered would be called, but this does not happen. Could you specify a clear test case with which the coalescing action could be tested? Linux or BSD based, please. Linux don't use RTC as time source and I don't know about BSD, so no Linux or BSD test case for you, sorry. Run WindowXP standard HAL and put heavy load on the host. You can run video inside the gust to trigger coalescing more easily. But what if the guest changed the frequency very often, and between changes used zero value, like 64Hz - 0Hz - 128Hz - 0Hz - 64Hz? Too bad, the world is not perfect. -- Gleb. -- Gleb.
Re: [Qemu-devel] [PATCH v3 04/17] qdev: Give qtree names precedence over user-assigned IDs
On 05/29/2010 11:01 AM, Markus Armbruster wrote: Jan Kiszkajan.kis...@web.de writes: From: Jan Kiszkajan.kis...@siemens.com As the user may specify ambiguous device IDs, let's search for their official names first before considering the user-supplied identifiers. Signed-off-by: Jan Kiszkajan.kis...@siemens.com The problem is letting the user specify ambiguous device IDs in the first place! That way is madness... Agreed, we're sowing the seeds for future problems. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Re: Another SIGFPE in display code, now in cirrus
On 05/12/2010 09:11 PM, Stefano Stabellini wrote: On Wed, 12 May 2010, Jamie Lokier wrote: Stefano Stabellini wrote: On Wed, 12 May 2010, Avi Kivity wrote: It's useful if you have a one-line horizontal pattern you want to propagate all over. It might be useful all right, but it is not entirely clear what the hardware should do in this situation from the documentation we have, and certainly the current state of the cirrus emulation code doesn't help. It's quite a reasonable thing for hardware to do, even if not documented. It would be surprising if the hardware didn't copy the one-line pattern. All right then, you convinced me :) This is my proposed solution, however it is untested with Windows NT. Signed-off-by: Stefano Stabellinistefano.stabell...@eu.citrix.com --- diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c index 9f61a01..a7f0d3c 100644 --- a/hw/cirrus_vga.c +++ b/hw/cirrus_vga.c @@ -676,15 +676,17 @@ static void cirrus_do_copy(CirrusVGAState *s, int dst, int src, int w, int h) int sx, sy; int dx, dy; int width, height; +uint32_t start_addr, line_offset, line_compare; int depth; int notify = 0; depth = s-vga.get_bpp(s-vga) / 8; s-vga.get_resolution(s-vga,width,height); +s-vga.get_offsets(s-vga,line_offset,start_addr,line_compare); /* extra x, y */ -sx = (src % ABS(s-cirrus_blt_srcpitch)) / depth; -sy = (src / ABS(s-cirrus_blt_srcpitch)); +sx = (src % line_offset) / depth; +sy = (src / line_offset); dx = (dst % ABS(s-cirrus_blt_dstpitch)) / depth; dy = (dst / ABS(s-cirrus_blt_dstpitch)); dx/dy also need to be calculated according to line_offset. I think the rules are: if src_byte_range in screen and dst_byte_range in screen and srcpitch == dstpitch == line_offset: can use qemu_console_copy elif dst_byte_range overlaps screen: if dstpitch == line_offset: invalidate rectangle else: invalidate full screen -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Re: [PATCH v2 12/15] monitor: Add basic device state visualization
On 05/29/2010 11:14 AM, Jan Kiszka wrote: Currently breaks down when IDs contain '/', but permitting that is a bug. There may be more problems; the path lookup code is way too clever. Indeed. Less can sometimes be more. My impression is that some of the cleverness was motivated by lacking qtree completion for the HMP. Can we disable abbreviations for QMP and only allow them for HMP? We can support that by adding a hidden argument to commands specifying whether the input comes from a human or machine. Abbreviations are dangerous if they become ambiguous; a human can recover while a machine can't. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: RFC: blockdev_add friends, brief rationale, QMP docs
On 05/28/2010 09:21 PM, Markus Armbruster wrote:
snip, agreed
Summary of the host / guest split:
-drive options host or guest?
bus, unit, if, index, addr guest, already covered by qdev
cyls, heads, secs, transguest, new qdev properties
(but defaults depend on image)
media guest
snapshot, file, cache, aio, format host, blockdev_add options
We expose some of the cache property to the guest. IMO we need the
cache property to be both guest and host, with qemu bridging the
impedance mismatch if needed.
rerror, werror host, guest drivers will reject
values they don't support
Did you mean 'block format drivers will reject'?
serial guest, new qdev properties
readonlyboth host guest, qdev will refuse
to connect readonly host to read/
write guest
QMP command docs:
blockdev_add
Add host block device.
Arguments:
- id: the host block device's ID, must be unique (json-string)
Unique in which namespace? A global ID namespace if fine.
- file: the disk image file to use (json-string, optional)
- format: disk format (json-string, optional)
- Possible values: raw, qcow2, ...
Need some way to list supported formats.
- aio: host AIO (json-string, optional)
- Possible values: threads (default), native
Need some way to list supported options.
- cache: host cache usage (json-string, optional)
- Possible values: writethrough (default), writeback, unsafe,
none
...
- readonly: open image read-only (json-bool, optional, default false)
- rerror: what to do on read error (json-string, optional)
- Possible values: report (default), ignore, stop
...
- werror: what to do on write error (json-string, optional)
- Possible values: enospc (default), report, ignore, stop
...
- snapshot: enable snapshot (json-bool, optional, default false)
An alternative to the Need some way to list * is to provide another
query capability, akin to KVM_CAP_..., but I think listing is superior.
Example:
- { execute: blockdev_add,
arguments: { format: raw, id: blk1,
file: fedora.img } }
- { return: {} }
Notes:
(1) If argument file is missing, all other optional arguments must be
missing as well. This defines a block device with no media
inserted.
(2) It's possible to list supported disk formats by running QEMU with
arguments -blockdev_add \?.
Ok, so there's a partial answer here.
blockdev_change
---
Change host block device media.
Arguments are exactly like blockdev_add.
Notes:
(1) If argument file is missing, all other optional arguments must be
missing as well. This ejects the media without inserting a new one.
Maybe we want an explicit blockdev_eject instead, not sure.
--
error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Re: RFC: blockdev_add friends, brief rationale, QMP docs
On 05/28/2010 10:24 PM, Luiz Capitulino wrote: If a password is needed, we should throw an error and let the QMP client set the password and try again. It's what we do today, a password should be set with block_passwd before issuing the change command. Otherwise an error is throw. Is the password some kind of global or per-monitor property? In that case it doesn't work with parallel execution of commands; better to have a password field (or assign IDs to passwords and require a passwordid=... argument). -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [PATCHv2-RFC 0/2] virtio: put last seen used index into ring itself
On Fri, May 28, 2010 at 11:56:54AM +0200, Jes Sorensen wrote: On 05/26/10 21:50, Michael S. Tsirkin wrote: Here's a rewrite of the original patch with a new layout. I haven't tested it yet so no idea how this performs, but I think this addresses the cache bounce issue raised by Avi. Posting for early flames/comments. Generally, the Host end of the virtio ring doesn't need to see where Guest is up to in consuming the ring. However, to completely understand what's going on from the outside, this information must be exposed. For example, host can reduce the number of interrupts by detecting that the guest is currently handling previous buffers. We add a feature bit so the guest can tell the host that it's writing out the current value there, if it wants to use that. This differs from original approach in that the used index is put after avail index (they are typically written out together). To avoid cache bounces on descriptor access, and make future extensions easier, we put the ring itself at start of page, and move the control after it. Hi Michael, It looks pretty good to me, however one thing I have been thinking of while reading through it: Rather than storing a pointer within the ring struct, pointing into a position within the same struct. How about storing a byte offset instead and using a cast to get to the pointer position? That would avoid the pointer dereference, which is less effective cache wise and harder for the CPU to predict. Not sure whether it really matters performance wise, just a thought. Cheers, Jes I think this won't work: when PUBLUSH_USED_IDX is negotiated, the pointer is to within the ring. -- MST
[Qemu-devel] Re: sparc mmu
On Sat, May 29, 2010 at 9:33 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/5/29 Blue Swirl blauwir...@gmail.com: Robert Reif did some improvements to SuperSparc emulation, but the work was not finished. That should be a good starting point. Do you mean the last patch he sent to us or are there some earlier unapplied patches? The last one. The last patch _seems_ to be mainly refactoring and disabling features which are not presented in certain models. I might have missed something of course: the patch is large. For me is also interesting what do we miss in the microSPARC implementation. If I switch off POST (which crashes due to the known FPU problems) LX/CX/X OBPs hang. Looks like it's expecting some interrupt (the SS-5 OBP escapes a similar endless loop on a timer irq), but not getting it. Do you know anything obvious qemu is missing in LX machine? I don't have a device tree for LX, but unimplemented interrupt sources could be audio, parallel port, video, modem. Floppy may be buggy.
Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
2010/5/30 Gleb Natapov g...@redhat.com: On Sat, May 29, 2010 at 08:52:34PM +, Blue Swirl wrote: On Sat, May 29, 2010 at 4:32 PM, Gleb Natapov g...@redhat.com wrote: On Sat, May 29, 2010 at 04:03:22PM +, Blue Swirl wrote: 2010/5/29 Gleb Natapov g...@redhat.com: On Sat, May 29, 2010 at 09:15:11AM +, Blue Swirl wrote: There is no code, because we're still at architecture design stage. Try to write test code to understand the problem better. I will. Please do ASAP. This discussion shows that you don't understand what is the problem that we are dialing with. Which part of the problem you think I don't understand? It seams to me you don't understand how Windows uses RTC for time keeping and how the QEMU solves the problem today. RTC causes periodic interrupts and Windows interrupt handler increments jiffies, like Linux? Linux does much more complicated things than that to keep time, so the only way to fix time drift in Linux was to introduce pvclock. For Window it is not so accurate too, since Windows can change clock frequency any time it can't calculate time from jiffies, it needs to update clock at each time tick. guests could also be assisted with special handling (like win2k install hack), for example guest instructions could be counted (approximately, for example using TB size or TSC) and only inject after at least N instructions have passed. Guest instructions cannot be easily counted in KVM (it can be done more or less reliably using perf counters, may be). Aren't there any debug registers or perf counters, which can generate an interrupt after some number of instructions have been executed? Don't think debug registers have something like that and they are available for guest use anyway. Perf counters differs greatly from CPU to CPU (even between two CPUs of the same manufacturer), and we want to keep using them for profiling guests. And I don't see what problem it will solve anyway that can be solved by simple delay between irq reinjection. This would allow counting the executed instructions and limit it. Thus we could emulate a 500MHz CPU on a 2GHz CPU more accurately. Why would you want to limit number of instruction executed by guest if CPU has nothing else to do anyway? The problem occurs not when we have spare cycles so give to a guest, but in opposite case. I think one problem is that the guest has executed too much compared to what would happen with real HW with a lesser CPU. That explains the RTC frequency reprogramming case. You think wrong. The problem is exactly opposite: the guest haven't had enough execution time between two time interrupts. I don't know what RTC frequency reprogramming case you are talking about here. The case you told me where N pending tick IRQs exist but the guest wants to change the RTC frequency from 64Hz to 1024Hz. Let's make this more concrete. 1 GHz CPU, initially 100Hz RTC, so 10Mcycles/tick or 10ms/tick. At T = 30Mcycles, guest wants to change the frequency to 1000Hz. The problem for emulation is that for the same 3 ticks, there has been so little execution power that the ticks have been coalesced. But isn't the guest cycle count then much lower than 30Mcyc? Isn't it so that the guest must be above 30Mcyc to be able to want the change? But if we reach that point, the problem must have not been too little execution time, but too much. Sorry I tried hard to understand what have you said above but failed. What do you mean to be able to want the change? Guest sometimes wants to get 64 timer interrupts per second and sometimes it wants to get 1024 timer interrupt per second. It wants it not as a result of time drift or anything. It's just how guest behaves. You seams to be to fixated on guest frequency change. It's just something you have to take into account when you reinject interrupts. I meant that in the scenario, the guest won't change the RTC before 30Mcyc because of some built in determinism in the guest. At that point, because of some reason, the change would happen. I still don't understand what are you trying to say here. Guest changes frequency because of some even in the guest. It is totally independent of what happens in QEMUs RTC emulation. I'm trying to understand the order of events. In the scenario, the order of events on real HW would be: 10Mcyc: tick IRQ 1 20Mcyc: tick IRQ 2 30Mcyc: tick IRQ 3 30Mcyc: reprogram timer 31Mcyc: tick IRQ 4 32Mcyc: tick IRQ 5 33Mcyc: tick IRQ 6 34Mcyc: tick IRQ 7 With QEMU, the order could become: 30Mcyc: reprogram timer 30.5Mcyc: tick IRQ 1 31Mcyc: tick IRQ 2 31.5Mcyc: tick IRQ 3 32Mcyc: tick IRQ 4 32.5Mcyc: tick IRQ 5 33Mcyc: tick IRQ 6 34Mcyc: tick IRQ 7 Correct?
Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
On 05/28/2010 01:19 AM, Jan Kiszka wrote: Still, this does not answer: - How do you want to detect lost timer ticks? Your (and Gleb's) approach: during injection An alternative: during guest ack The normal pattern is inj/ack/inj/ack; if we see inj/inj/inj we know the guest isn't keeping up. - What subsystem(s) keeps track of the backlog? Clearly, the clock chip (hpet/rtc/pit). With the alternative approach, the clock emulation requests that acks be reported via a qemu_irq interface. - And depending on the above: How to detect at all that a specific IRQ is a timer tick? Clearly, a blocker unless the clock is responsible for timekeeping. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
On 05/29/2010 12:15 PM, Blue Swirl wrote: This would allow counting the executed instructions and limit it. Thus we could emulate a 500MHz CPU on a 2GHz CPU more accurately. Why would you want to limit number of instruction executed by guest if CPU has nothing else to do anyway? The problem occurs not when we have spare cycles so give to a guest, but in opposite case. I think one problem is that the guest has executed too much compared to what would happen with real HW with a lesser CPU. That explains the RTC frequency reprogramming case. The root cause is that while qemu is scheduled out, the real time clock keeps ticking. Since we can't stop real time, we must compensate in other ways. So write the code and show us. You haven't show any evidence that RTC is the wrong place. RTC knows when interrupt was acknowledge to RTC, it know when clock frequency changes, it know when device reset happened. APIC knows only that interrupt was coalesced. It doesn't even know that it may be masked by a guest in IOAPIC (interrupts delivered while they are masked not considered coalesced). Oh, I thought interrupt masking was the reason for coalescing! What exactly is the reason then? The above. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
2010/5/30 Gleb Natapov g...@redhat.com: On Sat, May 29, 2010 at 09:21:14PM +, Blue Swirl wrote: On Sat, May 29, 2010 at 4:37 PM, Gleb Natapov g...@redhat.com wrote: On Sat, May 29, 2010 at 04:13:22PM +, Blue Swirl wrote: On Sat, May 29, 2010 at 2:46 PM, Gleb Natapov g...@redhat.com wrote: On Sat, May 29, 2010 at 09:35:30AM +, Blue Swirl wrote: I still don't see how the alternative is supposed to simplify our life or improve the efficiency of the de-coalescing workaround. It's rather problematic like Gleb pointed out: The de-coalescing logic needs to be informed about periodicity changes that can only be delivered along IRQs. So what to do with the backlog when the timer is stopped? What happens with the current design? Gleb only mentioned the frequency change, I thought that was not so big problem. But I don't think this case should be allowed happen at all, it can't exist on real HW. Hm, why it can't exist on real HW? Do simple exercise. Run WindowsXP inside QEMU, connect with gdb to QEMU process and check what frequency RTC configured with (hint: it will be 64Hz), now run video inside the guest and check frequency again (hint: it will be 1Khz). You missed the key word 'stopped'. If the timer is really stopped, no IRQs should ever come out afterwards, just like on real HW. For the emulation, this means loss of ticks which should have been delivered before the change. I haven't missed it. I describe to you reality of the situation. You want to change reality to be more close to what you want it to be by adding words to my description. Quoting Jan: 'So what to do with the backlog when the timer is stopped?' I didn't add any words to your description, please be more careful with your attributions. Why do you think I want to change the reality? Please refer to my words when you answer to my quote. You quoted my answer to you statement: Gleb only mentioned the frequency change, I thought that was not so big problem. But I don't think this case should be allowed happen at all, it can't exist on real HW. With 'this case' I was referring to 'case with timer stopped', not 'case which Gleb mentioned'. No 'stopped' was under discussion nowhere. It's clearly written there in the sentence Jan wrote. FWIW 'stopped' is just a case of frequency change. True. XP frequency change isn't the same case as timer being stopped. And what is the big difference exactly? Because after the timer is stopped, its extremely unrealistic to send any IRQs. Whereas if the frequency is changed to some other nonzero value, we can cheat and inject some more queued IRQs. Anyway, if this case is not interesting because it doesn't happen in real life emulation scenarios, we can forget it no matter how buggy the current QEMU implementation is. Please just go write code, experiment, debug and _then_ come here with design. I added some debugging to RTC, PIC and APIC. I also built a small guest in x86 assembly to test the coalescing. However, in the tests with this guest and others I noticed that the coalescing only happens in some obscure conditions. So try with real guest and with real load. Well, I'd like to get the test program also trigger it. Now I'm getting: apic: write: 0350 = apic: apic_reset_irq_delivered: old coalescing 0 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 1 apic: apic_get_irq_delivered: returning coalescing 1 apic: apic_reset_irq_delivered: old coalescing 1 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 0 apic: apic_get_irq_delivered: returning coalescing 0 apic: apic_reset_irq_delivered: old coalescing 0 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 0 It looks like some other IRQs cause the coalescing, because also looking at RTC code, it seems it's not possible for RTC to raise the IRQ (except update IRQ, alarm etc.) without calling apic_reset_irq_delivered(). I've attached my test program. Compile: gcc -m32 -o coalescing coalescing.S -ffreestanding -nostdlib -Wl,-T coalescing.ld -g objcopy -Obinary coalescing coalescing.bin Run: qemu -L . -bios coalescing.bin -no-hpet -rtc-td-hack By default the APIC's delivery method for IRQs is ExtInt and coalescing counting happens only with Fixed. This means that the guest needs to reprogram APIC. It also looks like RTC interrupts need to be triggered. But I didn't see both of these to happen simultaneously in my tests with Linux and Windows guests. Of course, -rtc-td-hack flag must be used and I also disabled HPET to be sure that RTC would be used. With DEBUG_COALESCING enabled, I just get increasing numbers for apic_irq_delivered: apic: apic_set_irq: coalescing 67123 apic: apic_set_irq: coalescing 67124 apic: apic_set_irq: coalescing 67125 So have you actually used -rtc-td-hack option? I compiled head of
Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
Blue Swirl wrote: Linux don't use RTC as time source and I don't know about BSD, so no Linux or BSD test case for you, sorry. Run WindowXP standard HAL and put heavy load on the host. You can run video inside the gust to trigger coalescing more easily. I don't have Windows XP, sorry. ReactOS [1], at least its 32-bit version, appears to use the RTC as well. Jan [1] http://www.reactos.org/de/download.html signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
On Sun, May 30, 2010 at 12:10:16PM +, Blue Swirl wrote: You missed the key word 'stopped'. If the timer is really stopped, no IRQs should ever come out afterwards, just like on real HW. For the emulation, this means loss of ticks which should have been delivered before the change. I haven't missed it. I describe to you reality of the situation. You want to change reality to be more close to what you want it to be by adding words to my description. Quoting Jan: 'So what to do with the backlog when the timer is stopped?' I didn't add any words to your description, please be more careful with your attributions. Why do you think I want to change the reality? Please refer to my words when you answer to my quote. You quoted my answer to you statement: Gleb only mentioned the frequency change, I thought that was not so big problem. But I don't think this case should be allowed happen at all, it can't exist on real HW. With 'this case' I was referring to 'case with timer stopped', not 'case which Gleb mentioned'. No 'stopped' was under discussion nowhere. It's clearly written there in the sentence Jan wrote. Jan, not me, but lets leave this topic alone since you agree that stopped is just a case of frequency change anyway. FWIW 'stopped' is just a case of frequency change. True. XP frequency change isn't the same case as timer being stopped. And what is the big difference exactly? Because after the timer is stopped, its extremely unrealistic to send any IRQs. Whereas if the frequency is changed to some other nonzero value, we can cheat and inject some more queued IRQs. Correct, when gets disables clock source (by reset or any other means) coalesced backlog should be forgotten. Anyway, if this case is not interesting because it doesn't happen in real life emulation scenarios, we can forget it no matter how buggy the current QEMU implementation is. Please just go write code, experiment, debug and _then_ come here with design. I added some debugging to RTC, PIC and APIC. I also built a small guest in x86 assembly to test the coalescing. However, in the tests with this guest and others I noticed that the coalescing only happens in some obscure conditions. So try with real guest and with real load. Well, I'd like to get the test program also trigger it. Now I'm getting: apic: write: 0350 = apic: apic_reset_irq_delivered: old coalescing 0 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 1 apic: apic_get_irq_delivered: returning coalescing 1 apic: apic_reset_irq_delivered: old coalescing 1 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 0 apic: apic_get_irq_delivered: returning coalescing 0 apic: apic_reset_irq_delivered: old coalescing 0 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 0 It looks like some other IRQs cause the coalescing, because also looking at RTC code, it seems it's not possible for RTC to raise the IRQ (except update IRQ, alarm etc.) without calling apic_reset_irq_delivered(). I've attached my test program. Compile: gcc -m32 -o coalescing coalescing.S -ffreestanding -nostdlib -Wl,-T coalescing.ld -g objcopy -Obinary coalescing coalescing.bin Run: qemu -L . -bios coalescing.bin -no-hpet -rtc-td-hack The application does not work for me. Looks like it fails to enter protected mode. $pc jumps from 0xfff0 to 0x000f003e and back. By default the APIC's delivery method for IRQs is ExtInt and coalescing counting happens only with Fixed. This means that the guest needs to reprogram APIC. It also looks like RTC interrupts need to be triggered. But I didn't see both of these to happen simultaneously in my tests with Linux and Windows guests. Of course, -rtc-td-hack flag must be used and I also disabled HPET to be sure that RTC would be used. With DEBUG_COALESCING enabled, I just get increasing numbers for apic_irq_delivered: apic: apic_set_irq: coalescing 67123 apic: apic_set_irq: coalescing 67124 apic: apic_set_irq: coalescing 67125 So have you actually used -rtc-td-hack option? I compiled head of qemu.git with DEBUG_COALESCING and run WindowsXP guest with -rtc-td-hack and I get: apic: apic_reset_irq_delivered: old coalescing 3 apic: apic_set_irq: coalescing 1 apic: apic_get_irq_delivered: returning coalescing 1 apic: apic_set_irq: coalescing 2 apic: apic_set_irq: coalescing 3 apic: apic_set_irq: coalescing 4 apic: apic_set_irq: coalescing 5 apic: apic_set_irq: coalescing 6 apic: apic_reset_irq_delivered: old coalescing 6 apic: apic_set_irq: coalescing 1 apic: apic_get_irq_delivered: returning coalescing 1 If the hack were active, the numbers would be close to zero (or at least some point) because apic_reset_irq_delivered would be called, but this does not happen.
Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
2010/5/30 Gleb Natapov g...@redhat.com: On Sun, May 30, 2010 at 12:10:16PM +, Blue Swirl wrote: You missed the key word 'stopped'. If the timer is really stopped, no IRQs should ever come out afterwards, just like on real HW. For the emulation, this means loss of ticks which should have been delivered before the change. I haven't missed it. I describe to you reality of the situation. You want to change reality to be more close to what you want it to be by adding words to my description. Quoting Jan: 'So what to do with the backlog when the timer is stopped?' I didn't add any words to your description, please be more careful with your attributions. Why do you think I want to change the reality? Please refer to my words when you answer to my quote. You quoted my answer to you statement: Gleb only mentioned the frequency change, I thought that was not so big problem. But I don't think this case should be allowed happen at all, it can't exist on real HW. With 'this case' I was referring to 'case with timer stopped', not 'case which Gleb mentioned'. No 'stopped' was under discussion nowhere. It's clearly written there in the sentence Jan wrote. Jan, not me, but lets leave this topic alone since you agree that stopped is just a case of frequency change anyway. FWIW 'stopped' is just a case of frequency change. True. XP frequency change isn't the same case as timer being stopped. And what is the big difference exactly? Because after the timer is stopped, its extremely unrealistic to send any IRQs. Whereas if the frequency is changed to some other nonzero value, we can cheat and inject some more queued IRQs. Correct, when gets disables clock source (by reset or any other means) coalesced backlog should be forgotten. Anyway, if this case is not interesting because it doesn't happen in real life emulation scenarios, we can forget it no matter how buggy the current QEMU implementation is. Please just go write code, experiment, debug and _then_ come here with design. I added some debugging to RTC, PIC and APIC. I also built a small guest in x86 assembly to test the coalescing. However, in the tests with this guest and others I noticed that the coalescing only happens in some obscure conditions. So try with real guest and with real load. Well, I'd like to get the test program also trigger it. Now I'm getting: apic: write: 0350 = apic: apic_reset_irq_delivered: old coalescing 0 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 1 apic: apic_get_irq_delivered: returning coalescing 1 apic: apic_reset_irq_delivered: old coalescing 1 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 0 apic: apic_get_irq_delivered: returning coalescing 0 apic: apic_reset_irq_delivered: old coalescing 0 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 0 It looks like some other IRQs cause the coalescing, because also looking at RTC code, it seems it's not possible for RTC to raise the IRQ (except update IRQ, alarm etc.) without calling apic_reset_irq_delivered(). I've attached my test program. Compile: gcc -m32 -o coalescing coalescing.S -ffreestanding -nostdlib -Wl,-T coalescing.ld -g objcopy -Obinary coalescing coalescing.bin Run: qemu -L . -bios coalescing.bin -no-hpet -rtc-td-hack The application does not work for me. Looks like it fails to enter protected mode. $pc jumps from 0xfff0 to 0x000f003e and back. Strange. Here's a working binary. By default the APIC's delivery method for IRQs is ExtInt and coalescing counting happens only with Fixed. This means that the guest needs to reprogram APIC. It also looks like RTC interrupts need to be triggered. But I didn't see both of these to happen simultaneously in my tests with Linux and Windows guests. Of course, -rtc-td-hack flag must be used and I also disabled HPET to be sure that RTC would be used. With DEBUG_COALESCING enabled, I just get increasing numbers for apic_irq_delivered: apic: apic_set_irq: coalescing 67123 apic: apic_set_irq: coalescing 67124 apic: apic_set_irq: coalescing 67125 So have you actually used -rtc-td-hack option? I compiled head of qemu.git with DEBUG_COALESCING and run WindowsXP guest with -rtc-td-hack and I get: apic: apic_reset_irq_delivered: old coalescing 3 apic: apic_set_irq: coalescing 1 apic: apic_get_irq_delivered: returning coalescing 1 apic: apic_set_irq: coalescing 2 apic: apic_set_irq: coalescing 3 apic: apic_set_irq: coalescing 4 apic: apic_set_irq: coalescing 5 apic: apic_set_irq: coalescing 6 apic: apic_reset_irq_delivered: old coalescing 6 apic: apic_set_irq: coalescing 1 apic: apic_get_irq_delivered: returning coalescing 1 If the hack were active, the numbers would be close to zero (or at least some point)
Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
On Sun, May 30, 2010 at 12:24 PM, Jan Kiszka jan.kis...@web.de wrote: Blue Swirl wrote: Linux don't use RTC as time source and I don't know about BSD, so no Linux or BSD test case for you, sorry. Run WindowXP standard HAL and put heavy load on the host. You can run video inside the gust to trigger coalescing more easily. I don't have Windows XP, sorry. ReactOS [1], at least its 32-bit version, appears to use the RTC as well. I tried LiveCD and QEMU versions, both seem to hang at boot. Is that expected?
Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
2010/5/30 Gleb Natapov g...@redhat.com: On Sun, May 30, 2010 at 12:10:16PM +, Blue Swirl wrote: You missed the key word 'stopped'. If the timer is really stopped, no IRQs should ever come out afterwards, just like on real HW. For the emulation, this means loss of ticks which should have been delivered before the change. I haven't missed it. I describe to you reality of the situation. You want to change reality to be more close to what you want it to be by adding words to my description. Quoting Jan: 'So what to do with the backlog when the timer is stopped?' I didn't add any words to your description, please be more careful with your attributions. Why do you think I want to change the reality? Please refer to my words when you answer to my quote. You quoted my answer to you statement: Gleb only mentioned the frequency change, I thought that was not so big problem. But I don't think this case should be allowed happen at all, it can't exist on real HW. With 'this case' I was referring to 'case with timer stopped', not 'case which Gleb mentioned'. No 'stopped' was under discussion nowhere. It's clearly written there in the sentence Jan wrote. Jan, not me, but lets leave this topic alone since you agree that stopped is just a case of frequency change anyway. FWIW 'stopped' is just a case of frequency change. True. XP frequency change isn't the same case as timer being stopped. And what is the big difference exactly? Because after the timer is stopped, its extremely unrealistic to send any IRQs. Whereas if the frequency is changed to some other nonzero value, we can cheat and inject some more queued IRQs. Correct, when gets disables clock source (by reset or any other means) coalesced backlog should be forgotten. Anyway, if this case is not interesting because it doesn't happen in real life emulation scenarios, we can forget it no matter how buggy the current QEMU implementation is. Please just go write code, experiment, debug and _then_ come here with design. I added some debugging to RTC, PIC and APIC. I also built a small guest in x86 assembly to test the coalescing. However, in the tests with this guest and others I noticed that the coalescing only happens in some obscure conditions. So try with real guest and with real load. Well, I'd like to get the test program also trigger it. Now I'm getting: apic: write: 0350 = apic: apic_reset_irq_delivered: old coalescing 0 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 1 apic: apic_get_irq_delivered: returning coalescing 1 apic: apic_reset_irq_delivered: old coalescing 1 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 0 apic: apic_get_irq_delivered: returning coalescing 0 apic: apic_reset_irq_delivered: old coalescing 0 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 0 It looks like some other IRQs cause the coalescing, because also looking at RTC code, it seems it's not possible for RTC to raise the IRQ (except update IRQ, alarm etc.) without calling apic_reset_irq_delivered(). I've attached my test program. Compile: gcc -m32 -o coalescing coalescing.S -ffreestanding -nostdlib -Wl,-T coalescing.ld -g objcopy -Obinary coalescing coalescing.bin Run: qemu -L . -bios coalescing.bin -no-hpet -rtc-td-hack The application does not work for me. Looks like it fails to enter protected mode. $pc jumps from 0xfff0 to 0x000f003e and back. By default the APIC's delivery method for IRQs is ExtInt and coalescing counting happens only with Fixed. This means that the guest needs to reprogram APIC. It also looks like RTC interrupts need to be triggered. But I didn't see both of these to happen simultaneously in my tests with Linux and Windows guests. Of course, -rtc-td-hack flag must be used and I also disabled HPET to be sure that RTC would be used. With DEBUG_COALESCING enabled, I just get increasing numbers for apic_irq_delivered: apic: apic_set_irq: coalescing 67123 apic: apic_set_irq: coalescing 67124 apic: apic_set_irq: coalescing 67125 So have you actually used -rtc-td-hack option? I compiled head of qemu.git with DEBUG_COALESCING and run WindowsXP guest with -rtc-td-hack and I get: apic: apic_reset_irq_delivered: old coalescing 3 apic: apic_set_irq: coalescing 1 apic: apic_get_irq_delivered: returning coalescing 1 apic: apic_set_irq: coalescing 2 apic: apic_set_irq: coalescing 3 apic: apic_set_irq: coalescing 4 apic: apic_set_irq: coalescing 5 apic: apic_set_irq: coalescing 6 apic: apic_reset_irq_delivered: old coalescing 6 apic: apic_set_irq: coalescing 1 apic: apic_get_irq_delivered: returning coalescing 1 If the hack were active, the numbers would be close to zero (or at least some point) because apic_reset_irq_delivered would be
[Qemu-devel] Re: Qemu-devel Digest, Vol 86, Issue 533
QtEmu 1.0.5 in Linux KDuXPv1.97 , workfine.
qemu-devel-requ...@nongnu.org escreveu:
Send Qemu-devel mailing list submissions to
qemu-devel@nongnu.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.nongnu.org/mailman/listinfo/qemu-devel
or, via email, send a message with subject or body 'help' to
qemu-devel-requ...@nongnu.org
You can reach the person managing the list at
qemu-devel-ow...@nongnu.org
When replying, please edit your Subject line so it is more specific
than Re: Contents of Qemu-devel digest...
Today's Topics:
1. [PATCH 2/3] qemu-thread: add cleanup_push() and cleanup_pop()
(Corentin Chary)
2. (no subject)
3. [PATCH 0/3] [RFC] Threaded vnc server (Corentin Chary)
4. [PATCH 1/3] qemu-thread: add qemu_mutex/cond_destroy and
qemu_mutex_exit (Corentin Chary)
5. Re: [PATCH] savevm: Really verify if a drive supports
snapshots (Markus Armbruster)
6. Re: [PATCH] Name the default PCI bus pci.0 on all
architectures (Markus Armbruster)
7. (no subject)
8. Re: cg14 (Bob Breuer)
--
Message: 1
Date: Sat, 29 May 2010 09:38:05 +0200
From: Corentin Chary corenti...@iksaif.net
Subject: [Qemu-devel] [PATCH 2/3] qemu-thread: add cleanup_push() and
cleanup_pop()
To: qemu-devel@nongnu.org
Cc: Corentin Chary corenti...@iksaif.net, Anthony Liguori
aligu...@linux.vnet.ibm.com,Gautham R Shenoy e...@in.ibm.com,
Alexander Graf ag...@suse.de, Adam Litke a...@us.ibm.com
Message-ID: 1275118686-15649-3-git-send-email-corenti...@iksaif.net
--
Message: 2
Message-ID: mailman.100.1275148431.11256.qemu-de...@nongnu.org
These functions manipulate the calling thread's stack of
thread-cancellation clean-up handlers. A clean-up handler is
a function that is automatically executed when a thread is canceled
[...] it might, for example, unlock a mutex so that it becomes
available to other threads in the process.
These two functions are implemented using macros because there is no
other way to do that (pthread man, again):
On Linux, the pthread_cleanup_push() and pthread_cleanup_pop()
functions are implemented as macros that expand to text containing
'{' and '}', respectively. This means that variables declared
within the scope of paired calls to these functions will only
be visible within that scope.
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
qemu-thread.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/qemu-thread.h b/qemu-thread.h
index 19bb30c..e5006bb 100644
--- a/qemu-thread.h
+++ b/qemu-thread.h
@@ -41,4 +41,8 @@ void qemu_thread_self(QemuThread *thread);
int qemu_thread_equal(QemuThread *thread1, QemuThread *thread2);
void qemu_thread_exit(void *retval);
+#define qemu_thread_cleanup_pop(execute) pthread_cleanup_pop(execute)
+#define qemu_thread_cleanup_push(routine, arg) \
+pthread_cleanup_push(routine, arg)
+
#endif
Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
On Sun, May 30, 2010 at 12:56:26PM +, Blue Swirl wrote: Well, I'd like to get the test program also trigger it. Now I'm getting: apic: write: 0350 = apic: apic_reset_irq_delivered: old coalescing 0 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 1 apic: apic_get_irq_delivered: returning coalescing 1 apic: apic_reset_irq_delivered: old coalescing 1 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 0 apic: apic_get_irq_delivered: returning coalescing 0 apic: apic_reset_irq_delivered: old coalescing 0 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 0 So interrupt is _alway_ coalesced. If apic_get_irq_delivered() returns 0 it means the interrupt was not delivered. It looks like some other IRQs cause the coalescing, because also looking at RTC code, it seems it's not possible for RTC to raise the IRQ (except update IRQ, alarm etc.) without calling apic_reset_irq_delivered(). I've attached my test program. Compile: gcc -m32 -o coalescing coalescing.S -ffreestanding -nostdlib -Wl,-T coalescing.ld -g objcopy -Obinary coalescing coalescing.bin Run: qemu -L . -bios coalescing.bin -no-hpet -rtc-td-hack The application does not work for me. Looks like it fails to enter protected mode. $pc jumps from 0xfff0 to 0x000f003e and back. Strange. Here's a working binary. Your binary works here too. What compiler are you using? -- Gleb.
[Qemu-devel] Re: [PATCH v2] pci-hotplug: make them aware of pci domain.
On Fri, May 28, 2010 at 06:30:46PM +0900, Isaku Yamahata wrote:
add helper function which converts root bus to pci domain.
make them aware of pci domain.
Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp
Doesn't seem to apply to master.
---
Changes: V1 - V2
- removed pci_find_bus()
- renamed pci_find_bus_by_bus() to pci_find_bus()
- add abort()
---
hw/pci-hotplug.c |7 ---
hw/pci.c | 22 +-
hw/pci.h |1 +
3 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/hw/pci-hotplug.c b/hw/pci-hotplug.c
index 37ac015..a8f3df1 100644
--- a/hw/pci-hotplug.c
+++ b/hw/pci-hotplug.c
@@ -124,7 +124,7 @@ void drive_hot_add(Monitor *mon, const QDict *qdict)
if (pci_read_devaddr(mon, pci_addr, dom, pci_bus, slot)) {
goto err;
}
-dev = pci_find_device(pci_find_root_bus(0), pci_bus, slot, 0);
+dev = pci_find_device(pci_find_root_bus(dom), pci_bus, slot, 0);
if (!dev) {
monitor_printf(mon, no pci device with address %s\n, pci_addr);
goto err;
@@ -252,7 +252,8 @@ void pci_device_hot_add(Monitor *mon, const QDict *qdict)
if (dev) {
monitor_printf(mon, OK domain %d, bus %d, slot %d, function %d\n,
- 0, pci_bus_num(dev-bus), PCI_SLOT(dev-devfn),
+ pci_find_domain(dev-bus),
+ pci_bus_num(dev-bus), PCI_SLOT(dev-devfn),
PCI_FUNC(dev-devfn));
} else
monitor_printf(mon, failed to add %s\n, opts);
@@ -269,7 +270,7 @@ int pci_device_hot_remove(Monitor *mon, const char
*pci_addr)
return -1;
}
-d = pci_find_device(pci_find_root_bus(0), bus, slot, 0);
+d = pci_find_device(pci_find_root_bus(dom), bus, slot, 0);
if (!d) {
monitor_printf(mon, slot %d empty\n, slot);
return -1;
diff --git a/hw/pci.c b/hw/pci.c
index 39a6206..f046029 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -200,6 +200,26 @@ PCIBus *pci_find_root_bus(int domain)
return NULL;
}
+int pci_find_domain(const PCIBus *bus)
+{
+PCIDevice *d;
+struct PCIHostBus *host;
+
+/* obtain root bus */
+while ((d = bus-parent_dev) != NULL) {
+bus = d-bus;
+}
+
+QLIST_FOREACH(host, host_buses, next) {
+if (host-bus == bus) {
+return host-domain;
+}
+}
+
+abort();/* should not be reached */
+return -1;
+}
+
void pci_bus_new_inplace(PCIBus *bus, DeviceState *parent,
const char *name, int devfn_min)
{
@@ -505,7 +525,7 @@ PCIBus *pci_get_bus_devfn(int *devfnp, const char
*devaddr)
}
*devfnp = slot 3;
-return pci_find_bus(pci_find_root_bus(0), bus);
+return pci_find_bus(pci_find_root_bus(dom), bus);
}
static void pci_init_cmask(PCIDevice *dev)
diff --git a/hw/pci.h b/hw/pci.h
index b803593..3a15bd4 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -218,6 +218,7 @@ PCIDevice *pci_nic_init_nofail(NICInfo *nd, const char
*default_model,
int pci_bus_num(PCIBus *s);
void pci_for_each_device(PCIBus *bus, int bus_num, void (*fn)(PCIBus *bus,
PCIDevice *d));
PCIBus *pci_find_root_bus(int domain);
+int pci_find_domain(const PCIBus *bus);
PCIBus *pci_find_bus(PCIBus *bus, int bus_num);
PCIDevice *pci_find_device(PCIBus *bus, int bus_num, int slot, int function);
PCIBus *pci_get_bus_devfn(int *devfnp, const char *devaddr);
--
1.6.6.1
--
yamahata
[Qemu-devel] [PATCH] [virtio-9p] Server side implementation for TLINK
Create a link.
SYNOPSIS
size[4] Tlink tag[2] dfid[4] oldpath[s] newpath[s]
size[4] Rlink tag[2]
DESCRIPTION
Create a link 'newpath' in directory pointed by dfid linking to oldpath.
Signed-off-by: Venkateswararao Jujjuri jv...@linux.vnet.ibm.com
---
hw/file-op-9p.h |2 +-
hw/virtio-9p-debug.c |9 +
hw/virtio-9p-local.c |2 +-
hw/virtio-9p.c | 40
hw/virtio-9p.h |2 ++
5 files changed, 45 insertions(+), 10 deletions(-)
diff --git a/hw/file-op-9p.h b/hw/file-op-9p.h
index b3a320c..6744d69 100644
--- a/hw/file-op-9p.h
+++ b/hw/file-op-9p.h
@@ -55,7 +55,7 @@ typedef struct FileOperations
int (*utime)(FsContext *, const char *, const struct utimbuf *);
int (*remove)(FsContext *, const char *);
int (*symlink)(FsContext *, const char *, const char *, FsCred *);
-int (*link)(FsContext *, const char *, const char *, FsCred *);
+int (*link)(FsContext *, const char *, const char *);
int (*setuid)(FsContext *, uid_t);
int (*close)(FsContext *, int);
int (*closedir)(FsContext *, DIR *);
diff --git a/hw/virtio-9p-debug.c b/hw/virtio-9p-debug.c
index a82b771..a870b97 100644
--- a/hw/virtio-9p-debug.c
+++ b/hw/virtio-9p-debug.c
@@ -463,6 +463,15 @@ void pprint_pdu(V9fsPDU *pdu)
case P9_RCLUNK:
fprintf(llogfile, RCLUNK: ();
break;
+case P9_TLINK:
+fprintf(llogfile, TLINK: ();
+pprint_int32(pdu, 0, offset, fid);
+pprint_str(pdu, 0, offset, , name);
+pprint_str(pdu, 0, offset, , linkname);
+break;
+case P9_RLINK:
+fprintf(llogfile, RLINK: ();
+break;
case P9_TREMOVE:
fprintf(llogfile, TREMOVE: ();
pprint_int32(pdu, 0, offset, fid);
diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c
index c5678ae..fa8d05c 100644
--- a/hw/virtio-9p-local.c
+++ b/hw/virtio-9p-local.c
@@ -375,7 +375,7 @@ err_end:
}
static int local_link(FsContext *fs_ctx, const char *oldpath,
-const char *newpath, FsCred *credp)
+const char *newpath)
{
char *tmp = qemu_strdup(rpath(fs_ctx, oldpath));
int err;
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 097dce8..d36d206 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -212,14 +212,9 @@ static int v9fs_do_symlink(V9fsState *s, V9fsCreateState
*vs)
cred);
}
-static int v9fs_do_link(V9fsState *s, V9fsFidState *nfidp, V9fsCreateState *vs)
+static int v9fs_do_link(V9fsState *s, char *oldpath, char *fullname)
{
-FsCred cred;
-cred_init(cred);
-cred.fc_uid = nfidp-uid;
-cred.fc_mode = vs-perm 0777;
-
-return s-ops-link(s-ctx, nfidp-path.data, vs-fullname.data, cred);
+return s-ops-link(s-ctx, oldpath, fullname);
}
static int v9fs_do_truncate(V9fsState *s, V9fsString *path, off_t size)
@@ -1919,7 +1914,7 @@ static void v9fs_create_post_lstat(V9fsState *s,
V9fsCreateState *vs, int err)
err = -errno;
v9fs_post_create(s, vs, err);
}
-err = v9fs_do_link(s, nfidp, vs);
+err = v9fs_do_link(s, nfidp-path.data, vs-fullname.data);
v9fs_create_post_perms(s, vs, err);
} else if (vs-perm P9_STAT_MODE_DEVICE) {
char ctype;
@@ -1999,6 +1994,34 @@ out:
qemu_free(vs);
}
+static void v9fs_link(V9fsState *s, V9fsPDU *pdu)
+{
+int32_t dfid;
+V9fsFidState *dfidp;
+V9fsString name, fullname, oldname;
+size_t offset = 7;
+int err = 0;
+
+v9fs_string_init(fullname);
+
+pdu_unmarshal(pdu, offset, dss, dfid, oldname, name);
+
+dfidp = lookup_fid(s, dfid);
+if (dfidp == NULL) {
+err = -errno;
+goto out;
+}
+
+v9fs_string_sprintf(fullname, %s/%s, dfidp-path.data, name.data);
+err = v9fs_do_link(s, oldname.data, fullname.data);
+v9fs_string_free(fullname);
+
+out:
+v9fs_string_free(name);
+v9fs_string_free(oldname);
+complete_pdu(s, pdu, err);
+}
+
static void v9fs_flush(V9fsState *s, V9fsPDU *pdu)
{
/* A nop call with no return */
@@ -2354,6 +2377,7 @@ static pdu_handler_t *pdu_handlers[] = {
[P9_TAUTH] = v9fs_auth,
#endif
[P9_TFLUSH] = v9fs_flush,
+[P9_TLINK] = v9fs_link,
[P9_TCREATE] = v9fs_create,
[P9_TWRITE] = v9fs_write,
[P9_TWSTAT] = v9fs_wstat,
diff --git a/hw/virtio-9p.h b/hw/virtio-9p.h
index 9773659..6b3d4a4 100644
--- a/hw/virtio-9p.h
+++ b/hw/virtio-9p.h
@@ -17,6 +17,8 @@ enum {
P9_RSTATFS,
P9_TREADDIR = 40,
P9_RREADDIR,
+P9_TLINK = 70,
+P9_RLINK,
P9_TVERSION = 100,
P9_RVERSION,
P9_TAUTH = 102,
--
1.6.5.2
Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
On Sun, May 30, 2010 at 1:49 PM, Gleb Natapov g...@redhat.com wrote: On Sun, May 30, 2010 at 12:56:26PM +, Blue Swirl wrote: Well, I'd like to get the test program also trigger it. Now I'm getting: apic: write: 0350 = apic: apic_reset_irq_delivered: old coalescing 0 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 1 apic: apic_get_irq_delivered: returning coalescing 1 apic: apic_reset_irq_delivered: old coalescing 1 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 0 apic: apic_get_irq_delivered: returning coalescing 0 apic: apic_reset_irq_delivered: old coalescing 0 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 0 So interrupt is _alway_ coalesced. If apic_get_irq_delivered() returns 0 it means the interrupt was not delivered. It looks like some other IRQs cause the coalescing, because also looking at RTC code, it seems it's not possible for RTC to raise the IRQ (except update IRQ, alarm etc.) without calling apic_reset_irq_delivered(). I've attached my test program. Compile: gcc -m32 -o coalescing coalescing.S -ffreestanding -nostdlib -Wl,-T coalescing.ld -g objcopy -Obinary coalescing coalescing.bin Run: qemu -L . -bios coalescing.bin -no-hpet -rtc-td-hack The application does not work for me. Looks like it fails to enter protected mode. $pc jumps from 0xfff0 to 0x000f003e and back. Strange. Here's a working binary. Your binary works here too. What compiler are you using? Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1)
Re: [Qemu-devel] [PULL] pci, vhost fixes
On Sun, May 30, 2010 at 3:50 PM, Michael S. Tsirkin m...@redhat.com wrote: The following changes since commit 259d5577ae546de27e25a40710f81aa031660de8: lsi: Fix value overflow in request tag processing (2010-05-22 15:32:32 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu.git pci Isaku Yamahata (4): pci: clean up of pci_set_default_subsystem_id(). pci: add const to pci_is_express(), pci_config_size(). pci.h: remove unused constants. msix: remove duplicated defines. Michael S. Tsirkin (1): vhost: fix build broken by 0bfcd599e3f5c5679cc7d0165a0a1822e2f60de2 Nack, see 29f91781bd300b228d9c38b9f6c1e0b6a38f25fb.
Re: [Qemu-devel] [PULL] pci, vhost fixes
On Sun, May 30, 2010 at 04:56:11PM +, Blue Swirl wrote: On Sun, May 30, 2010 at 3:50 PM, Michael S. Tsirkin m...@redhat.com wrote: The following changes since commit 259d5577ae546de27e25a40710f81aa031660de8: lsi: Fix value overflow in request tag processing (2010-05-22 15:32:32 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu.git pci Isaku Yamahata (4): pci: clean up of pci_set_default_subsystem_id(). pci: add const to pci_is_express(), pci_config_size(). pci.h: remove unused constants. msix: remove duplicated defines. Michael S. Tsirkin (1): vhost: fix build broken by 0bfcd599e3f5c5679cc7d0165a0a1822e2f60de2 Nack, see 29f91781bd300b228d9c38b9f6c1e0b6a38f25fb. Did you follow the discussion about that patch before applying? 29f91781bd300b228d9c38b9f6c1e0b6a38f25fb does not make sense to me, I think it should be reverted. we have long long value, let us just print with %ll. casting to uint64 and printing with PRi64 is silly. -- MST
Re: [Qemu-devel] [PULL] pci, vhost fixes
On Sun, May 30, 2010 at 6:05 PM, Michael S. Tsirkin m...@redhat.com wrote: On Sun, May 30, 2010 at 04:56:11PM +, Blue Swirl wrote: On Sun, May 30, 2010 at 3:50 PM, Michael S. Tsirkin m...@redhat.com wrote: The following changes since commit 259d5577ae546de27e25a40710f81aa031660de8: lsi: Fix value overflow in request tag processing (2010-05-22 15:32:32 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu.git pci Isaku Yamahata (4): pci: clean up of pci_set_default_subsystem_id(). pci: add const to pci_is_express(), pci_config_size(). pci.h: remove unused constants. msix: remove duplicated defines. Michael S. Tsirkin (1): vhost: fix build broken by 0bfcd599e3f5c5679cc7d0165a0a1822e2f60de2 Nack, see 29f91781bd300b228d9c38b9f6c1e0b6a38f25fb. Did you follow the discussion about that patch before applying? 29f91781bd300b228d9c38b9f6c1e0b6a38f25fb does not make sense to me, I think it should be reverted. we have long long value, let us just print with %ll. casting to uint64 and printing with PRi64 is silly. We have PRI*64 just for this purpose, so let's use them. The discussion about that was earlier.
Re: [Qemu-devel] [PULL] pci, vhost fixes
On Sun, May 30, 2010 at 6:58 PM, Michael S. Tsirkin m...@redhat.com wrote: On Sun, May 30, 2010 at 06:19:40PM +, Blue Swirl wrote: On Sun, May 30, 2010 at 6:05 PM, Michael S. Tsirkin m...@redhat.com wrote: On Sun, May 30, 2010 at 04:56:11PM +, Blue Swirl wrote: On Sun, May 30, 2010 at 3:50 PM, Michael S. Tsirkin m...@redhat.com wrote: The following changes since commit 259d5577ae546de27e25a40710f81aa031660de8: lsi: Fix value overflow in request tag processing (2010-05-22 15:32:32 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu.git pci Isaku Yamahata (4): pci: clean up of pci_set_default_subsystem_id(). pci: add const to pci_is_express(), pci_config_size(). pci.h: remove unused constants. msix: remove duplicated defines. Michael S. Tsirkin (1): vhost: fix build broken by 0bfcd599e3f5c5679cc7d0165a0a1822e2f60de2 Nack, see 29f91781bd300b228d9c38b9f6c1e0b6a38f25fb. Did you follow the discussion about that patch before applying? 29f91781bd300b228d9c38b9f6c1e0b6a38f25fb does not make sense to me, I think it should be reverted. we have long long value, let us just print with %ll. casting to uint64 and printing with PRi64 is silly. We have PRI*64 just for this purpose, so let's use them. The discussion about that was earlier. Ho hum. As long as enough people got annoyed, there was hope that debian will upodate their mingw port. I guess if everyone works around this in code no one'll bother. Oh well, not important enough to care. To make things even more annoying, mingw gcc from Debian stable (4.2.1-sjlj) gives no warnings, the warnings came from the updated compiler (4.4.2) of the future release. So we'll be stuck with the warnings for a looong time. :-(
Re: [Qemu-devel] [PULL] pci, vhost fixes
On Sun, May 30, 2010 at 06:19:40PM +, Blue Swirl wrote: On Sun, May 30, 2010 at 6:05 PM, Michael S. Tsirkin m...@redhat.com wrote: On Sun, May 30, 2010 at 04:56:11PM +, Blue Swirl wrote: On Sun, May 30, 2010 at 3:50 PM, Michael S. Tsirkin m...@redhat.com wrote: The following changes since commit 259d5577ae546de27e25a40710f81aa031660de8: lsi: Fix value overflow in request tag processing (2010-05-22 15:32:32 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu.git pci Isaku Yamahata (4): pci: clean up of pci_set_default_subsystem_id(). pci: add const to pci_is_express(), pci_config_size(). pci.h: remove unused constants. msix: remove duplicated defines. Michael S. Tsirkin (1): vhost: fix build broken by 0bfcd599e3f5c5679cc7d0165a0a1822e2f60de2 Nack, see 29f91781bd300b228d9c38b9f6c1e0b6a38f25fb. Did you follow the discussion about that patch before applying? 29f91781bd300b228d9c38b9f6c1e0b6a38f25fb does not make sense to me, I think it should be reverted. we have long long value, let us just print with %ll. casting to uint64 and printing with PRi64 is silly. We have PRI*64 just for this purpose, so let's use them. The discussion about that was earlier. Ho hum. As long as enough people got annoyed, there was hope that debian will upodate their mingw port. I guess if everyone works around this in code no one'll bother. Oh well, not important enough to care. -- MST
Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
On Sun, May 30, 2010 at 1:49 PM, Gleb Natapov g...@redhat.com wrote: On Sun, May 30, 2010 at 12:56:26PM +, Blue Swirl wrote: Well, I'd like to get the test program also trigger it. Now I'm getting: apic: write: 0350 = apic: apic_reset_irq_delivered: old coalescing 0 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 1 apic: apic_get_irq_delivered: returning coalescing 1 apic: apic_reset_irq_delivered: old coalescing 1 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 0 apic: apic_get_irq_delivered: returning coalescing 0 apic: apic_reset_irq_delivered: old coalescing 0 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 0 So interrupt is _alway_ coalesced. If apic_get_irq_delivered() returns 0 it means the interrupt was not delivered. That seems strange. I changed the program so that the handler gets executed, also output a dot to serial from the handler. I changed the frequency to 2Hz. Now, if I leave out -rtc-td-hack, I get the dots at 2Hz as expected. With -rtc-td-hack, the dots come out much faster. I added DEBUG_COALESCING also to RTC, with that enabled I get: qemu -L . -bios coalescing.bin -d in_asm,int -no-hpet -rtc-td-hack -serial stdio cmos: coalesced irqs scaled to 0 cmos: coalesced irqs increased to 1 cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack ..cmos: injecting from timer .cmos: coalesced irqs increased to 2 cmos: injecting on ack So, there are bogus injections. coalescing.S Description: Binary data coalescing.bin.bz2 Description: BZip2 compressed data
Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
On Sun, May 30, 2010 at 07:37:59PM +, Blue Swirl wrote: On Sun, May 30, 2010 at 1:49 PM, Gleb Natapov g...@redhat.com wrote: On Sun, May 30, 2010 at 12:56:26PM +, Blue Swirl wrote: Well, I'd like to get the test program also trigger it. Now I'm getting: apic: write: 0350 = apic: apic_reset_irq_delivered: old coalescing 0 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 1 apic: apic_get_irq_delivered: returning coalescing 1 apic: apic_reset_irq_delivered: old coalescing 1 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 0 apic: apic_get_irq_delivered: returning coalescing 0 apic: apic_reset_irq_delivered: old coalescing 0 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 0 So interrupt is _alway_ coalesced. If apic_get_irq_delivered() returns 0 it means the interrupt was not delivered. That seems strange. I changed the program so that the handler gets executed, also output a dot to serial from the handler. I changed the frequency to 2Hz. Now, if I leave out -rtc-td-hack, I get the dots at 2Hz as expected. With -rtc-td-hack, the dots come out much faster. I added DEBUG_COALESCING also to RTC, with that enabled I get: qemu -L . -bios coalescing.bin -d in_asm,int -no-hpet -rtc-td-hack -serial stdio cmos: coalesced irqs scaled to 0 cmos: coalesced irqs increased to 1 cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack ..cmos: injecting from timer .cmos: coalesced irqs increased to 2 cmos: injecting on ack So, there are bogus injections. Looks like irr in apic is never cleared. Probably bug in userspace apic emulation. I'll look into it. Try to route interrupt via APIC (not ExtInt), or use qemu-kvm with in kernel irq chip. -- Gleb.
Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
On Sun, May 30, 2010 at 8:07 PM, Gleb Natapov g...@redhat.com wrote: On Sun, May 30, 2010 at 07:37:59PM +, Blue Swirl wrote: On Sun, May 30, 2010 at 1:49 PM, Gleb Natapov g...@redhat.com wrote: On Sun, May 30, 2010 at 12:56:26PM +, Blue Swirl wrote: Well, I'd like to get the test program also trigger it. Now I'm getting: apic: write: 0350 = apic: apic_reset_irq_delivered: old coalescing 0 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 1 apic: apic_get_irq_delivered: returning coalescing 1 apic: apic_reset_irq_delivered: old coalescing 1 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 0 apic: apic_get_irq_delivered: returning coalescing 0 apic: apic_reset_irq_delivered: old coalescing 0 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 0 So interrupt is _alway_ coalesced. If apic_get_irq_delivered() returns 0 it means the interrupt was not delivered. That seems strange. I changed the program so that the handler gets executed, also output a dot to serial from the handler. I changed the frequency to 2Hz. Now, if I leave out -rtc-td-hack, I get the dots at 2Hz as expected. With -rtc-td-hack, the dots come out much faster. I added DEBUG_COALESCING also to RTC, with that enabled I get: qemu -L . -bios coalescing.bin -d in_asm,int -no-hpet -rtc-td-hack -serial stdio cmos: coalesced irqs scaled to 0 cmos: coalesced irqs increased to 1 cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack ..cmos: injecting from timer .cmos: coalesced irqs increased to 2 cmos: injecting on ack So, there are bogus injections. Looks like irr in apic is never cleared. Probably bug in userspace apic emulation. I'll look into it. Try to route interrupt via APIC (not ExtInt), or use qemu-kvm with in kernel irq chip. With APIC you mean Fixed? Then the IRQ is not delivered at all.
[Qemu-devel] [PATCH] sparc32 esp fix spurious interrupts in chip reset
lower interrupt during chip reset. Otherwise the ESP_RSTAT register
may get out of sync with the IRQ line status. This effect became
visible after commit 65899fe3
Signed-off-by: Artyom Tarasenko atar4q...@gmail.com
---
hw/esp.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/hw/esp.c b/hw/esp.c
index 0a8cf6e..0532c67 100644
--- a/hw/esp.c
+++ b/hw/esp.c
@@ -423,6 +423,7 @@ static void esp_reset(DeviceState *d)
{
ESPState *s = container_of(d, ESPState, busdev.qdev);
+esp_lower_irq(s);
memset(s-rregs, 0, ESP_REGS);
memset(s-wregs, 0, ESP_REGS);
s-rregs[ESP_TCHI] = TCHI_FAS100A; // Indicate fas100a
--
1.6.2.5
[Qemu-devel] [PATCH 0/2] Setup scsi-bus xfer and xfer_mode for PR IN/OUT and Maintenance IN/OUT
From: Nicholas Bellinger n...@linux-iscsi.org Greetings Gerd, Kevin and Co, Attached are two patches to add the necesary CDB parsing to determine SCSIRequest-cmd.xfer (length) and SCSIRequest-cmd.mode (direction) for Persistent Reservation IN/OUT CDBs and for Maintenance IN/OUT CDBs used for Asymmetric Logical Unit Access, et al. There is a special case for the latter Maintenance CDBs with TYPE_ROM that has been included in scsi_req_length(). Also, I should mention this is a temporary measure in order to ensure that we can actually do passthrough of these CDBs into KVM Guest for lsi and megaraid HBA emulation. What will need to eventually happen is to get rid of scsi_req_xfer_mode() all together and just setup SCSIRequest-cmd.mode based on CDB type in scsi_req_length(), instead of having to have another switch(cdb[0]) statement for every SCSI WRITE CDB on the planet to set SCSI_XFER_TO_DEV. Anyways, I will look at doing this conversion in scsi_req_length() at some point, but please apply these for the moment so folks can get access to their SPC-4 Port LUNs with QEMU. ;) Best, --nab Nicholas Bellinger (2): [scsi-bus]: Add PR-OUT and PR-IN case for SCSIRequest xfer and xfer_mode setup [scsi-bus]: Add MAINTENANCE_IN and MAINTENANCE_OUT case for SCSIRequest xfer and xfer_mode setup hw/scsi-bus.c | 19 +++ hw/scsi-defs.h |2 ++ 2 files changed, 21 insertions(+), 0 deletions(-)
[Qemu-devel] [PATCH 1/2] [scsi-bus]: Add PR-OUT and PR-IN case for SCSIRequest xfer and xfer_mode setup
From: Nicholas Bellinger n...@linux-iscsi.org This patch updates hw/scsi-bus.c to add PERSISTENT_RESERVE_OUT and PERSISTENT_RESERVE_IN case in scsi_req_length() to extra the incoming buffer length into SCSIRequest-cmd.xfer, and adds a second PERSISTENT_RESERVE_OUT case in scsi_req_xfer_mode() in order to properly set SCSI_XFER_TO_DEV for WRITE data. Tested with Linux KVM guests and Megasas 8708EM2 HBA emulation and TCM_Loop target ports. Signed-off-by: Nicholas A. Bellinger n...@linux-iscsi.org --- hw/scsi-bus.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/hw/scsi-bus.c b/hw/scsi-bus.c index b8e4b71..75ec74e 100644 --- a/hw/scsi-bus.c +++ b/hw/scsi-bus.c @@ -325,6 +325,10 @@ static int scsi_req_length(SCSIRequest *req, uint8_t *cmd) case INQUIRY: req-cmd.xfer = cmd[4] | (cmd[3] 8); break; +case PERSISTENT_RESERVE_OUT: +case PERSISTENT_RESERVE_IN: +req-cmd.xfer = cmd[8] | (cmd[7] 8); +break; } return 0; } @@ -389,6 +393,7 @@ static void scsi_req_xfer_mode(SCSIRequest *req) case MEDIUM_SCAN: case SEND_VOLUME_TAG: case WRITE_LONG_2: +case PERSISTENT_RESERVE_OUT: req-cmd.mode = SCSI_XFER_TO_DEV; break; default: -- 1.5.6.5
[Qemu-devel] [PATCH 2/2] [scsi-bus]: Add MAINTENANCE_IN and MAINTENANCE_OUT case for SCSIRequest xfer and xfer_mode setup
From: Nicholas Bellinger n...@linux-iscsi.org
This patch updates hw/scsi-bus.c to add MAINTENANCE_IN and MAINTENANCE_OUT case
in
scsi_req_length() to extra the incoming buffer length into
SCSIRequest-cmd.xfer,
and adds a second MAINTENANCE_OUT case in scsi_req_xfer_mode() in order to
properly
set SCSI_XFER_TO_DEV for WRITE data.
Tested with Linux KVM guests and Megasas 8708EM2 HBA emulation and TCM_Loop
target ports.
Signed-off-by: Nicholas A. Bellinger n...@linux-iscsi.org
---
hw/scsi-bus.c | 14 ++
hw/scsi-defs.h |2 ++
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/hw/scsi-bus.c b/hw/scsi-bus.c
index 75ec74e..7d80405 100644
--- a/hw/scsi-bus.c
+++ b/hw/scsi-bus.c
@@ -329,6 +329,17 @@ static int scsi_req_length(SCSIRequest *req, uint8_t *cmd)
case PERSISTENT_RESERVE_IN:
req-cmd.xfer = cmd[8] | (cmd[7] 8);
break;
+case MAINTENANCE_OUT:
+case MAINTENANCE_IN:
+if (req-dev-type != TYPE_ROM) {
+/* Used for MI_REPORT_TARGET_PGS, MO_SET_TARGET_PGS et al. */
+req-cmd.xfer = cmd[9] | (cmd[8] 8) |
+(cmd[7] 16) | (cmd[6] 24);
+} else {
+/* GPCMD_REPORT_KEY and GPCMD_SEND_KEY from multi media commands */
+req-cmd.xfer = cmd[9] | (cmd[8] 8);
+}
+break;
}
return 0;
}
@@ -394,6 +405,7 @@ static void scsi_req_xfer_mode(SCSIRequest *req)
case SEND_VOLUME_TAG:
case WRITE_LONG_2:
case PERSISTENT_RESERVE_OUT:
+case MAINTENANCE_OUT:
req-cmd.mode = SCSI_XFER_TO_DEV;
break;
default:
@@ -539,6 +551,8 @@ const char *scsi_command_name(uint8_t cmd)
[ SPACE] = SPACE,
[ INQUIRY ] = INQUIRY,
[ RECOVER_BUFFERED_DATA] = RECOVER_BUFFERED_DATA,
+[ MAINTENANCE_IN ] = MAINTENANCE_IN,
+[ MAINTENANCE_OUT ] = MAINTENANCE_OUT,
[ MODE_SELECT ] = MODE_SELECT,
[ RESERVE ] = RESERVE,
[ RELEASE ] = RELEASE,
diff --git a/hw/scsi-defs.h b/hw/scsi-defs.h
index 5890094..a4a3518 100644
--- a/hw/scsi-defs.h
+++ b/hw/scsi-defs.h
@@ -84,6 +84,8 @@
#define MODE_SENSE_10 0x5a
#define PERSISTENT_RESERVE_IN 0x5e
#define PERSISTENT_RESERVE_OUT 0x5f
+#define MAINTENANCE_IN0xa3
+#define MAINTENANCE_OUT 0xa4
#define MOVE_MEDIUM 0xa5
#define READ_12 0xa8
#define WRITE_12 0xaa
--
1.5.6.5
Re: [Qemu-devel] Re: [PATCH v2] pci-hotplug: make them aware of pci domain.
On Sun, May 30, 2010 at 06:48:03PM +0300, Michael S. Tsirkin wrote:
On Fri, May 28, 2010 at 06:30:46PM +0900, Isaku Yamahata wrote:
add helper function which converts root bus to pci domain.
make them aware of pci domain.
Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp
Doesn't seem to apply to master.
Do you mean
master == pci branch
of git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu.git
Here is the version rebased to 4cecb52f3370d9c1a4251eef7c9331253c9f9719
of the branch.
The previous one applies to the change set of
aa6f63fff62faf2fe9ffba5a789675d49293614d in qemu.org main branch
which does include 6c6a58aee425338bf67ec8faffdcda56b0b82090,
but the pci branch doesn't include it.
From 389ec34a80d2630ff4ad3e491328c2e1fb53be6f Mon Sep 17 00:00:00 2001
Message-Id:
389ec34a80d2630ff4ad3e491328c2e1fb53be6f.1275273565.git.yamah...@valinux.co.jp
In-Reply-To: cover.1275273565.git.yamah...@valinux.co.jp
References: cover.1275273565.git.yamah...@valinux.co.jp
From: Isaku Yamahata yamah...@valinux.co.jp
Date: Mon, 31 May 2010 11:32:52 +0900
Subject: [PATCH] pci-hotplug: make them aware of pci domain.
add helper function which converts root bus to pci domain.
make them aware of pci domain.
Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp
---
Changes: V1 - V2
- removed pci_find_bus()
- renamed pci_find_bus_by_bus() to pci_find_bus()
- add abort()
---
hw/pci-hotplug.c |9 +
hw/pci.c | 22 +-
hw/pci.h |1 +
3 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/hw/pci-hotplug.c b/hw/pci-hotplug.c
index cc45c50..9c7161b 100644
--- a/hw/pci-hotplug.c
+++ b/hw/pci-hotplug.c
@@ -125,7 +125,7 @@ void drive_hot_add(Monitor *mon, const QDict *qdict)
if (pci_read_devaddr(mon, pci_addr, dom, pci_bus, slot)) {
goto err;
}
-dev = pci_find_device(pci_find_root_bus(0), pci_bus, slot, 0);
+dev = pci_find_device(pci_find_root_bus(dom), pci_bus, slot, 0);
if (!dev) {
monitor_printf(mon, no pci device with address %s\n, pci_addr);
goto err;
@@ -283,8 +283,9 @@ int pci_device_hot_add(Monitor *mon, const QDict *qdict,
QObject **ret_data)
if (dev) {
*ret_data =
-qobject_from_jsonf({ 'domain': 0, 'bus': %d, 'slot': %d,
- 'function': %d }, pci_bus_num(dev-bus),
+qobject_from_jsonf({ 'domain': %d, 'bus': %d, 'slot': %d,
+ 'function': %d },
+ pci_find_domain(dev-bus), pci_bus_num(dev-bus),
PCI_SLOT(dev-devfn), PCI_FUNC(dev-devfn));
} else {
monitor_printf(mon, failed to add %s\n, opts);
@@ -305,7 +306,7 @@ int pci_device_hot_remove(Monitor *mon, const char
*pci_addr)
return -1;
}
-d = pci_find_device(pci_find_root_bus(0), bus, slot, 0);
+d = pci_find_device(pci_find_root_bus(dom), bus, slot, 0);
if (!d) {
monitor_printf(mon, slot %d empty\n, slot);
return -1;
diff --git a/hw/pci.c b/hw/pci.c
index 3362842..f084cc0 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -200,6 +200,26 @@ PCIBus *pci_find_root_bus(int domain)
return NULL;
}
+int pci_find_domain(const PCIBus *bus)
+{
+PCIDevice *d;
+struct PCIHostBus *host;
+
+/* obtain root bus */
+while ((d = bus-parent_dev) != NULL) {
+bus = d-bus;
+}
+
+QLIST_FOREACH(host, host_buses, next) {
+if (host-bus == bus) {
+return host-domain;
+}
+}
+
+abort();/* should not be reached */
+return -1;
+}
+
void pci_bus_new_inplace(PCIBus *bus, DeviceState *parent,
const char *name, int devfn_min)
{
@@ -505,7 +525,7 @@ PCIBus *pci_get_bus_devfn(int *devfnp, const char *devaddr)
}
*devfnp = slot 3;
-return pci_find_bus(pci_find_root_bus(0), bus);
+return pci_find_bus(pci_find_root_bus(dom), bus);
}
static void pci_init_cmask(PCIDevice *dev)
diff --git a/hw/pci.h b/hw/pci.h
index b803593..3a15bd4 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -218,6 +218,7 @@ PCIDevice *pci_nic_init_nofail(NICInfo *nd, const char
*default_model,
int pci_bus_num(PCIBus *s);
void pci_for_each_device(PCIBus *bus, int bus_num, void (*fn)(PCIBus *bus,
PCIDevice *d));
PCIBus *pci_find_root_bus(int domain);
+int pci_find_domain(const PCIBus *bus);
PCIBus *pci_find_bus(PCIBus *bus, int bus_num);
PCIDevice *pci_find_device(PCIBus *bus, int bus_num, int slot, int function);
PCIBus *pci_get_bus_devfn(int *devfnp, const char *devaddr);
--
1.6.6.1
--
yamahata
[Qemu-devel] What's the meaning and the functionality of the assembly instructions in the beginning of cpu_exec?
I’m working with Qemu source study, but now I have some difficulty in these assembly instructions at the beginning of cpu_exec function. My question as follows: After entering function cpu_exec, there are some assembly codes: register host_reg_t reg_AREG0 asm(ebp); volatile host_reg_t saved_AREG0; register host_reg_t reg_AREG1 asm(ebx); volatile host_reg_t saved_AREG1; register host_reg_t reg_AREG2 asm(esi); volatile host_reg_t saved_AREG2; register host_reg_t reg_AREG3 asm(edi); volatile host_reg_t saved_AREG3; and there is also: __asm__ __volatile__ ( : =r (reg_AREG0)); saved_AREG0 = reg_AREG0; __asm__ __volatile__ ( : =r (reg_AREG1)); saved_AREG1 = reg_AREG1; __asm__ __volatile__ ( : =r (reg_AREG2)); saved_AREG2 = reg_AREG2; __asm__ __volatile__ ( : =r (reg_AREG3)); saved_AREG3 = reg_AREG3; Where are variables: reg_AREG-, saved_AREG- defined and how they are used in the later codes? I really understand these assembly codes’ functionality. Do they use for Qemu virtual register mapping or translating optimization? Could anyone give me some advise, thank. Thank you very much for your help.
Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
On Sun, May 30, 2010 at 08:21:30PM +, Blue Swirl wrote: On Sun, May 30, 2010 at 8:07 PM, Gleb Natapov g...@redhat.com wrote: On Sun, May 30, 2010 at 07:37:59PM +, Blue Swirl wrote: On Sun, May 30, 2010 at 1:49 PM, Gleb Natapov g...@redhat.com wrote: On Sun, May 30, 2010 at 12:56:26PM +, Blue Swirl wrote: Well, I'd like to get the test program also trigger it. Now I'm getting: apic: write: 0350 = apic: apic_reset_irq_delivered: old coalescing 0 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 1 apic: apic_get_irq_delivered: returning coalescing 1 apic: apic_reset_irq_delivered: old coalescing 1 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 0 apic: apic_get_irq_delivered: returning coalescing 0 apic: apic_reset_irq_delivered: old coalescing 0 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 0 So interrupt is _alway_ coalesced. If apic_get_irq_delivered() returns 0 it means the interrupt was not delivered. That seems strange. I changed the program so that the handler gets executed, also output a dot to serial from the handler. I changed the frequency to 2Hz. Now, if I leave out -rtc-td-hack, I get the dots at 2Hz as expected. With -rtc-td-hack, the dots come out much faster. I added DEBUG_COALESCING also to RTC, with that enabled I get: qemu -L . -bios coalescing.bin -d in_asm,int -no-hpet -rtc-td-hack -serial stdio cmos: coalesced irqs scaled to 0 cmos: coalesced irqs increased to 1 cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack ..cmos: injecting from timer .cmos: coalesced irqs increased to 2 cmos: injecting on ack So, there are bogus injections. Looks like irr in apic is never cleared. Probably bug in userspace apic emulation. I'll look into it. Try to route interrupt via APIC (not ExtInt), or use qemu-kvm with in kernel irq chip. With APIC you mean Fixed? Then the IRQ is not delivered at all. You need to deliver it through IOAPIC. -- Gleb.
