Re: [Qemu-devel] [PATCH] makefile: detect corrupted elf files
On Sat, May 25, 2013 at 05:32:24PM +, Blue Swirl wrote: On Wed, May 22, 2013 at 11:35 AM, Michael S. Tsirkin m...@redhat.com wrote: On Wed, May 22, 2013 at 01:12:15PM +0200, Paolo Bonzini wrote: Il 22/05/2013 13:09, Michael S. Tsirkin ha scritto: Usually I do the same---I just do slightly more thorough testing for configure patches. I've no idea what happens with ccache on a crash by the way. It's possible that it's careful to do renames in order to not leave corrupted output files behind. It doesn't, it leave 0-sized files. (Or at least it didn't last time power failed during a compilation. :)) Paolo Well looking at the source, there's quite a bit of handling of renames, so maybe ccache hackers will be interested in fixing this. Manpage says: It should be noted that ccache is susceptible to general storage problems. If a bad object file sneaks into the cache for some reason, it will of course stay bad. Some possible reasons for erroneous object files are bad hardware (disk drive, disk controller, memory, etc), buggy drivers or file systems, a bad CCACHE_PREFIX command or compiler wrapper. ... There are no reported issues about ccache producing broken object files reproducibly. That doesn’t mean it can’t happen, so if you find a repeatable case, please report it. power failure is not listed ... Neither is kill -9 issued by evil BOFH. So presumably ccache will not fill with junk if you do this. IIRC I've also had bad builds and weird errors because the disk was almost completely full (not necessarily due to ccache). Once I overclocked a machine but I had to reduce the speed because of random compile errors. This could be a parallel build, and possibly we have some missing dependencies in the makefile. But I think your patch is way too simple to cover possible failure cases when you can't trust the compile environment. That's not the intent. Merely to address the common failure which I personally observe all the time. Maybe you should build in two separate directories and compare the resulting objects or just the final executables. For added paranoia, build using two machines which have different set of components from different manufacturers, but identical userland. Another way to handle this would be to enhance GCC and linker to use atomic operations when producing or combining object files. The tools could also print a SHA of the object which the next user should verify. Even better, the object files should include a robust checksum to ensure integrity. I think we can make the makefile more robust. It can create a temporary file in same directory and rename when ready. This will prevent corrupted files from appearing in the first place. -- MST
Re: [Qemu-devel] [PATCH v3 2/2] net: introduce command to query rx-filter information
On Fri, May 24, 2013 at 04:00:42PM -0400, Luiz Capitulino wrote: On Fri, 24 May 2013 12:05:12 -0600 Eric Blake ebl...@redhat.com wrote: On 05/24/2013 10:12 AM, Michael S. Tsirkin wrote: Event message contains the net client name, management might only want to query the single net client. The client can do the filtering itself. I'm not sure I buy the responsiveness argument. Sure, the fastest I/O is no I/O, but whether you read and parse 100 bytes or 1000 from a Unix domain socket once in a great while shouldn't make a difference. And the time spent malloc'ing the larger message to send from qemu, as well as the time spent malloc'ing the libvirt side that parses the qemu string into C code for use, and the time spent strcmp'ing every entry to find the right one... It really IS more efficient to filter as low down in the stack as possible, once it is determined that filtering is desirable. Whether filtering makes a difference in performance is a different question - you may be right that always returning the entire list and making libvirt do its own filtering will still not add any more noticeable delay compared to libvirt doing a filtered query, if the bottleneck lies elsewhere (such as libvirt telling macvtap its new configration). My main concern is to keep the external interface simple. I'm rather reluctant to have query commands grow options. In a case where we need the give me everything query anyway, the give me this particular part option is additional complexity. Needs justification, say arguments involving throughput, latency or client complexity. Perhaps cases exist where we never want to ask for everything. Then the give me everything query is useless, and the option should be mandatory. For this _particular_ interface, I'm not sure whether libvirt will ever use an unfiltered query - If having the argument is useful for libvirt, then it's fine to have it. But I'd be very reluctant to buy any performance argument w/o real numbers to back them up. Me too. I think it's more convenience than performance. -- MST
Re: [Qemu-devel] [PATCH] i386/translate: ignore 0x67 (PREFIX_ADR) on TARGET_X86_64 CODE64()
Il 26/05/2013 01:23, Richard Henderson ha scritto:
On 2013-05-24 14:37, Laszlo Ersek wrote:
@@ -4813,7 +4813,11 @@ static target_ulong disas_insn(CPUX86State
*env, DisasContext *s,
/* 0x66 is ignored if rex.w is set */
dflag = 2;
}
-if (!(prefixes PREFIX_ADR)) {
+if (prefixes PREFIX_ADR) {
+/* flip it back, 0x67 should have no effect */
+aflag ^= 1;
+}
+else {
aflag = 2;
}
}
Agreed that there's a bug here. I'm thinking it would be clearer to not
write this as yet another flip, but understand that unlike dflag, aflag
can only be either 1 or 2 in 64-bit mode.
I'm thinking of something more like this:
diff --git a/target-i386/translate.c b/target-i386/translate.c
index 0aeccdb..bf772aa 100644
--- a/target-i386/translate.c
+++ b/target-i386/translate.c
@@ -4813,9 +4813,8 @@ static target_ulong disas_insn(CPUX86State *env,
DisasContext *s,
/* 0x66 is ignored if rex.w is set */
dflag = 2;
}
-if (!(prefixes PREFIX_ADR)) {
-aflag = 2;
-}
+/* 0x67 toggles between 64-bit and 32-bit addressing. */
+aflag = (prefixes PREFIX_ADR ? 1 : 2);
Isn't that just aflag++? Needs a comment of course (toggle between
32- and 64-bit, not 16- and 32-bit.).
Paolo
Re: [Qemu-devel] [PATCH 17/30] memory: add address_space_translate
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 25/05/2013 13:30, Jan Kiszka ha scritto: On 2013-05-25 13:20, Paolo Bonzini wrote: Il 25/05/2013 12:19, Jan Kiszka ha scritto: addr -= section-offset_within_address_space; -len = MIN(section-size - addr, len); ^ This is the size of a section minus an offset in the section. +diff = int128_sub(section-mr-size, int128_make64(addr)); ^ This is the size of a region minus the same offset in the section. +len = MIN(int128_get64(diff), len); /* Compute offset within MemoryRegion */ addr += section-offset_within_region; So this has to be moved above. Right, fixed. Do you have a branch pushed somewhere that I can test against? git://git.kiszka.org/qemu.git queues/ioport Nice patches. Only one thing, how is .impl.unaligned different from the existing .valid.unaligned? Paolo -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRoc4vAAoJEBvWZb6bTYby7UEP/0l5Stow6nrKirryCNuds3ky L3FTjqEhLZ+aKha4rdbYNKhwbvY92rfR/Wo8hMckkFv6wwcieHD+nYQltuIDW3y2 xV7FmCPJd1M1pajIQ5Nk+Ssqf7Qhv7jRX5Kg2L6ksNf5srb5485J9oH4M9hIO6CH XFHO9GeKmynbeeZmSNFF9mNlQd0leHx6h6IbJxYov/eD0zxp5cxoN7xM6+V5hCP/ UjBa2Zn07AI94BS/64YSHSa155BLxIOS5jJi25PNOWti29wHE8Nhw2KF5pMD/JYM hPblsTIpFf6zg53FMHmrY/B990Ol+IjNogQhRh3tSfNf/48XWA4l+anLdaMweQf6 TuCEOoDqgNphz6c5lOPjzQB/CJZFUCQzxaUjok499ZQyPY5SpIgjKmzl7Vszos8I wnYmJJ3xVLyJujvx61rg7qiW3ckyVx0sPHZXt/DWEDUNDHTW+HdqAcrZ8TgJrIni gQF1VEKNplxdgauIv17RGxnVOXwb8PcoNwXE9Gn6XJ/KKQLh9KukmdufCSBmOARV iiAo8N4rUK8FaCFXDwrZ3S8OIiyWCSdnud/4wZPcsI+r5gM/rrtlrZoQExyx5meO 9RzLBtL5hwFaQ9erE8ce+GDKbo+nie593z3UiN5NKLuH5KjWig2OYQxV6ylg4Vx7 RscCNjGvppk+2I3PAv9R =pCeD -END PGP SIGNATURE-
Re: [Qemu-devel] Potential to accelerate QEMU for specific architectures
Am 26.05.2013 07:40, schrieb Lior Vernia: On Sat, May 25, 2013 at 10:06 PM, Andreas Färber afaer...@suse.de wrote: Am 24.05.2013 21:24, schrieb Lior Vernia: I am running x86 applications on an ARM device using QEMU, and found it too slow for my needs. Before we start going into technical details, what are you trying to achieve on a high level and how did you try to do it? Are you using qemu-system-x86_64 or qemu-x86_64? The latest v1.5.0? Sorry, right after I wrote the message it occured to me I should have mentioned that I was talking about qemu-system, either x86 or i386. At the moment I just ran the limbo app on a Galaxy SIII with various images, just to see the capabilities, and was disappointed. Limbo seems to run v1.1.0. First time I hear of that app... v1.1.0 is a year old, many TCG improvements have happened since. Suggest you contact the app's author to get that updated to v1.5.0. http://git.qemu.org/?p=qemu.git;a=history;f=tcg/arm;hb=HEAD If you suspect that it's the JNI wrapping that's causing a lot of the damage, The UI (drawing) code could also be a potential bottleneck - but judging from the files it looks as if the UI were just a Java VNC client, which probably accesses a JNI-unaffected QEMU process? http://code.google.com/p/limbo-android/source/browse/#git%2Fsrc then we can talk about compiling QEMU for ARM and running it natively, I just haven't been able to get that to work. That would take some of the uncertainties out of the equation, yes. You still haven't said what it is that you would like to do with system emulation on your ARM device: Does it need to be x86? If you just want access to a full Linux system from Android, you might be more interested in investigating qemu-system-arm with KVM acceleration (requires Cortex-A15 and 3.9+ kernel) - in practice virtualization will be faster than anything binary translation can offer. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH 17/30] memory: add address_space_translate
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 25/05/2013 13:30, Jan Kiszka ha scritto: On 2013-05-25 13:20, Paolo Bonzini wrote: Il 25/05/2013 12:19, Jan Kiszka ha scritto: addr -= section-offset_within_address_space; -len = MIN(section-size - addr, len); ^ This is the size of a section minus an offset in the section. +diff = int128_sub(section-mr-size, int128_make64(addr)); ^ This is the size of a region minus the same offset in the section. +len = MIN(int128_get64(diff), len); /* Compute offset within MemoryRegion */ addr += section-offset_within_region; So this has to be moved above. Right, fixed. Do you have a branch pushed somewhere that I can test against? git://git.kiszka.org/qemu.git queues/ioport And another thing... in ioport: Switch dispatching to memory core layer, could you put memory_region_iorange_read/write in mr-ops-read/write instead of adding an if in the dispatch routines? Paolo -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRoc9MAAoJEBvWZb6bTYbya6IP/Rso0r/qUrRttOZYyC0GX1IL xBXZEyCDrbV49pQw9O85Lpb2BRzbUOy38RZ/gvrUfGzg9iYo+88nxoA4qiTXSKil IBxC/Nu5QCcV01zTWLE7dsjAGVVP6td2UWqtI/41T7H1OmhmN9BR2hD0hHhDT6aO f1KAhzkrdD2aOJHCyWjtehriZFH+J638QuAem8zMIC6kFGOBm475iYBI5l4haXaN k2Rx66EaOuJRFzZVscHnTw3Ohrk2QZEe8EpBScQIf3hxAlDv4wPDzXYjADUmCGhH u5dHXSDMgD3+ll5/XLAq3dX/lZPn6nJCzAqV2DPboAxhjpe5+gt0i50r91Di8T+3 Rn8ycEi5hy7Pck++ijwTDs4JGU1vGvT6xpnCmsTwiU3Tw5Yd8lNEQJyOQAMsdsrH GX+Tsqiowoq8LKVACHSOHouffUB4TM5XdUN0dPGKdohPGyDSlRlkE58mFPeBmMRT SIhaCPkykpRguNFnkxx5iLl66yUsi5Jb0qeXslffKKx6wCr6N5d3jOeb2jqjG/LT AAlQ4U5GdKbKU6rDWmcB8GeV2HZh9+ivIUwC4Q4+s+inlaXXh5V4hnNKQ8aHc2MX wBfq07Zit8bbCUvB+tYf+ORAWHUV1BFWjFRkE4sZ08ouCs45TN7Ug67334GyPvxe K5Zz+3M9ZKkvnK4kNINg =71ln -END PGP SIGNATURE-
Re: [Qemu-devel] [PATCH 17/30] memory: add address_space_translate
On 2013-05-26 10:56, Paolo Bonzini wrote: Il 25/05/2013 13:30, Jan Kiszka ha scritto: On 2013-05-25 13:20, Paolo Bonzini wrote: Il 25/05/2013 12:19, Jan Kiszka ha scritto: addr -= section-offset_within_address_space; -len = MIN(section-size - addr, len); ^ This is the size of a section minus an offset in the section. +diff = int128_sub(section-mr-size, int128_make64(addr)); ^ This is the size of a region minus the same offset in the section. +len = MIN(int128_get64(diff), len); /* Compute offset within MemoryRegion */ addr += section-offset_within_region; So this has to be moved above. Right, fixed. Do you have a branch pushed somewhere that I can test against? git://git.kiszka.org/qemu.git queues/ioport Nice patches. Only one thing, how is .impl.unaligned different from the existing .valid.unaligned? See memory.h: valid controls is an unaligned access traps or gets processed, impl manages if it is passed as-is to the device or broken up and aligned first. Jan signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 17/30] memory: add address_space_translate
On 2013-05-26 11:01, Paolo Bonzini wrote: Il 25/05/2013 13:30, Jan Kiszka ha scritto: On 2013-05-25 13:20, Paolo Bonzini wrote: Il 25/05/2013 12:19, Jan Kiszka ha scritto: addr -= section-offset_within_address_space; -len = MIN(section-size - addr, len); ^ This is the size of a section minus an offset in the section. +diff = int128_sub(section-mr-size, int128_make64(addr)); ^ This is the size of a region minus the same offset in the section. +len = MIN(int128_get64(diff), len); /* Compute offset within MemoryRegion */ addr += section-offset_within_region; So this has to be moved above. Right, fixed. Do you have a branch pushed somewhere that I can test against? git://git.kiszka.org/qemu.git queues/ioport And another thing... in ioport: Switch dispatching to memory core layer, could you put memory_region_iorange_read/write in mr-ops-read/write instead of adding an if in the dispatch routines? Not trivially because mr-opaque is passed to the read/write handler, but memory_region_iorange_read/write needs the region. Can add more data structures to handles this, but what does it buy us? Jan signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH] makefile: detect corrupted elf files
On 26 May 2013 08:35, Michael S. Tsirkin m...@redhat.com wrote: On Sat, May 25, 2013 at 05:32:24PM +, Blue Swirl wrote: Another way to handle this would be to enhance GCC and linker to use atomic operations when producing or combining object files. The tools could also print a SHA of the object which the next user should verify. Even better, the object files should include a robust checksum to ensure integrity. I think we can make the makefile more robust. It can create a temporary file in same directory and rename when ready. This will prevent corrupted files from appearing in the first place. I definitely think individual project makefiles are the wrong place to fix this. If create-as-temp-and-rename is useful functionality it needs to go in the compiler so that everybody benefits. Or you could write yourself a cc wrapper that did the renaming and use configure's --cc= flag. thanks -- PMM
Re: [Qemu-devel] Potential to accelerate QEMU for specific architectures
On 26 May 2013 06:40, Lior Vernia liorv...@gmail.com wrote: Sorry, right after I wrote the message it occured to me I should have mentioned that I was talking about qemu-system, either x86 or i386. At the moment I just ran the limbo app on a Galaxy SIII with various images, just to see the capabilities, and was disappointed. Limbo seems to run v1.1.0. I wanted to add that I've been reading about this Russian startup that's looking to emulate x86 on ARM at 40% of native speed using dynamic binary translation (as far as I gather): http://www.bit-tech.net/news/hardware/2012/10/04/x86-on-arm/1 So this should be possible. And it can't be very much unlike QEMU, can it? That article suggests they're doing application-level translation, not system-level emulation. If you: * design your emulation from scratch with that use case in mind (qemu is system emulation first with app-level as a secondary case) * are happy to have just one guest and one target architecture (this is actually mostly useful in that it reduces the set of things you have to test; it also lets you take shortcuts in corner cases for your initial implementation) * put more concentrated effort into emulation performance than QEMU then you should be able to do better than qemu does currently. You'd probably end up with something like Transitive's QuickTransit/ Rosetta. thanks -- PMM
Re: [Qemu-devel] Potential to accelerate QEMU for specific architectures
On Sun, May 26, 2013 at 10:26:04AM +0100, Peter Maydell wrote: On 26 May 2013 06:40, Lior Vernia liorv...@gmail.com wrote: Sorry, right after I wrote the message it occured to me I should have mentioned that I was talking about qemu-system, either x86 or i386. At the moment I just ran the limbo app on a Galaxy SIII with various images, just to see the capabilities, and was disappointed. Limbo seems to run v1.1.0. I wanted to add that I've been reading about this Russian startup that's looking to emulate x86 on ARM at 40% of native speed using dynamic binary translation (as far as I gather): http://www.bit-tech.net/news/hardware/2012/10/04/x86-on-arm/1 So this should be possible. And it can't be very much unlike QEMU, can it? That article suggests they're doing application-level translation, not system-level emulation. If you: * design your emulation from scratch with that use case in mind (qemu is system emulation first with app-level as a secondary case) * are happy to have just one guest and one target architecture (this is actually mostly useful in that it reduces the set of things you have to test; it also lets you take shortcuts in corner cases for your initial implementation) * put more concentrated effort into emulation performance than QEMU then you should be able to do better than qemu does currently. You'd probably end up with something like Transitive's QuickTransit/ Rosetta. Actually here is an example of Starcraft running in android on ARM in full speed: http://forum.xda-developers.com/showthread.php?p=39009939 Search more about winulator. -- Gleb.
Re: [Qemu-devel] Potential to accelerate QEMU for specific architectures
On 26 May 2013 10:58, Gleb Natapov g...@redhat.com wrote: Actually here is an example of Starcraft running in android on ARM in full speed: http://forum.xda-developers.com/showthread.php?p=39009939 Search more about winulator. Yes; that seems to also be taking the path of going specifically for application level emulation (of Windows apps in this case) with one supported guest/target combination. -- PMM
[Qemu-devel] make check breakage on 32 bit hosts
I get this on i386 chroot for make check: GTESTER tests/test-qmp-output-visitor ** ERROR:/src/qemu/tests/test-qmp-output-visitor.c:595:check_native_list: assertion failed: (tmp) GTester: last random seed: R02S559792e7c8d0762d9a2ee153fba8896c ** ERROR:/src/qemu/tests/test-qmp-output-visitor.c:595:check_native_list: assertion failed: (tmp) GTester: last random seed: R02S525fa86060d45f6d4299653ffb5dd904 ** ERROR:/src/qemu/tests/test-qmp-output-visitor.c:595:check_native_list: assertion failed: (tmp) GTester: last random seed: R02S7ae707c4805ddbba77d7d41893ebf867 ** ERROR:/src/qemu/tests/test-qmp-output-visitor.c:633:check_native_list: assertion failed: (tmp) GTester: last random seed: R02S38f6b432c1499bbd11f431efcf631a46 The same happens on an ARM host: GTESTER tests/test-qmp-output-visitor ** ERROR:/src/qemu/tests/test-qmp-output-visitor.c:595:check_native_list: assertion failed: (tmp) GTester: last random seed: R02Sb86519e4b02345f084b2b23eb7deb24b ** ERROR:/src/qemu/tests/test-qmp-output-visitor.c:595:check_native_list: assertion failed: (tmp) GTester: last random seed: R02S5207cd8bf70d0fd158dd531ad3b3b127 ** ERROR:/src/qemu/tests/test-qmp-output-visitor.c:595:check_native_list: assertion failed: (tmp) GTester: last random seed: R02S1805df984bcb85d0f11bc0d66e94630e ** ERROR:/src/qemu/tests/test-qmp-output-visitor.c:633:check_native_list: assertion failed: (tmp) GTester: last random seed: R02S9a6b4dd63a8e370a262925d5b130a79b
Re: [Qemu-devel] [PATCH] makefile: detect corrupted elf files
On Sun, May 26, 2013 at 10:12:21AM +0100, Peter Maydell wrote: On 26 May 2013 08:35, Michael S. Tsirkin m...@redhat.com wrote: On Sat, May 25, 2013 at 05:32:24PM +, Blue Swirl wrote: Another way to handle this would be to enhance GCC and linker to use atomic operations when producing or combining object files. The tools could also print a SHA of the object which the next user should verify. Even better, the object files should include a robust checksum to ensure integrity. I think we can make the makefile more robust. It can create a temporary file in same directory and rename when ready. This will prevent corrupted files from appearing in the first place. I definitely think individual project makefiles are the wrong place to fix this. If create-as-temp-and-rename is useful functionality it needs to go in the compiler so that everybody benefits. This will not help users on existing systems. Also it's not just compiler. We'd have to do it in linker, asm, ... lots of work. You are wellcome to implement this in compiler/linker/etc if you like but we will still want to handle it in our makefile as well. Or you could write yourself a cc wrapper that did the renaming and use configure's --cc= flag. thanks -- PMM We also run lots of scripts in our makefiles. Would you like to also change each of them individually? Add wrapper scripts for e.g. python? What's the benefit as compared to just fixing it all in one place in the makefile? -- MST
Re: [Qemu-devel] [PATCH] makefile: detect corrupted elf files
Am 26.05.2013 14:31, schrieb Michael S. Tsirkin: On Sun, May 26, 2013 at 10:12:21AM +0100, Peter Maydell wrote: On 26 May 2013 08:35, Michael S. Tsirkin m...@redhat.com wrote: On Sat, May 25, 2013 at 05:32:24PM +, Blue Swirl wrote: Another way to handle this would be to enhance GCC and linker to use atomic operations when producing or combining object files. The tools could also print a SHA of the object which the next user should verify. Even better, the object files should include a robust checksum to ensure integrity. I think we can make the makefile more robust. It can create a temporary file in same directory and rename when ready. This will prevent corrupted files from appearing in the first place. I definitely think individual project makefiles are the wrong place to fix this. If create-as-temp-and-rename is useful functionality it needs to go in the compiler so that everybody benefits. This will not help users on existing systems. Also it's not just compiler. We'd have to do it in linker, asm, ... lots of work. You are wellcome to implement this in compiler/linker/etc if you like but we will still want to handle it in our makefile as well. Or you could write yourself a cc wrapper that did the renaming and use configure's --cc= flag. thanks -- PMM We also run lots of scripts in our makefiles. Would you like to also change each of them individually? Add wrapper scripts for e.g. python? What's the benefit as compared to just fixing it all in one place in the makefile? GNU make automatically removes .o files which were built because of a Makefile rule if that rule returns an error, so OOM or compiler crashes should not result in corrupted .o files. The same applies to other kinds of files built by make. If there are corrupted files, we have to look whether the Makefile rules for those files are correct (or exist at all). Are there other Open Source projects which try to detect corrupted elf files? I know none. Regards Stefan W.
Re: [Qemu-devel] [PATCH 15/30] memory: add address_space_valid
On Sat, May 25, 2013 at 10:23:32AM +0100, Peter Maydell wrote: On 25 May 2013 04:44, David Gibson da...@gibson.dropbear.id.au wrote: On Fri, May 24, 2013 at 11:52:17AM +0100, Peter Maydell wrote: So when *is* it a good idea to use this API? In real hardware you don't usually get a tell me whether this access would succeed if I did it bus operation -- you just do the operation and the memory transaction either succeeds or it doesn't. Are we modelling something that really exists in hardware on spapr here? So, as a general rule, you should just attempt the access and handle failures - this is a bad interface. The reason I added it, however, is that the PAPR specification mandates that the virtual LAN pre-check various buffers when they're registered, and return specific errors if they're not mapped to valid memory. Since we have nothing to read or write at that point, adding this interface was the only way I could see to implement that requirement. Would it work to just read and throw away the result of the read? Not when checking for writability. Or... a bit more charitably: You should always handle failures at the point of read or write, but using this interface can give you an earlier, and therefore potentially easier to analyze, error in the more common failure cases, even if there are more complex cases where the pre-check succeeds but the read/write still fails later. There's also the converse case where the pre-check fails but doing the operation at the proper time would succeed, in which case where we're modelling real hardware we would be doing it wrong. So the set of cases where it's OK to pre-check seems a bit limited. Whether originally real or otherwise, this is a question of faithfully implementing what the hardware is supposed to do. In the case of the PAPR llan, the (virtual) hardware specification says that the buffer accessibility is checked at buffer add time, and the driver won't work if it only makes the buffers accessible between that point and the actual buffer access. It would be entirely possible to design real hardware with similar behaviour (probe buffer accessibility when a descriptor is added to a pool, say), although it's not the sort of thing hardware people generally do. So, certainly qemu should not go using this pre-check when the hardware it's emulating does not do such a check. Designing hardware that does do a pre-check is not, IMO, a good idea on balance, but the point is that there is a reason (albeit, not a great one) you might want to design the (possibly virtual) hardware that way. As an aside, when you consider devices with embedded firmware - which is practically everything these days - the distinction between real hardware and virtual hardware can get kind of blurry. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: Digital signature
Re: [Qemu-devel] [RFC PATCH 1/2] mem: make phys_section and phys_map_nodes prepared for RCU
[...]
+static PhysPageTable *cur_pgtbl;
+static PhysPageTable *next_pgtbl;
You shouldn't need cur_pgtbl. Instead, each AddressSpaceDispatch should
have a pointer to its own cur_pgtbl. In the commit hook you can then
take a lock, unref the old table, assign cur_pgtbl = next_pgtbl and ref
the new one.
Here is a trick. All AddressSpaceDispatch will update its radix tree
at the same time, so the re-claimer will come after all of them commit
to drop the old phys_map_node[] which holds the radix trees all at
once. Is it OK? Or you still prefer each AddressSpaceDispatch has its
own space for radix tree?
I'm not sure... I prefer to have more stuff in AddressSpaceDispatch to
make things as streamlined as possible on the read side.
When I try to make each AddressSpaceDispatch own a separate radix
tree, I found in subpage_read/write(), we need to retrieve
phys_sections for this subpage, ie,
section = phys_sections[mmio-sub_section[idx]]; will be changed to
section = subpage-as_dispatch-phys_sections[mmio-sub_section[idx]];
It will sacrifice performance. Is it acceptable?
Regards,
Pingfan
The lock must also be taken in address_space_translate, together with a
relatively expensive ref/unref pair (two atomic operations). We
probably need real RCU so that we can skip the ref/unref.
Currently, without RCU, do we rely on as-lock? So no need ref/unref
on cur_pgtbl? With RCU, I think we need ref/unref on mr, since
mr-ops-read/write can block, and should be excluded from RCU
section.
Yes, we need ref/unref on the region, but in many cases that will be a
no-op (most important, for access to system RAM). And if we can do the
dispatch in the RCU section, similar to what I proposed in reviewing
your patch 2, we have no ref/unref in the common case of accessing RAM.
#define PHYS_MAP_NODE_NIL (((uint16_t)~0) 1)
@@ -111,13 +122,13 @@ static MemoryRegion io_mem_watch;
static void phys_map_node_reserve(unsigned nodes)
{
-if (phys_map_nodes_nb + nodes phys_map_nodes_nb_alloc) {
+if (next_pgtbl-phys_map_nodes_nb + nodes
next_pgtbl-phys_map_nodes_nb_alloc) {
typedef PhysPageEntry Node[L2_SIZE];
-phys_map_nodes_nb_alloc = MAX(phys_map_nodes_nb_alloc * 2, 16);
-phys_map_nodes_nb_alloc = MAX(phys_map_nodes_nb_alloc,
- phys_map_nodes_nb + nodes);
-phys_map_nodes = g_renew(Node, phys_map_nodes,
- phys_map_nodes_nb_alloc);
+next_pgtbl-phys_map_nodes_nb_alloc =
MAX(next_pgtbl-phys_map_nodes_nb_alloc * 2, 16);
+next_pgtbl-phys_map_nodes_nb_alloc =
MAX(next_pgtbl-phys_map_nodes_nb_alloc,
+ next_pgtbl-phys_map_nodes_nb +
nodes);
+next_pgtbl-phys_map_nodes = g_renew(Node,
next_pgtbl-phys_map_nodes,
+ next_pgtbl-phys_map_nodes_nb_alloc);
}
}
@@ -126,22 +137,16 @@ static uint16_t phys_map_node_alloc(void)
unsigned i;
uint16_t ret;
-ret = phys_map_nodes_nb++;
+ret = next_pgtbl-phys_map_nodes_nb++;
assert(ret != PHYS_MAP_NODE_NIL);
-assert(ret != phys_map_nodes_nb_alloc);
+assert(ret != next_pgtbl-phys_map_nodes_nb_alloc);
for (i = 0; i L2_SIZE; ++i) {
-phys_map_nodes[ret][i].is_leaf = 0;
-phys_map_nodes[ret][i].ptr = PHYS_MAP_NODE_NIL;
+next_pgtbl-phys_map_nodes[ret][i].is_leaf = 0;
+next_pgtbl-phys_map_nodes[ret][i].ptr = PHYS_MAP_NODE_NIL;
}
return ret;
}
-static void phys_map_nodes_reset(void)
-{
-phys_map_nodes_nb = 0;
-}
-
-
static void phys_page_set_level(PhysPageEntry *lp, hwaddr *index,
hwaddr *nb, uint16_t leaf,
int level)
@@ -152,15 +157,15 @@ static void phys_page_set_level(PhysPageEntry *lp,
hwaddr *index,
if (!lp-is_leaf lp-ptr == PHYS_MAP_NODE_NIL) {
lp-ptr = phys_map_node_alloc();
-p = phys_map_nodes[lp-ptr];
+p = next_pgtbl-phys_map_nodes[lp-ptr];
if (level == 0) {
for (i = 0; i L2_SIZE; i++) {
p[i].is_leaf = 1;
-p[i].ptr = phys_section_unassigned;
+p[i].ptr = next_pgtbl-phys_section_unassigned;
}
}
} else {
-p = phys_map_nodes[lp-ptr];
+p = next_pgtbl-phys_map_nodes[lp-ptr];
}
lp = p[(*index (level * L2_BITS)) (L2_SIZE - 1)];
@@ -192,11 +197,13 @@ static PhysSection
*phys_section_find(AddressSpaceDispatch *d,
{
PhysPageEntry lp = d-phys_map;
PhysPageEntry *p;
+PhysSection *phys_sections = cur_pgtbl-phys_sections;
+Node *phys_map_nodes = cur_pgtbl-phys_map_nodes;
int i;
for (i = P_L2_LEVELS - 1; i = 0 !lp.is_leaf; i--) {
if (lp.ptr == PHYS_MAP_NODE_NIL) {
-return phys_sections[phys_section_unassigned];
+return
Re: [Qemu-devel] [PATCH] makefile: detect corrupted elf files
On Sun, May 26, 2013 at 02:48:11PM +0200, Stefan Weil wrote: Am 26.05.2013 14:31, schrieb Michael S. Tsirkin: On Sun, May 26, 2013 at 10:12:21AM +0100, Peter Maydell wrote: On 26 May 2013 08:35, Michael S. Tsirkin m...@redhat.com wrote: On Sat, May 25, 2013 at 05:32:24PM +, Blue Swirl wrote: Another way to handle this would be to enhance GCC and linker to use atomic operations when producing or combining object files. The tools could also print a SHA of the object which the next user should verify. Even better, the object files should include a robust checksum to ensure integrity. I think we can make the makefile more robust. It can create a temporary file in same directory and rename when ready. This will prevent corrupted files from appearing in the first place. I definitely think individual project makefiles are the wrong place to fix this. If create-as-temp-and-rename is useful functionality it needs to go in the compiler so that everybody benefits. This will not help users on existing systems. Also it's not just compiler. We'd have to do it in linker, asm, ... lots of work. You are wellcome to implement this in compiler/linker/etc if you like but we will still want to handle it in our makefile as well. Or you could write yourself a cc wrapper that did the renaming and use configure's --cc= flag. thanks -- PMM We also run lots of scripts in our makefiles. Would you like to also change each of them individually? Add wrapper scripts for e.g. python? What's the benefit as compared to just fixing it all in one place in the makefile? GNU make automatically removes .o files which were built because of a Makefile rule if that rule returns an error, so OOM or compiler crashes should not result in corrupted .o files. Not if make itself is killed. The same applies to other kinds of files built by make. Another problem is power failures and other cases of sudden reboot. If there are corrupted files, we have to look whether the Makefile rules for those files are correct (or exist at all). Are there other Open Source projects which try to detect corrupted elf files? I know none. Regards Stefan W. It saves me time, at least. I can keep it out of tree if it rubs others the wrong way for some reason, it's no big deal. If I have some spare time I might code up the more generic thing with create then rename for all files, if I do we can discuss that. -- MST
[Qemu-devel] [PATCH stable-1.1] qga: set umask 0077 when daemonizing (CVE-2013-2007)
From: Laszlo Ersek ler...@redhat.com
The qemu guest agent creates a bunch of files with insecure permissions
when started in daemon mode. For example:
-rw-rw-rw- 1 root root /var/log/qemu-ga.log
-rw-rw-rw- 1 root root /var/run/qga.state
-rw-rw-rw- 1 root root /var/log/qga-fsfreeze-hook.log
In addition, at least all files created with the guest-file-open QMP
command, and all files created with shell output redirection (or
otherwise) by utilities invoked by the fsfreeze hook script are affected.
For now mask all file mode bits for group and others in
become_daemon().
Temporarily, for compatibility reasons, stick with the 0666 file-mode in
case of files newly created by the guest-file-open QMP call. Do so
without changing the umask temporarily.
Signed-off-by: Laszlo Ersek ler...@redhat.com
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
(cherry picked from commit c689b4f1bac352dcfd6ecb9a1d45337de0f1de67)
[AF: Use error_set() instead of error_setg*()]
Signed-off-by: Andreas Färber afaer...@suse.de
---
qemu-ga.c| 2 +-
qga/commands-posix.c | 117 +--
2 files changed, 115 insertions(+), 4 deletions(-)
diff --git a/qemu-ga.c b/qemu-ga.c
index 1b00c2f..086b1b9 100644
--- a/qemu-ga.c
+++ b/qemu-ga.c
@@ -424,7 +424,7 @@ static void become_daemon(const char *pidfile)
}
}
-umask(0);
+umask(S_IRWXG | S_IRWXO);
sid = setsid();
if (sid 0) {
goto fail;
diff --git a/qga/commands-posix.c b/qga/commands-posix.c
index 00d035d..c0a1bd4 100644
--- a/qga/commands-posix.c
+++ b/qga/commands-posix.c
@@ -15,6 +15,9 @@
#include sys/types.h
#include sys/ioctl.h
#include sys/wait.h
+#include stdio.h
+#include string.h
+#include sys/stat.h
#include qga/guest-agent-core.h
#include qga-qmp-commands.h
#include qerror.h
@@ -122,9 +125,117 @@ static GuestFileHandle *guest_file_handle_find(int64_t id)
return NULL;
}
+typedef const char * const ccpc;
+
+/* http://pubs.opengroup.org/onlinepubs/9699919799/functions/fopen.html */
+static const struct {
+ccpc *forms;
+int oflag_base;
+} guest_file_open_modes[] = {
+{ (ccpc[]){ r, rb, NULL }, O_RDONLY },
+{ (ccpc[]){ w, wb, NULL }, O_WRONLY | O_CREAT | O_TRUNC },
+{ (ccpc[]){ a, ab, NULL }, O_WRONLY | O_CREAT | O_APPEND },
+{ (ccpc[]){ r+, rb+, r+b, NULL }, O_RDWR},
+{ (ccpc[]){ w+, wb+, w+b, NULL }, O_RDWR | O_CREAT | O_TRUNC },
+{ (ccpc[]){ a+, ab+, a+b, NULL }, O_RDWR | O_CREAT | O_APPEND }
+};
+
+static int
+find_open_flag(const char *mode_str, Error **err)
+{
+unsigned mode;
+
+for (mode = 0; mode ARRAY_SIZE(guest_file_open_modes); ++mode) {
+ccpc *form;
+
+form = guest_file_open_modes[mode].forms;
+while (*form != NULL strcmp(*form, mode_str) != 0) {
+++form;
+}
+if (*form != NULL) {
+break;
+}
+}
+
+if (mode == ARRAY_SIZE(guest_file_open_modes)) {
+error_set(err, QERR_UNSUPPORTED);
+return -1;
+}
+return guest_file_open_modes[mode].oflag_base | O_NOCTTY | O_NONBLOCK;
+}
+
+#define DEFAULT_NEW_FILE_MODE (S_IRUSR | S_IWUSR | \
+ S_IRGRP | S_IWGRP | \
+ S_IROTH | S_IWOTH)
+
+static FILE *
+safe_open_or_create(const char *path, const char *mode, Error **err)
+{
+Error *local_err = NULL;
+int oflag;
+
+oflag = find_open_flag(mode, local_err);
+if (local_err == NULL) {
+int fd;
+
+/* If the caller wants / allows creation of a new file, we implement it
+ * with a two step process: open() + (open() / fchmod()).
+ *
+ * First we insist on creating the file exclusively as a new file. If
+ * that succeeds, we're free to set any file-mode bits on it. (The
+ * motivation is that we want to set those file-mode bits independently
+ * of the current umask.)
+ *
+ * If the exclusive creation fails because the file already exists
+ * (EEXIST is not possible for any other reason), we just attempt to
+ * open the file, but in this case we won't be allowed to change the
+ * file-mode bits on the preexistent file.
+ *
+ * The pathname should never disappear between the two open()s in
+ * practice. If it happens, then someone very likely tried to race us.
+ * In this case just go ahead and report the ENOENT from the second
+ * open() to the caller.
+ *
+ * If the caller wants to open a preexistent file, then the first
+ * open() is decisive and its third argument is ignored, and the second
+ * open() and the fchmod() are never called.
+ */
+fd = open(path, oflag | ((oflag O_CREAT) ? O_EXCL : 0), 0);
+if (fd == -1 errno == EEXIST) {
+oflag = ~(unsigned)O_CREAT;
+
Re: [Qemu-devel] [PATCH] makefile: detect corrupted elf files
On 26 May 2013 13:31, Michael S. Tsirkin m...@redhat.com wrote: On Sun, May 26, 2013 at 10:12:21AM +0100, Peter Maydell wrote: I definitely think individual project makefiles are the wrong place to fix this. If create-as-temp-and-rename is useful functionality it needs to go in the compiler so that everybody benefits. This will not help users on existing systems. Also it's not just compiler. We'd have to do it in linker, asm, ... lots of work. This is clearly less work than implementing it in the makefile of every single open source project in the world (or even every single open source project in Debian). You are wellcome to implement this in compiler/linker/etc if you like but we will still want to handle it in our makefile as well. I specifically don't want it handled in our makefiles because it's the wrong place to fix the problem and it will make our build system more complicated. -- PMM
Re: [Qemu-devel] [PATCH] makefile: detect corrupted elf files
On Sun, May 26, 2013 at 02:36:28PM +0100, Peter Maydell wrote: On 26 May 2013 13:31, Michael S. Tsirkin m...@redhat.com wrote: On Sun, May 26, 2013 at 10:12:21AM +0100, Peter Maydell wrote: I definitely think individual project makefiles are the wrong place to fix this. If create-as-temp-and-rename is useful functionality it needs to go in the compiler so that everybody benefits. This will not help users on existing systems. Also it's not just compiler. We'd have to do it in linker, asm, ... lots of work. This is clearly less work than implementing it in the makefile of every single open source project in the world (or even every single open source project in Debian). You seem to have removed the part that explained that 1. we run scripts in our makefiles so need to handle that anyway 2. we care about users on existing systems This means that we would need the fix in our makefiles even if compiler and linker gain this feature. You are wellcome to implement this in compiler/linker/etc if you like but we will still want to handle it in our makefile as well. I specifically don't want it handled in our makefiles because it's the wrong place to fix the problem and it will make our build system more complicated. -- PMM
Re: [Qemu-devel] [PATCH 12/15] s390x: reduce TARGET_PHYS_ADDR_SPACE_BITS to 62
Am 24.05.2013 19:03, schrieb Paolo Bonzini: With the next patch, the memory API will complain if the TARGET_PHYS_ADDR_SPACE_BITS gets dangerously close to an overflow. s390x can handle up to 64 bit of physical address space from its page tables, but we never use that much. Just decrease the value. Cc: Alexander Graf ag...@suse.de Signed-off-by: Paolo Bonzini pbonz...@redhat.com Didn't Avi introduce 128-bit arithmetic into QEMU to avoid 64-bit values overflowing? Why are you limiting Memory API to 62-bit now? Andreas --- target-s390x/cpu.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/target-s390x/cpu.h b/target-s390x/cpu.h index 0ce82cf..6304c4d 100644 --- a/target-s390x/cpu.h +++ b/target-s390x/cpu.h @@ -34,7 +34,10 @@ #include exec/cpu-defs.h #define TARGET_PAGE_BITS 12 -#define TARGET_PHYS_ADDR_SPACE_BITS 64 +/* Actually 64-bits, limited by the memory API to 62 bits. We + * never use that much. + */ +#define TARGET_PHYS_ADDR_SPACE_BITS 62 #define TARGET_VIRT_ADDR_SPACE_BITS 64 #include exec/cpu-all.h -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] FPU x86 instructions error
Hi, Am 24.05.2013 23:44, schrieb Paolo Bonzini: Il 24/05/2013 23:39, Clemens Kolbitsch ha scritto: we recently had an issue with running a program using FPU instructions to obtain the current EIP (basically a weird way of call 0; pop eax) that was not working on QEMU (with TCG). Looking at the problem, we found this patch to be useful/fixing the issue: https://launchpadlibrarian.net/140457932/patch-qemu-1.5.0-fpip.diff Looking through the DEVEL archives, I found this patch http://lists.nongnu.org/archive/html/qemu-devel/2011-06/msg01206.html that adds the FPU flags to the environment, but is only using them for KVM. I was wondering - since the above patch is rather old, you have probably come across it before - if there was a reason for not including it in QEMU (I checked in git:master and it's not applied). If there isn't, maybe it'd be worth re-considering :) For the TCG patch, there is no Signed-off-by and using a helper is not necessary. Clemens, generally we can't just take another person's patch and apply it - that's what we need the Signed-off-by for. Your post is the only Google hit for that link and no hits for fpip in my archive - you'll need to contact the author to obtain her Sob and properly submit it to qemu-devel - or post a patch yourself that is not based on that one. http://wiki.qemu.org/Contribute/SubmitAPatch For the KVM patch, it simply fell through the cracks, I believe. It didn't: http://git.qemu.org/?p=qemu.git;a=commit;h=42cc8fa620cbc73e349e96d84cf46469e828ec34 (I was about to suggest placing the non-TCG fields into X86CPU. :)) Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [Qemu-stable] qmp commands get rejected
Am 26.05.2013 03:23, schrieb mdroth:
On Sat, May 25, 2013 at 01:09:50PM +0200, Stefan Priebe wrote:
Am 25.05.2013 00:32, schrieb mdroth:
On Sat, May 25, 2013 at 12:12:22AM +0200, Stefan Priebe wrote:
Am 25.05.2013 00:09, schrieb mdroth:
I would try to create a small example script.
I use qmp-shell and other little scripts very often.
Am this be due to the fact that I don't wait for the welcome banner
right now?
If you're not reading from the socket, then you'll get the banner back
when
you read your first response. But qom-set shouldn't fail because of that.
I can workaround it by adding this patch:
diff --git a/monitor.c b/monitor.c
index 62aaebe..9997520 100644
--- a/monitor.c
+++ b/monitor.c
@@ -4239,7 +4239,8 @@ static int monitor_can_read(void *opaque)
static int invalid_qmp_mode(const Monitor *mon, const char *cmd_name)
{
int is_cap = compare_cmd(cmd_name, qmp_capabilities);
-return (qmp_cmd_mode(mon) ? is_cap : !is_cap);
+//return (qmp_cmd_mode(mon) ? is_cap : !is_cap);
+return ((is_cap 0) ? 0 : (qmp_cmd_mode(mon) ? is_cap : !is_cap));
}
I think this is unrelated to your original issue. If you issue
'qmp_capabilities' command more than once you will get CommandNotFound,
and that behavior seems to be present even with v1.3.0. This patch seems
to be masking the problem you're having (which seems to be state from
previous monitor sessions/connections leaking into subsequent ones).
That sounds reasonable. I'm using proxmox / PVE which does a lot of
qmp queries in the background. So i might see situations where X
connections in parallel do qmp queries.
It's possible the GSource-based mechanism for handling I/O for chardev
backends is causing a difference in behavior. Still not sure exactly
what's going on though.
Can i revert some patches to test?
I think somewhere prior to this one should be enough to test:
2ea5a7af7bfa576a5936400ccca4144caca9640b
YES! I used 2ea5a7af7bfa576a5936400ccca4144caca9640b~1 for my tests
and this works absoluty fine.
Turns out the real culprit was a few commits later:
9f939df955a4152aad69a19a77e0898631bb2c18
I've sent a workaround this fixes things for QMP, but we may need a more
general fix. Please give it a shot and see if it fixes your issues:
http://article.gmane.org/gmane.comp.emulators.qemu/213106
no i got again:
The command qom-set has not been found JSON Reply: {id: 21677:2,
error: {class: CommandNotFound, desc: The command qom-set has
not been found}} JSON Query:
{execute:qom-set,id:21677:2,arguments:{value:2,path:machine/peripheral/balloon0,property:guest-stats-polling-interval}}
at /usr/share/perl5/PVE/QMPClient.pm line 101.
Stefan
[Qemu-devel] snabbswitch integration with QEMU for userspace ethernet I/O
Dear qemu-devel hackers, I am writing to ask for some technical advice. I am making embarrassingly slow progress on finding a good way to integrate the Snabb Switch user-space ethernet switch (http://snabb.co/snabbswitch/) with QEMU for efficient ethernet I/O. Stefan put us onto the highly promising track of vhost/virtio. We have implemented this between Snabb Switch and the Linux kernel, but not directly between Snabb Switch and QEMU guests. The roadblock we have hit is embarrasingly basic: QEMU is using user-to-kernel system calls to setup vhost (open /dev/net/tun and /dev/vhost-net, ioctl()s) and I haven't found a good way to map these towards Snabb Switch instead of the kernel. We have several ideas on the table and we would love some technical feedback on what sounds like a good way forward -- ideally a better alternative that we haven't thought of at all, not being QEMU gurus ourselves. Here are the ideas on the table right now: 1. Use FUSE to implement a complete clone of /dev/net/tun and /dev/vhost-net inside Snabb Switch. Implement every ioctl() that QEMU requires. 2. Extend QEMU to support a user-user IPC mode of vhost. In this mode QEMU would not use ioctl() etc but some other system calls that are appropriate for IPC between user-space processes. 3. Use the kernel as a middle-man. Create a double-ended veth interface and have Snabb Switch and QEMU each open a PF_PACKET socket and accelerate it with VHOST_NET. #1 is appealing _if_ it can really be done. Risk is that we hit a road-block when implementing the behavior of the ioctl()s, for example have trouble mapping guest memory or getting hold of an eventfd, and that FUSE is kinda heavy-weight. #2 is appealing _if_ it can be done in a nice way. I don't know which system calls would be appropriate and I don't know how to write the code inside QEMU in a neat way. #3 is appealing _if_ there is no significant overhead e.g. an extra memory copy inside the kernel, or if it's really quick to do as a temporary stop-gap. We would love some words of wisdom about the options above and/or a new idea :-) Cheers, -Luke
[Qemu-devel] [PATCH v2 01/11] make: pull in linux-headers on all platforms
Things we pull from linux-headers are actually quite portable. All we need is implement linux/types.h using stdint.h and we are able to compile on any platform. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- Makefile.target | 5 +++-- configure | 7 ++- 2 files changed, 9 insertions(+), 3 deletions(-) diff --git a/Makefile.target b/Makefile.target index ce4391f..5d69d50 100644 --- a/Makefile.target +++ b/Makefile.target @@ -6,9 +6,10 @@ include config-devices.mak include $(SRC_PATH)/rules.mak $(call set-vpath, $(SRC_PATH)) -ifdef CONFIG_LINUX -QEMU_CFLAGS += -I../linux-headers +ifndef CONFIG_LINUX +QEMU_CFLAGS += -I../linux-stubs endif +QEMU_CFLAGS += -I../linux-headers QEMU_CFLAGS += -I.. -I$(SRC_PATH)/target-$(TARGET_BASE_ARCH) -DNEED_CPU_H QEMU_CFLAGS+=-I$(SRC_PATH)/include diff --git a/configure b/configure index 5ae7e4a..8321f8b 100755 --- a/configure +++ b/configure @@ -427,6 +427,7 @@ fi # OS specific +QEMU_LINUX_HEADER_INCLUDES=-I\$(SRC_PATH)/linux-stubs -I\$(SRC_PATH)/linux-headers case $targetos in CYGWIN*) mingw32=yes @@ -547,10 +548,14 @@ Haiku) if [ $cpu = i386 -o $cpu = x86_64 ] ; then audio_possible_drivers=$audio_possible_drivers fmod fi - QEMU_INCLUDES=-I\$(SRC_PATH)/linux-headers $QEMU_INCLUDES + QEMU_LINUX_HEADER_INCLUDES=-I\$(SRC_PATH)/linux-headers ;; esac +#Always pull in linux-headers, we make sure they are +#cross-platform +QEMU_INCLUDES=$QEMU_LINUX_HEADER_INCLUDES$QEMU_INCLUDES + if [ $bsd = yes ] ; then if [ $darwin != yes ] ; then usb=bsd -- MST
[Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code
virtio linux headers are actually pretty portable: all we need is implement linux/types.h in a portable way, and we can import them and use on any platform. These patches do exactly that, as a pre-requisite to adding support for new virtio layout. Note: if someone adds non-portable code in files we import from linux-headers, we'll have to revert to copying code manually. This didn't happen yet so hopefully it won't. Changes from v1: - add stubs for non linux platforms - fix mingw cross build Michael S. Tsirkin (11): make: pull in linux-headers on all platforms scripts/update-linux-headers.sh: add virtio virtio-9p: switch to linux-headers virtio-net, eth: use linux-headers virtio-blk: switch to linux-headers virtio-balloon: switch to linux-headers virtio-rng: switch to linux-headers virtio-console: switch to linux-headers virtio: add virtio_ids from linux-headers virtio-pci: switch to linux-headers virtio: use ring structure from linux-headers Makefile.target | 5 +- configure| 7 +- hw/9pfs/virtio-9p.h | 13 +-- hw/block/dataplane/virtio-blk.c | 12 +-- hw/block/virtio-blk.c| 10 +- hw/virtio/virtio-balloon.c | 2 +- hw/virtio/virtio-pci.c | 49 + hw/virtio/virtio.c | 23 +--- include/hw/virtio/virtio-balloon.h | 37 +-- include/hw/virtio/virtio-blk.h | 86 +-- include/hw/virtio/virtio-net.h | 141 +--- include/hw/virtio/virtio-rng.h | 5 +- include/hw/virtio/virtio-serial.h| 38 +-- include/hw/virtio/virtio.h | 45 +--- include/net/eth.h| 5 +- include/net/tap.h| 24 + linux-headers/linux/if_ether.h | 140 linux-headers/linux/virtio_9p.h | 44 linux-headers/linux/virtio_balloon.h | 59 ++ linux-headers/linux/virtio_blk.h | 128 ++ linux-headers/linux/virtio_console.h | 74 + linux-headers/linux/virtio_ids.h | 43 linux-headers/linux/virtio_net.h | 202 +++ linux-headers/linux/virtio_pci.h | 97 + linux-headers/linux/virtio_rng.h | 8 ++ scripts/update-linux-headers.sh | 17 ++- 26 files changed, 862 insertions(+), 452 deletions(-) create mode 100644 linux-headers/linux/if_ether.h create mode 100644 linux-headers/linux/virtio_9p.h create mode 100644 linux-headers/linux/virtio_balloon.h create mode 100644 linux-headers/linux/virtio_blk.h create mode 100644 linux-headers/linux/virtio_console.h create mode 100644 linux-headers/linux/virtio_ids.h create mode 100644 linux-headers/linux/virtio_net.h create mode 100644 linux-headers/linux/virtio_pci.h create mode 100644 linux-headers/linux/virtio_rng.h -- MST
[Qemu-devel] [PATCH v2 02/11] scripts/update-linux-headers.sh: add virtio
Add virtio headers to make it easy to keep things in sync. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- scripts/update-linux-headers.sh | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/scripts/update-linux-headers.sh b/scripts/update-linux-headers.sh index 120a694..334fba9 100755 --- a/scripts/update-linux-headers.sh +++ b/scripts/update-linux-headers.sh @@ -61,7 +61,22 @@ done rm -rf $output/linux-headers/linux mkdir -p $output/linux-headers/linux -for header in kvm.h kvm_para.h vfio.h vhost.h virtio_config.h virtio_ring.h; do +for header in \ +kvm.h \ +kvm_para.h \ +vfio.h \ +vhost.h \ +virtio_9p.h \ +virtio_balloon.h \ +virtio_blk.h \ +virtio_config.h \ +virtio_console.h \ +virtio_ids.h \ +virtio_net.h \ +virtio_pci.h \ +virtio_ring.h \ +virtio_rng.h \ +; do cp $tmpdir/include/linux/$header $output/linux-headers/linux done rm -rf $output/linux-headers/asm-generic -- MST
[Qemu-devel] [PATCH v2 03/11] virtio-9p: switch to linux-headers
It's easier to keep everything in sync if
we just use linux headers for virtio constants.
Add virtio-9p header from linux 3.10-rc1, and
remove duplicate symbols from virtio-9p.h
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
hw/9pfs/virtio-9p.h | 13 +---
linux-headers/linux/virtio_9p.h | 44 +
2 files changed, 45 insertions(+), 12 deletions(-)
create mode 100644 linux-headers/linux/virtio_9p.h
diff --git a/hw/9pfs/virtio-9p.h b/hw/9pfs/virtio-9p.h
index 1d6eedb..5ba4411 100644
--- a/hw/9pfs/virtio-9p.h
+++ b/hw/9pfs/virtio-9p.h
@@ -11,10 +11,7 @@
#include fsdev/virtio-9p-marshal.h
#include qemu/thread.h
#include block/coroutine.h
-
-/* The feature bitmap for virtio 9P */
-/* The mount point is specified in a config variable */
-#define VIRTIO_9P_MOUNT_TAG 0
+#include linux/virtio_9p.h
enum {
P9_TLERROR = 6,
@@ -277,14 +274,6 @@ typedef struct V9fsWriteState {
int cnt;
} V9fsWriteState;
-struct virtio_9p_config
-{
-/* number of characters in tag */
-uint16_t tag_len;
-/* Variable size tag name */
-uint8_t tag[0];
-} QEMU_PACKED;
-
typedef struct V9fsMkState {
V9fsPDU *pdu;
size_t offset;
diff --git a/linux-headers/linux/virtio_9p.h b/linux-headers/linux/virtio_9p.h
new file mode 100644
index 000..277c4ad
--- /dev/null
+++ b/linux-headers/linux/virtio_9p.h
@@ -0,0 +1,44 @@
+#ifndef _LINUX_VIRTIO_9P_H
+#define _LINUX_VIRTIO_9P_H
+/* This header is BSD licensed so anyone can use the definitions to implement
+ * compatible drivers/servers.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of IBM nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS
IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL IBM OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE. */
+#include linux/types.h
+#include linux/virtio_ids.h
+#include linux/virtio_config.h
+
+/* The feature bitmap for virtio 9P */
+
+/* The mount point is specified in a config variable */
+#define VIRTIO_9P_MOUNT_TAG 0
+
+struct virtio_9p_config {
+ /* length of the tag name */
+ __u16 tag_len;
+ /* non-NULL terminated tag name */
+ __u8 tag[0];
+} __attribute__((packed));
+
+#endif /* _LINUX_VIRTIO_9P_H */
--
MST
[Qemu-devel] [PATCH v2 06/11] virtio-balloon: switch to linux-headers
It's easier to keep everything in sync if
we just use linux headers for virtio constants.
Add virtio_balloon.h header from linux 3.10-rc1, and
remove duplicate symbols from virtio-balloon.h
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
hw/virtio/virtio-balloon.c | 2 +-
include/hw/virtio/virtio-balloon.h | 37 ++
linux-headers/linux/virtio_balloon.h | 59
3 files changed, 63 insertions(+), 35 deletions(-)
create mode 100644 linux-headers/linux/virtio_balloon.h
diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
index d669756..548508b 100644
--- a/hw/virtio/virtio-balloon.c
+++ b/hw/virtio/virtio-balloon.c
@@ -216,7 +216,7 @@ static void virtio_balloon_receive_stats(VirtIODevice
*vdev, VirtQueue *vq)
{
VirtIOBalloon *s = VIRTIO_BALLOON(vdev);
VirtQueueElement *elem = s-stats_vq_elem;
-VirtIOBalloonStat stat;
+struct virtio_balloon_stat stat;
size_t offset = 0;
qemu_timeval tv;
diff --git a/include/hw/virtio/virtio-balloon.h
b/include/hw/virtio/virtio-balloon.h
index f863bfe..dc0702d 100644
--- a/include/hw/virtio/virtio-balloon.h
+++ b/include/hw/virtio/virtio-balloon.h
@@ -17,45 +17,14 @@
#include hw/virtio/virtio.h
#include hw/pci/pci.h
+#include linux/virtio_balloon.h
+#include linux/virtio_ids.h
+
#define TYPE_VIRTIO_BALLOON virtio-balloon-device
#define VIRTIO_BALLOON(obj) \
OBJECT_CHECK(VirtIOBalloon, (obj), TYPE_VIRTIO_BALLOON)
-/* from Linux's linux/virtio_balloon.h */
-
-/* The ID for virtio_balloon */
-#define VIRTIO_ID_BALLOON 5
-
-/* The feature bitmap for virtio balloon */
-#define VIRTIO_BALLOON_F_MUST_TELL_HOST 0 /* Tell before reclaiming pages */
-#define VIRTIO_BALLOON_F_STATS_VQ 1 /* Memory stats virtqueue */
-
-/* Size of a PFN in the balloon interface. */
-#define VIRTIO_BALLOON_PFN_SHIFT 12
-
-struct virtio_balloon_config
-{
-/* Number of pages host wants Guest to give up. */
-uint32_t num_pages;
-/* Number of pages we've actually got in balloon. */
-uint32_t actual;
-};
-
-/* Memory Statistics */
-#define VIRTIO_BALLOON_S_SWAP_IN 0 /* Amount of memory swapped in */
-#define VIRTIO_BALLOON_S_SWAP_OUT 1 /* Amount of memory swapped out */
-#define VIRTIO_BALLOON_S_MAJFLT 2 /* Number of major faults */
-#define VIRTIO_BALLOON_S_MINFLT 3 /* Number of minor faults */
-#define VIRTIO_BALLOON_S_MEMFREE 4 /* Total amount of free memory */
-#define VIRTIO_BALLOON_S_MEMTOT 5 /* Total amount of memory */
-#define VIRTIO_BALLOON_S_NR 6
-
-typedef struct VirtIOBalloonStat {
-uint16_t tag;
-uint64_t val;
-} QEMU_PACKED VirtIOBalloonStat;
-
typedef struct VirtIOBalloon {
VirtIODevice parent_obj;
VirtQueue *ivq, *dvq, *svq;
diff --git a/linux-headers/linux/virtio_balloon.h
b/linux-headers/linux/virtio_balloon.h
new file mode 100644
index 000..5e26f61
--- /dev/null
+++ b/linux-headers/linux/virtio_balloon.h
@@ -0,0 +1,59 @@
+#ifndef _LINUX_VIRTIO_BALLOON_H
+#define _LINUX_VIRTIO_BALLOON_H
+/* This header is BSD licensed so anyone can use the definitions to implement
+ * compatible drivers/servers.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of IBM nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS
IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL IBM OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE. */
+#include linux/virtio_ids.h
+#include linux/virtio_config.h
+
+/* The feature bitmap for virtio balloon */
+#define VIRTIO_BALLOON_F_MUST_TELL_HOST0 /* Tell before reclaiming
pages */
+#define VIRTIO_BALLOON_F_STATS_VQ 1 /* Memory Stats virtqueue */
+
+/* Size of a PFN in the balloon interface. */
[Qemu-devel] [PATCH v2 04/11] virtio-net, eth: use linux-headers
It's easier to keep everything virtio in sync if
we just use headers exported from linux kernel.
Import linux/virtio_net.h and linux/if_ether.h
that it depends on. Switch to symbols from
that header for stuff that was
duplicated in tap.h and eth.h
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
include/hw/virtio/virtio-net.h | 141 +--
include/net/eth.h| 5 +-
include/net/tap.h| 24 +
linux-headers/linux/if_ether.h | 140 +++
linux-headers/linux/virtio_net.h | 202 +++
5 files changed, 347 insertions(+), 165 deletions(-)
create mode 100644 linux-headers/linux/if_ether.h
create mode 100644 linux-headers/linux/virtio_net.h
diff --git a/include/hw/virtio/virtio-net.h b/include/hw/virtio/virtio-net.h
index b315ac9..65616c0 100644
--- a/include/hw/virtio/virtio-net.h
+++ b/include/hw/virtio/virtio-net.h
@@ -16,46 +16,13 @@
#include hw/virtio/virtio.h
#include hw/pci/pci.h
+#include linux/virtio_net.h
+#include linux/virtio_ids.h
#define TYPE_VIRTIO_NET virtio-net-device
#define VIRTIO_NET(obj) \
OBJECT_CHECK(VirtIONet, (obj), TYPE_VIRTIO_NET)
-#define ETH_ALEN6
-
-/* from Linux's virtio_net.h */
-
-/* The ID for virtio_net */
-#define VIRTIO_ID_NET 1
-
-/* The feature bitmap for virtio net */
-#define VIRTIO_NET_F_CSUM 0 /* Host handles pkts w/ partial csum */
-#define VIRTIO_NET_F_GUEST_CSUM 1 /* Guest handles pkts w/ partial csum
*/
-#define VIRTIO_NET_F_CTRL_GUEST_OFFLOADS 2 /* Control channel offload
- * configuration support */
-#define VIRTIO_NET_F_MAC5 /* Host has given MAC address. */
-#define VIRTIO_NET_F_GSO6 /* Host handles pkts w/ any GSO type */
-#define VIRTIO_NET_F_GUEST_TSO4 7 /* Guest can handle TSOv4 in. */
-#define VIRTIO_NET_F_GUEST_TSO6 8 /* Guest can handle TSOv6 in. */
-#define VIRTIO_NET_F_GUEST_ECN 9 /* Guest can handle TSO[6] w/ ECN in.
*/
-#define VIRTIO_NET_F_GUEST_UFO 10 /* Guest can handle UFO in. */
-#define VIRTIO_NET_F_HOST_TSO4 11 /* Host can handle TSOv4 in. */
-#define VIRTIO_NET_F_HOST_TSO6 12 /* Host can handle TSOv6 in. */
-#define VIRTIO_NET_F_HOST_ECN 13 /* Host can handle TSO[6] w/ ECN in. */
-#define VIRTIO_NET_F_HOST_UFO 14 /* Host can handle UFO in. */
-#define VIRTIO_NET_F_MRG_RXBUF 15 /* Host can merge receive buffers. */
-#define VIRTIO_NET_F_STATUS 16 /* virtio_net_config.status available
*/
-#define VIRTIO_NET_F_CTRL_VQ17 /* Control channel available */
-#define VIRTIO_NET_F_CTRL_RX18 /* Control channel RX mode support */
-#define VIRTIO_NET_F_CTRL_VLAN 19 /* Control channel VLAN filtering */
-#define VIRTIO_NET_F_CTRL_RX_EXTRA 20 /* Extra RX mode control support */
-#define VIRTIO_NET_F_MQ 22 /* Device supports Receive Flow
- * Steering */
-
-#define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
-
-#define VIRTIO_NET_S_LINK_UP1 /* Link is up */
-
#define TX_TIMER_INTERVAL 15 /* 150 us */
/* Limit the number of packets that can be sent via a single flush
@@ -75,72 +42,6 @@ typedef struct virtio_net_conf
/* Maximum packet size we can receive from tap device: header + 64k */
#define VIRTIO_NET_MAX_BUFSIZE (sizeof(struct virtio_net_hdr) + (64 10))
-struct virtio_net_config
-{
-/* The config defining mac address ($ETH_ALEN bytes) */
-uint8_t mac[ETH_ALEN];
-/* See VIRTIO_NET_F_STATUS and VIRTIO_NET_S_* above */
-uint16_t status;
-/* Max virtqueue pairs supported by the device */
-uint16_t max_virtqueue_pairs;
-} QEMU_PACKED;
-
-/*
- * Control virtqueue data structures
- *
- * The control virtqueue expects a header in the first sg entry
- * and an ack/status response in the last entry. Data for the
- * command goes in between.
- */
-struct virtio_net_ctrl_hdr {
-uint8_t class;
-uint8_t cmd;
-};
-
-typedef uint8_t virtio_net_ctrl_ack;
-
-#define VIRTIO_NET_OK 0
-#define VIRTIO_NET_ERR1
-
-/*
- * Control the RX mode, ie. promisucous, allmulti, etc...
- * All commands require an out sg entry containing a 1 byte
- * state value, zero = disable, non-zero = enable. Commands
- * 0 and 1 are supported with the VIRTIO_NET_F_CTRL_RX feature.
- * Commands 2-5 are added with VIRTIO_NET_F_CTRL_RX_EXTRA.
- */
-#define VIRTIO_NET_CTRL_RX0
- #define VIRTIO_NET_CTRL_RX_PROMISC 0
- #define VIRTIO_NET_CTRL_RX_ALLMULTI 1
- #define VIRTIO_NET_CTRL_RX_ALLUNI 2
- #define VIRTIO_NET_CTRL_RX_NOMULTI 3
- #define VIRTIO_NET_CTRL_RX_NOUNI4
- #define VIRTIO_NET_CTRL_RX_NOBCAST 5
-
-/*
- * Control the MAC
- *
- * The MAC filter table is managed by the hypervisor, the guest should
- * assume the size is infinite. Filtering should be considered
- * non-perfect, ie. based on hypervisor resources, the
[Qemu-devel] [PATCH v2 05/11] virtio-blk: switch to linux-headers
It's easier to keep everything in sync if
we just use linux headers for virtio constants.
Add virtio_blk.h header from linux 3.10-rc1, and
remove duplicate symbols from virtio-blk.h
In particular, it turns out that linux does
not have struct virtio_blk_inhdr for the status
field, so make this struct match the qemu coding style.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
hw/block/dataplane/virtio-blk.c | 12 ++--
hw/block/virtio-blk.c| 10 +--
include/hw/virtio/virtio-blk.h | 86 ++
linux-headers/linux/virtio_blk.h | 128 +++
4 files changed, 144 insertions(+), 92 deletions(-)
create mode 100644 linux-headers/linux/virtio_blk.h
diff --git a/hw/block/dataplane/virtio-blk.c b/hw/block/dataplane/virtio-blk.c
index 0356665..e582ff3 100644
--- a/hw/block/dataplane/virtio-blk.c
+++ b/hw/block/dataplane/virtio-blk.c
@@ -87,7 +87,7 @@ static void complete_request(struct iocb *iocb, ssize_t ret,
void *opaque)
{
VirtIOBlockDataPlane *s = opaque;
VirtIOBlockRequest *req = container_of(iocb, VirtIOBlockRequest, iocb);
-struct virtio_blk_inhdr hdr;
+VirtIOBlockInHdr hdr;
int len;
if (likely(ret = 0)) {
@@ -128,7 +128,7 @@ static void complete_request(struct iocb *iocb, ssize_t
ret, void *opaque)
static void complete_request_early(VirtIOBlockDataPlane *s, unsigned int head,
QEMUIOVector *inhdr, unsigned char status)
{
-struct virtio_blk_inhdr hdr = {
+VirtIOBlockInHdr hdr = {
.status = status,
};
@@ -215,16 +215,16 @@ static int process_request(IOQueue *ioq, struct iovec
iov[],
/* Grab inhdr for later */
in_size = iov_size(in_iov, in_num);
-if (in_size sizeof(struct virtio_blk_inhdr)) {
+if (in_size sizeof(VirtIOBlockInHdr)) {
error_report(virtio_blk request inhdr too short);
return -EFAULT;
}
inhdr = g_slice_new(QEMUIOVector);
qemu_iovec_init(inhdr, 1);
qemu_iovec_concat_iov(inhdr, in_iov, in_num,
-in_size - sizeof(struct virtio_blk_inhdr),
-sizeof(struct virtio_blk_inhdr));
-iov_discard_back(in_iov, in_num, sizeof(struct virtio_blk_inhdr));
+in_size - sizeof(VirtIOBlockInHdr),
+sizeof(VirtIOBlockInHdr));
+iov_discard_back(in_iov, in_num, sizeof(VirtIOBlockInHdr));
/* TODO Linux sets the barrier bit even when not advertised! */
outhdr.type = ~VIRTIO_BLK_T_BARRIER;
diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index cf12469..d8131f7 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -30,7 +30,7 @@ typedef struct VirtIOBlockReq
{
VirtIOBlock *dev;
VirtQueueElement elem;
-struct virtio_blk_inhdr *in;
+VirtIOBlockInHdr *in;
struct virtio_blk_outhdr *out;
struct virtio_scsi_inhdr *scsi;
QEMUIOVector qiov;
@@ -487,11 +487,11 @@ static void virtio_blk_update_config(VirtIODevice *vdev,
uint8_t *config)
memset(blkcfg, 0, sizeof(blkcfg));
stq_raw(blkcfg.capacity, capacity);
stl_raw(blkcfg.seg_max, 128 - 2);
-stw_raw(blkcfg.cylinders, s-conf-cyls);
+stw_raw(blkcfg.geometry.cylinders, s-conf-cyls);
stl_raw(blkcfg.blk_size, blk_size);
stw_raw(blkcfg.min_io_size, s-conf-min_io_size / blk_size);
stw_raw(blkcfg.opt_io_size, s-conf-opt_io_size / blk_size);
-blkcfg.heads = s-conf-heads;
+blkcfg.geometry.heads = s-conf-heads;
/*
* We must ensure that the block device capacity is a multiple of
* the logical block size. If that is not the case, let's use
@@ -504,9 +504,9 @@ static void virtio_blk_update_config(VirtIODevice *vdev,
uint8_t *config)
* per track (cylinder).
*/
if (bdrv_getlength(s-bs) / s-conf-heads / s-conf-secs % blk_size) {
-blkcfg.sectors = s-conf-secs ~s-sector_mask;
+blkcfg.geometry.sectors = s-conf-secs ~s-sector_mask;
} else {
-blkcfg.sectors = s-conf-secs;
+blkcfg.geometry.sectors = s-conf-secs;
}
blkcfg.size_max = 0;
blkcfg.physical_block_exp = get_physical_block_exp(s-conf);
diff --git a/include/hw/virtio/virtio-blk.h b/include/hw/virtio/virtio-blk.h
index fc71853..911df23 100644
--- a/include/hw/virtio/virtio-blk.h
+++ b/include/hw/virtio/virtio-blk.h
@@ -16,95 +16,19 @@
#include hw/virtio/virtio.h
#include hw/block/block.h
+#include linux/virtio_blk.h
+#include linux/virtio_ids.h
#define TYPE_VIRTIO_BLK virtio-blk-device
#define VIRTIO_BLK(obj) \
OBJECT_CHECK(VirtIOBlock, (obj), TYPE_VIRTIO_BLK)
-/* from Linux's linux/virtio_blk.h */
-
-/* The ID for virtio_block */
-#define VIRTIO_ID_BLOCK 2
-
-/* Feature bits */
-#define VIRTIO_BLK_F_BARRIER0 /* Does host support barriers? */
-#define VIRTIO_BLK_F_SIZE_MAX 1 /* Indicates maximum segment size */
-#define VIRTIO_BLK_F_SEG_MAX2 /* Indicates maximum # of segments */
-#define VIRTIO_BLK_F_GEOMETRY 4 /*
[Qemu-devel] [PATCH v2 11/11] virtio: use ring structure from linux-headers
We already have ring structure in virtio-ring.h for use by dataplane.
Use it in virtio.h as well, renaming some conflicting functions.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
hw/virtio/virtio.c | 23 +--
include/hw/virtio/virtio.h | 45 +++--
2 files changed, 8 insertions(+), 60 deletions(-)
diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 8176c14..20bb6c2 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -145,7 +145,7 @@ static inline uint16_t vring_avail_ring(VirtQueue *vq, int
i)
return lduw_phys(pa);
}
-static inline uint16_t vring_used_event(VirtQueue *vq)
+static inline uint16_t vring_used_event_idx(VirtQueue *vq)
{
return vring_avail_ring(vq, vq-vring.num);
}
@@ -192,7 +192,7 @@ static inline void vring_used_flags_unset_bit(VirtQueue
*vq, int mask)
stw_phys(pa, lduw_phys(pa) ~mask);
}
-static inline void vring_avail_event(VirtQueue *vq, uint16_t val)
+static inline void vring_avail_event_idx(VirtQueue *vq, uint16_t val)
{
hwaddr pa;
if (!vq-notification) {
@@ -206,7 +206,7 @@ void virtio_queue_set_notification(VirtQueue *vq, int
enable)
{
vq-notification = enable;
if (vq-vdev-guest_features (1 VIRTIO_RING_F_EVENT_IDX)) {
-vring_avail_event(vq, vring_avail_idx(vq));
+vring_avail_event_idx(vq, vring_avail_idx(vq));
} else if (enable) {
vring_used_flags_unset_bit(vq, VRING_USED_F_NO_NOTIFY);
} else {
@@ -448,7 +448,7 @@ int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
i = head = virtqueue_get_head(vq, vq-last_avail_idx++);
if (vq-vdev-guest_features (1 VIRTIO_RING_F_EVENT_IDX)) {
-vring_avail_event(vq, vring_avail_idx(vq));
+vring_avail_event_idx(vq, vring_avail_idx(vq));
}
if (vring_desc_flags(desc_pa, i) VRING_DESC_F_INDIRECT) {
@@ -740,19 +740,6 @@ void virtio_irq(VirtQueue *vq)
virtio_notify_vector(vq-vdev, vq-vector);
}
-/* Assuming a given event_idx value from the other size, if
- * we have just incremented index from old to new_idx,
- * should we trigger an event? */
-static inline int vring_need_event(uint16_t event, uint16_t new, uint16_t old)
-{
- /* Note: Xen has similar logic for notification hold-off
-* in include/xen/interface/io/ring.h with req_event and req_prod
-* corresponding to event_idx + 1 and new respectively.
-* Note also that req_event and req_prod in Xen start at 1,
-* event indexes in virtio start at 0. */
- return (uint16_t)(new - event - 1) (uint16_t)(new - old);
-}
-
static bool vring_notify(VirtIODevice *vdev, VirtQueue *vq)
{
uint16_t old, new;
@@ -773,7 +760,7 @@ static bool vring_notify(VirtIODevice *vdev, VirtQueue *vq)
vq-signalled_used_valid = true;
old = vq-signalled_used;
new = vq-signalled_used = vring_used_idx(vq);
-return !v || vring_need_event(vring_used_event(vq), new, old);
+return !v || vring_need_event(vring_used_event_idx(vq), new, old);
}
void virtio_notify(VirtIODevice *vdev, VirtQueue *vq)
diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
index a6c5c53..3ea634d 100644
--- a/include/hw/virtio/virtio.h
+++ b/include/hw/virtio/virtio.h
@@ -22,50 +22,11 @@
#ifdef CONFIG_VIRTFS
#include hw/virtio/virtio-9p.h
#endif
+#include linux/virtio_config.h
+#include linux/virtio_ring.h
-/* from Linux's linux/virtio_config.h */
-
-/* Status byte for guest to report progress, and synchronize features. */
-/* We have seen device and processed generic fields (VIRTIO_CONFIG_F_VIRTIO) */
-#define VIRTIO_CONFIG_S_ACKNOWLEDGE 1
-/* We have found a driver for the device. */
-#define VIRTIO_CONFIG_S_DRIVER 2
-/* Driver has used its parts of the config, and is happy */
-#define VIRTIO_CONFIG_S_DRIVER_OK 4
-/* We've given up on this device. */
-#define VIRTIO_CONFIG_S_FAILED 0x80
-
-/* Some virtio feature bits (currently bits 28 through 31) are reserved for the
- * transport being used (eg. virtio_ring), the rest are per-device feature
bits. */
-#define VIRTIO_TRANSPORT_F_START28
-#define VIRTIO_TRANSPORT_F_END 32
-
-/* We notify when the ring is completely used, even if the guest is suppressing
- * callbacks */
-#define VIRTIO_F_NOTIFY_ON_EMPTY24
-/* We support indirect buffer descriptors */
-#define VIRTIO_RING_F_INDIRECT_DESC 28
-/* The Guest publishes the used index for which it expects an interrupt
- * at the end of the avail ring. Host should ignore the avail-flags field. */
-/* The Host publishes the avail index for which it expects a kick
- * at the end of the used ring. Guest should ignore the used-flags field. */
-#define VIRTIO_RING_F_EVENT_IDX 29
/* A guest should never accept this. It implies negotiation is broken. */
-#define VIRTIO_F_BAD_FEATURE 30
-
-/* from Linux's linux/virtio_ring.h */
-
-/* This marks a buffer as continuing via the
[Qemu-devel] [PATCH v2 10/11] virtio-pci: switch to linux-headers
It's easier to keep everything in sync if
we just use linux headers for virtio constants.
Add virtio_pci.h header from linux 3.10-rc1, and
remove duplicate symbols from virtio-pci.h
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
hw/virtio/virtio-pci.c | 49 +++-
linux-headers/linux/virtio_pci.h | 97
2 files changed, 102 insertions(+), 44 deletions(-)
create mode 100644 linux-headers/linux/virtio_pci.h
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 70d2c6b..8707463 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -34,53 +34,14 @@
#include qemu/range.h
#include hw/virtio/virtio-bus.h
#include qapi/visitor.h
-
-/* from Linux's linux/virtio_pci.h */
-
-/* A 32-bit r/o bitmask of the features supported by the host */
-#define VIRTIO_PCI_HOST_FEATURES0
-
-/* A 32-bit r/w bitmask of features activated by the guest */
-#define VIRTIO_PCI_GUEST_FEATURES 4
-
-/* A 32-bit r/w PFN for the currently selected queue */
-#define VIRTIO_PCI_QUEUE_PFN8
-
-/* A 16-bit r/o queue size for the currently selected queue */
-#define VIRTIO_PCI_QUEUE_NUM12
-
-/* A 16-bit r/w queue selector */
-#define VIRTIO_PCI_QUEUE_SEL14
-
-/* A 16-bit r/w queue notifier */
-#define VIRTIO_PCI_QUEUE_NOTIFY 16
-
-/* An 8-bit device status register. */
-#define VIRTIO_PCI_STATUS 18
-
-/* An 8-bit r/o interrupt status register. Reading the value will return the
- * current contents of the ISR and will also clear it. This is effectively
- * a read-and-acknowledge. */
-#define VIRTIO_PCI_ISR 19
-
-/* MSI-X registers: only enabled if MSI-X is enabled. */
-/* A 16-bit vector for configuration changes. */
-#define VIRTIO_MSI_CONFIG_VECTOR20
-/* A 16-bit vector for selected queue notifications. */
-#define VIRTIO_MSI_QUEUE_VECTOR 22
+#include linux/virtio_pci.h
/* Config space size */
-#define VIRTIO_PCI_CONFIG_NOMSI 20
-#define VIRTIO_PCI_CONFIG_MSI 24
-#define VIRTIO_PCI_REGION_SIZE(dev) (msix_present(dev) ? \
- VIRTIO_PCI_CONFIG_MSI : \
- VIRTIO_PCI_CONFIG_NOMSI)
+#define VIRTIO_PCI_REGION_SIZE(dev)
VIRTIO_PCI_CONFIG_OFF(msix_present(dev))
/* The remaining space is defined by each driver as the per-driver
* configuration space */
-#define VIRTIO_PCI_CONFIG(dev) (msix_enabled(dev) ? \
- VIRTIO_PCI_CONFIG_MSI : \
- VIRTIO_PCI_CONFIG_NOMSI)
+#define VIRTIO_PCI_CONFIG_SIZE(dev)
VIRTIO_PCI_CONFIG_OFF(msix_enabled(dev))
/* How many bits to shift physical queue address written to QUEUE_PFN.
* 12 is historical, and due to x86 page size. */
@@ -386,7 +347,7 @@ static uint64_t virtio_pci_config_read(void *opaque, hwaddr
addr,
unsigned size)
{
VirtIOPCIProxy *proxy = opaque;
-uint32_t config = VIRTIO_PCI_CONFIG(proxy-pci_dev);
+uint32_t config = VIRTIO_PCI_CONFIG_SIZE(proxy-pci_dev);
uint64_t val = 0;
if (addr config) {
return virtio_ioport_read(proxy, addr);
@@ -417,7 +378,7 @@ static void virtio_pci_config_write(void *opaque, hwaddr
addr,
uint64_t val, unsigned size)
{
VirtIOPCIProxy *proxy = opaque;
-uint32_t config = VIRTIO_PCI_CONFIG(proxy-pci_dev);
+uint32_t config = VIRTIO_PCI_CONFIG_SIZE(proxy-pci_dev);
if (addr config) {
virtio_ioport_write(proxy, addr, val);
return;
diff --git a/linux-headers/linux/virtio_pci.h b/linux-headers/linux/virtio_pci.h
new file mode 100644
index 000..e5ec1ca
--- /dev/null
+++ b/linux-headers/linux/virtio_pci.h
@@ -0,0 +1,97 @@
+/*
+ * Virtio PCI driver
+ *
+ * This module allows virtio devices to be used over a virtual PCI device.
+ * This can be used with QEMU based VMMs like KVM or Xen.
+ *
+ * Copyright IBM Corp. 2007
+ *
+ * Authors:
+ * Anthony Liguori aligu...@us.ibm.com
+ *
+ * This header is BSD licensed so anyone can use the definitions to implement
+ * compatible drivers/servers.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of IBM nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT
[Qemu-devel] [PATCH v2 07/11] virtio-rng: switch to linux-headers
It's easier to keep everything in sync if
we just use linux headers for virtio constants.
Add virtio_rng.h header from linux 3.10-rc1, and
remove duplicate symbols from virtio-rng.h
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
include/hw/virtio/virtio-rng.h | 5 ++---
linux-headers/linux/virtio_rng.h | 8
2 files changed, 10 insertions(+), 3 deletions(-)
create mode 100644 linux-headers/linux/virtio_rng.h
diff --git a/include/hw/virtio/virtio-rng.h b/include/hw/virtio/virtio-rng.h
index debaa15..a0cc62e 100644
--- a/include/hw/virtio/virtio-rng.h
+++ b/include/hw/virtio/virtio-rng.h
@@ -14,14 +14,13 @@
#include sysemu/rng.h
#include sysemu/rng-random.h
+#include linux/virtio_rng.h
+#include linux/virtio_ids.h
#define TYPE_VIRTIO_RNG virtio-rng-device
#define VIRTIO_RNG(obj) \
OBJECT_CHECK(VirtIORNG, (obj), TYPE_VIRTIO_RNG)
-/* The Virtio ID for the virtio rng device */
-#define VIRTIO_ID_RNG4
-
struct VirtIORNGConf {
RngBackend *rng;
uint64_t max_bytes;
diff --git a/linux-headers/linux/virtio_rng.h b/linux-headers/linux/virtio_rng.h
new file mode 100644
index 000..c4d5de8
--- /dev/null
+++ b/linux-headers/linux/virtio_rng.h
@@ -0,0 +1,8 @@
+#ifndef _LINUX_VIRTIO_RNG_H
+#define _LINUX_VIRTIO_RNG_H
+/* This header is BSD licensed so anyone can use the definitions to implement
+ * compatible drivers/servers. */
+#include linux/virtio_ids.h
+#include linux/virtio_config.h
+
+#endif /* _LINUX_VIRTIO_RNG_H */
--
MST
[Qemu-devel] [PATCH v2 08/11] virtio-console: switch to linux-headers
It's easier to keep everything in sync if
we just use linux headers for virtio constants.
Add virtio_console.h header from linux 3.10-rc1, and
remove duplicate symbols from virtio-serial.h
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
include/hw/virtio/virtio-serial.h| 38 +-
linux-headers/linux/virtio_console.h | 74
2 files changed, 75 insertions(+), 37 deletions(-)
create mode 100644 linux-headers/linux/virtio_console.h
diff --git a/include/hw/virtio/virtio-serial.h
b/include/hw/virtio/virtio-serial.h
index 1d2040b..7dd76ab 100644
--- a/include/hw/virtio/virtio-serial.h
+++ b/include/hw/virtio/virtio-serial.h
@@ -17,49 +17,13 @@
#include hw/qdev.h
#include hw/virtio/virtio.h
-
-/* == Interface shared between the guest kernel and qemu == */
-
-/* The Virtio ID for virtio console / serial ports */
-#define VIRTIO_ID_CONSOLE 3
-
-/* Features supported */
-#define VIRTIO_CONSOLE_F_MULTIPORT 1
-
-#define VIRTIO_CONSOLE_BAD_ID (~(uint32_t)0)
-
-struct virtio_console_config {
-/*
- * These two fields are used by VIRTIO_CONSOLE_F_SIZE which
- * isn't implemented here yet
- */
-uint16_t cols;
-uint16_t rows;
-
-uint32_t max_nr_ports;
-} QEMU_PACKED;
-
-struct virtio_console_control {
-uint32_t id; /* Port number */
-uint16_t event;/* The kind of control event (see below) */
-uint16_t value;/* Extra information for the key */
-};
+#include linux/virtio_console.h
struct virtio_serial_conf {
/* Max. number of ports we can have for a virtio-serial device */
uint32_t max_virtserial_ports;
};
-/* Some events for the internal messages (control packets) */
-#define VIRTIO_CONSOLE_DEVICE_READY0
-#define VIRTIO_CONSOLE_PORT_ADD1
-#define VIRTIO_CONSOLE_PORT_REMOVE 2
-#define VIRTIO_CONSOLE_PORT_READY 3
-#define VIRTIO_CONSOLE_CONSOLE_PORT4
-#define VIRTIO_CONSOLE_RESIZE 5
-#define VIRTIO_CONSOLE_PORT_OPEN 6
-#define VIRTIO_CONSOLE_PORT_NAME 7
-
/* == In-qemu interface == */
#define TYPE_VIRTIO_SERIAL_PORT virtio-serial-port
diff --git a/linux-headers/linux/virtio_console.h
b/linux-headers/linux/virtio_console.h
new file mode 100644
index 000..5403535
--- /dev/null
+++ b/linux-headers/linux/virtio_console.h
@@ -0,0 +1,74 @@
+/*
+ * This header, excluding the #ifdef __KERNEL__ part, is BSD licensed so
+ * anyone can use the definitions to implement compatible drivers/servers:
+ *
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of IBM nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS
IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL IBM OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ * Copyright (C) Red Hat, Inc., 2009, 2010, 2011
+ * Copyright (C) Amit Shah amit.s...@redhat.com, 2009, 2010, 2011
+ */
+#ifndef _LINUX_VIRTIO_CONSOLE_H
+#define _LINUX_VIRTIO_CONSOLE_H
+#include linux/types.h
+#include linux/virtio_ids.h
+#include linux/virtio_config.h
+
+/* Feature bits */
+#define VIRTIO_CONSOLE_F_SIZE 0 /* Does host provide console size? */
+#define VIRTIO_CONSOLE_F_MULTIPORT 1 /* Does host provide multiple ports? */
+
+#define VIRTIO_CONSOLE_BAD_ID (~(__u32)0)
+
+struct virtio_console_config {
+ /* colums of the screens */
+ __u16 cols;
+ /* rows of the screens */
+ __u16 rows;
+ /* max. number of ports this device can hold */
+ __u32 max_nr_ports;
+} __attribute__((packed));
+
+/*
+ * A message that's passed between the Host and the Guest for a
+ * particular port.
+ */
+struct virtio_console_control {
+ __u32 id; /* Port
[Qemu-devel] [PATCH v2 09/11] virtio: add virtio_ids from linux-headers
All imported headers will use it. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- linux-headers/linux/virtio_ids.h | 43 1 file changed, 43 insertions(+) create mode 100644 linux-headers/linux/virtio_ids.h diff --git a/linux-headers/linux/virtio_ids.h b/linux-headers/linux/virtio_ids.h new file mode 100644 index 000..284fc3a --- /dev/null +++ b/linux-headers/linux/virtio_ids.h @@ -0,0 +1,43 @@ +#ifndef _LINUX_VIRTIO_IDS_H +#define _LINUX_VIRTIO_IDS_H +/* + * Virtio IDs + * + * This header is BSD licensed so anyone can use the definitions to implement + * compatible drivers/servers. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + *notice, this list of conditions and the following disclaimer in the + *documentation and/or other materials provided with the distribution. + * 3. Neither the name of IBM nor the names of its contributors + *may be used to endorse or promote products derived from this software + *without specific prior written permission. + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL IBM OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. */ + +#define VIRTIO_ID_NET 1 /* virtio net */ +#define VIRTIO_ID_BLOCK2 /* virtio block */ +#define VIRTIO_ID_CONSOLE 3 /* virtio console */ +#define VIRTIO_ID_RNG 4 /* virtio rng */ +#define VIRTIO_ID_BALLOON 5 /* virtio balloon */ +#define VIRTIO_ID_RPMSG7 /* virtio remote processor messaging */ +#define VIRTIO_ID_SCSI 8 /* virtio scsi */ +#define VIRTIO_ID_9P 9 /* 9p virtio console */ +#define VIRTIO_ID_RPROC_SERIAL 11 /* virtio remoteproc serial link */ +#define VIRTIO_ID_CAIF12 /* Virtio caif */ + +#endif /* _LINUX_VIRTIO_IDS_H */ -- MST
Re: [Qemu-devel] make check breakage on 32 bit hosts
On Sun, May 26, 2013 at 12:00:57PM +, Blue Swirl wrote: I get this on i386 chroot for make check: GTESTER tests/test-qmp-output-visitor ** ERROR:/src/qemu/tests/test-qmp-output-visitor.c:595:check_native_list: assertion failed: (tmp) GTester: last random seed: R02S559792e7c8d0762d9a2ee153fba8896c ** Tests case looks correct, problem seems to be that we cast list node to GenericList, which expects the 'value' field to be a pointer type. With native lists types these are in some cases non-pointer types, like intList, where 'value' is an int64_t. On 32-bit archs this cast leads to use uses incorrect offset when trying to traverse the list. Don't see a way to fix this outside of making the code generators do a bit of massaging for these cases rather than a cast. Looking at it now, but might not be able to send a patch till later.
[Qemu-devel] [PATCH v2] monitor: work around delayed CHR_EVENT_OPENED events
In the past, CHR_EVENT_OPENED events were emitted via a pre-expired
QEMUTimer. Due to timers being processing at the tail end of each main
loop iteration, this generally meant that such events would be emitted
within the same main loop iteration, prior any client data being read
by tcp/unix socket server backends.
With 9f939df955a4152aad69a19a77e0898631bb2c18, this was switched to
a bottom-half that is registered via g_idle_add(). This makes it
likely that the event won't be sent until a subsequent iteration, and
also adds the possibility that such events will race with the
processing of client data.
In cases where we rely on the CHR_EVENT_OPENED event being delivered
prior to any client data being read, this may cause unexpected behavior.
In the case of a QMP monitor session using a socket backend, the delayed
processing of the CHR_EVENT_OPENED event can lead to a situation where
a previous session, where 'qmp_capabilities' has already processed, can
cause the rejection of 'qmp_capabilities' for a subsequent session,
since we reset capabilities in response to CHR_EVENT_OPENED, which may
not yet have been delivered. This can be reproduced with the following
command, generally within 50 or so iterations:
mdroth@loki:~$ cat cmds
{'execute':'qmp_capabilities'}
{'execute':'query-cpus'}
mdroth@loki:~$ while true; do if socat stdio unix-connect:/tmp/qmp.sock
cmds | grep CommandNotFound /dev/null; then echo failed; break; else
echo ok; fi; done;
ok
ok
failed
mdroth@loki:~$
As a work-around, we reset capabilities as part of the CHR_EVENT_CLOSED
hook, which gets called as part of the GIOChannel cb associated with the
client rather than a bottom-half, and is thus guaranteed to be delivered
prior to accepting any subsequent client sessions.
This does not address the more general problem of whether or not there
are chardev users that rely on CHR_EVENT_OPENED being delivered prior to
client data, and whether or not we should consider moving CHR_EVENT_OPENED
in-band with connection establishment as a general solution, but fixes
QMP for the time being.
Reported-by: Stefan Priebe s.pri...@profihost.ag
Cc: qemu-sta...@nongnu.org
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
v1-v2:
* remove command_mode reset from CHR_EVENT_OPENED case, since this
might still cause a race
monitor.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/monitor.c b/monitor.c
index 6ce2a4e..f1953a0 100644
--- a/monitor.c
+++ b/monitor.c
@@ -4649,7 +4649,6 @@ static void monitor_control_event(void *opaque, int event)
switch (event) {
case CHR_EVENT_OPENED:
-mon-mc-command_mode = 0;
data = get_qmp_greeting();
monitor_json_emitter(mon, data);
qobject_decref(data);
@@ -4660,6 +4659,7 @@ static void monitor_control_event(void *opaque, int event)
json_message_parser_init(mon-mc-parser, handle_qmp_command);
mon_refcount--;
monitor_fdsets_cleanup();
+mon-mc-command_mode = 0;
break;
}
}
--
1.7.9.5
Re: [Qemu-devel] [Qemu-stable] qmp commands get rejected
On Sun, May 26, 2013 at 05:13:36PM +0200, Stefan Priebe wrote:
Am 26.05.2013 03:23, schrieb mdroth:
On Sat, May 25, 2013 at 01:09:50PM +0200, Stefan Priebe wrote:
Am 25.05.2013 00:32, schrieb mdroth:
On Sat, May 25, 2013 at 12:12:22AM +0200, Stefan Priebe wrote:
Am 25.05.2013 00:09, schrieb mdroth:
I would try to create a small example script.
I use qmp-shell and other little scripts very often.
Am this be due to the fact that I don't wait for the welcome banner
right now?
If you're not reading from the socket, then you'll get the banner back
when
you read your first response. But qom-set shouldn't fail because of
that.
I can workaround it by adding this patch:
diff --git a/monitor.c b/monitor.c
index 62aaebe..9997520 100644
--- a/monitor.c
+++ b/monitor.c
@@ -4239,7 +4239,8 @@ static int monitor_can_read(void *opaque)
static int invalid_qmp_mode(const Monitor *mon, const char *cmd_name)
{
int is_cap = compare_cmd(cmd_name, qmp_capabilities);
-return (qmp_cmd_mode(mon) ? is_cap : !is_cap);
+//return (qmp_cmd_mode(mon) ? is_cap : !is_cap);
+return ((is_cap 0) ? 0 : (qmp_cmd_mode(mon) ? is_cap : !is_cap));
}
I think this is unrelated to your original issue. If you issue
'qmp_capabilities' command more than once you will get CommandNotFound,
and that behavior seems to be present even with v1.3.0. This patch seems
to be masking the problem you're having (which seems to be state from
previous monitor sessions/connections leaking into subsequent ones).
That sounds reasonable. I'm using proxmox / PVE which does a lot of
qmp queries in the background. So i might see situations where X
connections in parallel do qmp queries.
It's possible the GSource-based mechanism for handling I/O for chardev
backends is causing a difference in behavior. Still not sure exactly
what's going on though.
Can i revert some patches to test?
I think somewhere prior to this one should be enough to test:
2ea5a7af7bfa576a5936400ccca4144caca9640b
YES! I used 2ea5a7af7bfa576a5936400ccca4144caca9640b~1 for my tests
and this works absoluty fine.
Turns out the real culprit was a few commits later:
9f939df955a4152aad69a19a77e0898631bb2c18
I've sent a workaround this fixes things for QMP, but we may need a more
general fix. Please give it a shot and see if it fixes your issues:
http://article.gmane.org/gmane.comp.emulators.qemu/213106
no i got again:
The command qom-set has not been found JSON Reply: {id:
21677:2, error: {class: CommandNotFound, desc: The
command qom-set has not been found}} JSON Query:
{execute:qom-set,id:21677:2,arguments:{value:2,path:machine/peripheral/balloon0,property:guest-stats-polling-interval}}
at /usr/share/perl5/PVE/QMPClient.pm line 101.
Darn, I noticed another potential race after I sent the patch. Hadn't
been able to trigger it on my end, but it might be what you're hitting.
Just sent a v2, can you give that a shot?
http://article.gmane.org/gmane.comp.emulators.qemu/213147
Stefan
Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code
On 26 May 2013 16:22, Michael S. Tsirkin m...@redhat.com wrote: virtio linux headers are actually pretty portable: all we need is implement linux/types.h in a portable way, and we can import them and use on any platform. These patches do exactly that, as a pre-requisite to adding support for new virtio layout. Note: if someone adds non-portable code in files we import from linux-headers, we'll have to revert to copying code manually. This didn't happen yet so hopefully it won't. This series breaks compilation on MacOSX: CCnet/eth.o In file included from net/eth.c:18: In file included from /Users/pm215/src/qemu/include/net/eth.h:29: /Users/pm215/src/qemu/linux-headers/linux/if_ether.h:24:10: fatal error: 'linux/types.h' file not found #include linux/types.h ^ 1 error generated. make: *** [net/eth.o] Error 1 thanks -- PMM
Re: [Qemu-devel] [update][PATCH 00/12] target-i386: remove some macros
Am 24.05.2013 13:37, schrieb Andreas Färber: Am 23.04.2013 10:16, schrieb liguang: remove macros EAX, EBX, ECX, EDX, EBP, ESP, ESI, EDI, EIP, DF as suggested by Richard Henderson r...@twiddle.net Li Guang (12) target-i386/helper: remove EAX macro target-i386/helper: remove EBX macro target-i386/helper: remove ECX macro target-i386/helper: remove EDX macro target-i386/helper: remove EBP macro target-i386/helper: remove ESP macro target-i386/helper: remove ESI macro target-i386/helper: remove EDI macro target-i386/helper: remove EIP macro target-i386/helper: remove DF macro target-i386/helper: remove redundant env-eip assignment target-i386: fix over 80 chars warnings Hard Freeze is over, so more time to look into refactorings: There's one thing to be aware of here, macros would make it easier to transition from CPUX86State to X86CPU fields. However I am guessing that all these registers are accessed by TCG code via offsets from cpu_env - please verify that. Confirmed, I just stumbled over it myself in translate.c: * all but EIP and DF are assigned to cpu_regs[] * EIP is manually stored with offsetof() twice * DF is manually loaded/stored with offsetof() thrice Andreas If so, Reviewed-by: Andreas Färber afaer...@suse.de However, it would be nice if you could fix the \ alignment in patch 06/12 or in the cleanup patch 12/12. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] Potential to accelerate QEMU for specific architectures
On Sun, May 26, 2013 at 12:00 PM, Andreas Färber afaer...@suse.de wrote: Am 26.05.2013 07:40, schrieb Lior Vernia: On Sat, May 25, 2013 at 10:06 PM, Andreas Färber afaer...@suse.de wrote: Am 24.05.2013 21:24, schrieb Lior Vernia: I am running x86 applications on an ARM device using QEMU, and found it too slow for my needs. Before we start going into technical details, what are you trying to achieve on a high level and how did you try to do it? Are you using qemu-system-x86_64 or qemu-x86_64? The latest v1.5.0? Sorry, right after I wrote the message it occured to me I should have mentioned that I was talking about qemu-system, either x86 or i386. At the moment I just ran the limbo app on a Galaxy SIII with various images, just to see the capabilities, and was disappointed. Limbo seems to run v1.1.0. First time I hear of that app... v1.1.0 is a year old, many TCG improvements have happened since. Suggest you contact the app's author to get that updated to v1.5.0. http://git.qemu.org/?p=qemu.git;a=history;f=tcg/arm;hb=HEAD If you suspect that it's the JNI wrapping that's causing a lot of the damage, The UI (drawing) code could also be a potential bottleneck - but judging from the files it looks as if the UI were just a Java VNC client, which probably accesses a JNI-unaffected QEMU process? Yes, that was my impression as well. http://code.google.com/p/limbo-android/source/browse/#git%2Fsrc then we can talk about compiling QEMU for ARM and running it natively, I just haven't been able to get that to work. That would take some of the uncertainties out of the equation, yes. A little off-topic, so maybe I'll start a different thread on how I tried to compile and what I got when trying to run it. You still haven't said what it is that you would like to do with system emulation on your ARM device: Does it need to be x86? If you just want access to a full Linux system from Android, you might be more interested in investigating qemu-system-arm with KVM acceleration (requires Cortex-A15 and 3.9+ kernel) - in practice virtualization will be faster than anything binary translation can offer. Yes, I'm sorry if I haven't made that clear enough, the mission statement would be to run an arbitrary x86 system image on an ARM host. Preferably as a non-privileged user. Both of which led me to QEMU. Lior. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] Potential to accelerate QEMU for specific architectures
Hi Peter, On May 26, 2013 12:26 PM, Peter Maydell peter.mayd...@linaro.org wrote: On 26 May 2013 06:40, Lior Vernia liorv...@gmail.com wrote: Sorry, right after I wrote the message it occured to me I should have mentioned that I was talking about qemu-system, either x86 or i386. At the moment I just ran the limbo app on a Galaxy SIII with various images, just to see the capabilities, and was disappointed. Limbo seems to run v1.1.0. I wanted to add that I've been reading about this Russian startup that's looking to emulate x86 on ARM at 40% of native speed using dynamic binary translation (as far as I gather): http://www.bit-tech.net/news/hardware/2012/10/04/x86-on-arm/1 So this should be possible. And it can't be very much unlike QEMU, can it? That article suggests they're doing application-level translation, not system-level emulation. If you: * design your emulation from scratch with that use case in mind (qemu is system emulation first with app-level as a secondary case) * are happy to have just one guest and one target architecture (this is actually mostly useful in that it reduces the set of things you have to test; it also lets you take shortcuts in corner cases for your initial implementation) * put more concentrated effort into emulation performance than QEMU then you should be able to do better than qemu does currently. You'd probably end up with something like Transitive's QuickTransit/ Rosetta. What about no to the first bullet but yes to the second (just x86 on ARM)? Any room for significant improvement in that case, starting from the foundations of QEMU? thanks -- PMM
Re: [Qemu-devel] [PATCH 00/10] target-arm: fix TCGv usage (AArch64 prep)
On Thu, May 23, 2013 at 11:59 AM, Peter Maydell
peter.mayd...@linaro.org wrote:
This patch series is preparatory cleanup for the impending
AArch64 support.
Thanks, applied 1 to 9.
Patch 1 replaces all the uses of TCGv, tcg_temp_new(), etc in the
current 32 bit ARM decoder with the specifically-TCGv_i32 versions.
This is necessary for supporting a 64-bit core, which will have
TARGET_LONG_BITS==64 (and so TCGv == TCGv_i64) but still wants 32 bit
vaddrs, register sizes, etc in the A32/T32/T16 instruction sets. The
mechanical conversion is correct for everything except the arguments
to tcg_gen_qemu_{ld,st}*, which we handle separately later.
Patches 2-9 remove the gen_ld* and gen_st* helper functions in favour
of open-coding the creation/deletion of the TCG temp. I think this
makes the code easier to understand because the temp creation and
deletion is all at the same level of the code and it reduces the
current confusing situation where some gen_ functions will destroy a
temp they're passed and some will not. I think it also brings it
closer into line with other targets. That said, if there's pushback
that this part of the patchset is going in the wrong direction I can
drop it. (Conversely, if people like it then there are other
functions like load_reg() and store_reg() which could also be changed
not to create/destroy temporaries.)
Patch 10 fixes the load/store bits that patch 1 did not, by
abstracting out AArch32 load/store into gen functions which
extend/truncate the 32 bit values to 64 bits as necessary. NB that
the TARGET_LONG_BITS==64 parts are only compile-tested. I include it
in this series because it completes the work that patch 1 starts,
and as motivation/indication of direction.
Peter Maydell (10):
target-arm: Don't use TCGv when we mean TCGv_i32
target-arm: Remove gen_ld64() and gen_st64()
target-arm: Remove uses of gen_{ld,st}* from iWMMXt code
target-arm: Remove uses of gen_{ld,st}* from Neon code
target-arm: Remove use of gen_{ld,st}* from ldrex/strex
target-arm: Remove gen_{ld,st}* from basic ARM insns
target-arm: Remove gen_{ld,st}* from Thumb insns
target-arm: Remove gen_{ld,st}* from thumb2 decoder
target-arm: Remove gen_{ld,st}* definitions
target-arm: Abstract out load/store from a vaddr in AArch32
target-arm/translate.c | 862
+++-
1 file changed, 490 insertions(+), 372 deletions(-)
--
1.7.9.5
Re: [Qemu-devel] [PATCH] Remove OSS support for OpenBSD
On Fri, May 24, 2013 at 11:01 PM, Brad Smith b...@comstyle.com wrote:
Remove the OSS support for OpenBSD. The OSS API has not been usable
for quite some time.
Signed-off-by: Brad Smith b...@comstyle.com
Thanks, applied.
diff --git a/audio/ossaudio.c b/audio/ossaudio.c
index 00be9c9..007c641 100644
--- a/audio/ossaudio.c
+++ b/audio/ossaudio.c
@@ -25,11 +25,7 @@
#include sys/mman.h
#include sys/types.h
#include sys/ioctl.h
-#ifdef __OpenBSD__
-#include soundcard.h
-#else
#include sys/soundcard.h
-#endif
#include qemu-common.h
#include qemu/main-loop.h
#include qemu/host-utils.h
diff --git a/configure b/configure
index 5ae7e4a..eb74510 100755
--- a/configure
+++ b/configure
@@ -468,9 +468,8 @@ NetBSD)
OpenBSD)
bsd=yes
make=${MAKE-gmake}
- audio_drv_list=oss
- audio_possible_drivers=oss sdl esd
- oss_lib=-lossaudio
+ audio_drv_list=sdl
+ audio_possible_drivers=sdl esd
;;
Darwin)
bsd=yes
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: [Qemu-devel] IDE disk FLUSH take more than 30 secs, the SUSE guest reports lost interrupt and the file system becomes read-only
Am 21.05.2013 09:12, schrieb Gonglei (Arei):
Through analysis, I found that because the system call the fdatasync command
in the Qemu over 30s,
after the Guest's kernel thread detects the io transferation is timeout, went
to check IDE disk state.
But the IDE disk status is 0x50, rather than the BSY status, and then
departed error process...
the path of kernel's action is :
scsi_softirq_done
scsi_eh_scmd_add
scsi_error_handler
shost-transportt-eh_strategy_handler
ata_scsi_error
ap-ops-lost_interrupt
ata_sff_lost_interrupt
Finally, the file system becomes read-only.
Why not set the IDE disk for the BSY status When 0xe7 command is executed in
the Qemu?
Have you actually tried that out with a patch such as the following?
diff --git a/hw/ide/core.c b/hw/ide/core.c
index c7a8041..bf1ff18 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -795,6 +795,8 @@ static void ide_flush_cb(void *opaque, int ret)
{
IDEState *s = opaque;
+s-status = ~BUSY_STAT;
+
if (ret 0) {
/* XXX: What sector number to set here? */
if (ide_handle_rw_error(s, -ret, BM_STATUS_RETRY_FLUSH)) {
@@ -814,6 +816,7 @@ void ide_flush_cache(IDEState *s)
return;
}
+s-status |= BUSY_STAT;
bdrv_acct_start(s-bs, s-acct, 0, BDRV_ACCT_FLUSH);
bdrv_aio_flush(s-bs, ide_flush_cb, s);
}
No clue if this is spec-compliant. ;)
Note however that qemu_fdatasync() is done in the flush callback of
block/raw-posix.c, so IIUC everything calling bdrv_aio_flush() or
bdrv_flush_all() may potentially run into issues beyond just ATA:
hw/block/virtio-blk.c
hw/block/xen_disk.c
hw/ide/core.c
hw/scsi/scsi-disk.c
cpus.c:do_vm_stop()
hw/xen/xen_platform.c:platform_fixed_ioport_writew()
qemu_fdatasync() further occurs in:
hw/block/dataplane/virtio-blk.c:process_request()
hw/9pfs/virtio-9p-*.c
Quite possibly not all of them are problematic, but flush times 30 sec
are very likely not well tested by developers...
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [PATCH v2] e600 core for MPC86xx processors
MPC86xx processors are based on the e600 core, which is not the case
in qemu where it is based on the 7400 processor.
This patch creates the e600 core and instantiates the MPC86xx
processors based on it. Therefore, adding the high BATs and the SPRG
4..7 registers, which are e600-specific [1].
This allows to define the MPC8610 processor too and my program running
on a real MPC8610 target is now able to run on qemu :)
[1] http://cache.freescale.com/files/32bit/doc/ref_manual/E600CORERM.pdf
Signed-off-by: Julio Guerra gu...@julio.in
---
target-ppc/cpu-models.c | 10 ++--
target-ppc/cpu-models.h | 4 +-
target-ppc/translate_init.c | 122
3 files changed, 127 insertions(+), 9 deletions(-)
diff --git a/target-ppc/cpu-models.c b/target-ppc/cpu-models.c
index 17f56b7..8a2ab50 100644
--- a/target-ppc/cpu-models.c
+++ b/target-ppc/cpu-models.c
@@ -792,17 +792,15 @@
POWERPC_DEF_SVR(MPC8572E, MPC8572E,
CPU_POWERPC_MPC8572E, POWERPC_SVR_8572E, e500v2)
/* e600 family */
-POWERPC_DEF(e600, CPU_POWERPC_e600, 7400,
+POWERPC_DEF(e600, CPU_POWERPC_e600, e600,
PowerPC e600 core)
/* PowerPC e600 microcontrollers */
-#if defined(TODO)
POWERPC_DEF_SVR(MPC8610, MPC8610,
-CPU_POWERPC_MPC8610, POWERPC_SVR_8610, 7400)
-#endif
+CPU_POWERPC_MPC8610, POWERPC_SVR_8610, e600)
POWERPC_DEF_SVR(MPC8641, MPC8641,
-CPU_POWERPC_MPC8641, POWERPC_SVR_8641, 7400)
+CPU_POWERPC_MPC8641, POWERPC_SVR_8641, e600)
POWERPC_DEF_SVR(MPC8641D, MPC8641D,
-CPU_POWERPC_MPC8641D, POWERPC_SVR_8641D, 7400)
+CPU_POWERPC_MPC8641D, POWERPC_SVR_8641D, e600)
/* 32 bits classic PowerPC */
/* PowerPC 6xx family*/
POWERPC_DEF(601_v0,CPU_POWERPC_601_v0, 601,
diff --git a/target-ppc/cpu-models.h b/target-ppc/cpu-models.h
index a94f835..8ba96bb 100644
--- a/target-ppc/cpu-models.h
+++ b/target-ppc/cpu-models.h
@@ -731,9 +731,7 @@ enum {
POWERPC_SVR_8568E = 0x807D0011 | POWERPC_SVR_E500,
POWERPC_SVR_8572 = 0x80E00010 | POWERPC_SVR_E500,
POWERPC_SVR_8572E = 0x80E80010 | POWERPC_SVR_E500,
-#if 0
-POWERPC_SVR_8610 = xxx,
-#endif
+POWERPC_SVR_8610 = 0x80A00011,
POWERPC_SVR_8641 = 0x80900021,
POWERPC_SVR_8641D = 0x80900121,
};
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 021a31e..916fe0d 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -6525,2 +6525,2 @@ POWERPC_FAMILY(7457)(ObjectClass *oc, void *data)
POWERPC_FLAG_BUS_CLK;
}
+static void init_proc_e600(CPUPPCState *env)
+{
+gen_spr_ne_601(env);
+gen_spr_7xx(env);
+/* Time base */
+gen_tbl(env);
+/* 74xx specific SPR */
+gen_spr_74xx(env);
+/* XXX : not implemented */
+spr_register(env, SPR_UBAMR, UBAMR,
+ spr_read_ureg, SPR_NOACCESS,
+ spr_read_ureg, SPR_NOACCESS,
+ 0x);
+/* XXX : not implemented */
+spr_register(env, SPR_LDSTCR, LDSTCR,
+ SPR_NOACCESS, SPR_NOACCESS,
+ spr_read_generic, spr_write_generic,
+ 0x);
+/* XXX : not implemented */
+spr_register(env, SPR_ICTRL, ICTRL,
+ SPR_NOACCESS, SPR_NOACCESS,
+ spr_read_generic, spr_write_generic,
+ 0x);
+/* XXX : not implemented */
+spr_register(env, SPR_MSSSR0, MSSSR0,
+ SPR_NOACCESS, SPR_NOACCESS,
+ spr_read_generic, spr_write_generic,
+ 0x);
+/* XXX : not implemented */
+spr_register(env, SPR_PMC5, PMC5,
+ SPR_NOACCESS, SPR_NOACCESS,
+ spr_read_generic, spr_write_generic,
+ 0x);
+/* XXX : not implemented */
+spr_register(env, SPR_UPMC5, UPMC5,
+ spr_read_ureg, SPR_NOACCESS,
+ spr_read_ureg, SPR_NOACCESS,
+ 0x);
+/* XXX : not implemented */
+spr_register(env, SPR_PMC6, PMC6,
+ SPR_NOACCESS, SPR_NOACCESS,
+ spr_read_generic, spr_write_generic,
+ 0x);
+/* XXX : not implemented */
+spr_register(env, SPR_UPMC6, UPMC6,
+ spr_read_ureg, SPR_NOACCESS,
+ spr_read_ureg, SPR_NOACCESS,
+ 0x);
+/* SPRGs */
+spr_register(env, SPR_SPRG4, SPRG4,
+
Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code
On Sun, May 26, 2013 at 04:43:57PM +0100, Peter Maydell wrote: On 26 May 2013 16:22, Michael S. Tsirkin m...@redhat.com wrote: virtio linux headers are actually pretty portable: all we need is implement linux/types.h in a portable way, and we can import them and use on any platform. These patches do exactly that, as a pre-requisite to adding support for new virtio layout. Note: if someone adds non-portable code in files we import from linux-headers, we'll have to revert to copying code manually. This didn't happen yet so hopefully it won't. This series breaks compilation on MacOSX: CCnet/eth.o In file included from net/eth.c:18: In file included from /Users/pm215/src/qemu/include/net/eth.h:29: /Users/pm215/src/qemu/linux-headers/linux/if_ether.h:24:10: fatal error: 'linux/types.h' file not found #include linux/types.h ^ 1 error generated. make: *** [net/eth.o] Error 1 thanks -- PMM Could be a stale file in your tree ... Did configure get re-run? Could you post the config-host.mak file please?
Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code
On 26 May 2013 18:51, Michael S. Tsirkin m...@redhat.com wrote: On Sun, May 26, 2013 at 04:43:57PM +0100, Peter Maydell wrote: This series breaks compilation on MacOSX: CCnet/eth.o In file included from net/eth.c:18: In file included from /Users/pm215/src/qemu/include/net/eth.h:29: /Users/pm215/src/qemu/linux-headers/linux/if_ether.h:24:10: fatal error: 'linux/types.h' file not found #include linux/types.h ^ 1 error generated. make: *** [net/eth.o] Error 1 Could be a stale file in your tree ... Did configure get re-run? Could you post the config-host.mak file please? Configure did get rerun, but where are you expecting the header to pull linux/types.h from? Your patchset adds files which include it but doesn't add any copy itself, so if you're not on a Linux host then it just doesn't exist... config-host.mak attached. thanks -- PMM config-host.mak Description: Binary data
Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code
On Sun, May 26, 2013 at 07:00:58PM +0100, Peter Maydell wrote: On 26 May 2013 18:51, Michael S. Tsirkin m...@redhat.com wrote: On Sun, May 26, 2013 at 04:43:57PM +0100, Peter Maydell wrote: This series breaks compilation on MacOSX: CCnet/eth.o In file included from net/eth.c:18: In file included from /Users/pm215/src/qemu/include/net/eth.h:29: /Users/pm215/src/qemu/linux-headers/linux/if_ether.h:24:10: fatal error: 'linux/types.h' file not found #include linux/types.h ^ 1 error generated. make: *** [net/eth.o] Error 1 Could be a stale file in your tree ... Did configure get re-run? Could you post the config-host.mak file please? Configure did get rerun, but where are you expecting the header to pull linux/types.h from? Your patchset adds files which include it but doesn't add any copy itself, so if you're not on a Linux host then it just doesn't exist... config-host.mak attached. thanks -- PMM Ouch. Forgot to git-add them. Thanks. I'll send a fixed version - could you please try this patch on top? linux-stubs: linux/types.h This adds a directory with minimal stubs that make it possible to use some linux headers in qemu in a portable environment. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- diff --git a/linux-stubs/linux/types.h b/linux-stubs/linux/types.h new file mode 100644 index 000..8642cbb --- /dev/null +++ b/linux-stubs/linux/types.h @@ -0,0 +1,37 @@ +#ifndef STUBS_LINUX_TYPES_H +#define STUBS_LINUX_TYPES_H + +#include stdint.h + +/* + * Below are Linux-specific types that should never collide with + * any application/library that wants linux/types.h. + */ + +typedef uint8_t __u8; +typedef uint16_t __u16; +typedef uint32_t __u32; +typedef uint64_t __u64; + +#ifdef __CHECKER__ +#define __bitwise__ __attribute__((bitwise)) +#else +#define __bitwise__ +#endif +#ifdef __CHECK_ENDIAN__ +#define __bitwise __bitwise__ +#else +#define __bitwise +#endif + +typedef __u16 __bitwise __le16; +typedef __u16 __bitwise __be16; +typedef __u32 __bitwise __le32; +typedef __u32 __bitwise __be32; +typedef __u64 __bitwise __le64; +typedef __u64 __bitwise __be64; + +typedef __u16 __bitwise __sum16; +typedef __u32 __bitwise __wsum; + +#endif -- MST
Re: [Qemu-devel] [PATCH] makefile: detect corrupted elf files
On Sun, May 26, 2013 at 1:40 PM, Michael S. Tsirkin m...@redhat.com wrote: On Sun, May 26, 2013 at 02:36:28PM +0100, Peter Maydell wrote: On 26 May 2013 13:31, Michael S. Tsirkin m...@redhat.com wrote: On Sun, May 26, 2013 at 10:12:21AM +0100, Peter Maydell wrote: I definitely think individual project makefiles are the wrong place to fix this. If create-as-temp-and-rename is useful functionality it needs to go in the compiler so that everybody benefits. This will not help users on existing systems. Also it's not just compiler. We'd have to do it in linker, asm, ... lots of work. This is clearly less work than implementing it in the makefile of every single open source project in the world (or even every single open source project in Debian). You seem to have removed the part that explained that 1. we run scripts in our makefiles so need to handle that anyway 2. we care about users on existing systems A generic hook (default none, or maybe test -s) after object production and before linkage should be enough but would scale to SHA producing/verifying tools. This means that we would need the fix in our makefiles even if compiler and linker gain this feature. Depends on the feature. If the object files have robust checksums which are checked after output and before input, this should be transparent to the build system. You are wellcome to implement this in compiler/linker/etc if you like but we will still want to handle it in our makefile as well. I specifically don't want it handled in our makefiles because it's the wrong place to fix the problem and it will make our build system more complicated. +1 Also, what is the worst case scenario? The link fails and you have to clean up and rebuild? An automated build system can't produce the expected output if the build machine is unreliable? -- PMM
Re: [Qemu-devel] [PATCH 17/30] memory: add address_space_translate
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 26/05/2013 11:12, Jan Kiszka ha scritto:
On 2013-05-26 11:01, Paolo Bonzini wrote:
Il 25/05/2013 13:30, Jan Kiszka ha scritto:
On 2013-05-25 13:20, Paolo Bonzini wrote:
Il 25/05/2013 12:19, Jan Kiszka ha scritto:
addr -= section-offset_within_address_space; -len
= MIN(section-size - addr, len);
^
This is the size of a section minus an offset in the
section.
+diff = int128_sub(section-mr-size,
int128_make64(addr));
^
This is the size of a region minus the same offset in the
section.
+len = MIN(int128_get64(diff), len);
/* Compute offset within MemoryRegion */ addr +=
section-offset_within_region;
So this has to be moved above.
Right, fixed.
Do you have a branch pushed somewhere that I can test
against?
git://git.kiszka.org/qemu.git queues/ioport
And another thing... in ioport: Switch dispatching to memory
core layer, could you put memory_region_iorange_read/write in
mr-ops-read/write instead of adding an if in the dispatch
routines?
Not trivially because mr-opaque is passed to the read/write
handler, but memory_region_iorange_read/write needs the region. Can
add more data structures to handles this, but what does it buy us?
It's simpler, and I think it lets us remove ops-old_portio too. We
can have something like
typedef MemoryRegionPortioList {
MemoryRegion mr;
void *piolist_opaque;
MemoryRegionPortio pio[];
}
then you can set mr-opaque == mr. It's more similar to how other
regions are implemented, e.g. subpages.
Paolo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRolMGAAoJEBvWZb6bTYbym5wP/izYQtpCSLhiAe6LiyN5cSVj
wMe+gSqhqyvi8Ho/GewilHlp1L0UKXQs18KhKqZbEtVETFdvKYoU+sJCPqWbRThW
Gj62dfo1Zn814gnv/CxiebslcI5fiU2UrHtpW1oXBKCZWmLJrfZSJqT5K7o1Z8Y3
qRDcR2sIISIQgAxM/n2EbuJWq/v50BUCDOXgpT3eUrq3rvdQHbh/Ym+y8Zd74sXl
VhK3UmP17ro0YPLtImForhrFutgavtgKuKCVvMTkD04ZLrWrW+QdXJmGl+LuCp+M
L/ib7jaR/4uPJ1RiDPbZexKc956yRsA5gzvJo9kHE0B6IipM+uqVCbrfk96kWrAC
Cg3qGn26cT/bc4zNF7NudJxAErVaHf220iJecoqFXNi6OwZTM6IgHlVH58l+yrRE
swQlxqQHQoYEzm4ZzsuK9C9Y50Y4C6G0LzkEWeyvYi5UdbOxt/hl1yh0pdSnhSSx
47Hw28nZgceDpcySv/Deb3zBzw/Pxx1Z3wkTxMhVpZ6t3Bot/T9hmkGQyuFqvXWF
cdrJEdYmJ2CEkmY2uwKUWCZeMzNtR+qfij+QlcI9RjFoVlmlOySJmBwR55Y7yu5m
H4wRZjeQ8PtfpZH/NmmwkNPOxaghDTaUn9k9/rEQzCDM9b17ddovvDI8JYqo9oaa
K1di55883LPNfkvycya3
=dJkN
-END PGP SIGNATURE-
Re: [Qemu-devel] [PATCH] makefile: detect corrupted elf files
On Sun, May 26, 2013 at 06:20:17PM +, Blue Swirl wrote: On Sun, May 26, 2013 at 1:40 PM, Michael S. Tsirkin m...@redhat.com wrote: On Sun, May 26, 2013 at 02:36:28PM +0100, Peter Maydell wrote: On 26 May 2013 13:31, Michael S. Tsirkin m...@redhat.com wrote: On Sun, May 26, 2013 at 10:12:21AM +0100, Peter Maydell wrote: I definitely think individual project makefiles are the wrong place to fix this. If create-as-temp-and-rename is useful functionality it needs to go in the compiler so that everybody benefits. This will not help users on existing systems. Also it's not just compiler. We'd have to do it in linker, asm, ... lots of work. This is clearly less work than implementing it in the makefile of every single open source project in the world (or even every single open source project in Debian). You seem to have removed the part that explained that 1. we run scripts in our makefiles so need to handle that anyway 2. we care about users on existing systems A generic hook (default none, or maybe test -s) after object production and before linkage should be enough but would scale to SHA producing/verifying tools. This means that we would need the fix in our makefiles even if compiler and linker gain this feature. Depends on the feature. If the object files have robust checksums which are checked after output and before input, this should be transparent to the build system. You are wellcome to implement this in compiler/linker/etc if you like but we will still want to handle it in our makefile as well. I specifically don't want it handled in our makefiles because it's the wrong place to fix the problem and it will make our build system more complicated. +1 Also, what is the worst case scenario? The link fails and you have to clean up and rebuild? An automated build system can't produce the expected output if the build machine is unreliable? It's a simple issue. Each time I reboot during build, I have to make clean and rebuild. This wastes my time so I looked for ways to save the time. On my system at least, it has no measureable cost, likely also because size only looks at headers and metadata. If others are not interested, I can keep it out of tree. -- PMM
Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code
Il 26/05/2013 20:10, Michael S. Tsirkin ha scritto: On Sun, May 26, 2013 at 07:00:58PM +0100, Peter Maydell wrote: On 26 May 2013 18:51, Michael S. Tsirkin m...@redhat.com wrote: On Sun, May 26, 2013 at 04:43:57PM +0100, Peter Maydell wrote: This series breaks compilation on MacOSX: CCnet/eth.o In file included from net/eth.c:18: In file included from /Users/pm215/src/qemu/include/net/eth.h:29: /Users/pm215/src/qemu/linux-headers/linux/if_ether.h:24:10: fatal error: 'linux/types.h' file not found #include linux/types.h ^ 1 error generated. make: *** [net/eth.o] Error 1 Could be a stale file in your tree ... Did configure get re-run? Could you post the config-host.mak file please? Configure did get rerun, but where are you expecting the header to pull linux/types.h from? Your patchset adds files which include it but doesn't add any copy itself, so if you're not on a Linux host then it just doesn't exist... config-host.mak attached. thanks -- PMM Ouch. Forgot to git-add them. Thanks. I'll send a fixed version - could you please try this patch on top? linux-stubs: linux/types.h This adds a directory with minimal stubs that make it possible to use some linux headers in qemu in a portable environment. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- diff --git a/linux-stubs/linux/types.h b/linux-stubs/linux/types.h new file mode 100644 index 000..8642cbb --- /dev/null +++ b/linux-stubs/linux/types.h @@ -0,0 +1,37 @@ +#ifndef STUBS_LINUX_TYPES_H +#define STUBS_LINUX_TYPES_H + +#include stdint.h + +/* + * Below are Linux-specific types that should never collide with + * any application/library that wants linux/types.h. + */ + +typedef uint8_t __u8; +typedef uint16_t __u16; +typedef uint32_t __u32; +typedef uint64_t __u64; + +#ifdef __CHECKER__ +#define __bitwise__ __attribute__((bitwise)) +#else +#define __bitwise__ +#endif +#ifdef __CHECK_ENDIAN__ +#define __bitwise __bitwise__ +#else +#define __bitwise +#endif + +typedef __u16 __bitwise __le16; +typedef __u16 __bitwise __be16; +typedef __u32 __bitwise __le32; +typedef __u32 __bitwise __be32; +typedef __u64 __bitwise __le64; +typedef __u64 __bitwise __be64; + +typedef __u16 __bitwise __sum16; +typedef __u32 __bitwise __wsum; + I don't like defining __-prefixed types. Can we preprocess linux-headers to avoid usage of __u8/16/32/64, and to s,linux/types.h,stdint.h, ? Paolo +#endif
Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code
On Sun, May 26, 2013 at 08:26:14PM +0200, Paolo Bonzini wrote: Il 26/05/2013 20:10, Michael S. Tsirkin ha scritto: On Sun, May 26, 2013 at 07:00:58PM +0100, Peter Maydell wrote: On 26 May 2013 18:51, Michael S. Tsirkin m...@redhat.com wrote: On Sun, May 26, 2013 at 04:43:57PM +0100, Peter Maydell wrote: This series breaks compilation on MacOSX: CCnet/eth.o In file included from net/eth.c:18: In file included from /Users/pm215/src/qemu/include/net/eth.h:29: /Users/pm215/src/qemu/linux-headers/linux/if_ether.h:24:10: fatal error: 'linux/types.h' file not found #include linux/types.h ^ 1 error generated. make: *** [net/eth.o] Error 1 Could be a stale file in your tree ... Did configure get re-run? Could you post the config-host.mak file please? Configure did get rerun, but where are you expecting the header to pull linux/types.h from? Your patchset adds files which include it but doesn't add any copy itself, so if you're not on a Linux host then it just doesn't exist... config-host.mak attached. thanks -- PMM Ouch. Forgot to git-add them. Thanks. I'll send a fixed version - could you please try this patch on top? linux-stubs: linux/types.h This adds a directory with minimal stubs that make it possible to use some linux headers in qemu in a portable environment. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- diff --git a/linux-stubs/linux/types.h b/linux-stubs/linux/types.h new file mode 100644 index 000..8642cbb --- /dev/null +++ b/linux-stubs/linux/types.h @@ -0,0 +1,37 @@ +#ifndef STUBS_LINUX_TYPES_H +#define STUBS_LINUX_TYPES_H + +#include stdint.h + +/* + * Below are Linux-specific types that should never collide with + * any application/library that wants linux/types.h. + */ + +typedef uint8_t __u8; +typedef uint16_t __u16; +typedef uint32_t __u32; +typedef uint64_t __u64; + +#ifdef __CHECKER__ +#define __bitwise__ __attribute__((bitwise)) +#else +#define __bitwise__ +#endif +#ifdef __CHECK_ENDIAN__ +#define __bitwise __bitwise__ +#else +#define __bitwise +#endif + +typedef __u16 __bitwise __le16; +typedef __u16 __bitwise __be16; +typedef __u32 __bitwise __le32; +typedef __u32 __bitwise __be32; +typedef __u64 __bitwise __le64; +typedef __u64 __bitwise __be64; + +typedef __u16 __bitwise __sum16; +typedef __u32 __bitwise __wsum; + I don't like defining __-prefixed types. Can we preprocess linux-headers to avoid usage of __u8/16/32/64, and to s,linux/types.h,stdint.h, ? Paolo Let's not be purists, and do the practical thing. When I suggested this you didn't like it: I can think of two ways: - strip linux/types.h in update_headers - add a stub linux/types.h for non linux platforms The latter, using stdint.h types, would be fine. And now, I think it's cleaner to keep it as is. Most likely, these specific __ types work fine, *if* we see a problem we can think what's to be done. In particular, there are __le/__be tags there which can be useful to do static code analysis. What's the worst case failure scanario? Conflict with some system standard header on some strange target OS, this results in a failed build, and we go and try to fix it, almost surely with ifndef around some of the stubs. Why worry now? +#endif
Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code
Il 26/05/2013 20:37, Michael S. Tsirkin ha scritto: I don't like defining __-prefixed types. Can we preprocess linux-headers to avoid usage of __u8/16/32/64, and to s,linux/types.h,stdint.h, ? Paolo Let's not be purists, and do the practical thing. When I suggested this you didn't like it: I can think of two ways: - strip linux/types.h in update_headers - add a stub linux/types.h for non linux platforms The latter, using stdint.h types, would be fine. My fault. I should have looked at linux/types.h (actually asm-generic/). Paolo
Re: [Qemu-devel] [PATCH 12/15] s390x: reduce TARGET_PHYS_ADDR_SPACE_BITS to 62
Il 26/05/2013 16:14, Andreas Färber ha scritto: With the next patch, the memory API will complain if the TARGET_PHYS_ADDR_SPACE_BITS gets dangerously close to an overflow. s390x can handle up to 64 bit of physical address space from its page tables, but we never use that much. Just decrease the value. Cc: Alexander Graf ag...@suse.de Signed-off-by: Paolo Bonzini pbonz...@redhat.com Didn't Avi introduce 128-bit arithmetic into QEMU to avoid 64-bit values overflowing? Why are you limiting Memory API to 62-bit now? The next patch makes a difference between artificial memory regions (containers and aliases) which can have arbitrary placement and width, and the final view of the address space which cannot have a full 64-bit size. 63 bits probably would work, but I preferred to be safe since 62 is the largest used by other targets. It should be fixable, but if it is not a problem I wouldn't worry much about it. Paolo
Re: [Qemu-devel] [PATCH] makefile: detect corrupted elf files
On Sun, May 26, 2013 at 6:24 PM, Michael S. Tsirkin m...@redhat.com wrote: On Sun, May 26, 2013 at 06:20:17PM +, Blue Swirl wrote: On Sun, May 26, 2013 at 1:40 PM, Michael S. Tsirkin m...@redhat.com wrote: On Sun, May 26, 2013 at 02:36:28PM +0100, Peter Maydell wrote: On 26 May 2013 13:31, Michael S. Tsirkin m...@redhat.com wrote: On Sun, May 26, 2013 at 10:12:21AM +0100, Peter Maydell wrote: I definitely think individual project makefiles are the wrong place to fix this. If create-as-temp-and-rename is useful functionality it needs to go in the compiler so that everybody benefits. This will not help users on existing systems. Also it's not just compiler. We'd have to do it in linker, asm, ... lots of work. This is clearly less work than implementing it in the makefile of every single open source project in the world (or even every single open source project in Debian). You seem to have removed the part that explained that 1. we run scripts in our makefiles so need to handle that anyway 2. we care about users on existing systems A generic hook (default none, or maybe test -s) after object production and before linkage should be enough but would scale to SHA producing/verifying tools. This means that we would need the fix in our makefiles even if compiler and linker gain this feature. Depends on the feature. If the object files have robust checksums which are checked after output and before input, this should be transparent to the build system. You are wellcome to implement this in compiler/linker/etc if you like but we will still want to handle it in our makefile as well. I specifically don't want it handled in our makefiles because it's the wrong place to fix the problem and it will make our build system more complicated. +1 Also, what is the worst case scenario? The link fails and you have to clean up and rebuild? An automated build system can't produce the expected output if the build machine is unreliable? It's a simple issue. Each time I reboot during build, I have to make clean and rebuild. This wastes my time so I looked for ways to save the time. Compile under a stable kernel and test the bleeding edge kernel only as KVM guest? Get a different box for testing or compiling? Run 'sync' every time gcc finishes? Don't you have bigger problems with file systems due to the crashes? On my system at least, it has no measureable cost, likely also because size only looks at headers and metadata. For example on OpenBSD, 'size' does not seem to come from binutils, so there could be portability issues. If others are not interested, I can keep it out of tree. I've had problems with disk close to full, so I'm semi-interested if the solution does not slow down others and it's not too ugly. -- PMM
Re: [Qemu-devel] Win32 QEMU binaries built from MinGW fail (access violation)
Success of sorts. The new tool-chain seems to have fixed the
issue, but I seemed to have to use a meat cleaver to get it install
properly. In any case, I have a QEMU build working, but extremely
slowly. At this point I am content that QEMU can be built FROM
windows FOR windows, but someone might want to straighten up the
QEMU/MinGW documentation. It is not nearly as straight forward as it
sounds, and I think use of MinGW-w64 should become the ONLY supported
MinGW tool chain. My experience with the older MinGW was far from
favorable.
I did get a reply from another FROM windows FOR windows builder, and
it does look like all problems are related to my tool chain. I'll
spend some time this summer trying to figure out how to build up the
MinGW-w64 build environment properly without the use of my meat
cleaver. If I ever get a clean result that I'm happy with I'll post
my results and would be happy to contribute to the documentation when
the time comes.
Thanks again for your tips... and please let me know if you find a
good MinGW-w64 primmer you would suggest.
ref1: http://wiki.qemu.org/Hosts/W32
ref2: http://en.wikibooks.org/wiki/QEMU/MinGW
Long explination at:
http://screamingmonkeys.blogspot.com/2013/05/qemu-with-mingw-use-source-luke.html
On Sat, May 25, 2013 at 3:52 AM, Dan tpb8675...@gmail.com wrote:
Great Idea... never occurred to me that gdb would actually work in MinGW
So I tried that, specifically adding --enable-debug --disable-pie
(ref1) and now the failure went away, but it is DOG slow!
I will try the following this weekend and report back:
1) Try another MinGW-w32 build without --disable-pie to see if the
bug comes back despite (ref1).
2) Wipe my Cygwin and MinGW directories, and rebuild with the following:
a) Cygwin with {MinGW-w64 zlib gettext libiconv glib pkg-config} installed
b) Download libSDL and make native
3) Download Qemu source and rebuild with new tool chain.
a) If I get a crash, retry with debugging.
4) As a last resort, wipe and reload, this time using the Gtk+ bundle
instead of Cygwin repositories.
5) Repeat 1-4 as needed on Windows 8 x64 system and Windows Vista x86 system.
In either case, I should have some good results in a few days.
Thanks for the help.
ref1: http://stackoverflow.com/a/14276340
On Sat, May 25, 2013 at 1:27 AM, Stefan Weil s...@weilnetz.de wrote:
Am 25.05.2013 03:56, schrieb Dan:
I've been trying to build QEMU source directly with MinGW. The
compile/link works but there are tons of warnings (mostly Wformat).
Once I try to run the binaries in Windows though, I quickly hit access
violations once the HD image is mounted. I've tested on the
linux-0.2.img.bz2 so that I can be consistent with others. The
violations bounce around based on the image and emulation. I've tried
with -nographic to try to rule out SDL.dll. I'm at a loss, and
beginning to wonder if 100's of Wformat errors need to be patched one
by one to have a run-able windows binary.
What I'm confused by is that both qemu.org (ref1) and wikibooks.org
(ref2) seem to imply that there are no special MinGW patches. I've
also found many sites hosting valid QEMU win32 binaries like
omledom.com (ref3). I've even ensured that my ./configure settings
match theirs (omledom), but of course I have no way to know if they
are compiliing FROM windows FOR windows, or FROM linux FOR windows.
Here's is an abridged list of my process.
install cygwin to for wget and unzip, though nothing is in the PATH varable.
wget mingw-get-inst-20120426.exe
wget python-2.6.6.msi
wget gtk+-bundle_2.24.10-20120208_win32.zip
wget SDL-devel-1.2.15-mingw32.tar.gz
wget qemu-1.4.1.tar.bz2
wget linux-0.2.img.bz2
install mingw-get-inst-20120426.exe
install python-2.6.6.msi
unzip gtk+-bundle_2.24.10-20120208_win32.zip to c:\MinGW
unzip SDL-devel-1.2.15-mingw32.tar.gz to c:\MinGW\msys\1.0\src
unzip qemu-1.4.1.tar.bz2 to c:\MinGW\msys\1.0\src
decompress linux-0.2.img.bz2 to c:\MinGW\msys\1.0\bld
launch msys prompt cd /usr/src/SDL make native
launch msys prompt cd /usr/src/qemu
./configure --python=c:/Python26/python.exe --prefix=/usr/bld
make make install cd /usr/bld
./qemu-system-i386.exe linux-0.2.img
Observe an access violation in qemu-system-i386.exe within 5 seconds.
Am I the only one compiling qemu FROM windows FOR windows?
Also, just for grins, I replace my copy of qemu-system-i386.exe with
the one from omledom and things work without any issues. I've also
tried the qemu 1.5 repositories and this weeks .git snapshot. All
fail with similar errors.
I've also done this on two machines, an x86 Windows Vista system and
an x64 Windows 8 system. Same results on both.
ref1: http://wiki.qemu.org/Hosts/W32
ref2: http://en.wikibooks.org/wiki/QEMU/MinGW
ref3: http://www.omledom.com/
Long explanation at:
http://screamingmonkeys.blogspot.com/2013/05/return-to-linux-compiling-qemu-with.html
-Dan
Hi Dan,
native builds for Windows should
Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code
On Sun, May 26, 2013 at 08:53:33PM +0200, Paolo Bonzini wrote: Il 26/05/2013 20:37, Michael S. Tsirkin ha scritto: I don't like defining __-prefixed types. Can we preprocess linux-headers to avoid usage of __u8/16/32/64, and to s,linux/types.h,stdint.h, ? Paolo Let's not be purists, and do the practical thing. When I suggested this you didn't like it: I can think of two ways: - strip linux/types.h in update_headers - add a stub linux/types.h for non linux platforms The latter, using stdint.h types, would be fine. My fault. I should have looked at linux/types.h (actually asm-generic/). Paolo Not really, __uX appear in the headers that were posted. What I'm saying is - a chance of a conflict is very remote, if it happens it's a build failure so easy to debug. -- MST
Re: [Qemu-devel] [PATCH] makefile: detect corrupted elf files
On Sun, May 26, 2013 at 07:28:40PM +, Blue Swirl wrote: On Sun, May 26, 2013 at 6:24 PM, Michael S. Tsirkin m...@redhat.com wrote: On Sun, May 26, 2013 at 06:20:17PM +, Blue Swirl wrote: On Sun, May 26, 2013 at 1:40 PM, Michael S. Tsirkin m...@redhat.com wrote: On Sun, May 26, 2013 at 02:36:28PM +0100, Peter Maydell wrote: On 26 May 2013 13:31, Michael S. Tsirkin m...@redhat.com wrote: On Sun, May 26, 2013 at 10:12:21AM +0100, Peter Maydell wrote: I definitely think individual project makefiles are the wrong place to fix this. If create-as-temp-and-rename is useful functionality it needs to go in the compiler so that everybody benefits. This will not help users on existing systems. Also it's not just compiler. We'd have to do it in linker, asm, ... lots of work. This is clearly less work than implementing it in the makefile of every single open source project in the world (or even every single open source project in Debian). You seem to have removed the part that explained that 1. we run scripts in our makefiles so need to handle that anyway 2. we care about users on existing systems A generic hook (default none, or maybe test -s) after object production and before linkage should be enough but would scale to SHA producing/verifying tools. This means that we would need the fix in our makefiles even if compiler and linker gain this feature. Depends on the feature. If the object files have robust checksums which are checked after output and before input, this should be transparent to the build system. You are wellcome to implement this in compiler/linker/etc if you like but we will still want to handle it in our makefile as well. I specifically don't want it handled in our makefiles because it's the wrong place to fix the problem and it will make our build system more complicated. +1 Also, what is the worst case scenario? The link fails and you have to clean up and rebuild? An automated build system can't produce the expected output if the build machine is unreliable? It's a simple issue. Each time I reboot during build, I have to make clean and rebuild. This wastes my time so I looked for ways to save the time. Compile under a stable kernel and test the bleeding edge kernel only as KVM guest? Get a different box for testing or compiling? Run 'sync' every time gcc finishes? What's the question here? Don't you have bigger problems with file systems due to the crashes? As it happens, no. Maybe because I'm using ext4. Maybe I'm lucky. On my system at least, it has no measureable cost, likely also because size only looks at headers and metadata. For example on OpenBSD, 'size' does not seem to come from binutils, so there could be portability issues. True, I'm not saying it's perfect. If others are not interested, I can keep it out of tree. I've had problems with disk close to full, so I'm semi-interested if the solution does not slow down others and it's not too ugly. I think the simplest way to do it is to change makefile to unlike, create then rename. Then you are safe against abrupt killing or crashing make. And with a journaled fs, if you also have e.g. linux ext4 and mount with data=ordered, you are safe against power failures. It shouldn't be hard to do and I don't expect this to have any measureable speed impact. What do you think? -- PMM
Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code
Il 26/05/2013 22:02, Michael S. Tsirkin ha scritto: My fault. I should have looked at linux/types.h (actually asm-generic/). Not really, __uX appear in the headers that were posted. What I'm saying is - a chance of a conflict is very remote, if it happens it's a build failure so easy to debug. I'm sure that others will complain, :) but you can go ahead. Paolo
Re: [Qemu-devel] [PATCH] makefile: detect corrupted elf files
On Sun, May 26, 2013 at 8:15 PM, Michael S. Tsirkin m...@redhat.com wrote: On Sun, May 26, 2013 at 07:28:40PM +, Blue Swirl wrote: On Sun, May 26, 2013 at 6:24 PM, Michael S. Tsirkin m...@redhat.com wrote: On Sun, May 26, 2013 at 06:20:17PM +, Blue Swirl wrote: On Sun, May 26, 2013 at 1:40 PM, Michael S. Tsirkin m...@redhat.com wrote: On Sun, May 26, 2013 at 02:36:28PM +0100, Peter Maydell wrote: On 26 May 2013 13:31, Michael S. Tsirkin m...@redhat.com wrote: On Sun, May 26, 2013 at 10:12:21AM +0100, Peter Maydell wrote: I definitely think individual project makefiles are the wrong place to fix this. If create-as-temp-and-rename is useful functionality it needs to go in the compiler so that everybody benefits. This will not help users on existing systems. Also it's not just compiler. We'd have to do it in linker, asm, ... lots of work. This is clearly less work than implementing it in the makefile of every single open source project in the world (or even every single open source project in Debian). You seem to have removed the part that explained that 1. we run scripts in our makefiles so need to handle that anyway 2. we care about users on existing systems A generic hook (default none, or maybe test -s) after object production and before linkage should be enough but would scale to SHA producing/verifying tools. This means that we would need the fix in our makefiles even if compiler and linker gain this feature. Depends on the feature. If the object files have robust checksums which are checked after output and before input, this should be transparent to the build system. You are wellcome to implement this in compiler/linker/etc if you like but we will still want to handle it in our makefile as well. I specifically don't want it handled in our makefiles because it's the wrong place to fix the problem and it will make our build system more complicated. +1 Also, what is the worst case scenario? The link fails and you have to clean up and rebuild? An automated build system can't produce the expected output if the build machine is unreliable? It's a simple issue. Each time I reboot during build, I have to make clean and rebuild. This wastes my time so I looked for ways to save the time. Compile under a stable kernel and test the bleeding edge kernel only as KVM guest? Get a different box for testing or compiling? Run 'sync' every time gcc finishes? What's the question here? The question is if any of the suggestions solves the problem? Also how about something this: post boot, find -name '*.o' | xargs -iF sh -c 'if test ! -s F; then rm F;fi' Don't you have bigger problems with file systems due to the crashes? As it happens, no. Maybe because I'm using ext4. Maybe I'm lucky. On my system at least, it has no measureable cost, likely also because size only looks at headers and metadata. For example on OpenBSD, 'size' does not seem to come from binutils, so there could be portability issues. True, I'm not saying it's perfect. If others are not interested, I can keep it out of tree. I've had problems with disk close to full, so I'm semi-interested if the solution does not slow down others and it's not too ugly. I think the simplest way to do it is to change makefile to unlike, create then rename. Then you are safe against abrupt killing or crashing make. And with a journaled fs, if you also have e.g. linux ext4 and mount with data=ordered, you are safe against power failures. It shouldn't be hard to do and I don't expect this to have any measureable speed impact. What do you think? I'd prefer a more generic solution, like the hook. What you propose wouldn't protect from the disk full scenario. -- PMM
Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code
Paolo Bonzini pbonz...@redhat.com writes: Il 26/05/2013 22:02, Michael S. Tsirkin ha scritto: My fault. I should have looked at linux/types.h (actually asm-generic/). Not really, __uX appear in the headers that were posted. Which is a problem because this is a reserved namespace in C99. What I'm saying is - a chance of a conflict is very remote, if it happens it's a build failure so easy to debug. I'm sure that others will complain, :) but you can go ahead. I think we should clean up the virtio headers in the kernel first. Seems like a good thing to do given the standardization effort too. There are lots of headers in uapi that use the C99 int types so there doesn't seem to be a reason they couldn't be used in virtio. fuse.h even has a: #ifdef __KERNEL__ #include linux/types.h #else #include stdint.h #endif Which seems like a reasonable thing to do. The only other kernel dependency is linux/if_ether.h to define ETH_ALEN. But it seems completely reasonable to define a VIRTIO_NET_MAC_ALEN or something like that. This would make the virtio headers completely stand alone and includable in userspace (without violating C99). Perhaps it's even worth moving the headers from uapi/linux to uapi/virtio. Rusty, what do you think? Regards, Anhtony Liguori Paolo
Re: [Qemu-devel] [Qemu-stable] qmp commands get rejected
Am 26.05.2013 17:36, schrieb mdroth:
On Sun, May 26, 2013 at 05:13:36PM +0200, Stefan Priebe wrote:
Am 26.05.2013 03:23, schrieb mdroth:
On Sat, May 25, 2013 at 01:09:50PM +0200, Stefan Priebe wrote:
Am 25.05.2013 00:32, schrieb mdroth:
On Sat, May 25, 2013 at 12:12:22AM +0200, Stefan Priebe wrote:
Am 25.05.2013 00:09, schrieb mdroth:
I would try to create a small example script.
I use qmp-shell and other little scripts very often.
Am this be due to the fact that I don't wait for the welcome banner
right now?
If you're not reading from the socket, then you'll get the banner back
when
you read your first response. But qom-set shouldn't fail because of that.
I can workaround it by adding this patch:
diff --git a/monitor.c b/monitor.c
index 62aaebe..9997520 100644
--- a/monitor.c
+++ b/monitor.c
@@ -4239,7 +4239,8 @@ static int monitor_can_read(void *opaque)
static int invalid_qmp_mode(const Monitor *mon, const char *cmd_name)
{
int is_cap = compare_cmd(cmd_name, qmp_capabilities);
-return (qmp_cmd_mode(mon) ? is_cap : !is_cap);
+//return (qmp_cmd_mode(mon) ? is_cap : !is_cap);
+return ((is_cap 0) ? 0 : (qmp_cmd_mode(mon) ? is_cap : !is_cap));
}
I think this is unrelated to your original issue. If you issue
'qmp_capabilities' command more than once you will get CommandNotFound,
and that behavior seems to be present even with v1.3.0. This patch seems
to be masking the problem you're having (which seems to be state from
previous monitor sessions/connections leaking into subsequent ones).
That sounds reasonable. I'm using proxmox / PVE which does a lot of
qmp queries in the background. So i might see situations where X
connections in parallel do qmp queries.
It's possible the GSource-based mechanism for handling I/O for chardev
backends is causing a difference in behavior. Still not sure exactly
what's going on though.
Can i revert some patches to test?
I think somewhere prior to this one should be enough to test:
2ea5a7af7bfa576a5936400ccca4144caca9640b
YES! I used 2ea5a7af7bfa576a5936400ccca4144caca9640b~1 for my tests
and this works absoluty fine.
Turns out the real culprit was a few commits later:
9f939df955a4152aad69a19a77e0898631bb2c18
I've sent a workaround this fixes things for QMP, but we may need a more
general fix. Please give it a shot and see if it fixes your issues:
http://article.gmane.org/gmane.comp.emulators.qemu/213106
no i got again:
The command qom-set has not been found JSON Reply: {id:
21677:2, error: {class: CommandNotFound, desc: The
command qom-set has not been found}} JSON Query:
{execute:qom-set,id:21677:2,arguments:{value:2,path:machine/peripheral/balloon0,property:guest-stats-polling-interval}}
at /usr/share/perl5/PVE/QMPClient.pm line 101.
Darn, I noticed another potential race after I sent the patch. Hadn't
been able to trigger it on my end, but it might be what you're hitting.
Just sent a v2, can you give that a shot?
http://article.gmane.org/gmane.comp.emulators.qemu/213147
Thanks! This one works fine.
Stefan
Re: [Qemu-devel] [PATCH] makefile: detect corrupted elf files
On Sun, May 26, 2013 at 08:29:35PM +, Blue Swirl wrote: On Sun, May 26, 2013 at 8:15 PM, Michael S. Tsirkin m...@redhat.com wrote: On Sun, May 26, 2013 at 07:28:40PM +, Blue Swirl wrote: On Sun, May 26, 2013 at 6:24 PM, Michael S. Tsirkin m...@redhat.com wrote: On Sun, May 26, 2013 at 06:20:17PM +, Blue Swirl wrote: On Sun, May 26, 2013 at 1:40 PM, Michael S. Tsirkin m...@redhat.com wrote: On Sun, May 26, 2013 at 02:36:28PM +0100, Peter Maydell wrote: On 26 May 2013 13:31, Michael S. Tsirkin m...@redhat.com wrote: On Sun, May 26, 2013 at 10:12:21AM +0100, Peter Maydell wrote: I definitely think individual project makefiles are the wrong place to fix this. If create-as-temp-and-rename is useful functionality it needs to go in the compiler so that everybody benefits. This will not help users on existing systems. Also it's not just compiler. We'd have to do it in linker, asm, ... lots of work. This is clearly less work than implementing it in the makefile of every single open source project in the world (or even every single open source project in Debian). You seem to have removed the part that explained that 1. we run scripts in our makefiles so need to handle that anyway 2. we care about users on existing systems A generic hook (default none, or maybe test -s) after object production and before linkage should be enough but would scale to SHA producing/verifying tools. This means that we would need the fix in our makefiles even if compiler and linker gain this feature. Depends on the feature. If the object files have robust checksums which are checked after output and before input, this should be transparent to the build system. You are wellcome to implement this in compiler/linker/etc if you like but we will still want to handle it in our makefile as well. I specifically don't want it handled in our makefiles because it's the wrong place to fix the problem and it will make our build system more complicated. +1 Also, what is the worst case scenario? The link fails and you have to clean up and rebuild? An automated build system can't produce the expected output if the build machine is unreliable? It's a simple issue. Each time I reboot during build, I have to make clean and rebuild. This wastes my time so I looked for ways to save the time. Compile under a stable kernel and test the bleeding edge kernel only as KVM guest? Get a different box for testing or compiling? Run 'sync' every time gcc finishes? What's the question here? The question is if any of the suggestions solves the problem? Also how about something this: post boot, find -name '*.o' | xargs -iF sh -c 'if test ! -s F; then rm F;fi' Maybe. I don't know if it's the only kind one typically sees after a power failure. I'll experiment when this happens next. Don't you have bigger problems with file systems due to the crashes? As it happens, no. Maybe because I'm using ext4. Maybe I'm lucky. On my system at least, it has no measureable cost, likely also because size only looks at headers and metadata. For example on OpenBSD, 'size' does not seem to come from binutils, so there could be portability issues. True, I'm not saying it's perfect. If others are not interested, I can keep it out of tree. I've had problems with disk close to full, so I'm semi-interested if the solution does not slow down others and it's not too ugly. I think the simplest way to do it is to change makefile to unlike, create then rename. Then you are safe against abrupt killing or crashing make. And with a journaled fs, if you also have e.g. linux ext4 and mount with data=ordered, you are safe against power failures. It shouldn't be hard to do and I don't expect this to have any measureable speed impact. What do you think? I'd prefer a more generic solution, like the hook. What is meant by the hook? What you propose wouldn't protect from the disk full scenario. Why not? I think it will - renaming file in same directory doesn't need any space so is almost sure to succeed even on disk full. What I mean is this gcc -o a.o a.c - rm a.o gcc -o a.tmp.o a.c mv a.tmp.o a.o -- PMM
Re: [Qemu-devel] [PATCH] makefile: detect corrupted elf files
Michael S. Tsirkin m...@redhat.com writes: On Sun, May 26, 2013 at 06:20:17PM +, Blue Swirl wrote: It's a simple issue. Each time I reboot during build, I have to make clean and rebuild. This wastes my time so I looked for ways to save the time. On my system at least, it has no measureable cost, likely also because size only looks at headers and metadata. If others are not interested, I can keep it out of tree. You probably should. Trying to be robust here is going to cause more headache than it's worth. I think your problem has better solutions too. Doing a full build with all optional dependencies enabled really doesn't take that long. $ time ( ~/git/qemu/configure CCACHE_DISABLE=1 make -j24) lots of output real 2m28.222s user 21m33.763s sys 1m30.721s I've switched to this as standard practice since it's so quick. This is a modest two socket system with spinning disks. I'm sure it's even faster with more recent processors and SSDs. With tmpfs as the build directory it would probably fly. Our build parallelizes very well, even if you only have slow systems, distcc will work wonders. Regards, Anthony Liguori -- PMM
Re: [Qemu-devel] [PATCH 12/15] s390x: reduce TARGET_PHYS_ADDR_SPACE_BITS to 62
On 26/05/13 21:07, Paolo Bonzini wrote: Il 26/05/2013 16:14, Andreas Färber ha scritto: With the next patch, the memory API will complain if the TARGET_PHYS_ADDR_SPACE_BITS gets dangerously close to an overflow. s390x can handle up to 64 bit of physical address space from its page tables, but we never use that much. Just decrease the value. Cc: Alexander Graf ag...@suse.de Signed-off-by: Paolo Bonzini pbonz...@redhat.com Didn't Avi introduce 128-bit arithmetic into QEMU to avoid 64-bit values overflowing? Why are you limiting Memory API to 62-bit now? The next patch makes a difference between artificial memory regions (containers and aliases) which can have arbitrary placement and width, and the final view of the address space which cannot have a full 64-bit size. 63 bits probably would work, but I preferred to be safe since 62 is the largest used by other targets. It should be fixable, but if it is not a problem I wouldn't worry much about it. I would prefer to allow 64bit of address space. Memory on s390x can be discontiguous. It is currently not used under KVM and it might not make a lot of sense, but the current KVM code would allow a guest that has a layout of lets say 0...1GB + 16EB-1GB...16EB. Furthermore, I know of some (prototype only) hw memory devices that actually populated the upper memory addresses. If such a thing becomes reality in the future we cannot provide virtualization of those. Christian
Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code
On Sun, May 26, 2013 at 03:49:53PM -0500, Anthony Liguori wrote: Paolo Bonzini pbonz...@redhat.com writes: Il 26/05/2013 22:02, Michael S. Tsirkin ha scritto: My fault. I should have looked at linux/types.h (actually asm-generic/). Not really, __uX appear in the headers that were posted. Which is a problem because this is a reserved namespace in C99. What I'm saying is - a chance of a conflict is very remote, if it happens it's a build failure so easy to debug. I'm sure that others will complain, :) but you can go ahead. I think we should clean up the virtio headers in the kernel first. Seems like a good thing to do given the standardization effort too. There are lots of headers in uapi that use the C99 int types I found 4: $ grep -l uint include/uapi/linux/*h include/uapi/linux/dm-log-userspace.h include/uapi/linux/fuse.h include/uapi/linux/jffs2.h include/uapi/linux/pps.h include/uapi/linux/rds.h include/uapi/linux/sctp.h That's not really lots. so there doesn't seem to be a reason they couldn't be used in virtio. fuse.h even has a: #ifdef __KERNEL__ #include linux/types.h #else #include stdint.h #endif Which seems like a reasonable thing to do. In kernel, we really want to use things like endian-ness checks (and, we really should have them in userspace too!). So we want __le32 and other kernel goodies like that. stdint.h won't cut it. The only other kernel dependency is linux/if_ether.h to define ETH_ALEN. But it seems completely reasonable to define a VIRTIO_NET_MAC_ALEN or something like that. Ugh. Not really reasonable IMO. We also use ETH_P_IP in code, would like to get rid of redefining that too. But we can have our own linux/if_ether.h for non-linux hosts, just with a couple of macros like that, it's not a big deal. This would make the virtio headers completely stand alone and includable in userspace (without violating C99). Perhaps it's even worth moving the headers from uapi/linux to uapi/virtio. Rusty, what do you think? Regards, Anhtony Liguori Paolo
Re: [Qemu-devel] [PATCH] i386/translate: ignore 0x67 (PREFIX_ADR) on TARGET_X86_64 CODE64()
On 05/26/13 10:33, Paolo Bonzini wrote:
Il 26/05/2013 01:23, Richard Henderson ha scritto:
On 2013-05-24 14:37, Laszlo Ersek wrote:
@@ -4813,7 +4813,11 @@ static target_ulong disas_insn(CPUX86State
*env, DisasContext *s,
/* 0x66 is ignored if rex.w is set */
dflag = 2;
}
-if (!(prefixes PREFIX_ADR)) {
+if (prefixes PREFIX_ADR) {
+/* flip it back, 0x67 should have no effect */
+aflag ^= 1;
+}
+else {
aflag = 2;
}
}
Agreed that there's a bug here. I'm thinking it would be clearer to not
write this as yet another flip, but understand that unlike dflag, aflag
can only be either 1 or 2 in 64-bit mode.
I'm thinking of something more like this:
diff --git a/target-i386/translate.c b/target-i386/translate.c
index 0aeccdb..bf772aa 100644
--- a/target-i386/translate.c
+++ b/target-i386/translate.c
@@ -4813,9 +4813,8 @@ static target_ulong disas_insn(CPUX86State *env,
DisasContext *s,
/* 0x66 is ignored if rex.w is set */
dflag = 2;
}
-if (!(prefixes PREFIX_ADR)) {
-aflag = 2;
-}
+/* 0x67 toggles between 64-bit and 32-bit addressing. */
+aflag = (prefixes PREFIX_ADR ? 1 : 2);
Isn't that just aflag++? Needs a comment of course (toggle between
32- and 64-bit, not 16- and 32-bit.).
I finally looked up in the SDM what the 0x67 (address-size override)
prefix does. Apparently,
2.1.1 Instruction Prefixes
[...] The address-size override prefix (67H) allows programs to
switch between 16- and 32-bit addressing. Either size can be the
default; the prefix selects the non-default size. [...]
CMPS/CMPSB/CMPSW/CMPSD/CMPSQ -- Compare String Operands
[...] In 64-bit mode, the instruction's default address size is 64
bits, 32 bit address size is supported using the prefix 67H. [...]
Assuming that
- aflag==0 means 16-bit address,
- aflag==1 means 32-bit address,
- aflag==2 means 64-bit address,
- and bit0 in s-code32 carries aflag corresponding to the default
address size in 32-bit mode,
I think Richard's patch is correct (my approach was only to restore the
pre-patch logic without having any clue about the variables' contents).
I believe aflag++ is incorrect if the current default address size for
32-bit is 16-bit (ie. (s-code32 1) == 0). In this case the first XOR
(seeing the 0x67 prefix) flips it to 1, and the increment would change
it to 2. aflag==2 corresponds to 64-bit address, but in 64-bit mode with
the 0x67 prefix we must choose 32-bit.
(IOW in 32-bit mode the meaning of the 0x67 prefix is not absolute but
relative.)
Laszlo
Re: [Qemu-devel] FPU x86 instructions error
On Sun, May 26, 2013 at 7:54 AM, Andreas Färber afaer...@suse.de wrote: Hi, Am 24.05.2013 23:44, schrieb Paolo Bonzini: Il 24/05/2013 23:39, Clemens Kolbitsch ha scritto: we recently had an issue with running a program using FPU instructions to obtain the current EIP (basically a weird way of call 0; pop eax) that was not working on QEMU (with TCG). Looking at the problem, we found this patch to be useful/fixing the issue: https://launchpadlibrarian.net/140457932/patch-qemu-1.5.0-fpip.diff Looking through the DEVEL archives, I found this patch http://lists.nongnu.org/archive/html/qemu-devel/2011-06/msg01206.html that adds the FPU flags to the environment, but is only using them for KVM. I was wondering - since the above patch is rather old, you have probably come across it before - if there was a reason for not including it in QEMU (I checked in git:master and it's not applied). If there isn't, maybe it'd be worth re-considering :) For the TCG patch, there is no Signed-off-by and using a helper is not necessary. Clemens, generally we can't just take another person's patch and apply it - that's what we need the Signed-off-by for. Your post is the only Google hit for that link and no hits for fpip in my archive - you'll need to contact the author to obtain her Sob and properly submit it to qemu-devel - or post a patch yourself that is not based on that one. Andreas, thanks for that info - that makes it much clearer. Since the patch is rather short, it will be difficult, but we can give it a shot :) http://wiki.qemu.org/Contribute/SubmitAPatch For the KVM patch, it simply fell through the cracks, I believe. It didn't: http://git.qemu.org/?p=qemu.git;a=commit;h=42cc8fa620cbc73e349e96d84cf46469e828ec34 (I was about to suggest placing the non-TCG fields into X86CPU. :)) Yes, I think that was a misunderstanding. I was trying to say that for first one didn't get picked up and the second one is just a prerequisite -- not that it was missing as well :) thanks! -Clemens
Re: [Qemu-devel] [PATCH stable-1.1] qga: set umask 0077 when daemonizing (CVE-2013-2007)
On 05/26/13 15:34, Andreas Färber wrote:
From: Laszlo Ersek ler...@redhat.com
The qemu guest agent creates a bunch of files with insecure permissions
when started in daemon mode. For example:
-rw-rw-rw- 1 root root /var/log/qemu-ga.log
-rw-rw-rw- 1 root root /var/run/qga.state
-rw-rw-rw- 1 root root /var/log/qga-fsfreeze-hook.log
In addition, at least all files created with the guest-file-open QMP
command, and all files created with shell output redirection (or
otherwise) by utilities invoked by the fsfreeze hook script are affected.
For now mask all file mode bits for group and others in
become_daemon().
Temporarily, for compatibility reasons, stick with the 0666 file-mode in
case of files newly created by the guest-file-open QMP call. Do so
without changing the umask temporarily.
Signed-off-by: Laszlo Ersek ler...@redhat.com
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
(cherry picked from commit c689b4f1bac352dcfd6ecb9a1d45337de0f1de67)
[AF: Use error_set() instead of error_setg*()]
Signed-off-by: Andreas Färber afaer...@suse.de
---
qemu-ga.c| 2 +-
qga/commands-posix.c | 117
+--
2 files changed, 115 insertions(+), 4 deletions(-)
diff --git a/qemu-ga.c b/qemu-ga.c
index 1b00c2f..086b1b9 100644
--- a/qemu-ga.c
+++ b/qemu-ga.c
@@ -424,7 +424,7 @@ static void become_daemon(const char *pidfile)
}
}
-umask(0);
+umask(S_IRWXG | S_IRWXO);
sid = setsid();
if (sid 0) {
goto fail;
diff --git a/qga/commands-posix.c b/qga/commands-posix.c
index 00d035d..c0a1bd4 100644
--- a/qga/commands-posix.c
+++ b/qga/commands-posix.c
@@ -15,6 +15,9 @@
#include sys/types.h
#include sys/ioctl.h
#include sys/wait.h
+#include stdio.h
+#include string.h
+#include sys/stat.h
#include qga/guest-agent-core.h
#include qga-qmp-commands.h
#include qerror.h
@@ -122,9 +125,117 @@ static GuestFileHandle *guest_file_handle_find(int64_t
id)
return NULL;
}
+typedef const char * const ccpc;
+
+/* http://pubs.opengroup.org/onlinepubs/9699919799/functions/fopen.html */
+static const struct {
+ccpc *forms;
+int oflag_base;
+} guest_file_open_modes[] = {
+{ (ccpc[]){ r, rb, NULL }, O_RDONLY },
+{ (ccpc[]){ w, wb, NULL }, O_WRONLY | O_CREAT | O_TRUNC },
+{ (ccpc[]){ a, ab, NULL }, O_WRONLY | O_CREAT | O_APPEND },
+{ (ccpc[]){ r+, rb+, r+b, NULL }, O_RDWR},
+{ (ccpc[]){ w+, wb+, w+b, NULL }, O_RDWR | O_CREAT | O_TRUNC },
+{ (ccpc[]){ a+, ab+, a+b, NULL }, O_RDWR | O_CREAT | O_APPEND }
+};
+
+static int
+find_open_flag(const char *mode_str, Error **err)
+{
+unsigned mode;
+
+for (mode = 0; mode ARRAY_SIZE(guest_file_open_modes); ++mode) {
+ccpc *form;
+
+form = guest_file_open_modes[mode].forms;
+while (*form != NULL strcmp(*form, mode_str) != 0) {
+++form;
+}
+if (*form != NULL) {
+break;
+}
+}
+
+if (mode == ARRAY_SIZE(guest_file_open_modes)) {
+error_set(err, QERR_UNSUPPORTED);
+return -1;
+}
+return guest_file_open_modes[mode].oflag_base | O_NOCTTY | O_NONBLOCK;
+}
+
+#define DEFAULT_NEW_FILE_MODE (S_IRUSR | S_IWUSR | \
+ S_IRGRP | S_IWGRP | \
+ S_IROTH | S_IWOTH)
+
+static FILE *
+safe_open_or_create(const char *path, const char *mode, Error **err)
+{
+Error *local_err = NULL;
+int oflag;
+
+oflag = find_open_flag(mode, local_err);
+if (local_err == NULL) {
+int fd;
+
+/* If the caller wants / allows creation of a new file, we implement
it
+ * with a two step process: open() + (open() / fchmod()).
+ *
+ * First we insist on creating the file exclusively as a new file. If
+ * that succeeds, we're free to set any file-mode bits on it. (The
+ * motivation is that we want to set those file-mode bits
independently
+ * of the current umask.)
+ *
+ * If the exclusive creation fails because the file already exists
+ * (EEXIST is not possible for any other reason), we just attempt to
+ * open the file, but in this case we won't be allowed to change the
+ * file-mode bits on the preexistent file.
+ *
+ * The pathname should never disappear between the two open()s in
+ * practice. If it happens, then someone very likely tried to race
us.
+ * In this case just go ahead and report the ENOENT from the second
+ * open() to the caller.
+ *
+ * If the caller wants to open a preexistent file, then the first
+ * open() is decisive and its third argument is ignored, and the
second
+ * open() and the fchmod() are
Re: [Qemu-devel] [PATCH stable-1.1] qga: set umask 0077 when daemonizing (CVE-2013-2007)
On 05/27/13 02:11, Laszlo Ersek wrote:
On 05/26/13 15:34, Andreas Färber wrote:
From: Laszlo Ersek ler...@redhat.com
The qemu guest agent creates a bunch of files with insecure permissions
when started in daemon mode. For example:
-rw-rw-rw- 1 root root /var/log/qemu-ga.log
-rw-rw-rw- 1 root root /var/run/qga.state
-rw-rw-rw- 1 root root /var/log/qga-fsfreeze-hook.log
In addition, at least all files created with the guest-file-open QMP
command, and all files created with shell output redirection (or
otherwise) by utilities invoked by the fsfreeze hook script are affected.
For now mask all file mode bits for group and others in
become_daemon().
Temporarily, for compatibility reasons, stick with the 0666 file-mode in
case of files newly created by the guest-file-open QMP call. Do so
without changing the umask temporarily.
Signed-off-by: Laszlo Ersek ler...@redhat.com
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
(cherry picked from commit c689b4f1bac352dcfd6ecb9a1d45337de0f1de67)
[AF: Use error_set() instead of error_setg*()]
Signed-off-by: Andreas Färber afaer...@suse.de
---
qemu-ga.c| 2 +-
qga/commands-posix.c | 117
+--
2 files changed, 115 insertions(+), 4 deletions(-)
diff --git a/qemu-ga.c b/qemu-ga.c
index 1b00c2f..086b1b9 100644
--- a/qemu-ga.c
+++ b/qemu-ga.c
@@ -424,7 +424,7 @@ static void become_daemon(const char *pidfile)
}
}
-umask(0);
+umask(S_IRWXG | S_IRWXO);
sid = setsid();
if (sid 0) {
goto fail;
diff --git a/qga/commands-posix.c b/qga/commands-posix.c
index 00d035d..c0a1bd4 100644
--- a/qga/commands-posix.c
+++ b/qga/commands-posix.c
@@ -15,6 +15,9 @@
#include sys/types.h
#include sys/ioctl.h
#include sys/wait.h
+#include stdio.h
+#include string.h
+#include sys/stat.h
#include qga/guest-agent-core.h
#include qga-qmp-commands.h
#include qerror.h
@@ -122,9 +125,117 @@ static GuestFileHandle *guest_file_handle_find(int64_t
id)
return NULL;
}
+typedef const char * const ccpc;
+
+/* http://pubs.opengroup.org/onlinepubs/9699919799/functions/fopen.html */
+static const struct {
+ccpc *forms;
+int oflag_base;
+} guest_file_open_modes[] = {
+{ (ccpc[]){ r, rb, NULL }, O_RDONLY },
+{ (ccpc[]){ w, wb, NULL }, O_WRONLY | O_CREAT | O_TRUNC },
+{ (ccpc[]){ a, ab, NULL }, O_WRONLY | O_CREAT | O_APPEND },
+{ (ccpc[]){ r+, rb+, r+b, NULL }, O_RDWR},
+{ (ccpc[]){ w+, wb+, w+b, NULL }, O_RDWR | O_CREAT | O_TRUNC },
+{ (ccpc[]){ a+, ab+, a+b, NULL }, O_RDWR | O_CREAT | O_APPEND }
+};
+
+static int
+find_open_flag(const char *mode_str, Error **err)
+{
+unsigned mode;
+
+for (mode = 0; mode ARRAY_SIZE(guest_file_open_modes); ++mode) {
+ccpc *form;
+
+form = guest_file_open_modes[mode].forms;
+while (*form != NULL strcmp(*form, mode_str) != 0) {
+++form;
+}
+if (*form != NULL) {
+break;
+}
+}
+
+if (mode == ARRAY_SIZE(guest_file_open_modes)) {
+error_set(err, QERR_UNSUPPORTED);
+return -1;
+}
+return guest_file_open_modes[mode].oflag_base | O_NOCTTY | O_NONBLOCK;
+}
+
+#define DEFAULT_NEW_FILE_MODE (S_IRUSR | S_IWUSR | \
+ S_IRGRP | S_IWGRP | \
+ S_IROTH | S_IWOTH)
+
+static FILE *
+safe_open_or_create(const char *path, const char *mode, Error **err)
+{
+Error *local_err = NULL;
+int oflag;
+
+oflag = find_open_flag(mode, local_err);
+if (local_err == NULL) {
+int fd;
+
+/* If the caller wants / allows creation of a new file, we
implement it
+ * with a two step process: open() + (open() / fchmod()).
+ *
+ * First we insist on creating the file exclusively as a new file.
If
+ * that succeeds, we're free to set any file-mode bits on it. (The
+ * motivation is that we want to set those file-mode bits
independently
+ * of the current umask.)
+ *
+ * If the exclusive creation fails because the file already exists
+ * (EEXIST is not possible for any other reason), we just attempt to
+ * open the file, but in this case we won't be allowed to change the
+ * file-mode bits on the preexistent file.
+ *
+ * The pathname should never disappear between the two open()s in
+ * practice. If it happens, then someone very likely tried to race
us.
+ * In this case just go ahead and report the ENOENT from the second
+ * open() to the caller.
+ *
+ * If the caller wants to open a preexistent file, then the first
+ * open() is decisive and its third argument is ignored, and the
second
+
Re: [Qemu-devel] [PATCH stable-1.1] qga: set umask 0077 when daemonizing (CVE-2013-2007)
Am 27.05.2013 02:11, schrieb Laszlo Ersek: On 05/26/13 15:34, Andreas Färber wrote: From: Laszlo Ersek ler...@redhat.com The qemu guest agent creates a bunch of files with insecure permissions when started in daemon mode. For example: -rw-rw-rw- 1 root root /var/log/qemu-ga.log -rw-rw-rw- 1 root root /var/run/qga.state -rw-rw-rw- 1 root root /var/log/qga-fsfreeze-hook.log In addition, at least all files created with the guest-file-open QMP command, and all files created with shell output redirection (or otherwise) by utilities invoked by the fsfreeze hook script are affected. For now mask all file mode bits for group and others in become_daemon(). Temporarily, for compatibility reasons, stick with the 0666 file-mode in case of files newly created by the guest-file-open QMP call. Do so without changing the umask temporarily. Signed-off-by: Laszlo Ersek ler...@redhat.com Signed-off-by: Anthony Liguori aligu...@us.ibm.com (cherry picked from commit c689b4f1bac352dcfd6ecb9a1d45337de0f1de67) [AF: Use error_set() instead of error_setg*()] Signed-off-by: Andreas Färber afaer...@suse.de --- qemu-ga.c| 2 +- qga/commands-posix.c | 117 +-- 2 files changed, 115 insertions(+), 4 deletions(-) [...] Looks good to me. Do you plan to backport 8fe6bbc qga: distinguish binary modes in guest_file_open_modes map 2b72001 qga: unlink just created guest-file if fchmod() or fdopen() fails on it too? These are considered polish for the CVE fix. I did backport both to openSUSE 12.2 - they apply without conflicts. :) I mainly posted this one to check if there are better QERRs to use. Also, a side-note: existing world-writable log files etc. are not recreated nor have their modes changed, so maybe a release note or some such would be useful for admins (delete your previous logfile optional unix domain socket, or change their modes manually). Feel free to add a note to the 1.5 Release Notes - it can then be copied to the previous releases we backport this fix to. Apart from 1.1 I backported to our 1.3 branch. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH 0/4] add ACPI Embedded Controller
在 2013-05-24五的 14:45 +0300，Michael S. Tsirkin写道： On Wed, May 22, 2013 at 11:46:33AM +0800, liguang wrote: These patches try to add ACPI Embedded Controller (EC), refer-to: ACPI SPEC v5 chapter 5 ACPI Embedded Controller Interface Specification EC is a standard ACPI device, it plays flexible roles, e.g. power controller, it can control power sequence for platform to enter or leave system state(0,1,3,4,5), it can controller CPU fan by the temperature of sensor. event carrier, it can pass events between platform and OS, so OS can execute _Qxx method which defined by yourself. So, I want to deliver CPU online/offline event between OS and QEMU for CPU hotplug feature, then we will don't need to echo 1 /sys/devices/system/cpu/cpu1/online again after 'cpu-add'. patches for online/offline event handler of QEUM and linux kernel are writing, and will send once finished. since EC is a common device, so I send pathes separately. Do any non-linux guests support this device? In fact, any OSes support ACPI will support this device. so, windows will.
Re: [Qemu-devel] [update][PATCH 00/12] target-i386: remove some macros
在 2013-05-26日的 17:55 +0200，Andreas Färber写道： Am 24.05.2013 13:37, schrieb Andreas Färber: Am 23.04.2013 10:16, schrieb liguang: remove macros EAX, EBX, ECX, EDX, EBP, ESP, ESI, EDI, EIP, DF as suggested by Richard Henderson r...@twiddle.net Li Guang (12) target-i386/helper: remove EAX macro target-i386/helper: remove EBX macro target-i386/helper: remove ECX macro target-i386/helper: remove EDX macro target-i386/helper: remove EBP macro target-i386/helper: remove ESP macro target-i386/helper: remove ESI macro target-i386/helper: remove EDI macro target-i386/helper: remove EIP macro target-i386/helper: remove DF macro target-i386/helper: remove redundant env-eip assignment target-i386: fix over 80 chars warnings Hard Freeze is over, so more time to look into refactorings: There's one thing to be aware of here, macros would make it easier to transition from CPUX86State to X86CPU fields. However I am guessing that all these registers are accessed by TCG code via offsets from cpu_env - please verify that. Confirmed, I just stumbled over it myself in translate.c: * all but EIP and DF are assigned to cpu_regs[] * EIP is manually stored with offsetof() twice * DF is manually loaded/stored with offsetof() thrice OK, thanks! If so, Reviewed-by: Andreas Färber afaer...@suse.de However, it would be nice if you could fix the \ alignment in patch 06/12 or in the cleanup patch 12/12. Regards, Andreas
Re: [Qemu-devel] [PATCH stable-1.1] qga: set umask 0077 when daemonizing (CVE-2013-2007)
On 05/27/13 02:19, Andreas Färber wrote: Am 27.05.2013 02:11, schrieb Laszlo Ersek: Do you plan to backport 8fe6bbc qga: distinguish binary modes in guest_file_open_modes map 2b72001 qga: unlink just created guest-file if fchmod() or fdopen() fails on it too? These are considered polish for the CVE fix. I did backport both to openSUSE 12.2 - they apply without conflicts. :) I mainly posted this one to check if there are better QERRs to use. I think your choices were apt. Also, a side-note: existing world-writable log files etc. are not recreated nor have their modes changed, so maybe a release note or some such would be useful for admins (delete your previous logfile optional unix domain socket, or change their modes manually). Feel free to add a note to the 1.5 Release Notes - it can then be copied to the previous releases we backport this fix to. Do you mean in the wiki? I'll need an account first :) Thanks, Laszlo
Re: [Qemu-devel] [PATCH 0/4] add ACPI Embedded Controller
li guang lig.f...@cn.fujitsu.com writes: 在 2013-05-24五的 14:45 +0300，Michael S. Tsirkin写道： On Wed, May 22, 2013 at 11:46:33AM +0800, liguang wrote: These patches try to add ACPI Embedded Controller (EC), refer-to: ACPI SPEC v5 chapter 5 ACPI Embedded Controller Interface Specification EC is a standard ACPI device, it plays flexible roles, e.g. power controller, it can control power sequence for platform to enter or leave system state(0,1,3,4,5), it can controller CPU fan by the temperature of sensor. event carrier, it can pass events between platform and OS, so OS can execute _Qxx method which defined by yourself. So, I want to deliver CPU online/offline event between OS and QEMU for CPU hotplug feature, then we will don't need to echo 1 /sys/devices/system/cpu/cpu1/online again after 'cpu-add'. patches for online/offline event handler of QEUM and linux kernel are writing, and will send once finished. since EC is a common device, so I send pathes separately. Do any non-linux guests support this device? In fact, any OSes support ACPI will support this device. so, windows will. When you say any OSes supporting ACPI I think what you really mean is that we can provide bytecode that interacts with the embedded controller. There is not explicit driver in Linux or Windows AFAIK. I still don't get the point of this. We can make ACPI hotplug work without introducing a new device like this. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code
Michael S. Tsirkin m...@redhat.com writes: On Sun, May 26, 2013 at 03:49:53PM -0500, Anthony Liguori wrote: Paolo Bonzini pbonz...@redhat.com writes: Il 26/05/2013 22:02, Michael S. Tsirkin ha scritto: My fault. I should have looked at linux/types.h (actually asm-generic/). Not really, __uX appear in the headers that were posted. Which is a problem because this is a reserved namespace in C99. What I'm saying is - a chance of a conflict is very remote, if it happens it's a build failure so easy to debug. I'm sure that others will complain, :) but you can go ahead. I think we should clean up the virtio headers in the kernel first. Seems like a good thing to do given the standardization effort too. There are lots of headers in uapi that use the C99 int types I found 4: $ grep -l uint include/uapi/linux/*h include/uapi/linux/dm-log-userspace.h include/uapi/linux/fuse.h include/uapi/linux/jffs2.h include/uapi/linux/pps.h include/uapi/linux/rds.h include/uapi/linux/sctp.h That's not really lots. so there doesn't seem to be a reason they couldn't be used in virtio. fuse.h even has a: #ifdef __KERNEL__ #include linux/types.h #else #include stdint.h #endif Which seems like a reasonable thing to do. In kernel, we really want to use things like endian-ness checks (and, we really should have them in userspace too!). So we want __le32 and other kernel goodies like that. stdint.h won't cut it. With the spec being standardized, I think having a stand alone set of headers is a good thing. Licensing is problematic here too. If virtio headers depend on other Linux headers, then it really doesn't matter if they are BSD licensed if you need a GPL header (like linux/if_ether.h). Now, we can certainly debate the copyrightability of these defines and what have you but if the headers are meant to be 1) consumed outside the kernel 2) licensed under a different license than the general kernel then depending on kernel goodies is the wrong strategy. The only other kernel dependency is linux/if_ether.h to define ETH_ALEN. But it seems completely reasonable to define a VIRTIO_NET_MAC_ALEN or something like that. Ugh. Not really reasonable IMO. We also use ETH_P_IP in code, would like to get rid of redefining that too. But we can have our own linux/if_ether.h for non-linux hosts, just with a couple of macros like that, it's not a big deal. See above. Regards, Anthony Liguori This would make the virtio headers completely stand alone and includable in userspace (without violating C99). Perhaps it's even worth moving the headers from uapi/linux to uapi/virtio. Rusty, what do you think? Regards, Anhtony Liguori Paolo
Re: [Qemu-devel] FPU x86 instructions error
On Sat, May 25, 2013 at 5:39 AM, Clemens Kolbitsch kolbit...@lastline.com wrote: Hi guys, we recently had an issue with running a program using FPU instructions to obtain the current EIP (basically a weird way of call 0; pop eax) that was not working on QEMU (with TCG). Looking at the problem, we found this patch to be useful/fixing the issue: https://launchpadlibrarian.net/140457932/patch-qemu-1.5.0-fpip.diff This patch is not working fully because the floating-point control instructions do not change fpip. Looking through the DEVEL archives, I found this patch http://lists.nongnu.org/archive/html/qemu-devel/2011-06/msg01206.html that adds the FPU flags to the environment, but is only using them for KVM. I was wondering - since the above patch is rather old, you have probably come across it before - if there was a reason for not including it in QEMU (I checked in git:master and it's not applied). If there isn't, maybe it'd be worth re-considering :) thanks! -Clemens -- Clemens Kolbitsch Security Researcher kolbit...@lastline.com Lastline, Inc. 6950 Hollister Avenue, Suite 101 Goleta, CA 93117 www.lastline.com
Re: [Qemu-devel] [PATCH 0/4] add ACPI Embedded Controller
在 2013-05-26日的 19:51 -0500，Anthony Liguori写道： li guang lig.f...@cn.fujitsu.com writes: 在 2013-05-24五的 14:45 +0300，Michael S. Tsirkin写道： On Wed, May 22, 2013 at 11:46:33AM +0800, liguang wrote: These patches try to add ACPI Embedded Controller (EC), refer-to: ACPI SPEC v5 chapter 5 ACPI Embedded Controller Interface Specification EC is a standard ACPI device, it plays flexible roles, e.g. power controller, it can control power sequence for platform to enter or leave system state(0,1,3,4,5), it can controller CPU fan by the temperature of sensor. event carrier, it can pass events between platform and OS, so OS can execute _Qxx method which defined by yourself. So, I want to deliver CPU online/offline event between OS and QEMU for CPU hotplug feature, then we will don't need to echo 1 /sys/devices/system/cpu/cpu1/online again after 'cpu-add'. patches for online/offline event handler of QEUM and linux kernel are writing, and will send once finished. since EC is a common device, so I send pathes separately. Do any non-linux guests support this device? In fact, any OSes support ACPI will support this device. so, windows will. When you say any OSes supporting ACPI I think what you really mean is that we can provide bytecode that interacts with the embedded controller. There is not explicit driver in Linux or Windows AFAIK. Hmm, yep, mostly there's no special driver for EC, because it is directly embedded in code for ACPI for linux kernel, it's drivers/acpi/ec.c I still don't get the point of this. We can make ACPI hotplug work without introducing a new device like this. when you 'cpu-add' a cpu, acpi driver for cpu will not trigger 'cpu_up' for linux kernel AFAIK, unless you add a user space program to listen it's uevent and tigger 'cpu_up'. and EC is not only for ACPI hotplug for example, the 'pvpanic', if there's a EC, we can pass pvpanic event by EC's ACPI space or Q-event, then we will not need this kind of special devices anymore.
Re: [Qemu-devel] [PATCH V13 3/6] qmp: add recursive member in ImageInfo
于 2013-5-26 0:10, Eric Blake 写道: On 05/24/2013 10:24 PM, Wenchao Xia wrote: New member *backing-image is added to reflect the backing chain status. Signed-off-by: Wenchao Xia xiaw...@linux.vnet.ibm.com --- block/qapi.c | 16 +++- qapi-schema.json |5 - 2 files changed, 19 insertions(+), 2 deletions(-) diff --git a/block/qapi.c b/block/qapi.c index 680ec23..cbef584 100644 --- a/block/qapi.c +++ b/block/qapi.c @@ -88,7 +88,21 @@ int bdrv_query_snapshot_info_list(BlockDriverState *bs, return 0; } -/* @p_info will be set only on success. */ +/** + * bdrv_query_image_info: + * @bs: block device to examine + * @p_info: location to store image information + * @errp: location to store error information + * + * Store flat image inforation in @p_info. s/inforation/information/ + * + * Flat means it does *not* query backing image information, + * i.e. (*pinfo)-has_backing_image will be set to false and + * (*pinfo)-backing_image to NULL even when the image does in fact have + * a backing image. + * + * @p_info will be set only on success. On error, store error in @errp. + */ Does this comment hunk belong in the previous patch? Yes, it got modified again in this one, will move it. void bdrv_query_image_info(BlockDriverState *bs, ImageInfo **p_info, Error **errp) diff --git a/qapi-schema.json b/qapi-schema.json index ef1f657..a02999d 100644 --- a/qapi-schema.json +++ b/qapi-schema.json @@ -236,6 +236,8 @@ # # @snapshots: #optional list of VM snapshots # +# @backing-image: #optional info of the backing image (since 1.6) +# # Since: 1.3 # ## @@ -245,7 +247,8 @@ '*actual-size': 'int', 'virtual-size': 'int', '*cluster-size': 'int', '*encrypted': 'bool', '*backing-filename': 'str', '*full-backing-filename': 'str', - '*backing-filename-format': 'str', '*snapshots': ['SnapshotInfo'] } } + '*backing-filename-format': 'str', '*snapshots': ['SnapshotInfo'], + '*backing-image': 'ImageInfo' } } The API change looks fine, except there is no code change to actually populate the new field. This hunk should probably be squashed with the patch that implements the field. Also, are you missing any changes to qmp-commands.hx? nop, in next patch qmp-commands.hx parts is added. Just to make review easier, after that I am fine to squash them. -- Best Regards Wenchao Xia
Re: [Qemu-devel] [Qemu-trivial] [PATCH 0/4] debugcon: fix some bugs when DEBUG_DEBUGCON
在 2013-05-25六的 14:42 +0400，Michael Tokarev写道： 25.05.2013 14:35, Andreas Färber wrote: Am 25.05.2013 11:28, schrieb Michael Tokarev: [] debugcon: use fprintf(stderr...) instead of printf The subjects and commit messages are a bit inaccurate, and as Andreas says, these may have been merged together, but the inaccuracy is small (and mostly due to language barriers), and the result is good anyway, with one patch doing one thing. So.. thanks, applied to the trivial-patches queue. NACK. If you want to apply 1-3, okay. But please unqueue 4/4, it makes no sense as-is (just look at the stderr output to see what I mean) and it pretends that I suggested that! Actually I did just that, rebuild with DEBUG_DEBUGCON and looked at the output, -- because I didn't know how it works. And you're right, it's not a good change ;) But your email come before I was able to reply. Unqueued. Hi, Michael do you queued patch 1-3? if so, I will only send one patch for comments from Andreas, otherwise, I will refactor all patches. Thanks!
[Qemu-devel] [RFC] Add a stp file for usage from build directory
For systemtap the location of the process being tapped is crucial, so the existing stp file requires installation to use. A new file providing qemu.local prefixed probes lets scripts run without an install step. Signed-off-by: Alon Levy al...@redhat.com --- Makefile.target | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/Makefile.target b/Makefile.target index ce4391f..5d176e2 100644 --- a/Makefile.target +++ b/Makefile.target @@ -35,7 +35,7 @@ config-target.h: config-target.h-timestamp config-target.h-timestamp: config-target.mak ifdef CONFIG_TRACE_SYSTEMTAP -stap: $(QEMU_PROG).stp +stap: $(QEMU_PROG).stp $(QEMU_PROG).local.stp ifdef CONFIG_USER_ONLY TARGET_TYPE=user @@ -51,6 +51,17 @@ $(QEMU_PROG).stp: $(SRC_PATH)/trace-events --target-arch=$(TARGET_ARCH) \ --target-type=$(TARGET_TYPE) \ $ $@, GEN $(TARGET_DIR)$(QEMU_PROG).stp) + +$(QEMU_PROG).local.stp: $(SRC_PATH)/trace-events + $(call quiet-command,$(TRACETOOL) \ + --format=stap \ + --backend=$(TRACE_BACKEND) \ + --binary=$(SRC_PATH)/$(TARGET_DIR)$(QEMU_PROG) \ + --probe-prefix=qemu.local \ + --target-arch=$(TARGET_ARCH) \ + --target-type=$(TARGET_TYPE) \ +$ $@, GEN $(TARGET_DIR)$(QEMU_PROG).local.stp) + else stap: endif -- 1.8.2.1
Re: [Qemu-devel] [PATCH v6 00/12] curl: fix curl read
On Fri, 05/24 09:07, Richard W.M. Jones wrote: On Fri, May 24, 2013 at 01:36:55PM +0800, Fam Zheng wrote: Changes from v5: 05: Rename bs to s for BDRVCURLState. 06: Use int64_t for offsets. Fix printf format string. Move introducing of use_count to 07. 07: Drop explicit cast. Use int64_t for offsets. Use_count moved here. 08: Remove duplicated. Move s-url = NULL to separate patch. 09: Fix while(0); 12: Added: curl: set s-url to NULL after free. This patch is definitely not working. The guest sees loads of disk errors like this: [ 30.880265] sd 2:0:0:0: [sda] [ 30.880265] Add. Sense: I/O process terminated [ 30.880265] sd 2:0:0:0: [sda] CDB: [ 30.880265] Read(10): 28 00 00 bf b0 87 00 00 01 00 [ 32.030702] sd 2:0:0:0: [sda] [ 32.031663] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 32.031663] sd 2:0:0:0: [sda] [ 32.031663] Sense Key : Aborted Command [current] [ 32.031663] sd 2:0:0:0: [sda] [ 32.031663] Add. Sense: I/O process terminated [ 32.031663] sd 2:0:0:0: [sda] CDB: [ 32.031663] Read(10): 28 00 00 00 08 46 00 00 01 00 [ 32.031663] blk_update_request: 32 callbacks suppressed [ 32.031663] end_request: I/O error, dev sda, sector 2118 [ 32.031663] quiet_error: 46 callbacks suppressed [ 32.031663] Buffer I/O error on device sda1, logical block 2055 [ 32.031663] sd 2:0:0:0: [sda] [ 32.031663] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 32.031663] sd 2:0:0:0: [sda] [ 32.031663] Sense Key : Aborted Command [current] [ 32.031663] sd 2:0:0:0: [sda] [ 32.031663] Add. Sense: I/O process terminated [ 32.031663] sd 2:0:0:0: [sda] CDB: [ 32.031663] Read(10): 28 00 00 00 08 45 00 00 01 00 [ 32.031663] end_request: I/O error, dev sda, sector 2117 [ 32.031663] Buffer I/O error on device sda1, logical block 2054 [ 32.031663] sd 2:0:0:0: [sda] Rich, are you testing with libguestfs or qemu? Since I can't get libguestfs run with your patch to refuse writable open. Can you post your command? -- Fam
[Qemu-devel] [PATCH 0/3] debugcon: fix some issues of debugcon debug
when enable DEBUG_DEBUGCON, there are some message printing issues, so fix them. Li Guang (3) debugcon: fix debug format specifiers debugcon: beautify debugcon debug output debugcon: add DPRINTF for debugcon debug hw/char/debugcon.c | 22 +++-- 1 files changed, 16 insertions(+), 6 deletions(-)
[Qemu-devel] [PATCH arm-devs v3 1/1] sd/sd.c: Fix inquiry ACMD41
From: Peter Crosthwaite peter.crosthwa...@xilinx.com
QEMU models two (of the three) ACMD41 has two modes, inquiry and
first. The selection logic for which of the two is incorrect - it
compares != 0 for the entire argument value rather than only bits 23:0
as per the spec. Fix.
Signed-off-by: Peter Crosthwaite peter.crosthwa...@xilinx.com
---
Changed since v2:
Macroified magic number
Added explanatory comment (PMM review)
Changed since v1:
Total rewrite
hw/sd/sd.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/hw/sd/sd.c b/hw/sd/sd.c
index 2e0ef3e..a10313b 100644
--- a/hw/sd/sd.c
+++ b/hw/sd/sd.c
@@ -43,6 +43,8 @@ do { fprintf(stderr, SD: fmt , ## __VA_ARGS__); } while (0)
#define DPRINTF(fmt, ...) do {} while(0)
#endif
+#define ACMD41_ENQUIRY_MASK 0x00ff
+
typedef enum {
sd_r0 = 0,/* no response */
sd_r1,/* normal response command */
@@ -1277,9 +1279,14 @@ static sd_rsp_type_t sd_app_command(SDState *sd,
}
switch (sd-state) {
case sd_idle_state:
-/* We accept any voltage. 1 V is nothing. */
-if (req.arg)
+/* We accept any voltage. 1 V is nothing.
+ *
+ * We don't model init delay so just advance straight to ready
state
+ * unless its an enquiry ACMD41 (bits 23:0 == 0).
+ */
+if (req.arg ACMD41_ENQUIRY_MASK) {
sd-state = sd_ready_state;
+}
return sd_r3;
--
1.8.3.rc1.44.gb387c77.dirty
[Qemu-devel] [PATCH 1/3] debugcon: fix debug format specifiers
some specifiers of printing format for debugcon debug were wrong, either always print 0 for any values wrote to debugcon or spit compiler warnings, so fix them. Signed-off-by: liguang lig.f...@cn.fujitsu.com --- hw/char/debugcon.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/hw/char/debugcon.c b/hw/char/debugcon.c index 02c9577..cb31544 100644 --- a/hw/char/debugcon.c +++ b/hw/char/debugcon.c @@ -55,7 +55,8 @@ static void debugcon_ioport_write(void *opaque, hwaddr addr, uint64_t val, unsigned char ch = val; #ifdef DEBUG_DEBUGCON -printf(debugcon: write addr=0x%04x val=0x%02x\n, addr, val); +printf(debugcon: write addr=0x%04 HWADDR_PRIx val=0x%02 + PRIx64 \n, addr, val); #endif qemu_chr_fe_write(s-chr, ch, 1); @@ -67,7 +68,7 @@ static uint64_t debugcon_ioport_read(void *opaque, hwaddr addr, unsigned width) DebugconState *s = opaque; #ifdef DEBUG_DEBUGCON -printf(debugcon: read addr=0x%04x\n, addr); +printf(debugcon: read addr=0x%04 HWADDR_PRIx \n, addr); #endif return s-readback; -- 1.7.2.5
[Qemu-devel] [PATCH 3/3] debugcon: add DPRINTF for debugcon debug
Signed-off-by: liguang lig.f...@cn.fujitsu.com
---
hw/char/debugcon.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/hw/char/debugcon.c b/hw/char/debugcon.c
index de73f1b..49a76d5 100644
--- a/hw/char/debugcon.c
+++ b/hw/char/debugcon.c
@@ -35,6 +35,15 @@
//#define DEBUG_DEBUGCON
+#ifdef DEBUG_DEBUGCON
+#define DPRINTF(fmt, ...) \
+do { fprintf(stderr, fmt, ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) \
+do { } while (0)
+#endif
+
+
typedef struct DebugconState {
MemoryRegion io;
CharDriverState *chr;
@@ -55,7 +64,7 @@ static void debugcon_ioport_write(void *opaque, hwaddr addr,
uint64_t val,
unsigned char ch = val;
#ifdef DEBUG_DEBUGCON
-printf( [debugcon: write addr=0x%04 HWADDR_PRIx val=0x%02
+DPRINTF( [debugcon: write addr=0x%04 HWADDR_PRIx val=0x%02
PRIx64 ]\n, addr, val);
#endif
@@ -68,7 +77,7 @@ static uint64_t debugcon_ioport_read(void *opaque, hwaddr
addr, unsigned width)
DebugconState *s = opaque;
#ifdef DEBUG_DEBUGCON
-printf(debugcon: read addr=0x%04 HWADDR_PRIx \n, addr);
+DPRINTF(debugcon: read addr=0x%04 HWADDR_PRIx \n, addr);
#endif
return s-readback;
--
1.7.2.5
[Qemu-devel] [PATCH 2/3] debugcon: beautify debugcon debug output
use '[...msg...]' to separate debug console output from device debug output Signed-off-by: liguang lig.f...@cn.fujitsu.com --- hw/char/debugcon.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/hw/char/debugcon.c b/hw/char/debugcon.c index cb31544..de73f1b 100644 --- a/hw/char/debugcon.c +++ b/hw/char/debugcon.c @@ -55,8 +55,8 @@ static void debugcon_ioport_write(void *opaque, hwaddr addr, uint64_t val, unsigned char ch = val; #ifdef DEBUG_DEBUGCON -printf(debugcon: write addr=0x%04 HWADDR_PRIx val=0x%02 - PRIx64 \n, addr, val); +printf( [debugcon: write addr=0x%04 HWADDR_PRIx val=0x%02 + PRIx64 ]\n, addr, val); #endif qemu_chr_fe_write(s-chr, ch, 1); -- 1.7.2.5
Re: [Qemu-devel] [PATCH v1 1/1] configure: Probe for libfdt_env.h
Hi Peter, On Wed, May 22, 2013 at 6:26 PM, Peter Maydell peter.mayd...@linaro.org wrote: On 22 May 2013 08:47, Edgar E. Iglesias edgar.igles...@gmail.com wrote: On Wed, May 22, 2013 at 11:50:22AM +1000, peter.crosthwa...@xilinx.com wrote: From: Peter Crosthwaite peter.crosthwa...@xilinx.com Currently QEMU provides a local clone of the file libfdt_env.h in /include. This file is supposed to come with the libfdt package and is only needed for broken installs of libfdt. Unfortunately, libfdt 1.3 stable is tagged with this bug so we cant realistically remove the clone. So instead, use a configure time probe - check to see if the host is already providing this file, and if so, don't use QEMUs local clone of libfdt.h. Moved include/libfdt_env.h to include/libfdt/libfdt_env.h so it can be treated as a special case. For newer (development) versions of libfdt this probe will succeed and include/libfdt/libfdt_env.h will simply be ignored. Should we consider removing our builtin version and stick to either using the hosts or when that fails suggest the submoduled dtc pkg? I agree that that sounds like a better idea: just add the #include to our existing fdt probe, and then we'll simply ignore system libfdt if it's not new enough. The relevant changes got committed to libfdt git in 2008, after all I'm happy with this respin assuming Peters dtc-is-compulsory series goes through before. Otherwise people with dtc 1.3.0 installed will get cop a silent failure when qemu borks on their previously-working system 1.3.0 and falls backs to just building with no dtc at all. I'll remake in the meantime. Regards, Peter thanks -- PMM
Re: [Qemu-devel] [PATCH 5/5] memory: able to pin guest node memory to host node manually
Ping
On 05/23/2013 04:47 PM, Wanlong Gao wrote:
Use mbind to pin guest numa node memory to host nodes manually.
If we are not able to pin memory to host node, we may meet the
cross node memory access performance regression.
With this patch, we can add manual pinning host node like this:
-m 1024 -numa node,cpus=0,nodeid=0,mem=512,pin=0 -numa
node,nodeid=1,cpus=1,mem=512,pin=1
And, if PCI-passthrough is used, direct-attached-device uses DMA transfer
between device and qemu process. All pages of the guest will be pinned by
get_user_pages().
KVM_ASSIGN_PCI_DEVICE ioctl
kvm_vm_ioctl_assign_device()
=kvm_assign_device()
= kvm_iommu_map_memslots()
= kvm_iommu_map_pages()
= kvm_pin_pages()
So, with direct-attached-device, all guest page's page count will be +1 and
any page migration will not work. AutoNUMA won't too. And direction by
libvirt is *ignored*.
Above all, we need manual pinning memory to host node to avoid
such cross nodes memmory access performance regression.
Any comments ?
Thanks,
Wanlong Gao
Signed-off-by: Wanlong Gao gaowanl...@cn.fujitsu.com
---
exec.c | 21 +
include/sysemu/sysemu.h | 1 +
vl.c| 13 +
3 files changed, 35 insertions(+)
diff --git a/exec.c b/exec.c
index aec65c5..fe929ef 100644
--- a/exec.c
+++ b/exec.c
@@ -36,6 +36,8 @@
#include qemu/config-file.h
#include exec/memory.h
#include sysemu/dma.h
+#include sysemu/sysemu.h
+#include qemu/bitops.h
#include exec/address-spaces.h
#if defined(CONFIG_USER_ONLY)
#include qemu.h
@@ -1081,6 +1083,25 @@ ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size,
void *host,
memory_try_enable_merging(new_block-host, size);
}
}
+
+if (nb_numa_nodes 0 !strcmp(mr-name, pc.ram)) {
+int i;
+uint64_t nodes_mem = 0;
+unsigned long *maskp = g_malloc0(sizeof(*maskp));
+for (i = 0; i nb_numa_nodes; i++) {
+*maskp = 0;
+if (node_pin[i] != -1) {
+set_bit(node_pin[i], maskp);
+if (qemu_mbind(new_block-host + nodes_mem, node_mem[i],
+ QEMU_MPOL_BIND, maskp, MAX_NODES, 0)) {
+perror(qemu_mbind);
+exit(1);
+}
+}
+nodes_mem += node_mem[i];
+}
+}
+
new_block-length = size;
/* Keep the list sorted from biggest to smallest block. */
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 2fb71af..ebf6580 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -131,6 +131,7 @@ extern QEMUClock *rtc_clock;
#define MAX_CPUMASK_BITS 255
extern int nb_numa_nodes;
extern uint64_t node_mem[MAX_NODES];
+extern int node_pin[MAX_NODES];
extern unsigned long *node_cpumask[MAX_NODES];
#define MAX_OPTION_ROMS 16
diff --git a/vl.c b/vl.c
index b1d..3768002 100644
--- a/vl.c
+++ b/vl.c
@@ -253,6 +253,7 @@ static QTAILQ_HEAD(, FWBootEntry) fw_boot_order =
int nb_numa_nodes;
uint64_t node_mem[MAX_NODES];
+int node_pin[MAX_NODES];
unsigned long *node_cpumask[MAX_NODES];
uint8_t qemu_uuid[16];
@@ -1390,6 +1391,17 @@ static void numa_add(const char *optarg)
}
node_mem[nodenr] = sval;
}
+
+if (get_param_value(option, 128, pin, optarg) != 0) {
+int unsigned long long pin_node;
+if (parse_uint_full(option, pin_node, 10) 0) {
+fprintf(stderr, qemu: Invalid pinning nodeid: %s\n,
optarg);
+exit(1);
+} else {
+node_pin[nodenr] = pin_node;
+}
+}
+
if (get_param_value(option, 128, cpus, optarg) != 0) {
numa_node_parse_cpus(nodenr, option);
}
@@ -2921,6 +2933,7 @@ int main(int argc, char **argv, char **envp)
for (i = 0; i MAX_NODES; i++) {
node_mem[i] = 0;
+node_pin[i] = -1;
node_cpumask[i] = bitmap_new(MAX_CPUMASK_BITS);
}
[Qemu-devel] [PATCH] qapi: pad GenericList value fields to 64 bits
With the introduction of native list types, we now have types such as
int64List where the 'value' field is not a pointer, but the actual
64-bit value.
On 32-bit architectures, this can lead to situations where 'next' field
offset in GenericList does not correspond to the 'next' field in the
types that we cast to GenericList when using the visit_next_list()
interface, causing issues when we attempt to traverse linked list
structures of these types.
To fix this, pad the 'value' field of GenericList and other
schema-defined/native *List types out to 64-bits.
This is less memory-efficient for 32-bit architectures, but allows us to
continue to rely on list-handling interfaces that target GenericList to
simply visitor implementations.
In the future we can improve efficiency by defaulting to using native C
array backends to handle list of non-pointer types, which would be more
memory efficient in itself and allow us to roll back this change.
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
include/qapi/visitor.h |5 -
scripts/qapi-types.py | 10 --
tests/test-qmp-output-visitor.c |5 -
3 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/include/qapi/visitor.h b/include/qapi/visitor.h
index 1fef18c..28c21d8 100644
--- a/include/qapi/visitor.h
+++ b/include/qapi/visitor.h
@@ -18,7 +18,10 @@
typedef struct GenericList
{
-void *value;
+union {
+void *value;
+uint64_t padding;
+};
struct GenericList *next;
} GenericList;
diff --git a/scripts/qapi-types.py b/scripts/qapi-types.py
index fd42d71..ddcfed9 100644
--- a/scripts/qapi-types.py
+++ b/scripts/qapi-types.py
@@ -22,7 +22,10 @@ def generate_fwd_struct(name, members, builtin_type=False):
typedef struct %(name)sList
{
-%(type)s value;
+union {
+%(type)s value;
+uint64_t padding;
+};
struct %(name)sList *next;
} %(name)sList;
''',
@@ -35,7 +38,10 @@ typedef struct %(name)s %(name)s;
typedef struct %(name)sList
{
-%(name)s *value;
+union {
+%(name)s *value;
+uint64_t padding;
+};
struct %(name)sList *next;
} %(name)sList;
''',
diff --git a/tests/test-qmp-output-visitor.c b/tests/test-qmp-output-visitor.c
index 0942a41..b2fa9a7 100644
--- a/tests/test-qmp-output-visitor.c
+++ b/tests/test-qmp-output-visitor.c
@@ -295,7 +295,10 @@ static void
test_visitor_out_struct_errors(TestOutputVisitorData *data,
typedef struct TestStructList
{
-TestStruct *value;
+union {
+TestStruct *value;
+uint64_t padding;
+};
struct TestStructList *next;
} TestStructList;
--
1.7.9.5
Re: [Qemu-devel] make check breakage on 32 bit hosts
On Sun, May 26, 2013 at 10:26:48AM -0500, mdroth wrote: On Sun, May 26, 2013 at 12:00:57PM +, Blue Swirl wrote: I get this on i386 chroot for make check: GTESTER tests/test-qmp-output-visitor ** ERROR:/src/qemu/tests/test-qmp-output-visitor.c:595:check_native_list: assertion failed: (tmp) GTester: last random seed: R02S559792e7c8d0762d9a2ee153fba8896c ** Tests case looks correct, problem seems to be that we cast list node to GenericList, which expects the 'value' field to be a pointer type. With native lists types these are in some cases non-pointer types, like intList, where 'value' is an int64_t. On 32-bit archs this cast leads to use uses incorrect offset when trying to traverse the list. Don't see a way to fix this outside of making the code generators do a bit of massaging for these cases rather than a cast. Looking at it now, but might not be able to send a patch till later. Patch sent: http://article.gmane.org/gmane.comp.emulators.qemu/213202 Teaching code generators to be smarter didn't work out so well since visitor implementations allocate storage of list types based on GenericList, so ended up relying on padding to 64-bit instead.
Re: [Qemu-devel] [RFC PATCH v3 00/11] qemu-ga: fsfreeze on Windows using VSS
Hi,
I tried the patch v3,with the following config.
Guest os : win7 32bit professional
Host os : fedora 17
Command:
qemu-kvm -enable-kvm -name win7 -M pc-0.15 -m 1024 -smp 2 -boot c -device
virtio-serial -drive
file=/home/libaiqing/vss/win7.img,if=virtio,index=0,format=qcow2 - -monitor
stdio -vga qxl -vnc :1 -chardev
socket,id=charchannel0,path=/var/lib/libvirt/qemu/wahaha1_requester,server,nowait
-device
virtserialport,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0
Output:
[root@fedora121 ~]# socat stdio,ignoreeof
unix-connect:/var/lib/libvirt/qemu/wahaha1_requester
{execute:guest-fsfreeze-freeze}
{return: 2}
{execute:guest-fsfreeze-status}
{return: frozen}
{execute:guest-fsfreeze-thaw}
{error: {class: GenericError, desc: DoSnapshotSet. (Error:
8004230f) }}
{execute:guest-fsfreeze-status}
{return: thawed}
{execute:guest-fsfreeze-freeze}
{return: 2}
{execute:guest-fsfreeze-status}
{return: frozen}
{execute:guest-fsfreeze-thaw}
{error: {class: GenericError, desc: DoSnapshotSet. (Error:
80042314) }}
{execute:guest-fsfreeze-status}
{return: thawed}
Issue:
1 Extcuting the command guest-fsfreeze-thaw failed,but the fs status is
changed to thawed.Is this ok?
2 Extcuting the command guest-fsfreeze-thaw twice,the desc is different
each time.
Could you give me some advise to debug this problem ? I can provide more
information if need.
Regards,
baiqing
-Original Message-
From: qemu-devel-bounces+libaiqing=huawei@nongnu.org
[mailto:qemu-devel-bounces+libaiqing=huawei@nongnu.org] On Behalf Of
Tomoki Sekiyama
Sent: Tuesday, May 21, 2013 11:34 PM
To: qemu-devel@nongnu.org
Cc: mdr...@linux.vnet.ibm.com; lcapitul...@redhat.com;
vroze...@redhat.com; pbonz...@redhat.com; seiji.agu...@hds.com;
ar...@redhat.com
Subject: [Qemu-devel] [RFC PATCH v3 00/11] qemu-ga: fsfreeze on Windows
using VSS
Hi,
This patch series adds fsfreeze support for Windows qemu-guest-agent.
changes from v2:
- [06/11] Fix errors in Windows 7, reported by Li Baiqing
(see below for details).
changes from v1:
- Fix out-tree build by stop using recursive Makefile
- Added script to extract VSS SDK headers on POSIX systems using msitools
(thanks Paolo)
- Remove some unnecessary header files
v2: http://lists.gnu.org/archive/html/qemu-devel/2013-04/msg02518.html
* Description
In Windows, VSS (Volume Shadow Copy Service) provides a facility to
quiesce filesystems and applications before disk snapshots are taken.
This patch series implements fsfreeze command of qemu-ga using VSS.
* How to build run qemu-ga with VSS support
- Download Microsoft VSS SDK from:
http://www.microsoft.com/en-us/download/details.aspx?id=23490
- Setup the SDK
scripts/extract-vsssdk-headers setup.exe (on POSIX-systems)
- Specify installed SDK directory to configure option as:
./configure -with-vss-sdk=path/to/VSS SDK
--cross-prefix=i686-w64-mingw32-
- make qemu-ga.exe
- Install qemu-ga.exe, qga/vss-win32-provider/qga-provider.{dll,tlb}, and
the other required mingw libraries into the same directory in guests
- Run `qemu-ga.exe -s install' and `net start qemu-ga' in the guests
* About errors in Windows 7 with patch v2
VSS requires to write to snapshot volumes just before making them read-only
at final commit phase. This feature is called `auto-recovery'
(See
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384651(v=vs.85)
.aspx#base.vssgloss_auto_recoved_shadow_copy for details).
Since qemu and libvirt don't have feature to handle writable snapshots,
this patchset just disables auto-recovery by specifying
VSS_VOLSNAP_ATTR_NO_AUTORECOVERY flag to SetContext.
Unfortunately, this flag seems unsupported in Windows 7 or earlier.
It tries to look up the snapshot volumes to write and fails in
VSS_E_OBJECT_NOT_FOUND.
For fundamental resolution we need a framework for guests to query
snapshots
and to mount them as writable snapshots, but we just ignore the error in
this patchset.
Any feedback are appliciated.
---
Tomoki Sekiyama (11):
configure: Support configuring c++ compiler
Fix errors and warnings while compiling with c++ compilier
Add a script to extract VSS SDK headers on POSIX system
qemu-ga: Add an configure option to specify path to Windows VSS SDK
qemu-ga: Add Windows VSS provider to quiesce applications on fsfreeze
qemu-ga: Add Windows VSS requester to quisce applications and
filesystems
qemu-ga: call Windows VSS requester in fsfreeze command handler
qemu-ga: install Windows VSS provider on `qemu-ga -s install'
qemu-ga: Add VSS provider .tlb file in the repository
QMP/qemu-ga-client: make timeout longer for guest-fsfreeze-freeze
command
QMP/qmp.py: set locale for
[Qemu-devel] [PATCH v2 1/1] configure: dtc: Probe for libfdt_env.h
From: Peter Crosthwaite peter.crosthwa...@xilinx.com
Currently QEMU provides a local clone of the file libfdt_env.h in
/include. This file is supposed to come with the libfdt package and is
only needed for broken installs of libfdt. Now that we have submodule
dtc, just ignore these broken installs and prompt for the dtc submodule
install instead. QEMU's local libfdt_env.h is removed accordingly.
Manifests as a bug when building QEMU with modern libfdt. The new
version of libfdt does not compile when QEMUs libfdt_env.h takes
precedence over the hosts.
Signed-off-by: Peter Crosthwaite peter.crosthwa...@xilinx.com
---
changed since V1:
Just fallback to submodule rather than provide libfdt_env.h
I suggest this patch goes in behind PMMs patches to make dtc
compulsory for PPC/MB/ARM to avoid silent regressions for current
users of dtc 1.3.0.
To replicate bug (install latest dtc from src to host and make):
git submodule update --init dtc
cd dtc
git checkout master
make
sudo make install PREFIX=/usr/local
cd ..
./configure --target-list=arm-softmmu --enable-fdt
make
configure| 2 ++
include/libfdt_env.h | 36
2 files changed, 2 insertions(+), 36 deletions(-)
delete mode 100644 include/libfdt_env.h
diff --git a/configure b/configure
index eb74510..87bc9a7 100755
--- a/configure
+++ b/configure
@@ -2519,7 +2519,9 @@ fi
# fdt probe
if test $fdt != no ; then
fdt_libs=-lfdt
+ # explicitly check for libfdt_env.h as it is missing in some stable installs
cat $TMPC EOF
+#include libfdt_env.h
int main(void) { return 0; }
EOF
if compile_prog $fdt_libs ; then
diff --git a/include/libfdt_env.h b/include/libfdt_env.h
deleted file mode 100644
index 3667d4c..000
--- a/include/libfdt_env.h
+++ /dev/null
@@ -1,36 +0,0 @@
-/*
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License, version 2, as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, see http://www.gnu.org/licenses/.
- *
- * Copyright IBM Corp. 2008
- * Authors: Hollis Blanchard holl...@us.ibm.com
- *
- */
-
-#ifndef _LIBFDT_ENV_H
-#define _LIBFDT_ENV_H
-
-#include qemu/bswap.h
-
-#ifdef HOST_WORDS_BIGENDIAN
-#define fdt32_to_cpu(x) (x)
-#define cpu_to_fdt32(x) (x)
-#define fdt64_to_cpu(x) (x)
-#define cpu_to_fdt64(x) (x)
-#else
-#define fdt32_to_cpu(x) bswap32(x)
-#define cpu_to_fdt32(x) bswap32(x)
-#define fdt64_to_cpu(x) bswap64(x)
-#define cpu_to_fdt64(x) bswap64(x)
-#endif
-
-#endif /* _LIBFDT_ENV_H */
--
1.8.3.rc1.44.gb387c77.dirty
Re: [Qemu-devel] [PATCH] qapi: pad GenericList value fields to 64 bits
Am 27.05.2013 05:20, schrieb Michael Roth:
With the introduction of native list types, we now have types such as
int64List where the 'value' field is not a pointer, but the actual
64-bit value.
On 32-bit architectures, this can lead to situations where 'next' field
offset in GenericList does not correspond to the 'next' field in the
types that we cast to GenericList when using the visit_next_list()
interface, causing issues when we attempt to traverse linked list
structures of these types.
To fix this, pad the 'value' field of GenericList and other
schema-defined/native *List types out to 64-bits.
This is less memory-efficient for 32-bit architectures, but allows us to
continue to rely on list-handling interfaces that target GenericList to
simply visitor implementations.
In the future we can improve efficiency by defaulting to using native C
array backends to handle list of non-pointer types, which would be more
memory efficient in itself and allow us to roll back this change.
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
include/qapi/visitor.h |5 -
scripts/qapi-types.py | 10 --
tests/test-qmp-output-visitor.c |5 -
3 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/include/qapi/visitor.h b/include/qapi/visitor.h
index 1fef18c..28c21d8 100644
--- a/include/qapi/visitor.h
+++ b/include/qapi/visitor.h
@@ -18,7 +18,10 @@
typedef struct GenericList
{
-void *value;
+union {
+void *value;
+uint64_t padding;
+};
struct GenericList *next;
} GenericList;
diff --git a/scripts/qapi-types.py b/scripts/qapi-types.py
index fd42d71..ddcfed9 100644
--- a/scripts/qapi-types.py
+++ b/scripts/qapi-types.py
@@ -22,7 +22,10 @@ def generate_fwd_struct(name, members, builtin_type=False):
typedef struct %(name)sList
{
-%(type)s value;
+union {
+%(type)s value;
+uint64_t padding;
+};
struct %(name)sList *next;
} %(name)sList;
''',
@@ -35,7 +38,10 @@ typedef struct %(name)s %(name)s;
typedef struct %(name)sList
{
-%(name)s *value;
+union {
+%(name)s *value;
+uint64_t padding;
+};
struct %(name)sList *next;
} %(name)sList;
''',
diff --git a/tests/test-qmp-output-visitor.c b/tests/test-qmp-output-visitor.c
index 0942a41..b2fa9a7 100644
--- a/tests/test-qmp-output-visitor.c
+++ b/tests/test-qmp-output-visitor.c
@@ -295,7 +295,10 @@ static void
test_visitor_out_struct_errors(TestOutputVisitorData *data,
typedef struct TestStructList
{
-TestStruct *value;
+union {
+TestStruct *value;
+uint64_t padding;
+};
struct TestStructList *next;
} TestStructList;
Looks good. Would reordering of value, next work, too
(without memory overhead for 32 bit systems)?
typedef struct GenericList
{
struct GenericList *next;
void *value;
} GenericList;
typedef struct %(name)sList
{
struct %(name)sList *next;
%(type)s value;
} %(name)sList;
...
It looks like memory allocation (g_malloc0) for GenericList
was also wrong in the old code (this is fixed with your patch).
