Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
On 2011-10-10 08:59, Wen Congyang wrote: > At 10/10/2011 02:52 PM, Jan Kiszka Write: >> On 2011-10-10 04:21, Wen Congyang wrote: >>> At 10/09/2011 06:23 PM, Richard W.M. Jones Write: On Sun, Oct 09, 2011 at 10:49:57AM +0200, Jan Kiszka wrote: > As explained in the other replies: It is way more future-proof to use an > interface for this which was designed for it (remote gdb) instead of > artificially relaxing reasonable constraints of the migration mechanism > plus having to follow that format with the post-processing tool. Any interface that isn't "get this information off my production server *now*" so that I can get the server restarted, and send it to an expert to analyse -- is a poor interface, whether it was designed like that or not. Perhaps we don't have the right interface at all, but remote gdb is not it. >>> >>> What about the following idea? >>> >>> Introduce a new monitor command named dump, and this command accepts a >>> filename. >>> We can use almost all migration's code. We use this command to dump guest's >>> memory, so there is no need to check whether the guest has a unmigratable >>> device. >> >> I do not want to reject this proposal categorically, but I would like to >> see the gdb path fail /wrt essential requirements first. So far I don't >> see it would. > > ‘gdb path fail /wrt essential requirements’ > > what does it mean? That you explain why reading reading memory and processor states via the remote gdb interface and dumping it into a proper core file cannot be made working for you. Jan signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
Am 10.10.2011 um 08:52 schrieb Jan Kiszka : > On 2011-10-10 04:21, Wen Congyang wrote: >> At 10/09/2011 06:23 PM, Richard W.M. Jones Write: >>> On Sun, Oct 09, 2011 at 10:49:57AM +0200, Jan Kiszka wrote: As explained in the other replies: It is way more future-proof to use an interface for this which was designed for it (remote gdb) instead of artificially relaxing reasonable constraints of the migration mechanism plus having to follow that format with the post-processing tool. >>> >>> Any interface that isn't "get this information off my production >>> server *now*" so that I can get the server restarted, and send it to >>> an expert to analyse -- is a poor interface, whether it was designed >>> like that or not. Perhaps we don't have the right interface at all, >>> but remote gdb is not it. >> >> What about the following idea? >> >> Introduce a new monitor command named dump, and this command accepts a >> filename. >> We can use almost all migration's code. We use this command to dump guest's >> memory, so there is no need to check whether the guest has a unmigratable >> device. > > I do not want to reject this proposal categorically, but I would like to > see the gdb path fail /wrt essential requirements first. So far I don't > see it would. Through gdb you access virtual address space, whilein this case you really want physical. All you need to create a core file is a memory dump and a register dump. For registers, gdb sounds like a good interface. For memory, why not just use pmemsave? Maybe add a monitor/qmp command that tells you all ram regions, so pmemsave can be invoked intelligently. The alternative to all this is obviously an in-qemu 'core' command that creates core files inside of qemu. That's where I think it really belongs to. Libvirt is a management tool stack, not a "I don't like to work on qemu code so I push code to the layer on top" mesh of things. Or at least that's how it's really supposed to be :). Alex >
Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
On 2011-10-10 09:08, Alexander Graf wrote: > > Am 10.10.2011 um 08:52 schrieb Jan Kiszka : > >> On 2011-10-10 04:21, Wen Congyang wrote: >>> At 10/09/2011 06:23 PM, Richard W.M. Jones Write: On Sun, Oct 09, 2011 at 10:49:57AM +0200, Jan Kiszka wrote: > As explained in the other replies: It is way more future-proof to use an > interface for this which was designed for it (remote gdb) instead of > artificially relaxing reasonable constraints of the migration mechanism > plus having to follow that format with the post-processing tool. Any interface that isn't "get this information off my production server *now*" so that I can get the server restarted, and send it to an expert to analyse -- is a poor interface, whether it was designed like that or not. Perhaps we don't have the right interface at all, but remote gdb is not it. >>> >>> What about the following idea? >>> >>> Introduce a new monitor command named dump, and this command accepts a >>> filename. >>> We can use almost all migration's code. We use this command to dump guest's >>> memory, so there is no need to check whether the guest has a unmigratable >>> device. >> >> I do not want to reject this proposal categorically, but I would like to >> see the gdb path fail /wrt essential requirements first. So far I don't >> see it would. > > Through gdb you access virtual address space, whilein this case you really > want physical. You want to attach a debugger afterwards as well. So this is just about offlining the gdb session the end user should not have to handle himself. Jan signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
At 10/10/2011 03:01 PM, Jan Kiszka Write: > On 2011-10-10 08:59, Wen Congyang wrote: >> At 10/10/2011 02:52 PM, Jan Kiszka Write: >>> On 2011-10-10 04:21, Wen Congyang wrote: At 10/09/2011 06:23 PM, Richard W.M. Jones Write: > On Sun, Oct 09, 2011 at 10:49:57AM +0200, Jan Kiszka wrote: >> As explained in the other replies: It is way more future-proof to use an >> interface for this which was designed for it (remote gdb) instead of >> artificially relaxing reasonable constraints of the migration mechanism >> plus having to follow that format with the post-processing tool. > > Any interface that isn't "get this information off my production > server *now*" so that I can get the server restarted, and send it to > an expert to analyse -- is a poor interface, whether it was designed > like that or not. Perhaps we don't have the right interface at all, > but remote gdb is not it. What about the following idea? Introduce a new monitor command named dump, and this command accepts a filename. We can use almost all migration's code. We use this command to dump guest's memory, so there is no need to check whether the guest has a unmigratable device. >>> >>> I do not want to reject this proposal categorically, but I would like to >>> see the gdb path fail /wrt essential requirements first. So far I don't >>> see it would. >> >> ‘gdb path fail /wrt essential requirements’ >> >> what does it mean? > > That you explain why reading reading memory and processor states via the > remote gdb interface and dumping it into a proper core file cannot be > made working for you. First, I think crash can not analyze such core file. But it is not very important. What is remote gdb interface? Do you mean that: the supporter uses gdb from another machine to connect to customer's machine and get the data? If so, this way can not be used when the customer needs to dump the guest's memory automatically when watchdog timeouts. Thanks Wen Congyang > > Jan >
Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
On 2011-10-10 09:17, Wen Congyang wrote: > At 10/10/2011 03:01 PM, Jan Kiszka Write: >> On 2011-10-10 08:59, Wen Congyang wrote: >>> At 10/10/2011 02:52 PM, Jan Kiszka Write: On 2011-10-10 04:21, Wen Congyang wrote: > At 10/09/2011 06:23 PM, Richard W.M. Jones Write: >> On Sun, Oct 09, 2011 at 10:49:57AM +0200, Jan Kiszka wrote: >>> As explained in the other replies: It is way more future-proof to use an >>> interface for this which was designed for it (remote gdb) instead of >>> artificially relaxing reasonable constraints of the migration mechanism >>> plus having to follow that format with the post-processing tool. >> >> Any interface that isn't "get this information off my production >> server *now*" so that I can get the server restarted, and send it to >> an expert to analyse -- is a poor interface, whether it was designed >> like that or not. Perhaps we don't have the right interface at all, >> but remote gdb is not it. > > What about the following idea? > > Introduce a new monitor command named dump, and this command accepts a > filename. > We can use almost all migration's code. We use this command to dump > guest's > memory, so there is no need to check whether the guest has a unmigratable > device. I do not want to reject this proposal categorically, but I would like to see the gdb path fail /wrt essential requirements first. So far I don't see it would. >>> >>> ‘gdb path fail /wrt essential requirements’ >>> >>> what does it mean? >> >> That you explain why reading reading memory and processor states via the >> remote gdb interface and dumping it into a proper core file cannot be >> made working for you. > > First, I think crash can not analyze such core file. But it is not very > important. > > What is remote gdb interface? man qemu -> gdb. > Do you mean that: the supporter uses gdb from another machine Or locally. There are various transports possible. > to connect to customer's machine and get the data? If so, this way can not be > used when the customer needs to dump the guest's memory automatically when > watchdog timeouts. It is just another channel that can conceptually be used like the monitor, by a management app like libvirt, directly or indirectly via a scripted gdb frontend, or also by a human who wants to save some ongoing gdb session for later analysis. This dual use make such an approach the preferred one. Jan signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] Is realview-pb-a8 fully supported ?
On Sun, Oct 9, 2011 at 6:22 PM, Francis Moreau wrote: > On Sun, Oct 9, 2011 at 2:51 PM, Peter Maydell > wrote: >> On 9 October 2011 13:06, Francis Moreau wrote: >>> On Sun, Oct 9, 2011 at 12:48 PM, Peter Maydell >>> wrote: On 9 October 2011 09:28, Francis Moreau wrote: > I'm trying to use qemu to emulate the ARM realview-pb-a8 and more > specifically I'd like to boot using the SD interface. > > However it looks like some devices are not emulated at all on this > platform. Correct; not all devices are emulated. >> >>> May I suggest to report that a platform is partially supported when >>> doing "qemu -M ?" >> >> I suspect that (in the sense you seem to be using "partially supported") >> would cover almost all the platforms QEMU supports. Device and board >> modelling is not trivial, and the typical state is that devices may be >> missing, or have unimplemented features, or have bugs. >> >> The platform is supported in the sense that if you report regressions >> (ie things that used to work and have broken) I will look at them, and >> if you submit patches to improve it I will review them. >> > > Ok. > >>> However, those are still missing: >>> >>> amba_device_register failed to register dev:smc >>> amba_device_register failed to register dev:sctl >>> amba_device_register failed to register dev:wdog >>> amba_device_register failed to register dev:sci0 >>> amba_device_register failed to register dev:ssp0 >>> amba_device_register failed to register fpga:aaci >> >> Do you actually *need* these devices? > > Not really, but it took me some times to realize why booting from SD > interface did work with qemu. So I prefered asking to avoid been hit I meant: "why booting from SD interface *didn't* work..." I noticed another point for the realview platofrm: if I boot with "-M 512", it works however if I set "-M 256" then it doesn't. Is this expected ? Thanks -- Francis
Re: [Qemu-devel] [PATCH RFC] qemu-file: output data directly if possible
On 10/10/2011 01:56 AM, Michael S. Tsirkin wrote: qemu file currently always buffers up data before writing it out. At least for memory this is probably not a good idea: writing out to file would be cheaper. Let's do that if we can, which should be the common case. If we can't, buffer. Signed-off-by: Michael S. Tsirkin --- Completely untested, this is just thinking aloud. Shouldn't the below save us a data copy in the common case, helping speed up migration? The problem here is qemu_put_byte and friends, where the indirection of a function call would probably slow things down. In the common case, qemu_put_byte is called a lot and f->buf_index would not be zero. The way to go would probably be to merge QEMUFile and QEMUBufferedFile's two buffering layers, which also removes a copy. Paolo
Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
At 10/10/2011 03:22 PM, Jan Kiszka Write: > On 2011-10-10 09:17, Wen Congyang wrote: >> At 10/10/2011 03:01 PM, Jan Kiszka Write: >>> On 2011-10-10 08:59, Wen Congyang wrote: At 10/10/2011 02:52 PM, Jan Kiszka Write: > On 2011-10-10 04:21, Wen Congyang wrote: >> At 10/09/2011 06:23 PM, Richard W.M. Jones Write: >>> On Sun, Oct 09, 2011 at 10:49:57AM +0200, Jan Kiszka wrote: As explained in the other replies: It is way more future-proof to use an interface for this which was designed for it (remote gdb) instead of artificially relaxing reasonable constraints of the migration mechanism plus having to follow that format with the post-processing tool. >>> >>> Any interface that isn't "get this information off my production >>> server *now*" so that I can get the server restarted, and send it to >>> an expert to analyse -- is a poor interface, whether it was designed >>> like that or not. Perhaps we don't have the right interface at all, >>> but remote gdb is not it. >> >> What about the following idea? >> >> Introduce a new monitor command named dump, and this command accepts a >> filename. >> We can use almost all migration's code. We use this command to dump >> guest's >> memory, so there is no need to check whether the guest has a >> unmigratable device. > > I do not want to reject this proposal categorically, but I would like to > see the gdb path fail /wrt essential requirements first. So far I don't > see it would. ‘gdb path fail /wrt essential requirements’ what does it mean? >>> >>> That you explain why reading reading memory and processor states via the >>> remote gdb interface and dumping it into a proper core file cannot be >>> made working for you. >> >> First, I think crash can not analyze such core file. But it is not very >> important. >> >> What is remote gdb interface? > > man qemu -> gdb. > >> Do you mean that: the supporter uses gdb from another machine > > Or locally. There are various transports possible. > >> to connect to customer's machine and get the data? If so, this way can not be >> used when the customer needs to dump the guest's memory automatically when >> watchdog timeouts. > > It is just another channel that can conceptually be used like the > monitor, by a management app like libvirt, directly or indirectly via a > scripted gdb frontend, or also by a human who wants to save some ongoing > gdb session for later analysis. This dual use make such an approach the > preferred one. Is the following is right? 1. execute the monitor command 'gdbserver' 2. run gdb and then 'target remote :1234' But, unfortunately, the monitor command gdbserver does not exit when we use json to connect to monitor. Thanks Wen Congyang > > Jan >
Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
On 2011-10-10 09:47, Wen Congyang wrote: > At 10/10/2011 03:22 PM, Jan Kiszka Write: >> On 2011-10-10 09:17, Wen Congyang wrote: >>> At 10/10/2011 03:01 PM, Jan Kiszka Write: On 2011-10-10 08:59, Wen Congyang wrote: > At 10/10/2011 02:52 PM, Jan Kiszka Write: >> On 2011-10-10 04:21, Wen Congyang wrote: >>> At 10/09/2011 06:23 PM, Richard W.M. Jones Write: On Sun, Oct 09, 2011 at 10:49:57AM +0200, Jan Kiszka wrote: > As explained in the other replies: It is way more future-proof to use > an > interface for this which was designed for it (remote gdb) instead of > artificially relaxing reasonable constraints of the migration > mechanism > plus having to follow that format with the post-processing tool. Any interface that isn't "get this information off my production server *now*" so that I can get the server restarted, and send it to an expert to analyse -- is a poor interface, whether it was designed like that or not. Perhaps we don't have the right interface at all, but remote gdb is not it. >>> >>> What about the following idea? >>> >>> Introduce a new monitor command named dump, and this command accepts a >>> filename. >>> We can use almost all migration's code. We use this command to dump >>> guest's >>> memory, so there is no need to check whether the guest has a >>> unmigratable device. >> >> I do not want to reject this proposal categorically, but I would like to >> see the gdb path fail /wrt essential requirements first. So far I don't >> see it would. > > ‘gdb path fail /wrt essential requirements’ > > what does it mean? That you explain why reading reading memory and processor states via the remote gdb interface and dumping it into a proper core file cannot be made working for you. >>> >>> First, I think crash can not analyze such core file. But it is not very >>> important. >>> >>> What is remote gdb interface? >> >> man qemu -> gdb. >> >>> Do you mean that: the supporter uses gdb from another machine >> >> Or locally. There are various transports possible. >> >>> to connect to customer's machine and get the data? If so, this way can not >>> be >>> used when the customer needs to dump the guest's memory automatically when >>> watchdog timeouts. >> >> It is just another channel that can conceptually be used like the >> monitor, by a management app like libvirt, directly or indirectly via a >> scripted gdb frontend, or also by a human who wants to save some ongoing >> gdb session for later analysis. This dual use make such an approach the >> preferred one. > > Is the following is right? > > 1. execute the monitor command 'gdbserver' > 2. run gdb and then 'target remote :1234' Yep. > > But, unfortunately, the monitor command gdbserver does not exit when we use > json to connect to monitor. You mean via human-monitor-command (gdbserver is not a qmp command)? Would be a bug. Jan signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] CD foler list and content won't update after eject and replace CD in winxp guest
On 10/10/2011 06:26 AM, Jiff Shen wrote: > I recently found there is an issue with CD support in qemu, > my vm guest is windows xp, qemu version 0.13.50 which is from spice git, > the vm is startup with physical CDROM attached. > If I push the eject button of CDROM device and change CD media, most > time the directory list won't update in vm. (eject in winxp works) > I guess it's because the vm cannot receive the eject event from the > device, is this a known issue or has it already been fixed? It is possible that it has been fixed very recently. Markus Armbruster did a lot of improvements to the handling of CD-ROM media. However, I am not sure whether it works with a physical CD-ROM device being "passed" to the guest. Paolo
Re: [Qemu-devel] [RFC] Adding new filesystem 'proxy' to 9p
"Daniel P. Berrange" writes: > On Thu, Sep 29, 2011 at 11:42:47PM +0530, M. Mohan Kumar wrote: >> On Wednesday, September 28, 2011 08:29:06 PM Daniel P. Berrange wrote: [...] >> > If we assume that QEMU gets exploited, and that QEMU can find some flaw >> > in the proxy_helper that it can exploit, what damage can the proxy_helper >> > do ? Clearly we want it to not be able to read/write any files other >> > than those exported, even when it becomes compromised, ideally also >> > without requiring SELinux/AppArmour to make it safe. If proxy_helper >> > is running as root with full capabilities, it can trivially escape >> > the chroot[1], so this isn't all that nice for overall system security. >> >> When proxy helper process is forked, its made sure that all open file >> descriptor are closed except the socket descriptor, so that proxy helper >> can't >> escape chroot jail. > > Unfortunately that is not sufficient. Even if you have closed all > file descriptors except the socket, you can still escape the chroot > jail. There is a nice demo program for escaping from a chroot on > this webpage: > > http://www.bpfh.net/simes/computing/chroot-break.html [...] > Basically if the process inside the chroot, is still running as > root, then it is not securely contained. As Alan Cox observed, "chroot is not and never has been a security tool." It's a tool to configure the root of absolute path names. [...]
Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
At 10/10/2011 03:48 PM, Jan Kiszka Write: > On 2011-10-10 09:47, Wen Congyang wrote: >> At 10/10/2011 03:22 PM, Jan Kiszka Write: >>> On 2011-10-10 09:17, Wen Congyang wrote: At 10/10/2011 03:01 PM, Jan Kiszka Write: > On 2011-10-10 08:59, Wen Congyang wrote: >> At 10/10/2011 02:52 PM, Jan Kiszka Write: >>> On 2011-10-10 04:21, Wen Congyang wrote: At 10/09/2011 06:23 PM, Richard W.M. Jones Write: > On Sun, Oct 09, 2011 at 10:49:57AM +0200, Jan Kiszka wrote: >> As explained in the other replies: It is way more future-proof to >> use an >> interface for this which was designed for it (remote gdb) instead of >> artificially relaxing reasonable constraints of the migration >> mechanism >> plus having to follow that format with the post-processing tool. > > Any interface that isn't "get this information off my production > server *now*" so that I can get the server restarted, and send it to > an expert to analyse -- is a poor interface, whether it was designed > like that or not. Perhaps we don't have the right interface at all, > but remote gdb is not it. What about the following idea? Introduce a new monitor command named dump, and this command accepts a filename. We can use almost all migration's code. We use this command to dump guest's memory, so there is no need to check whether the guest has a unmigratable device. >>> >>> I do not want to reject this proposal categorically, but I would like to >>> see the gdb path fail /wrt essential requirements first. So far I don't >>> see it would. >> >> ‘gdb path fail /wrt essential requirements’ >> >> what does it mean? > > That you explain why reading reading memory and processor states via the > remote gdb interface and dumping it into a proper core file cannot be > made working for you. First, I think crash can not analyze such core file. But it is not very important. What is remote gdb interface? >>> >>> man qemu -> gdb. >>> Do you mean that: the supporter uses gdb from another machine >>> >>> Or locally. There are various transports possible. >>> to connect to customer's machine and get the data? If so, this way can not be used when the customer needs to dump the guest's memory automatically when watchdog timeouts. >>> >>> It is just another channel that can conceptually be used like the >>> monitor, by a management app like libvirt, directly or indirectly via a >>> scripted gdb frontend, or also by a human who wants to save some ongoing >>> gdb session for later analysis. This dual use make such an approach the >>> preferred one. >> >> Is the following is right? >> >> 1. execute the monitor command 'gdbserver' >> 2. run gdb and then 'target remote :1234' > > Yep. Can two guest use such port(1234) at the same time? If not, I think qemu should support to select a port automatically. Another problem is that: we should not require dev and debug tools(here is gdb) to be installed on the production host. > >> >> But, unfortunately, the monitor command gdbserver does not exit when we use >> json to connect to monitor. > > You mean via human-monitor-command (gdbserver is not a qmp command)? Yes. Thanks Wen Congyang > Would be a bug. > > Jan >
Re: [Qemu-devel] CD foler list and content won't update after eject and replace CD in winxp guest
Jiff Shen writes: > I recently found there is an issue with CD support in qemu, > my vm guest is windows xp, qemu version 0.13.50 which is from spice git, > the vm is startup with physical CDROM attached. > If I push the eject button of CDROM device and change CD media, most > time the directory list won't update in vm. (eject in winxp works) > I guess it's because the vm cannot receive the eject event from the > device, is this a known issue or has it already been fixed? We fixed quite a few CD-ROM bugs since then. Can't tell whether yours is among them, but you could: test with the current version. If you got your QEMU as part of a Linux distribution, many later fixes may have been applied to it already, but you need to talk to the maker of the distribution.
Re: [Qemu-devel] Is realview-pb-a8 fully supported ?
On 10 October 2011 08:35, Francis Moreau wrote: > I noticed another point for the realview platofrm: if I boot with "-M > 512", it works however if I set "-M 256" then it doesn't. Perhaps your kernel is configured to load in the higher 256MB address range, or is configured/has a command line which assumes it has 512MB of RAM? (In what way does it "not work" ?) -- PMM
Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
On Fri, Oct 07, 2011 at 02:56:56PM +0200, Jan Kiszka wrote: > On 2011-10-07 14:25, Wen Congyang wrote: > > 于 2011/10/7 18:16, Jan Kiszka 写道: > >> On 2011-10-07 11:46, Wen Congyang wrote: > >>> Currently, virsh dump uses monitor command migrate to dump guest's memory > >>> to file, and we can use crash to analyze the file. > >>> > >>> Unfortunately, virsh dump can not work if guest uses host pci device. The > >>> reason is that the device's status is also needed to migrate to remote > >>> machine, > >>> and the host pci device's status is not stored in qemu. So it is > >>> unmigratable. > >>> > >>> I think we can we can add a option to qmp command migrate(eg: skip) to > >>> allow > >>> the user to skip the check, and this option should be used only when > >>> dumping > >>> the guest's memory. > >> > >> Why not simply attach gdb? That works independently of migration. > > > > If qemu has some problem, we can use gdb to debug it. But if guest os > > has problem > > (eg:kernel panic and kdump does not work), we should dump guest's memory > > and use > > crash to analyze. > > qemu-system-xxx -s (or "gdbserver" via monitor if qemu is already > running), gdb vmlinux, then "target remote :1234". That is already possible, but that is not what we need for 'virsh dump'. The goal of that API is to provide a coredump of the guest, which can then be analysed off-node/site. While in theory you could attach GDB to the QEMU process and use GDB commands to then write out a coredump this isn't really satisfactory because too many large companies have security/audit compliance rules which forbid installation of developer tools (compilers, debuggers, etc) on production servers. So we cannot assume GDB is available. We need to be able to create a coredump natively from either QEMU or libvirt, with minimal of external tools. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
On Mon, Oct 10, 2011 at 08:52:08AM +0200, Jan Kiszka wrote: > On 2011-10-10 04:21, Wen Congyang wrote: > > At 10/09/2011 06:23 PM, Richard W.M. Jones Write: > >> On Sun, Oct 09, 2011 at 10:49:57AM +0200, Jan Kiszka wrote: > >>> As explained in the other replies: It is way more future-proof to use an > >>> interface for this which was designed for it (remote gdb) instead of > >>> artificially relaxing reasonable constraints of the migration mechanism > >>> plus having to follow that format with the post-processing tool. > >> > >> Any interface that isn't "get this information off my production > >> server *now*" so that I can get the server restarted, and send it to > >> an expert to analyse -- is a poor interface, whether it was designed > >> like that or not. Perhaps we don't have the right interface at all, > >> but remote gdb is not it. > > > > What about the following idea? > > > > Introduce a new monitor command named dump, and this command accepts a > > filename. > > We can use almost all migration's code. We use this command to dump guest's > > memory, so there is no need to check whether the guest has a unmigratable > > device. > > I do not want to reject this proposal categorically, but I would like to > see the gdb path fail /wrt essential requirements first. So far I don't > see it would. GDB is often forbidden on production servers, so that path is clearly not an option, unless we want libvirt to implement the GDB remote RPC protocol itself which just sounds like a world of hurt. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] [PATCH 1/2] hw/9pfs: Add new virtfs option cache=writethrough to skip host page cache
On Mon, 10 Oct 2011 05:54:56 +0100, Stefan Hajnoczi wrote:
> On Sun, Oct 9, 2011 at 7:35 PM, Aneesh Kumar K.V
> wrote:
> > On Sun, 9 Oct 2011 17:16:50 +0100, Stefan Hajnoczi
> > wrote:
> >> On Sun, Oct 9, 2011 at 4:34 PM, Aneesh Kumar K.V
> >> wrote:
> >> > On Sat, 8 Oct 2011 12:24:37 +0100, Stefan Hajnoczi
> >> > wrote:
> >> >> On Fri, Oct 7, 2011 at 7:46 AM, Aneesh Kumar K.V
> >> >> wrote:
> >> >> > cache=writethrough implies the file are opened in the host with
> >> >> > O_SYNC open flag
> >> >> >
> >> >> > Signed-off-by: Aneesh Kumar K.V
> >> >> > ---
> >> >> > fsdev/file-op-9p.h | 1 +
> >> >> > fsdev/qemu-fsdev.c | 10 --
> >> >> > fsdev/qemu-fsdev.h | 2 ++
> >> >> > hw/9pfs/virtio-9p-device.c | 5 +
> >> >> > hw/9pfs/virtio-9p.c | 24 ++--
> >> >> > qemu-config.c | 6 ++
> >> >> > qemu-options.hx | 17 -
> >> >> > vl.c | 6 ++
> >> >> > 8 files changed, 58 insertions(+), 13 deletions(-)
> >> >>
> >> >> When would this be used? For serving up vanilla 9P?
> >> >>
> >> >> I think 9P.u and 9P.l have support for fsync(2) while vanilla 9P does
> >> >> not.
> >> >>
> >> >
> >> > TFSYNC is added by 9p.L. So we would need this for 9p.u.
> >>
> >> I think 9p.u is covered by this wstat hack in
> >> http://ericvh.github.com/9p-rfc/rfc9p2000.html#anchor32:
> >>
> >> "if all the elements of the directory entry in a Twstat message are
> >> ``don't touch'' val- ues, the server may interpret it as a request to
> >> guarantee that the contents of the associated file are committed to
> >> stable storage before the Rwstat message is returned."
> >>
> >> A real TFSYNC operation is nicer though and could be mandatory (the
> >> 9P2000 RFC only says "the server *may*").
> >>
> >> > Another use
> >> > case is to ensure that we don't leave pages on host as dirty. That would
> >> > ensure that large writeback from a guest don't result in large number of
> >> > dirty pages on the host, thereby resulting in writeback in the host. It
> >> > would be needed for predictable I/O behavior in a setup where we have
> >> > multiple guest.
> >>
> >> I see. I'm mostly curious about this change because the caching modes
> >> are a nightmare with block devices - a lot of time is spent discussing
> >> and benchmarking them, and they cause confusion when configuring KVM.
> >>
> >> It sounds like O_SYNC is being used in order to keep page cache clean.
> >> But keeping the page cache clean is a side-effect of O_SYNC's
> >> behavior: writing out each page and synchronizing the disk write
> >> cache. If you are attempting to bypass the page cache, just use
> >> O_DIRECT without O_SYNC.
> >
> > But how about reads. I want to make sure i get to use the page cache for
> > reads and also want to keep the page cache clean.
> >
> >> O_SYNC is doing the additional disk write
> >> cache synchronization which will slow down I/O and prevent the server
> >> from using disk write cache. O_SYNC is not the right flag to use.
> >
> > O_DIRECT have additional requirement on buffer alignment, and we don't
> > want to send every read to disk. VirtFS also support zero copy
> > read/write, so that buffer alignment will always not be possible.
> > We want to make sure writes don't leave the page cache dirty so
> > that host doesn't spent much time in write back of data dirtied by the
> > guest.
>
> sync_file_range(2) kicks off the write-out but does not flush file
> system metadata or synchronize the disk write cache.
>
something like below ?
commit bc7c28877b30155264f351d26692b3cceca853bb
Author: Aneesh Kumar K.V
Date: Mon May 23 11:29:15 2011 +0530
hw/9pfs: Add new virtfs option cache=writethrough to skip host page cache
cache=writethrough implies the file are opened in the host with O_SYNC open
flag
Signed-off-by: Aneesh Kumar K.V
diff --git a/fsdev/file-op-9p.h b/fsdev/file-op-9p.h
index 8de8abf..84ec9e0 100644
--- a/fsdev/file-op-9p.h
+++ b/fsdev/file-op-9p.h
@@ -53,12 +53,16 @@ struct xattr_operations;
/* FsContext flag values */
#define PATHNAME_FSCONTEXT 0x1
+/* cache flags */
+#define V9FS_WRITETHROUGH_CACHE 0x1
+
typedef struct FsContext
{
int flags;
char *fs_root;
SecModel fs_sm;
uid_t uid;
+int cache_flags;
struct xattr_operations **xops;
/* fs driver specific data */
void *private;
diff --git a/fsdev/qemu-fsdev.c b/fsdev/qemu-fsdev.c
index 768819f..fce016b 100644
--- a/fsdev/qemu-fsdev.c
+++ b/fsdev/qemu-fsdev.c
@@ -34,6 +34,8 @@ int qemu_fsdev_add(QemuOpts *opts)
const char *fstype = qemu_opt_get(opts, "fstype");
const char *path = qemu_opt_get(opts, "path");
const char *sec_model = qemu_opt_get(opts, "security_model");
+const char *cache = qemu_opt_get(opts, "cache");
+
if (!fsdev_id) {
fprintf(stderr, "fsdev: No id specified\n");
@@ -72,10 +74,14 @@ int qemu_fsdev_add
Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
On Mon, Oct 10, 2011 at 10:21:02AM +0800, Wen Congyang wrote: > At 10/09/2011 06:23 PM, Richard W.M. Jones Write: > > On Sun, Oct 09, 2011 at 10:49:57AM +0200, Jan Kiszka wrote: > >> As explained in the other replies: It is way more future-proof to use an > >> interface for this which was designed for it (remote gdb) instead of > >> artificially relaxing reasonable constraints of the migration mechanism > >> plus having to follow that format with the post-processing tool. > > > > Any interface that isn't "get this information off my production > > server *now*" so that I can get the server restarted, and send it to > > an expert to analyse -- is a poor interface, whether it was designed > > like that or not. Perhaps we don't have the right interface at all, > > but remote gdb is not it. > > What about the following idea? > > Introduce a new monitor command named dump, and this command accepts a > filename. > We can use almost all migration's code. We use this command to dump guest's > memory, so there is no need to check whether the guest has a unmigratable > device. I think it would be a good idea of QEMU had a dedicated 'dump' command for this purpose, even if it was just an alias for 'migrate' initially. I have never really liked the fact that we abuse the 'migrate' command to generate a core dump. The resulting data file from this is more complex than it really needs to be, causing complexity for post-processing it. The needs of migration, are not entirely aligned with the needs of core dumping in the long term, so we should allow the possibility of their impls diverging without impacting apps using them. So adding a 'dump' command which wrote out data in a format that was optimized for offline processing by tools like 'crash' (or the windows equivalent) would be a good improvement, even if it just reuses the migrate code for now. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
On Mon, Oct 10, 2011 at 10:08:26AM +0100, Daniel P. Berrange wrote: > On Mon, Oct 10, 2011 at 10:21:02AM +0800, Wen Congyang wrote: > > At 10/09/2011 06:23 PM, Richard W.M. Jones Write: > > > On Sun, Oct 09, 2011 at 10:49:57AM +0200, Jan Kiszka wrote: > > >> As explained in the other replies: It is way more future-proof to use an > > >> interface for this which was designed for it (remote gdb) instead of > > >> artificially relaxing reasonable constraints of the migration mechanism > > >> plus having to follow that format with the post-processing tool. > > > > > > Any interface that isn't "get this information off my production > > > server *now*" so that I can get the server restarted, and send it to > > > an expert to analyse -- is a poor interface, whether it was designed > > > like that or not. Perhaps we don't have the right interface at all, > > > but remote gdb is not it. > > > > What about the following idea? > > > > Introduce a new monitor command named dump, and this command accepts a > > filename. > > We can use almost all migration's code. We use this command to dump guest's > > memory, so there is no need to check whether the guest has a unmigratable > > device. > > I think it would be a good idea of QEMU had a dedicated 'dump' command > for this purpose, even if it was just an alias for 'migrate' initially. > I have never really liked the fact that we abuse the 'migrate' command > to generate a core dump. The resulting data file from this is more > complex than it really needs to be, causing complexity for post-processing > it. The needs of migration, are not entirely aligned with the needs of > core dumping in the long term, so we should allow the possibility of > their impls diverging without impacting apps using them. > > So adding a 'dump' command which wrote out data in a format that was > optimized for offline processing by tools like 'crash' (or the windows > equivalent) would be a good improvement, even if it just reuses the > migrate code for now. The other reason why it would be good, is that we would then have a clearly defined standard "QEMU dump format", instead of "libvirt dump format for QEMU" Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] [PATCH RFC] qemu-file: output data directly if possible
On Mon, Oct 10, 2011 at 09:42:51AM +0200, Paolo Bonzini wrote: > On 10/10/2011 01:56 AM, Michael S. Tsirkin wrote: > >qemu file currently always buffers up data before writing it out. > >At least for memory this is probably not a good idea: > >writing out to file would be cheaper. Let's do > >that if we can, which should be the common case. If we can't, buffer. > > > >Signed-off-by: Michael S. Tsirkin > > > >--- > > > >Completely untested, this is just thinking aloud. > >Shouldn't the below save us a data copy in the > >common case, helping speed up migration? > > The problem here is qemu_put_byte and friends, where the indirection > of a function call would probably slow things down. In the common > case, qemu_put_byte is called a lot and f->buf_index would not be > zero. True, maybe the right thing to do is use a size cutoff, avoid a copy if buffer is large enough. I note the buffer in qemu file is 32K - is that based on some specific measurements or just a random large number? Any objections to making it smaller, like 4K? > The way to go would probably be to merge QEMUFile and > QEMUBufferedFile's two buffering layers, which also removes a copy. > > Paolo Yes, it does look sane. QEMUFile doesn't seem to ever be used without QEMUBufferedFile - is that true? -- MST
Re: [Qemu-devel] [PATCH RFC] qemu-file: output data directly if possible
On 10/10/2011 03:16 PM, Michael S. Tsirkin wrote: Yes, it does look sane. QEMUFile doesn't seem to ever be used without QEMUBufferedFile - is that true? I think savevm does use it that way. With migration thread it will be much easier, because the migration thread can just block. I'd hold it off until Juan's patches are in and then I can rebase Umesh's patches for migration thread. Paolo
Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
On 2011-10-10 11:02, Daniel P. Berrange wrote: > On Mon, Oct 10, 2011 at 08:52:08AM +0200, Jan Kiszka wrote: >> On 2011-10-10 04:21, Wen Congyang wrote: >>> At 10/09/2011 06:23 PM, Richard W.M. Jones Write: On Sun, Oct 09, 2011 at 10:49:57AM +0200, Jan Kiszka wrote: > As explained in the other replies: It is way more future-proof to use an > interface for this which was designed for it (remote gdb) instead of > artificially relaxing reasonable constraints of the migration mechanism > plus having to follow that format with the post-processing tool. Any interface that isn't "get this information off my production server *now*" so that I can get the server restarted, and send it to an expert to analyse -- is a poor interface, whether it was designed like that or not. Perhaps we don't have the right interface at all, but remote gdb is not it. >>> >>> What about the following idea? >>> >>> Introduce a new monitor command named dump, and this command accepts a >>> filename. >>> We can use almost all migration's code. We use this command to dump guest's >>> memory, so there is no need to check whether the guest has a unmigratable >>> device. >> >> I do not want to reject this proposal categorically, but I would like to >> see the gdb path fail /wrt essential requirements first. So far I don't >> see it would. > > GDB is often forbidden on production servers, so that path is > clearly not an option, unless we want libvirt to implement the > GDB remote RPC protocol itself which just sounds like a world > of hurt. Run gdb with "set debug remote 1" and watch the communication, it is not that complex. But a dump command is probably simpler for those scenarios, I agree. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
On Mon, Oct 10, 2011 at 10:10:21AM +0100, Daniel P. Berrange wrote: > On Mon, Oct 10, 2011 at 10:08:26AM +0100, Daniel P. Berrange wrote: > > On Mon, Oct 10, 2011 at 10:21:02AM +0800, Wen Congyang wrote: > > > At 10/09/2011 06:23 PM, Richard W.M. Jones Write: > > > > On Sun, Oct 09, 2011 at 10:49:57AM +0200, Jan Kiszka wrote: > > > >> As explained in the other replies: It is way more future-proof to use > > > >> an > > > >> interface for this which was designed for it (remote gdb) instead of > > > >> artificially relaxing reasonable constraints of the migration mechanism > > > >> plus having to follow that format with the post-processing tool. > > > > > > > > Any interface that isn't "get this information off my production > > > > server *now*" so that I can get the server restarted, and send it to > > > > an expert to analyse -- is a poor interface, whether it was designed > > > > like that or not. Perhaps we don't have the right interface at all, > > > > but remote gdb is not it. > > > > > > What about the following idea? > > > > > > Introduce a new monitor command named dump, and this command accepts a > > > filename. > > > We can use almost all migration's code. We use this command to dump > > > guest's > > > memory, so there is no need to check whether the guest has a unmigratable > > > device. > > > > I think it would be a good idea of QEMU had a dedicated 'dump' command > > for this purpose, even if it was just an alias for 'migrate' initially. > > I have never really liked the fact that we abuse the 'migrate' command > > to generate a core dump. The resulting data file from this is more > > complex than it really needs to be, causing complexity for post-processing > > it. The needs of migration, are not entirely aligned with the needs of > > core dumping in the long term, so we should allow the possibility of > > their impls diverging without impacting apps using them. > > > > So adding a 'dump' command which wrote out data in a format that was > > optimized for offline processing by tools like 'crash' (or the windows > > equivalent) would be a good improvement, even if it just reuses the > > migrate code for now. > > The other reason why it would be good, is that we would then have a clearly > defined standard "QEMU dump format", instead of "libvirt dump format for QEMU" Other reasons why this is a good idea: - so you don't need 3 processes doing a dance in order to capture a core dump - so that qemu can initiate a core dump itself (from watchdog events) - so that two qemu processes can do a core dump at the same time without trying to use conflicting ports Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
On 2011-10-10 11:10, Daniel P. Berrange wrote: > On Mon, Oct 10, 2011 at 10:08:26AM +0100, Daniel P. Berrange wrote: >> On Mon, Oct 10, 2011 at 10:21:02AM +0800, Wen Congyang wrote: >>> At 10/09/2011 06:23 PM, Richard W.M. Jones Write: On Sun, Oct 09, 2011 at 10:49:57AM +0200, Jan Kiszka wrote: > As explained in the other replies: It is way more future-proof to use an > interface for this which was designed for it (remote gdb) instead of > artificially relaxing reasonable constraints of the migration mechanism > plus having to follow that format with the post-processing tool. Any interface that isn't "get this information off my production server *now*" so that I can get the server restarted, and send it to an expert to analyse -- is a poor interface, whether it was designed like that or not. Perhaps we don't have the right interface at all, but remote gdb is not it. >>> >>> What about the following idea? >>> >>> Introduce a new monitor command named dump, and this command accepts a >>> filename. >>> We can use almost all migration's code. We use this command to dump guest's >>> memory, so there is no need to check whether the guest has a unmigratable >>> device. >> >> I think it would be a good idea of QEMU had a dedicated 'dump' command >> for this purpose, even if it was just an alias for 'migrate' initially. >> I have never really liked the fact that we abuse the 'migrate' command >> to generate a core dump. The resulting data file from this is more >> complex than it really needs to be, causing complexity for post-processing >> it. The needs of migration, are not entirely aligned with the needs of >> core dumping in the long term, so we should allow the possibility of >> their impls diverging without impacting apps using them. >> >> So adding a 'dump' command which wrote out data in a format that was >> optimized for offline processing by tools like 'crash' (or the windows >> equivalent) would be a good improvement, even if it just reuses the >> migrate code for now. > > The other reason why it would be good, is that we would then have a clearly > defined standard "QEMU dump format", instead of "libvirt dump format for QEMU" A core file would be that format - for direct gdb processing. No proprietary re-inventions please. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
[Qemu-devel] [PATCH 00/15] NBD server improvements
This series adds asynchronous operation support for the NBD server. The first 9 patches are a general refactoring that can be applied now. The others require the "main loop in tools" series. Most of the work is really in cleaning up the many parameters of nbd_trip, and implementing the abstractions needed to control multiple in-flight requests for the same client. Paolo Bonzini (15): qemu-nbd: remove offset argument to nbd_trip qemu-nbd: remove data_size argument to nbd_trip move corking functions to osdep.c qemu-nbd: simplify nbd_trip qemu-nbd: introduce nbd_do_send_reply qemu-nbd: more robust handling of invalid requests qemu-nbd: introduce nbd_do_receive_request qemu-nbd: introduce NBDExport qemu-nbd: introduce NBDRequest link the main loop and its dependencies into the tools qemu-nbd: use common main loop qemu-nbd: move client handling to nbd.c qemu-nbd: add client pointer to NBDRequest qemu-nbd: asynchronous operation qemu-nbd: throttle requests Makefile |4 +- block/sheepdog.c | 20 +--- nbd.c| 386 ++ nbd.h| 13 ++- os-posix.c | 42 -- os-win32.c |5 - osdep.c |9 ++ oslib-posix.c| 42 ++ oslib-win32.c|5 + qemu-nbd.c | 113 +++-- qemu-tool.c | 42 --- qemu_socket.h|1 + 12 files changed, 442 insertions(+), 240 deletions(-) -- 1.7.6
[Qemu-devel] [PATCH 03/15] move corking functions to osdep.c
Signed-off-by: Paolo Bonzini
---
block/sheepdog.c | 20 ++--
osdep.c |9 +
qemu_socket.h|1 +
3 files changed, 12 insertions(+), 18 deletions(-)
diff --git a/block/sheepdog.c b/block/sheepdog.c
index d168681..ddf7fa2 100644
--- a/block/sheepdog.c
+++ b/block/sheepdog.c
@@ -702,22 +702,6 @@ static int aio_flush_request(void *opaque)
return !QLIST_EMPTY(&s->outstanding_aio_head);
}
-#if !defined(SOL_TCP) || !defined(TCP_CORK)
-
-static int set_cork(int fd, int v)
-{
-return 0;
-}
-
-#else
-
-static int set_cork(int fd, int v)
-{
-return setsockopt(fd, SOL_TCP, TCP_CORK, &v, sizeof(v));
-}
-
-#endif
-
static int set_nodelay(int fd)
{
int ret, opt;
@@ -923,7 +907,7 @@ static int coroutine_fn add_aio_request(BDRVSheepdogState
*s, AIOReq *aio_req,
s->co_send = qemu_coroutine_self();
qemu_aio_set_fd_handler(s->fd, co_read_response, co_write_request,
aio_flush_request, NULL, s);
-set_cork(s->fd, 1);
+socket_set_cork(s->fd, 1);
/* send a header */
ret = qemu_co_send(s->fd, &hdr, sizeof(hdr));
@@ -940,7 +924,7 @@ static int coroutine_fn add_aio_request(BDRVSheepdogState
*s, AIOReq *aio_req,
}
}
-set_cork(s->fd, 0);
+socket_set_cork(s->fd, 0);
qemu_aio_set_fd_handler(s->fd, co_read_response, NULL,
aio_flush_request, NULL, s);
qemu_co_mutex_unlock(&s->lock);
diff --git a/osdep.c b/osdep.c
index 70bad27..3e6bada 100644
--- a/osdep.c
+++ b/osdep.c
@@ -48,6 +48,15 @@ extern int madvise(caddr_t, size_t, int);
#include "trace.h"
#include "qemu_socket.h"
+int socket_set_cork(int fd, int v)
+{
+#if defined(SOL_TCP) && defined(TCP_CORK)
+return setsockopt(fd, SOL_TCP, TCP_CORK, &v, sizeof(v));
+#else
+return 0;
+#endif
+}
+
int qemu_madvise(void *addr, size_t len, int advice)
{
if (advice == QEMU_MADV_INVALID) {
diff --git a/qemu_socket.h b/qemu_socket.h
index 9e32fac..fe4cf6c 100644
--- a/qemu_socket.h
+++ b/qemu_socket.h
@@ -35,6 +35,7 @@ int inet_aton(const char *cp, struct in_addr *ia);
/* misc helpers */
int qemu_socket(int domain, int type, int protocol);
int qemu_accept(int s, struct sockaddr *addr, socklen_t *addrlen);
+int socket_set_cork(int fd, int v);
void socket_set_block(int fd);
void socket_set_nonblock(int fd);
int send_all(int fd, const void *buf, int len1);
--
1.7.6
[Qemu-devel] [PATCH 12/15] qemu-nbd: move client handling to nbd.c
This patch sets up the fd handler in nbd.c instead of qemu-nbd.c. It
introduces NBDClient, which wraps the arguments to nbd_trip in a single
structure, so that we can add a notifier to it. This way, qemu-nbd can
know about disconnections.
Signed-off-by: Paolo Bonzini
---
nbd.c | 63 +++-
nbd.h |4 ++-
qemu-nbd.c | 13 ++-
3 files changed, 68 insertions(+), 12 deletions(-)
diff --git a/nbd.c b/nbd.c
index ae7f5ab..16c4c27 100644
--- a/nbd.c
+++ b/nbd.c
@@ -602,6 +602,37 @@ struct NBDExport {
QSIMPLEQ_HEAD(, NBDRequest) requests;
};
+struct NBDClient {
+int refcount;
+void (*close)(NBDClient *client);
+
+NBDExport *exp;
+int sock;
+};
+
+static void nbd_client_get(NBDClient *client)
+{
+client->refcount++;
+}
+
+static void nbd_client_put(NBDClient *client)
+{
+if (--client->refcount == 0) {
+g_free(client);
+}
+}
+
+static void nbd_client_close(NBDClient *client)
+{
+qemu_set_fd_handler2(client->sock, NULL, NULL, NULL, NULL);
+close(client->sock);
+client->sock = -1;
+if (client->close) {
+client->close(client);
+}
+nbd_client_put(client);
+}
+
static NBDRequest *nbd_request_get(NBDExport *exp)
{
NBDRequest *req;
@@ -714,9 +745,11 @@ out:
return rc;
}
-int nbd_trip(NBDExport *exp, int csock)
+static int nbd_trip(NBDClient *client)
{
+NBDExport *exp = client->exp;
NBDRequest *req = nbd_request_get(exp);
+int csock = client->sock;
struct nbd_request request;
struct nbd_reply reply;
int rc = -1;
@@ -837,3 +870,31 @@ out:
nbd_request_put(exp, req);
return rc;
}
+
+static void nbd_read(void *opaque)
+{
+NBDClient *client = opaque;
+
+nbd_client_get(client);
+if (nbd_trip(client) != 0) {
+nbd_client_close(client);
+}
+
+nbd_client_put(client);
+}
+
+NBDClient *nbd_client_new(NBDExport *exp, int csock,
+ void (*close)(NBDClient *))
+{
+NBDClient *client;
+if (nbd_negotiate(csock, exp->size, exp->nbdflags) == -1) {
+return NULL;
+}
+client = g_malloc0(sizeof(NBDClient));
+client->refcount = 1;
+client->exp = exp;
+client->sock = csock;
+client->close = close;
+qemu_set_fd_handler2(csock, NULL, nbd_read, NULL, client);
+return client;
+}
diff --git a/nbd.h b/nbd.h
index d368156..383c693 100644
--- a/nbd.h
+++ b/nbd.h
@@ -77,10 +77,12 @@ int nbd_client(int fd);
int nbd_disconnect(int fd);
typedef struct NBDExport NBDExport;
+typedef struct NBDClient NBDClient;
NBDExport *nbd_export_new(BlockDriverState *bs, off_t dev_offset,
off_t size, uint32_t nbdflags);
void nbd_export_close(NBDExport *exp);
-int nbd_trip(NBDExport *exp, int csock);
+NBDClient *nbd_client_new(NBDExport *exp, int csock,
+ void (*close)(NBDClient *));
#endif
diff --git a/qemu-nbd.c b/qemu-nbd.c
index 7896e9b..2b29011 100644
--- a/qemu-nbd.c
+++ b/qemu-nbd.c
@@ -186,15 +186,9 @@ static int nbd_can_accept(void *opaque)
return nb_fds < shared;
}
-static void nbd_read(void *opaque)
+static void nbd_client_closed(NBDClient *client)
{
-int fd = (uintptr_t) opaque;
-
-if (nbd_trip(&exp, fd) != 0) {
-qemu_set_fd_handler2(fd, NULL, NULL, NULL, NULL);
-close(fd);
-nb_fds--;
-}
+nb_fds--;
}
static void nbd_accept(void *opaque)
@@ -204,8 +198,7 @@ static void nbd_accept(void *opaque)
socklen_t addr_len = sizeof(addr);
int fd = accept(server_fd, (struct sockaddr *)&addr, &addr_len);
-if (fd != -1 && nbd_negotiate(fd, exp.size, exp.nbdflags) != -1) {
-qemu_set_fd_handler2(fd, NULL, nbd_read, NULL, (void *) (intptr_t) fd);
+if (fd != -1 && nbd_client_new(exp, fd, nbd_client_closed)) {
nb_fds++;
}
}
--
1.7.6
[Qemu-devel] [PATCH 13/15] qemu-nbd: add client pointer to NBDRequest
By attaching a client to an NBDRequest, we can avoid passing around the
socket descriptor and data buffer.
Signed-off-by: Paolo Bonzini
---
nbd.c | 48 +++-
1 files changed, 27 insertions(+), 21 deletions(-)
diff --git a/nbd.c b/nbd.c
index 16c4c27..e016175 100644
--- a/nbd.c
+++ b/nbd.c
@@ -591,6 +591,7 @@ typedef struct NBDRequest NBDRequest;
struct NBDRequest {
QSIMPLEQ_ENTRY(NBDRequest) entry;
+NBDClient *client;
uint8_t *data;
};
@@ -633,9 +634,11 @@ static void nbd_client_close(NBDClient *client)
nbd_client_put(client);
}
-static NBDRequest *nbd_request_get(NBDExport *exp)
+static NBDRequest *nbd_request_get(NBDClient *client)
{
NBDRequest *req;
+NBDExport *exp = client->exp;
+
if (QSIMPLEQ_EMPTY(&exp->requests)) {
req = g_malloc0(sizeof(NBDRequest));
req->data = qemu_blockalign(exp->bs, NBD_BUFFER_SIZE);
@@ -643,12 +646,16 @@ static NBDRequest *nbd_request_get(NBDExport *exp)
req = QSIMPLEQ_FIRST(&exp->requests);
QSIMPLEQ_REMOVE_HEAD(&exp->requests, entry);
}
+nbd_client_get(client);
+req->client = client;
return req;
}
-static void nbd_request_put(NBDExport *exp, NBDRequest *req)
+static void nbd_request_put(NBDRequest *req)
{
-QSIMPLEQ_INSERT_HEAD(&exp->requests, req, entry);
+NBDClient *client = req->client;
+QSIMPLEQ_INSERT_HEAD(&client->exp->requests, req, entry);
+nbd_client_put(client);
}
NBDExport *nbd_export_new(BlockDriverState *bs, off_t dev_offset,
@@ -676,9 +683,11 @@ void nbd_export_close(NBDExport *exp)
g_free(exp);
}
-static int nbd_do_send_reply(int csock, struct nbd_reply *reply,
- uint8_t *data, int len)
+static int nbd_do_send_reply(NBDRequest *req, struct nbd_reply *reply,
+ int len)
{
+NBDClient *client = req->client;
+int csock = client->sock;
int rc, ret;
if (!len) {
@@ -690,7 +699,7 @@ static int nbd_do_send_reply(int csock, struct nbd_reply
*reply,
socket_set_cork(csock, 1);
rc = nbd_send_reply(csock, reply);
if (rc != -1) {
-ret = write_sync(csock, data, len);
+ret = write_sync(csock, req->data, len);
if (ret != len) {
errno = EIO;
rc = -1;
@@ -704,9 +713,10 @@ static int nbd_do_send_reply(int csock, struct nbd_reply
*reply,
return rc;
}
-static int nbd_do_receive_request(int csock, struct nbd_request *request,
- uint8_t *data)
+static int nbd_do_receive_request(NBDRequest *req, struct nbd_request *request)
{
+NBDClient *client = req->client;
+int csock = client->sock;
int rc;
if (nbd_receive_request(csock, request) == -1) {
@@ -733,7 +743,7 @@ static int nbd_do_receive_request(int csock, struct
nbd_request *request,
if ((request->type & NBD_CMD_MASK_COMMAND) == NBD_CMD_WRITE) {
TRACE("Reading %u byte(s)", request->len);
-if (read_sync(csock, data, request->len) != request->len) {
+if (read_sync(csock, req->data, request->len) != request->len) {
LOG("reading from socket failed");
rc = -EIO;
goto out;
@@ -747,9 +757,8 @@ out:
static int nbd_trip(NBDClient *client)
{
+NBDRequest *req = nbd_request_get(client);
NBDExport *exp = client->exp;
-NBDRequest *req = nbd_request_get(exp);
-int csock = client->sock;
struct nbd_request request;
struct nbd_reply reply;
int rc = -1;
@@ -757,7 +766,7 @@ static int nbd_trip(NBDClient *client)
TRACE("Reading request.");
-ret = nbd_do_receive_request(csock, &request, req->data);
+ret = nbd_do_receive_request(req, &request);
if (ret == -EIO) {
goto out;
}
@@ -792,7 +801,7 @@ static int nbd_trip(NBDClient *client)
}
TRACE("Read %u byte(s)", request.len);
-if (nbd_do_send_reply(csock, &reply, req->data, request.len) < 0)
+if (nbd_do_send_reply(req, &reply, request.len) < 0)
goto out;
break;
case NBD_CMD_WRITE:
@@ -823,7 +832,7 @@ static int nbd_trip(NBDClient *client)
}
}
-if (nbd_do_send_reply(csock, &reply, NULL, 0) < 0)
+if (nbd_do_send_reply(req, &reply, 0) < 0)
goto out;
break;
case NBD_CMD_DISC:
@@ -839,7 +848,7 @@ static int nbd_trip(NBDClient *client)
reply.error = -ret;
}
-if (nbd_do_send_reply(csock, &reply, NULL, 0) < 0)
+if (nbd_do_send_reply(req, &reply, 0) < 0)
goto out;
break;
case NBD_CMD_TRIM:
@@ -850,7 +859,7 @@ static int nbd_trip(NBDClient *client)
LOG("discard failed");
reply.error = -ret;
}
-if (nbd_do_send_reply(csock, &reply, NULL, 0) < 0)
+if (nbd_do_send_reply(req, &reply, 0) < 0)
goto out;
break;
[Qemu-devel] [PATCH 09/15] qemu-nbd: introduce NBDRequest
Move the buffer from NBDExport to a new structure, so that it will be
possible to have multiple in-flight requests for the same export
(and for the same client too---we get that for free).
Signed-off-by: Paolo Bonzini
---
nbd.c | 65 +++--
1 files changed, 51 insertions(+), 14 deletions(-)
diff --git a/nbd.c b/nbd.c
index 00764da..ae7f5ab 100644
--- a/nbd.c
+++ b/nbd.c
@@ -36,6 +36,7 @@
#endif
#include "qemu_socket.h"
+#include "qemu-queue.h"
//#define DEBUG_NBD
@@ -586,29 +587,60 @@ static int nbd_send_reply(int csock, struct nbd_reply
*reply)
return 0;
}
+typedef struct NBDRequest NBDRequest;
+
+struct NBDRequest {
+QSIMPLEQ_ENTRY(NBDRequest) entry;
+uint8_t *data;
+};
+
struct NBDExport {
BlockDriverState *bs;
off_t dev_offset;
off_t size;
-uint8_t *data;
uint32_t nbdflags;
+QSIMPLEQ_HEAD(, NBDRequest) requests;
};
+static NBDRequest *nbd_request_get(NBDExport *exp)
+{
+NBDRequest *req;
+if (QSIMPLEQ_EMPTY(&exp->requests)) {
+req = g_malloc0(sizeof(NBDRequest));
+req->data = qemu_blockalign(exp->bs, NBD_BUFFER_SIZE);
+} else {
+req = QSIMPLEQ_FIRST(&exp->requests);
+QSIMPLEQ_REMOVE_HEAD(&exp->requests, entry);
+}
+return req;
+}
+
+static void nbd_request_put(NBDExport *exp, NBDRequest *req)
+{
+QSIMPLEQ_INSERT_HEAD(&exp->requests, req, entry);
+}
+
NBDExport *nbd_export_new(BlockDriverState *bs, off_t dev_offset,
off_t size, uint32_t nbdflags)
{
NBDExport *exp = g_malloc0(sizeof(NBDExport));
+QSIMPLEQ_INIT(&exp->requests);
exp->bs = bs;
exp->dev_offset = dev_offset;
exp->nbdflags = nbdflags;
exp->size = size == -1 ? exp->bs->total_sectors * 512 : size;
-exp->data = qemu_blockalign(exp->bs, NBD_BUFFER_SIZE);
return exp;
}
void nbd_export_close(NBDExport *exp)
{
-qemu_vfree(exp->data);
+while (!QSIMPLEQ_EMPTY(&exp->requests)) {
+NBDRequest *first = QSIMPLEQ_FIRST(&exp->requests);
+QSIMPLEQ_REMOVE_HEAD(&exp->requests, entry);
+qemu_vfree(first->data);
+g_free(first);
+}
+
bdrv_close(exp->bs);
g_free(exp);
}
@@ -684,15 +716,17 @@ out:
int nbd_trip(NBDExport *exp, int csock)
{
+NBDRequest *req = nbd_request_get(exp);
struct nbd_request request;
struct nbd_reply reply;
+int rc = -1;
int ret;
TRACE("Reading request.");
-ret = nbd_do_receive_request(csock, &request, exp->data);
+ret = nbd_do_receive_request(csock, &request, req->data);
if (ret == -EIO) {
-return -1;
+goto out;
}
reply.handle = request.handle;
@@ -717,7 +751,7 @@ int nbd_trip(NBDExport *exp, int csock)
TRACE("Request type is READ");
ret = bdrv_read(exp->bs, (request.from + exp->dev_offset) / 512,
-exp->data, request.len / 512);
+req->data, request.len / 512);
if (ret < 0) {
LOG("reading from file failed");
reply.error = -ret;
@@ -725,8 +759,8 @@ int nbd_trip(NBDExport *exp, int csock)
}
TRACE("Read %u byte(s)", request.len);
-if (nbd_do_send_reply(csock, &reply, exp->data, request.len) < 0)
-return -1;
+if (nbd_do_send_reply(csock, &reply, req->data, request.len) < 0)
+goto out;
break;
case NBD_CMD_WRITE:
TRACE("Request type is WRITE");
@@ -740,7 +774,7 @@ int nbd_trip(NBDExport *exp, int csock)
TRACE("Writing to device");
ret = bdrv_write(exp->bs, (request.from + exp->dev_offset) / 512,
- exp->data, request.len / 512);
+ req->data, request.len / 512);
if (ret < 0) {
LOG("writing to file failed");
reply.error = -ret;
@@ -757,7 +791,7 @@ int nbd_trip(NBDExport *exp, int csock)
}
if (nbd_do_send_reply(csock, &reply, NULL, 0) < 0)
-return -1;
+goto out;
break;
case NBD_CMD_DISC:
TRACE("Request type is DISCONNECT");
@@ -773,7 +807,7 @@ int nbd_trip(NBDExport *exp, int csock)
}
if (nbd_do_send_reply(csock, &reply, NULL, 0) < 0)
-return -1;
+goto out;
break;
case NBD_CMD_TRIM:
TRACE("Request type is TRIM");
@@ -784,7 +818,7 @@ int nbd_trip(NBDExport *exp, int csock)
reply.error = -ret;
}
if (nbd_do_send_reply(csock, &reply, NULL, 0) < 0)
-return -1;
+goto out;
break;
default:
LOG("invalid request type (%u) received", request.type);
@@ -792,11 +826,14 @@ int nbd_trip(NBDExport *exp, int csock)
reply.error = -EINVAL;
error_reply:
if (nbd_do_send_reply(csock, &reply, NULL, 0) == -1)
-return -1;
+goto out;
break;
}
TRAC
[Qemu-devel] [PATCH 15/15] qemu-nbd: throttle requests
Limiting the number of in-flight requests is implemented very simply
with a can_read callback. It does not require a semaphore, unlike the
client side in block/nbd.c, because we can throttle directly the creation
of coroutines. The client side can have a coroutine created at any time
when an I/O request is made.
Signed-off-by: Paolo Bonzini
---
nbd.c | 23 ---
1 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/nbd.c b/nbd.c
index 01d3a85..1869212 100644
--- a/nbd.c
+++ b/nbd.c
@@ -589,6 +589,8 @@ static int nbd_send_reply(int csock, struct nbd_reply
*reply)
return 0;
}
+#define MAX_NBD_REQUESTS 16
+
typedef struct NBDRequest NBDRequest;
struct NBDRequest {
@@ -616,6 +618,8 @@ struct NBDClient {
CoMutex send_lock;
Coroutine *send_coroutine;
+
+int nb_requests;
};
static void nbd_client_get(NBDClient *client)
@@ -646,6 +650,9 @@ static NBDRequest *nbd_request_get(NBDClient *client)
NBDRequest *req;
NBDExport *exp = client->exp;
+assert(client->nb_requests < MAX_NBD_REQUESTS);
+client->nb_requests++;
+
if (QSIMPLEQ_EMPTY(&exp->requests)) {
req = g_malloc0(sizeof(NBDRequest));
req->data = qemu_blockalign(exp->bs, NBD_BUFFER_SIZE);
@@ -662,6 +669,7 @@ static void nbd_request_put(NBDRequest *req)
{
NBDClient *client = req->client;
QSIMPLEQ_INSERT_HEAD(&client->exp->requests, req, entry);
+client->nb_requests--;
nbd_client_put(client);
}
@@ -690,6 +698,7 @@ void nbd_export_close(NBDExport *exp)
g_free(exp);
}
+static int nbd_can_read(void *opaque);
static void nbd_read(void *opaque);
static void nbd_restart_write(void *opaque);
@@ -701,7 +710,8 @@ static int nbd_co_send_reply(NBDRequest *req, struct
nbd_reply *reply,
int rc, ret;
qemu_co_mutex_lock(&client->send_lock);
-qemu_set_fd_handler2(csock, NULL, nbd_read, nbd_restart_write, client);
+qemu_set_fd_handler2(csock, nbd_can_read, nbd_read,
+ nbd_restart_write, client);
client->send_coroutine = qemu_coroutine_self();
if (!len) {
@@ -726,7 +736,7 @@ static int nbd_co_send_reply(NBDRequest *req, struct
nbd_reply *reply,
}
client->send_coroutine = NULL;
-qemu_set_fd_handler2(csock, NULL, nbd_read, NULL, client);
+qemu_set_fd_handler2(csock, nbd_can_read, nbd_read, NULL, client);
qemu_co_mutex_unlock(&client->send_lock);
return rc;
}
@@ -902,6 +912,13 @@ out:
nbd_client_close(client);
}
+static int nbd_can_read(void *opaque)
+{
+NBDClient *client = opaque;
+
+return client->recv_coroutine || client->nb_requests < MAX_NBD_REQUESTS;
+}
+
static void nbd_read(void *opaque)
{
NBDClient *client = opaque;
@@ -933,6 +950,6 @@ NBDClient *nbd_client_new(NBDExport *exp, int csock,
client->sock = csock;
client->close = close;
qemu_co_mutex_init(&client->send_lock);
-qemu_set_fd_handler2(csock, NULL, nbd_read, NULL, client);
+qemu_set_fd_handler2(csock, nbd_can_read, nbd_read, NULL, client);
return client;
}
--
1.7.6
Re: [Qemu-devel] [PATCH] qemu-kvm: fix improper nmi emulation
Am 10.10.2011 08:49, schrieb Jan Kiszka: On 2011-10-10 08:06, Lai Jiangshan wrote: From: Kenji Kaneshige Currently, NMI interrupt is blindly sent to all the vCPUs when NMI button event happens. This doesn't properly emulate real hardware on which NMI button event triggers LINT1. Because of this, NMI is sent to the processor even when LINT1 is maskied in LVT. For example, this [...] This is targeting uq/master? Please make sure your patch passes checkpatch.pl While at it: masked? Andreas
[Qemu-devel] [PATCH 01/15] qemu-nbd: remove offset argument to nbd_trip
The argument is write-only.
Signed-off-by: Paolo Bonzini
---
nbd.c |8 +++-
nbd.h |2 +-
qemu-nbd.c |3 +--
3 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/nbd.c b/nbd.c
index 6a96878..a96c109 100644
--- a/nbd.c
+++ b/nbd.c
@@ -585,8 +585,9 @@ static int nbd_send_reply(int csock, struct nbd_reply
*reply)
return 0;
}
-int nbd_trip(BlockDriverState *bs, int csock, off_t size, uint64_t dev_offset,
- off_t *offset, uint32_t nbdflags, uint8_t *data, int data_size)
+int nbd_trip(BlockDriverState *bs, int csock, off_t size,
+ uint64_t dev_offset, uint32_t nbdflags,
+ uint8_t *data, int data_size)
{
struct nbd_request request;
struct nbd_reply reply;
@@ -637,7 +638,6 @@ int nbd_trip(BlockDriverState *bs, int csock, off_t size,
uint64_t dev_offset,
reply.error = -ret;
request.len = 0;
}
-*offset += request.len;
TRACE("Read %u byte(s)", request.len);
@@ -686,8 +686,6 @@ int nbd_trip(BlockDriverState *bs, int csock, off_t size,
uint64_t dev_offset,
request.len = 0;
}
-*offset += request.len;
-
if (request.type & NBD_CMD_FLAG_FUA) {
ret = bdrv_flush(bs);
if (ret < 0) {
diff --git a/nbd.h b/nbd.h
index 61553f4..ebdb2db 100644
--- a/nbd.h
+++ b/nbd.h
@@ -72,7 +72,7 @@ int nbd_init(int fd, int csock, uint32_t flags, off_t size,
size_t blocksize);
int nbd_send_request(int csock, struct nbd_request *request);
int nbd_receive_reply(int csock, struct nbd_reply *reply);
int nbd_trip(BlockDriverState *bs, int csock, off_t size, uint64_t dev_offset,
- off_t *offset, uint32_t nbdflags, uint8_t *data, int data_size);
+ uint32_t nbdflags, uint8_t *data, int data_size);
int nbd_client(int fd);
int nbd_disconnect(int fd);
diff --git a/qemu-nbd.c b/qemu-nbd.c
index d8d3e15..e2fe7cf 100644
--- a/qemu-nbd.c
+++ b/qemu-nbd.c
@@ -184,7 +184,6 @@ int main(int argc, char **argv)
{
BlockDriverState *bs;
off_t dev_offset = 0;
-off_t offset = 0;
uint32_t nbdflags = 0;
bool disconnect = false;
const char *bindto = "0.0.0.0";
@@ -462,7 +461,7 @@ int main(int argc, char **argv)
for (i = 1; i < nb_fds && ret; i++) {
if (FD_ISSET(sharing_fds[i], &fds)) {
if (nbd_trip(bs, sharing_fds[i], fd_size, dev_offset,
-&offset, nbdflags, data, NBD_BUFFER_SIZE) != 0) {
+nbdflags, data, NBD_BUFFER_SIZE) != 0) {
close(sharing_fds[i]);
nb_fds--;
sharing_fds[i] = sharing_fds[nb_fds];
--
1.7.6
[Qemu-devel] [PATCH 05/15] qemu-nbd: introduce nbd_do_send_reply
Group the sending of a reply and the associated data into a new function.
Without corking, the caller would be forced to leave 12 free bytes at the
beginning of the data pointer. Not too ugly, but still ugly. :)
Using nbd_do_send_reply everywhere will help when the routine will set up
the write handler that re-enters the send coroutine.
Signed-off-by: Paolo Bonzini
---
nbd.c | 46 --
1 files changed, 32 insertions(+), 14 deletions(-)
diff --git a/nbd.c b/nbd.c
index 252fa7c..5fd6daf 100644
--- a/nbd.c
+++ b/nbd.c
@@ -585,6 +585,34 @@ static int nbd_send_reply(int csock, struct nbd_reply
*reply)
return 0;
}
+static int nbd_do_send_reply(int csock, struct nbd_reply *reply,
+ uint8_t *data, int len)
+{
+int rc, ret;
+
+if (!len) {
+rc = nbd_send_reply(csock, reply);
+if (rc == -1) {
+rc = -errno;
+}
+} else {
+socket_set_cork(csock, 1);
+rc = nbd_send_reply(csock, reply);
+if (rc != -1) {
+ret = write_sync(csock, data, len);
+if (ret != len) {
+errno = EIO;
+rc = -1;
+}
+}
+if (rc == -1) {
+rc = -errno;
+}
+socket_set_cork(csock, 0);
+}
+return rc;
+}
+
int nbd_trip(BlockDriverState *bs, int csock, off_t size,
uint64_t dev_offset, uint32_t nbdflags,
uint8_t *data)
@@ -639,18 +667,8 @@ int nbd_trip(BlockDriverState *bs, int csock, off_t size,
}
TRACE("Read %u byte(s)", request.len);
-socket_set_cork(csock, 1);
-if (nbd_send_reply(csock, &reply) == -1)
+if (nbd_do_send_reply(csock, &reply, data, request.len) < 0)
return -1;
-
-TRACE("Sending data to client");
-
-if (write_sync(csock, data, request.len) != request.len) {
-LOG("writing to socket failed");
-errno = EINVAL;
-return -1;
-}
-socket_set_cork(csock, 0);
break;
case NBD_CMD_WRITE:
TRACE("Request type is WRITE");
@@ -686,7 +704,7 @@ int nbd_trip(BlockDriverState *bs, int csock, off_t size,
}
}
-if (nbd_send_reply(csock, &reply) == -1)
+if (nbd_do_send_reply(csock, &reply, NULL, 0) < 0)
return -1;
break;
case NBD_CMD_DISC:
@@ -702,7 +720,7 @@ int nbd_trip(BlockDriverState *bs, int csock, off_t size,
reply.error = -ret;
}
-if (nbd_send_reply(csock, &reply) == -1)
+if (nbd_do_send_reply(csock, &reply, NULL, 0) < 0)
return -1;
break;
case NBD_CMD_TRIM:
@@ -713,7 +731,7 @@ int nbd_trip(BlockDriverState *bs, int csock, off_t size,
LOG("discard failed");
reply.error = -ret;
}
-if (nbd_send_reply(csock, &reply) == -1)
+if (nbd_do_send_reply(csock, &reply, NULL, 0) < 0)
return -1;
break;
default:
--
1.7.6
[Qemu-devel] [PATCH 06/15] qemu-nbd: more robust handling of invalid requests
Fail invalid requests with EINVAL instead of dropping them into
the void.
Signed-off-by: Paolo Bonzini
---
nbd.c | 57 ++---
1 files changed, 30 insertions(+), 27 deletions(-)
diff --git a/nbd.c b/nbd.c
index 5fd6daf..ec84071 100644
--- a/nbd.c
+++ b/nbd.c
@@ -626,18 +626,19 @@ int nbd_trip(BlockDriverState *bs, int csock, off_t size,
if (nbd_receive_request(csock, &request) == -1)
return -1;
+reply.handle = request.handle;
+reply.error = 0;
+
if (request.len > NBD_BUFFER_SIZE) {
LOG("len (%u) is larger than max len (%u)",
request.len, NBD_BUFFER_SIZE);
-errno = EINVAL;
-return -1;
+goto invalid_request;
}
if ((request.from + request.len) < request.from) {
LOG("integer overflow detected! "
"you're probably being attacked");
-errno = EINVAL;
-return -1;
+goto invalid_request;
}
if ((request.from + request.len) > size) {
@@ -645,15 +646,11 @@ int nbd_trip(BlockDriverState *bs, int csock, off_t size,
", Offset: %" PRIu64 "\n",
request.from, request.len, (uint64_t)size, dev_offset);
LOG("requested operation past EOF--bad client?");
-errno = EINVAL;
-return -1;
+goto invalid_request;
}
TRACE("Decoding type");
-reply.handle = request.handle;
-reply.error = 0;
-
switch (request.type & NBD_CMD_MASK_COMMAND) {
case NBD_CMD_READ:
TRACE("Request type is READ");
@@ -663,7 +660,7 @@ int nbd_trip(BlockDriverState *bs, int csock, off_t size,
if (ret < 0) {
LOG("reading from file failed");
reply.error = -ret;
-request.len = 0;
+goto error_reply;
}
TRACE("Read %u byte(s)", request.len);
@@ -683,24 +680,26 @@ int nbd_trip(BlockDriverState *bs, int csock, off_t size,
if (nbdflags & NBD_FLAG_READ_ONLY) {
TRACE("Server is read-only, return error");
-reply.error = 1;
-} else {
-TRACE("Writing to device");
+reply.error = EROFS;
+goto error_reply;
+}
+
+TRACE("Writing to device");
+
+ret = bdrv_write(bs, (request.from + dev_offset) / 512,
+ data, request.len / 512);
+if (ret < 0) {
+LOG("writing to file failed");
+reply.error = -ret;
+goto error_reply;
+}
-ret = bdrv_write(bs, (request.from + dev_offset) / 512,
- data, request.len / 512);
+if (request.type & NBD_CMD_FLAG_FUA) {
+ret = bdrv_flush(bs);
if (ret < 0) {
-LOG("writing to file failed");
+LOG("flush failed");
reply.error = -ret;
-request.len = 0;
-}
-
-if (request.type & NBD_CMD_FLAG_FUA) {
-ret = bdrv_flush(bs);
-if (ret < 0) {
-LOG("flush failed");
-reply.error = -ret;
-}
+goto error_reply;
}
}
@@ -736,8 +735,12 @@ int nbd_trip(BlockDriverState *bs, int csock, off_t size,
break;
default:
LOG("invalid request type (%u) received", request.type);
-errno = EINVAL;
-return -1;
+invalid_request:
+reply.error = -EINVAL;
+error_reply:
+if (nbd_do_send_reply(csock, &reply, NULL, 0) == -1)
+return -1;
+break;
}
TRACE("Request/Reply complete");
--
1.7.6
[Qemu-devel] [PATCH 10/15] link the main loop and its dependencies into the tools
Using the main loop code from QEMU enables tools to operate fully
asynchronously. Advantages include better Windows portability (for some
definition of portability) over glib's.
Signed-off-by: Paolo Bonzini
---
Makefile |4 +++-
os-posix.c| 42 --
os-win32.c|5 -
oslib-posix.c | 42 ++
oslib-win32.c |5 +
qemu-tool.c | 42 +++---
6 files changed, 73 insertions(+), 67 deletions(-)
diff --git a/Makefile b/Makefile
index 5723108..4adf082 100644
--- a/Makefile
+++ b/Makefile
@@ -146,7 +146,9 @@ qemu-img.o: qemu-img-cmds.h
qemu-img.o qemu-tool.o qemu-nbd.o qemu-io.o cmd.o qemu-ga.o:
$(GENERATED_HEADERS)
tools-obj-y = qemu-tool.o qemu-error.o $(oslib-obj-y) $(trace-obj-y) \
-$(block-obj-y) $(qobject-obj-y) $(version-obj-y) qemu-timer-common.o
+$(block-obj-y) $(qobject-obj-y) $(version-obj-y) qemu-timer-common.o \
+qemu-timer.o main-loop.o notify.o iohandler.o
+tools-obj-$(CONFIG_POSIX) += compatfd.o
qemu-img$(EXESUF): qemu-img.o $(tools-obj-y)
qemu-nbd$(EXESUF): qemu-nbd.o $(tools-obj-y)
diff --git a/os-posix.c b/os-posix.c
index dbf3b24..c0188b3 100644
--- a/os-posix.c
+++ b/os-posix.c
@@ -42,11 +42,6 @@
#ifdef CONFIG_LINUX
#include
-#include
-#endif
-
-#ifdef CONFIG_EVENTFD
-#include
#endif
static struct passwd *user_pwd;
@@ -333,34 +328,6 @@ void os_set_line_buffering(void)
setvbuf(stdout, NULL, _IOLBF, 0);
}
-/*
- * Creates an eventfd that looks like a pipe and has EFD_CLOEXEC set.
- */
-int qemu_eventfd(int fds[2])
-{
-#ifdef CONFIG_EVENTFD
-int ret;
-
-ret = eventfd(0, 0);
-if (ret >= 0) {
-fds[0] = ret;
-qemu_set_cloexec(ret);
-if ((fds[1] = dup(ret)) == -1) {
-close(ret);
-return -1;
-}
-qemu_set_cloexec(fds[1]);
-return 0;
-}
-
-if (errno != ENOSYS) {
-return -1;
-}
-#endif
-
-return qemu_pipe(fds);
-}
-
int qemu_create_pidfile(const char *filename)
{
char buffer[128];
@@ -381,12 +348,3 @@ int qemu_create_pidfile(const char *filename)
return 0;
}
-
-int qemu_get_thread_id(void)
-{
-#if defined (__linux__)
-return syscall(SYS_gettid);
-#else
-return getpid();
-#endif
-}
diff --git a/os-win32.c b/os-win32.c
index 7909401..30a96ef 100644
--- a/os-win32.c
+++ b/os-win32.c
@@ -143,8 +143,3 @@ int qemu_create_pidfile(const char *filename)
}
return 0;
}
-
-int qemu_get_thread_id(void)
-{
-return GetCurrentThreadId();
-}
diff --git a/oslib-posix.c b/oslib-posix.c
index dbc8ee8..29c8647 100644
--- a/oslib-posix.c
+++ b/oslib-posix.c
@@ -47,7 +47,21 @@ extern int daemon(int, int);
#include "trace.h"
#include "qemu_socket.h"
+#ifdef CONFIG_LINUX
+#include
+#endif
+#ifdef CONFIG_EVENTFD
+#include
+#endif
+int qemu_get_thread_id(void)
+{
+#if defined(__linux__)
+return syscall(SYS_gettid);
+#else
+return getpid();
+#endif
+}
int qemu_daemon(int nochdir, int noclose)
{
@@ -146,6 +160,34 @@ int qemu_pipe(int pipefd[2])
return ret;
}
+/*
+ * Creates an eventfd that looks like a pipe and has EFD_CLOEXEC set.
+ */
+int qemu_eventfd(int fds[2])
+{
+#ifdef CONFIG_EVENTFD
+int ret;
+
+ret = eventfd(0, 0);
+if (ret >= 0) {
+fds[0] = ret;
+fds[1] = dup(ret);
+if (fds[1] == -1) {
+close(ret);
+return -1;
+}
+qemu_set_cloexec(ret);
+qemu_set_cloexec(fds[1]);
+return 0;
+}
+if (errno != ENOSYS) {
+return -1;
+}
+#endif
+
+return qemu_pipe(fds);
+}
+
int qemu_utimensat(int dirfd, const char *path, const struct timespec *times,
int flags)
{
diff --git a/oslib-win32.c b/oslib-win32.c
index 5e3de7d..ce3021e 100644
--- a/oslib-win32.c
+++ b/oslib-win32.c
@@ -118,3 +118,8 @@ int qemu_gettimeofday(qemu_timeval *tp)
Do not set errno on error. */
return 0;
}
+
+int qemu_get_thread_id(void)
+{
+return GetCurrentThreadId();
+}
diff --git a/qemu-tool.c b/qemu-tool.c
index e9f7fe1..aafa76a 100644
--- a/qemu-tool.c
+++ b/qemu-tool.c
@@ -15,12 +15,12 @@
#include "monitor.h"
#include "qemu-timer.h"
#include "qemu-log.h"
+#include "main-loop.h"
+#include "qemu_socket.h"
+#include "slirp/libslirp.h"
#include
-QEMUClock *rt_clock;
-QEMUClock *vm_clock;
-
FILE *logfile;
struct QEMUBH
@@ -56,39 +56,43 @@ void monitor_protocol_event(MonitorEvent event, QObject
*data)
{
}
-int qemu_set_fd_handler2(int fd,
- IOCanReadHandler *fd_read_poll,
- IOHandler *fd_read,
- IOHandler *fd_write,
- void *opaque)
+int64 cpu_get_clock(void)
{
-return 0;
+abort();
}
-void qemu_notify_event(void)
+int64 cpu_get_icount(void)
{
+abort();
}
-QEMUTimer *qemu_new_timer(QEMUClock *clock, int scale,
-
Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
On 2011-10-10 11:34, Richard W.M. Jones wrote: > On Mon, Oct 10, 2011 at 10:10:21AM +0100, Daniel P. Berrange wrote: >> On Mon, Oct 10, 2011 at 10:08:26AM +0100, Daniel P. Berrange wrote: >>> On Mon, Oct 10, 2011 at 10:21:02AM +0800, Wen Congyang wrote: At 10/09/2011 06:23 PM, Richard W.M. Jones Write: > On Sun, Oct 09, 2011 at 10:49:57AM +0200, Jan Kiszka wrote: >> As explained in the other replies: It is way more future-proof to use an >> interface for this which was designed for it (remote gdb) instead of >> artificially relaxing reasonable constraints of the migration mechanism >> plus having to follow that format with the post-processing tool. > > Any interface that isn't "get this information off my production > server *now*" so that I can get the server restarted, and send it to > an expert to analyse -- is a poor interface, whether it was designed > like that or not. Perhaps we don't have the right interface at all, > but remote gdb is not it. What about the following idea? Introduce a new monitor command named dump, and this command accepts a filename. We can use almost all migration's code. We use this command to dump guest's memory, so there is no need to check whether the guest has a unmigratable device. >>> >>> I think it would be a good idea of QEMU had a dedicated 'dump' command >>> for this purpose, even if it was just an alias for 'migrate' initially. >>> I have never really liked the fact that we abuse the 'migrate' command >>> to generate a core dump. The resulting data file from this is more >>> complex than it really needs to be, causing complexity for post-processing >>> it. The needs of migration, are not entirely aligned with the needs of >>> core dumping in the long term, so we should allow the possibility of >>> their impls diverging without impacting apps using them. >>> >>> So adding a 'dump' command which wrote out data in a format that was >>> optimized for offline processing by tools like 'crash' (or the windows >>> equivalent) would be a good improvement, even if it just reuses the >>> migrate code for now. >> >> The other reason why it would be good, is that we would then have a clearly >> defined standard "QEMU dump format", instead of "libvirt dump format for >> QEMU" > > Other reasons why this is a good idea: > > - so you don't need 3 processes doing a dance in order to capture a >core dump If it made the overall implementation simpler, that would have been no valid reason. The key is only that banning of gdb on certain systems (though I wonder if you cannot configure it to only support remote targets, thus making it useless for potential attackers). > > - so that qemu can initiate a core dump itself (from watchdog events) This is a management tool decision. A dump command would not have any pre-condition or auto-trigger. > > - so that two qemu processes can do a core dump at the same time >without trying to use conflicting ports That is a non-issue (just like you can have multiple monitors of multiple VMs listening on different TCP ports). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
On Mon, Oct 10, 2011 at 11:34:44AM +0200, Jan Kiszka wrote: > On 2011-10-10 11:10, Daniel P. Berrange wrote: > > On Mon, Oct 10, 2011 at 10:08:26AM +0100, Daniel P. Berrange wrote: > >> On Mon, Oct 10, 2011 at 10:21:02AM +0800, Wen Congyang wrote: > >>> At 10/09/2011 06:23 PM, Richard W.M. Jones Write: > On Sun, Oct 09, 2011 at 10:49:57AM +0200, Jan Kiszka wrote: > > As explained in the other replies: It is way more future-proof to use an > > interface for this which was designed for it (remote gdb) instead of > > artificially relaxing reasonable constraints of the migration mechanism > > plus having to follow that format with the post-processing tool. > > Any interface that isn't "get this information off my production > server *now*" so that I can get the server restarted, and send it to > an expert to analyse -- is a poor interface, whether it was designed > like that or not. Perhaps we don't have the right interface at all, > but remote gdb is not it. > >>> > >>> What about the following idea? > >>> > >>> Introduce a new monitor command named dump, and this command accepts a > >>> filename. > >>> We can use almost all migration's code. We use this command to dump > >>> guest's > >>> memory, so there is no need to check whether the guest has a unmigratable > >>> device. > >> > >> I think it would be a good idea of QEMU had a dedicated 'dump' command > >> for this purpose, even if it was just an alias for 'migrate' initially. > >> I have never really liked the fact that we abuse the 'migrate' command > >> to generate a core dump. The resulting data file from this is more > >> complex than it really needs to be, causing complexity for post-processing > >> it. The needs of migration, are not entirely aligned with the needs of > >> core dumping in the long term, so we should allow the possibility of > >> their impls diverging without impacting apps using them. > >> > >> So adding a 'dump' command which wrote out data in a format that was > >> optimized for offline processing by tools like 'crash' (or the windows > >> equivalent) would be a good improvement, even if it just reuses the > >> migrate code for now. > > > > The other reason why it would be good, is that we would then have a clearly > > defined standard "QEMU dump format", instead of "libvirt dump format for > > QEMU" > > A core file would be that format - for direct gdb processing. No > proprietary re-inventions please. I have no personal attachment to any particular format, so if the standard core file format is possible, then we should definitely try to use it in QEMU. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
[Qemu-devel] [PATCH 11/15] qemu-nbd: use common main loop
Using a single main loop for sockets will help yielding from the socket
coroutine back to the main loop, and later reentering it.
Signed-off-by: Paolo Bonzini
---
qemu-nbd.c | 101
1 files changed, 47 insertions(+), 54 deletions(-)
diff --git a/qemu-nbd.c b/qemu-nbd.c
index 9fa3979..7896e9b 100644
--- a/qemu-nbd.c
+++ b/qemu-nbd.c
@@ -36,6 +36,8 @@
static NBDExport *exp;
static int verbose;
+static int shared = 1;
+static int nb_fds;
static void usage(const char *name)
{
@@ -179,6 +181,35 @@ static void show_parts(const char *device)
}
}
+static int nbd_can_accept(void *opaque)
+{
+return nb_fds < shared;
+}
+
+static void nbd_read(void *opaque)
+{
+int fd = (uintptr_t) opaque;
+
+if (nbd_trip(&exp, fd) != 0) {
+qemu_set_fd_handler2(fd, NULL, NULL, NULL, NULL);
+close(fd);
+nb_fds--;
+}
+}
+
+static void nbd_accept(void *opaque)
+{
+int server_fd = (uintptr_t) opaque;
+struct sockaddr_in addr;
+socklen_t addr_len = sizeof(addr);
+
+int fd = accept(server_fd, (struct sockaddr *)&addr, &addr_len);
+if (fd != -1 && nbd_negotiate(fd, exp.size, exp.nbdflags) != -1) {
+qemu_set_fd_handler2(fd, NULL, nbd_read, NULL, (void *) (intptr_t) fd);
+nb_fds++;
+}
+}
+
int main(int argc, char **argv)
{
BlockDriverState *bs;
@@ -187,8 +218,6 @@ int main(int argc, char **argv)
bool disconnect = false;
const char *bindto = "0.0.0.0";
int port = NBD_DEFAULT_PORT;
-struct sockaddr_in addr;
-socklen_t addr_len = sizeof(addr);
off_t fd_size = -1;
char *device = NULL;
char *socket = NULL;
@@ -219,13 +248,8 @@ int main(int argc, char **argv)
int flags = BDRV_O_RDWR;
int partition = -1;
int ret;
-int shared = 1;
fd_set fds;
-int *sharing_fds;
int fd;
-int i;
-int nb_fds = 0;
-int max_fd;
int persistent = 0;
while ((ch = getopt_long(argc, argv, sopt, lopt, &opt_ind)) != -1) {
@@ -427,61 +451,30 @@ int main(int argc, char **argv)
/* children */
}
-sharing_fds = g_malloc((shared + 1) * sizeof(int));
-
if (socket) {
-sharing_fds[0] = unix_socket_incoming(socket);
+fd = unix_socket_incoming(socket);
} else {
-sharing_fds[0] = tcp_socket_incoming(bindto, port);
+fd = tcp_socket_incoming(bindto, port);
}
-if (sharing_fds[0] == -1)
+if (fd == -1) {
return 1;
-max_fd = sharing_fds[0];
-nb_fds++;
-
-do {
-
-FD_ZERO(&fds);
-for (i = 0; i < nb_fds; i++)
-FD_SET(sharing_fds[i], &fds);
-
-ret = select(max_fd + 1, &fds, NULL, NULL, NULL);
-if (ret == -1)
-break;
+}
-if (FD_ISSET(sharing_fds[0], &fds))
-ret--;
-for (i = 1; i < nb_fds && ret; i++) {
-if (FD_ISSET(sharing_fds[i], &fds)) {
-if (nbd_trip(exp, sharing_fds[i]) != 0) {
-close(sharing_fds[i]);
-nb_fds--;
-sharing_fds[i] = sharing_fds[nb_fds];
-i--;
-}
-ret--;
-}
-}
-/* new connection ? */
-if (FD_ISSET(sharing_fds[0], &fds)) {
-if (nb_fds < shared + 1) {
-sharing_fds[nb_fds] = accept(sharing_fds[0],
- (struct sockaddr *)&addr,
- &addr_len);
-if (sharing_fds[nb_fds] != -1 &&
-nbd_negotiate(sharing_fds[nb_fds], fd_size, nbdflags) !=
-1) {
-if (sharing_fds[nb_fds] > max_fd)
-max_fd = sharing_fds[nb_fds];
-nb_fds++;
-}
-}
-}
-} while (persistent || nb_fds > 1);
+qemu_set_fd_handler2(fd, nbd_can_accept, nbd_accept, NULL,
+ (void *)(uintptr_t)fd);
+
+/* Wait for the first incoming connection. */
+FD_ZERO(&fds);
+FD_SET(fd, &fds);
+ret = select(fd + 1, &fds, NULL, NULL, NULL);
+if (ret != -1) {
+do {
+main_loop_wait(false);
+} while (persistent || nb_fds > 0);
+}
-close(sharing_fds[0]);
nbd_export_close(exp);
-g_free(sharing_fds);
if (socket)
unlink(socket);
--
1.7.6
Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
On Mon, Oct 10, 2011 at 11:34:44AM +0200, Jan Kiszka wrote: > On 2011-10-10 11:10, Daniel P. Berrange wrote: > > On Mon, Oct 10, 2011 at 10:08:26AM +0100, Daniel P. Berrange wrote: > >> On Mon, Oct 10, 2011 at 10:21:02AM +0800, Wen Congyang wrote: > >>> At 10/09/2011 06:23 PM, Richard W.M. Jones Write: > On Sun, Oct 09, 2011 at 10:49:57AM +0200, Jan Kiszka wrote: > > As explained in the other replies: It is way more future-proof to use an > > interface for this which was designed for it (remote gdb) instead of > > artificially relaxing reasonable constraints of the migration mechanism > > plus having to follow that format with the post-processing tool. > > Any interface that isn't "get this information off my production > server *now*" so that I can get the server restarted, and send it to > an expert to analyse -- is a poor interface, whether it was designed > like that or not. Perhaps we don't have the right interface at all, > but remote gdb is not it. > >>> > >>> What about the following idea? > >>> > >>> Introduce a new monitor command named dump, and this command accepts a > >>> filename. > >>> We can use almost all migration's code. We use this command to dump > >>> guest's > >>> memory, so there is no need to check whether the guest has a unmigratable > >>> device. > >> > >> I think it would be a good idea of QEMU had a dedicated 'dump' command > >> for this purpose, even if it was just an alias for 'migrate' initially. > >> I have never really liked the fact that we abuse the 'migrate' command > >> to generate a core dump. The resulting data file from this is more > >> complex than it really needs to be, causing complexity for post-processing > >> it. The needs of migration, are not entirely aligned with the needs of > >> core dumping in the long term, so we should allow the possibility of > >> their impls diverging without impacting apps using them. > >> > >> So adding a 'dump' command which wrote out data in a format that was > >> optimized for offline processing by tools like 'crash' (or the windows > >> equivalent) would be a good improvement, even if it just reuses the > >> migrate code for now. > > > > The other reason why it would be good, is that we would then have a clearly > > defined standard "QEMU dump format", instead of "libvirt dump format for > > QEMU" > > A core file would be that format - for direct gdb processing. No > proprietary re-inventions please. Just a note: A core file to windows core dump file would be nice for windows guest crashes. > > Jan > > -- > Siemens AG, Corporate Technology, CT T DE IT 1 > Corporate Competence Center Embedded Linux >
[Qemu-devel] [PATCH 04/15] qemu-nbd: simplify nbd_trip
Use TCP_CORK to remove a violation of encapsulation, that would later
require nbd_trip to know too much about an NBD reply.
We could also switch to sendmsg (qemu_co_sendv) later, it is even
easier once coroutines are in.
Signed-off-by: Paolo Bonzini
---
nbd.c | 25 -
1 files changed, 8 insertions(+), 17 deletions(-)
diff --git a/nbd.c b/nbd.c
index 59c47ee..252fa7c 100644
--- a/nbd.c
+++ b/nbd.c
@@ -598,9 +598,9 @@ int nbd_trip(BlockDriverState *bs, int csock, off_t size,
if (nbd_receive_request(csock, &request) == -1)
return -1;
-if (request.len + NBD_REPLY_SIZE > NBD_BUFFER_SIZE) {
+if (request.len > NBD_BUFFER_SIZE) {
LOG("len (%u) is larger than max len (%u)",
-request.len + NBD_REPLY_SIZE, NBD_BUFFER_SIZE);
+request.len, NBD_BUFFER_SIZE);
errno = EINVAL;
return -1;
}
@@ -631,8 +631,7 @@ int nbd_trip(BlockDriverState *bs, int csock, off_t size,
TRACE("Request type is READ");
ret = bdrv_read(bs, (request.from + dev_offset) / 512,
-data + NBD_REPLY_SIZE,
-request.len / 512);
+data, request.len / 512);
if (ret < 0) {
LOG("reading from file failed");
reply.error = -ret;
@@ -640,26 +639,18 @@ int nbd_trip(BlockDriverState *bs, int csock, off_t size,
}
TRACE("Read %u byte(s)", request.len);
-
-/* Reply
- [ 0 .. 3]magic (NBD_REPLY_MAGIC)
- [ 4 .. 7]error (0 == no error)
- [ 7 .. 15]handle
- */
-
-cpu_to_be32w((uint32_t*)data, NBD_REPLY_MAGIC);
-cpu_to_be32w((uint32_t*)(data + 4), reply.error);
-cpu_to_be64w((uint64_t*)(data + 8), reply.handle);
+socket_set_cork(csock, 1);
+if (nbd_send_reply(csock, &reply) == -1)
+return -1;
TRACE("Sending data to client");
-if (write_sync(csock, data,
- request.len + NBD_REPLY_SIZE) !=
- request.len + NBD_REPLY_SIZE) {
+if (write_sync(csock, data, request.len) != request.len) {
LOG("writing to socket failed");
errno = EINVAL;
return -1;
}
+socket_set_cork(csock, 0);
break;
case NBD_CMD_WRITE:
TRACE("Request type is WRITE");
--
1.7.6
[Qemu-devel] [PATCH 07/15] qemu-nbd: introduce nbd_do_receive_request
Group the receiving of a response and the associated data into a new function.
Signed-off-by: Paolo Bonzini
---
nbd.c | 68
1 files changed, 47 insertions(+), 21 deletions(-)
diff --git a/nbd.c b/nbd.c
index ec84071..898206f 100644
--- a/nbd.c
+++ b/nbd.c
@@ -613,6 +613,47 @@ static int nbd_do_send_reply(int csock, struct nbd_reply
*reply,
return rc;
}
+static int nbd_do_receive_request(int csock, struct nbd_request *request,
+ uint8_t *data)
+{
+int rc;
+
+if (nbd_receive_request(csock, request) == -1) {
+rc = -EIO;
+goto out;
+}
+
+if (request->len > NBD_BUFFER_SIZE) {
+LOG("len (%u) is larger than max len (%u)",
+request->len, NBD_BUFFER_SIZE);
+rc = -EINVAL;
+goto out;
+}
+
+if ((request->from + request->len) < request->from) {
+LOG("integer overflow detected! "
+"you're probably being attacked");
+rc = -EINVAL;
+goto out;
+}
+
+TRACE("Decoding type");
+
+if ((request->type & NBD_CMD_MASK_COMMAND) == NBD_CMD_WRITE) {
+TRACE("Reading %u byte(s)", request->len);
+
+if (read_sync(csock, data, request->len) != request->len) {
+LOG("reading from socket failed");
+rc = -EIO;
+goto out;
+}
+}
+rc = 0;
+
+out:
+return rc;
+}
+
int nbd_trip(BlockDriverState *bs, int csock, off_t size,
uint64_t dev_offset, uint32_t nbdflags,
uint8_t *data)
@@ -623,22 +664,17 @@ int nbd_trip(BlockDriverState *bs, int csock, off_t size,
TRACE("Reading request.");
-if (nbd_receive_request(csock, &request) == -1)
+ret = nbd_do_receive_request(csock, &request, data);
+if (ret == -EIO) {
return -1;
+}
reply.handle = request.handle;
reply.error = 0;
-if (request.len > NBD_BUFFER_SIZE) {
-LOG("len (%u) is larger than max len (%u)",
-request.len, NBD_BUFFER_SIZE);
-goto invalid_request;
-}
-
-if ((request.from + request.len) < request.from) {
-LOG("integer overflow detected! "
-"you're probably being attacked");
-goto invalid_request;
+if (ret < 0) {
+reply.error = -ret;
+goto error_reply;
}
if ((request.from + request.len) > size) {
@@ -649,8 +685,6 @@ int nbd_trip(BlockDriverState *bs, int csock, off_t size,
goto invalid_request;
}
-TRACE("Decoding type");
-
switch (request.type & NBD_CMD_MASK_COMMAND) {
case NBD_CMD_READ:
TRACE("Request type is READ");
@@ -670,14 +704,6 @@ int nbd_trip(BlockDriverState *bs, int csock, off_t size,
case NBD_CMD_WRITE:
TRACE("Request type is WRITE");
-TRACE("Reading %u byte(s)", request.len);
-
-if (read_sync(csock, data, request.len) != request.len) {
-LOG("reading from socket failed");
-errno = EINVAL;
-return -1;
-}
-
if (nbdflags & NBD_FLAG_READ_ONLY) {
TRACE("Server is read-only, return error");
reply.error = EROFS;
--
1.7.6
Re: [Qemu-devel] [PATCH] kernel/kvm: fix improper nmi emulation
On 10/10/2011 08:06 AM, Lai Jiangshan wrote:
From: Kenji Kaneshige
Currently, NMI interrupt is blindly sent to all the vCPUs when NMI
button event happens. This doesn't properly emulate real hardware on
which NMI button event triggers LINT1. Because of this, NMI is sent to
the processor even when LINT1 is maskied in LVT. For example, this
causes the problem that kdump initiated by NMI sometimes doesn't work
on KVM, because kdump assumes NMI is masked on CPUs other than CPU0.
With this patch, KVM_NMI ioctl is handled as follows.
- When in-kernel irqchip is enabled, KVM_NMI ioctl is handled as a
request of triggering LINT1 on the processor. LINT1 is emulated in
in-kernel irqchip.
- When in-kernel irqchip is disabled, KVM_NMI ioctl is handled as a
request of injecting NMI to the processor. This assumes LINT1 is
already emulated in userland.
Please add a KVM_NMI section to Documentation/virtual/kvm/api.txt.
-static int kvm_vcpu_ioctl_nmi(struct kvm_vcpu *vcpu)
-{
- kvm_inject_nmi(vcpu);
-
- return 0;
-}
-
static int vcpu_ioctl_tpr_access_reporting(struct kvm_vcpu *vcpu,
struct kvm_tpr_access_ctl *tac)
{
@@ -3038,9 +3031,10 @@ long kvm_arch_vcpu_ioctl(struct file *fi
break;
}
case KVM_NMI: {
- r = kvm_vcpu_ioctl_nmi(vcpu);
- if (r)
- goto out;
+ if (irqchip_in_kernel(vcpu->kvm))
+ kvm_apic_lint1_deliver(vcpu);
+ else
+ kvm_inject_nmi(vcpu);
r = 0;
break;
}
Why did you drop kvm_vcpu_ioctl_nmi()?
Please add (and document) a KVM_CAP flag that lets userspace know the
new behaviour is supported.
--
error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH] Update README example
On 10/09/2011 06:02 PM, Liu, Jinsong wrote: Subject: [PATCH] Update README example Thanks, applied. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH] apic: test tsc deadline timer
On 10/09/2011 05:32 PM, Liu, Jinsong wrote: Updated test case for kvm tsc deadline timer https://github.com/avikivity/kvm-unit-tests, as attached. Applied, thanks. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH] virtio-9p: fix QEMU build break
qemu build break due to the redefinition of struct file_handle. My
qemu.git/HEAD is 8acbc9b21d757a6be4f8492e547b8159703a0547
Below is the log:
[root@f15 qemu]# make
CCqapi-generated/qga-qapi-types.o
LINK qemu-ga
CClibhw64/9pfs/virtio-9p-handle.o
/home/zwu/work/virt/qemu/hw/9pfs/virtio-9p-handle.c:31:8: error: redefinition
of "struct file_handle"
/usr/include/bits/fcntl.h:254:8: note: originally defined here
make[1]: *** [9pfs/virtio-9p-handle.o] Error 1
make: *** [subdir-libhw64] Error 2
[root@f15 qemu]# rpm -qf /usr/include/bits/fcntl.h
glibc-headers-2.13.90-9.x86_64
Signed-off-by: Zhi Yong Wu
---
hw/9pfs/virtio-9p-handle.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/9pfs/virtio-9p-handle.c b/hw/9pfs/virtio-9p-handle.c
index 5c8b5ed..5b3a867 100644
--- a/hw/9pfs/virtio-9p-handle.c
+++ b/hw/9pfs/virtio-9p-handle.c
@@ -27,7 +27,7 @@ struct handle_data {
int handle_bytes;
};
-#if __GLIBC__ <= 2 && __GLIBC_MINOR__ < 14
+#if __GLIBC__ <= 2 && __GLIBC_MINOR__ < 13
struct file_handle {
unsigned int handle_bytes;
int handle_type;
--
1.7.6
Re: [Qemu-devel] [PATCH][uq/master] kvm: Add top-like kvm statistics script
On 10/07/2011 09:37 AM, Jan Kiszka wrote: Taken from original qemu-kvm/kvm/kvm_stat. Applied, thanks. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH][uq/master] kvm: Add tool for querying VMX capabilities
On 10/07/2011 09:37 AM, Jan Kiszka wrote: Taken from original qemu-kvm/kvm/scripts/vmxcap. Applied, thanks. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH 14/15] qemu-nbd: asynchronous operation
Using coroutines enable asynchronous operation on both the network and
the block side. Network can be owned by two coroutines at the same time,
one writing and one reading. On the send side, mutual exclusion is
guaranteed by a CoMutex. On the receive side, mutual exclusion is
guaranteed because new coroutines immediately start receiving data,
and no new coroutines are created as long as the previous one is receiving.
Between receive and send, qemu-nbd can have an arbitrary number of
in-flight block transfers. Throttling is implemented by the next
patch.
Signed-off-by: Paolo Bonzini
---
nbd.c | 66
1 files changed, 49 insertions(+), 17 deletions(-)
diff --git a/nbd.c b/nbd.c
index e016175..01d3a85 100644
--- a/nbd.c
+++ b/nbd.c
@@ -20,6 +20,8 @@
#include "block.h"
#include "block_int.h"
+#include "qemu-coroutine.h"
+
#include
#include
#ifndef _WIN32
@@ -609,6 +611,11 @@ struct NBDClient {
NBDExport *exp;
int sock;
+
+Coroutine *recv_coroutine;
+
+CoMutex send_lock;
+Coroutine *send_coroutine;
};
static void nbd_client_get(NBDClient *client)
@@ -683,13 +690,20 @@ void nbd_export_close(NBDExport *exp)
g_free(exp);
}
-static int nbd_do_send_reply(NBDRequest *req, struct nbd_reply *reply,
+static void nbd_read(void *opaque);
+static void nbd_restart_write(void *opaque);
+
+static int nbd_co_send_reply(NBDRequest *req, struct nbd_reply *reply,
int len)
{
NBDClient *client = req->client;
int csock = client->sock;
int rc, ret;
+qemu_co_mutex_lock(&client->send_lock);
+qemu_set_fd_handler2(csock, NULL, nbd_read, nbd_restart_write, client);
+client->send_coroutine = qemu_coroutine_self();
+
if (!len) {
rc = nbd_send_reply(csock, reply);
if (rc == -1) {
@@ -699,7 +713,7 @@ static int nbd_do_send_reply(NBDRequest *req, struct
nbd_reply *reply,
socket_set_cork(csock, 1);
rc = nbd_send_reply(csock, reply);
if (rc != -1) {
-ret = write_sync(csock, req->data, len);
+ret = qemu_co_send(csock, req->data, len);
if (ret != len) {
errno = EIO;
rc = -1;
@@ -710,15 +724,20 @@ static int nbd_do_send_reply(NBDRequest *req, struct
nbd_reply *reply,
}
socket_set_cork(csock, 0);
}
+
+client->send_coroutine = NULL;
+qemu_set_fd_handler2(csock, NULL, nbd_read, NULL, client);
+qemu_co_mutex_unlock(&client->send_lock);
return rc;
}
-static int nbd_do_receive_request(NBDRequest *req, struct nbd_request *request)
+static int nbd_co_receive_request(NBDRequest *req, struct nbd_request *request)
{
NBDClient *client = req->client;
int csock = client->sock;
int rc;
+client->recv_coroutine = qemu_coroutine_self();
if (nbd_receive_request(csock, request) == -1) {
rc = -EIO;
goto out;
@@ -743,7 +762,7 @@ static int nbd_do_receive_request(NBDRequest *req, struct
nbd_request *request)
if ((request->type & NBD_CMD_MASK_COMMAND) == NBD_CMD_WRITE) {
TRACE("Reading %u byte(s)", request->len);
-if (read_sync(csock, req->data, request->len) != request->len) {
+if (qemu_co_recv(csock, req->data, request->len) != request->len) {
LOG("reading from socket failed");
rc = -EIO;
goto out;
@@ -752,21 +771,22 @@ static int nbd_do_receive_request(NBDRequest *req, struct
nbd_request *request)
rc = 0;
out:
+client->recv_coroutine = NULL;
return rc;
}
-static int nbd_trip(NBDClient *client)
+static void nbd_trip(void *opaque)
{
+NBDClient *client = opaque;
NBDRequest *req = nbd_request_get(client);
NBDExport *exp = client->exp;
struct nbd_request request;
struct nbd_reply reply;
-int rc = -1;
int ret;
TRACE("Reading request.");
-ret = nbd_do_receive_request(req, &request);
+ret = nbd_co_receive_request(req, &request);
if (ret == -EIO) {
goto out;
}
@@ -801,7 +821,7 @@ static int nbd_trip(NBDClient *client)
}
TRACE("Read %u byte(s)", request.len);
-if (nbd_do_send_reply(req, &reply, request.len) < 0)
+if (nbd_co_send_reply(req, &reply, request.len) < 0)
goto out;
break;
case NBD_CMD_WRITE:
@@ -832,13 +852,13 @@ static int nbd_trip(NBDClient *client)
}
}
-if (nbd_do_send_reply(req, &reply, 0) < 0)
+if (nbd_co_send_reply(req, &reply, 0) < 0)
goto out;
break;
case NBD_CMD_DISC:
TRACE("Request type is DISCONNECT");
errno = 0;
-return 1;
+goto out;
case NBD_CMD_FLUSH:
TRACE("Request type is FLUSH");
@@ -848,7 +868,7 @@ static int nbd_trip(NBDClient *client)
reply.error = -ret;
}
-if (nbd_do_send_reply(req, &reply, 0) < 0)
[Qemu-devel] [PATCH 08/15] qemu-nbd: introduce NBDExport
Wrap the common parameters of nbd_trip in a single opaque struct.
Signed-off-by: Paolo Bonzini
---
nbd.c | 57 ++---
nbd.h |9 +++--
qemu-nbd.c | 18 ++
3 files changed, 55 insertions(+), 29 deletions(-)
diff --git a/nbd.c b/nbd.c
index 898206f..00764da 100644
--- a/nbd.c
+++ b/nbd.c
@@ -18,6 +18,7 @@
#include "nbd.h"
#include "block.h"
+#include "block_int.h"
#include
#include
@@ -585,6 +586,33 @@ static int nbd_send_reply(int csock, struct nbd_reply
*reply)
return 0;
}
+struct NBDExport {
+BlockDriverState *bs;
+off_t dev_offset;
+off_t size;
+uint8_t *data;
+uint32_t nbdflags;
+};
+
+NBDExport *nbd_export_new(BlockDriverState *bs, off_t dev_offset,
+ off_t size, uint32_t nbdflags)
+{
+NBDExport *exp = g_malloc0(sizeof(NBDExport));
+exp->bs = bs;
+exp->dev_offset = dev_offset;
+exp->nbdflags = nbdflags;
+exp->size = size == -1 ? exp->bs->total_sectors * 512 : size;
+exp->data = qemu_blockalign(exp->bs, NBD_BUFFER_SIZE);
+return exp;
+}
+
+void nbd_export_close(NBDExport *exp)
+{
+qemu_vfree(exp->data);
+bdrv_close(exp->bs);
+g_free(exp);
+}
+
static int nbd_do_send_reply(int csock, struct nbd_reply *reply,
uint8_t *data, int len)
{
@@ -654,9 +682,7 @@ out:
return rc;
}
-int nbd_trip(BlockDriverState *bs, int csock, off_t size,
- uint64_t dev_offset, uint32_t nbdflags,
- uint8_t *data)
+int nbd_trip(NBDExport *exp, int csock)
{
struct nbd_request request;
struct nbd_reply reply;
@@ -664,7 +690,7 @@ int nbd_trip(BlockDriverState *bs, int csock, off_t size,
TRACE("Reading request.");
-ret = nbd_do_receive_request(csock, &request, data);
+ret = nbd_do_receive_request(csock, &request, exp->data);
if (ret == -EIO) {
return -1;
}
@@ -677,10 +703,11 @@ int nbd_trip(BlockDriverState *bs, int csock, off_t size,
goto error_reply;
}
-if ((request.from + request.len) > size) {
+if ((request.from + request.len) > exp->size) {
LOG("From: %" PRIu64 ", Len: %u, Size: %" PRIu64
", Offset: %" PRIu64 "\n",
-request.from, request.len, (uint64_t)size, dev_offset);
+request.from, request.len,
+(uint64_t)exp->size, exp->dev_offset);
LOG("requested operation past EOF--bad client?");
goto invalid_request;
}
@@ -689,8 +716,8 @@ int nbd_trip(BlockDriverState *bs, int csock, off_t size,
case NBD_CMD_READ:
TRACE("Request type is READ");
-ret = bdrv_read(bs, (request.from + dev_offset) / 512,
-data, request.len / 512);
+ret = bdrv_read(exp->bs, (request.from + exp->dev_offset) / 512,
+exp->data, request.len / 512);
if (ret < 0) {
LOG("reading from file failed");
reply.error = -ret;
@@ -698,13 +725,13 @@ int nbd_trip(BlockDriverState *bs, int csock, off_t size,
}
TRACE("Read %u byte(s)", request.len);
-if (nbd_do_send_reply(csock, &reply, data, request.len) < 0)
+if (nbd_do_send_reply(csock, &reply, exp->data, request.len) < 0)
return -1;
break;
case NBD_CMD_WRITE:
TRACE("Request type is WRITE");
-if (nbdflags & NBD_FLAG_READ_ONLY) {
+if (exp->nbdflags & NBD_FLAG_READ_ONLY) {
TRACE("Server is read-only, return error");
reply.error = EROFS;
goto error_reply;
@@ -712,8 +739,8 @@ int nbd_trip(BlockDriverState *bs, int csock, off_t size,
TRACE("Writing to device");
-ret = bdrv_write(bs, (request.from + dev_offset) / 512,
- data, request.len / 512);
+ret = bdrv_write(exp->bs, (request.from + exp->dev_offset) / 512,
+ exp->data, request.len / 512);
if (ret < 0) {
LOG("writing to file failed");
reply.error = -ret;
@@ -721,7 +748,7 @@ int nbd_trip(BlockDriverState *bs, int csock, off_t size,
}
if (request.type & NBD_CMD_FLAG_FUA) {
-ret = bdrv_flush(bs);
+ret = bdrv_flush(exp->bs);
if (ret < 0) {
LOG("flush failed");
reply.error = -ret;
@@ -739,7 +766,7 @@ int nbd_trip(BlockDriverState *bs, int csock, off_t size,
case NBD_CMD_FLUSH:
TRACE("Request type is FLUSH");
-ret = bdrv_flush(bs);
+ret = bdrv_flush(exp->bs);
if (ret < 0) {
LOG("flush failed");
reply.error = -ret;
@@ -750,7 +777,7 @@ int nbd_trip(BlockDriverState *bs, int csock, off_t size,
break;
case NBD_CMD_TRIM:
TRACE("Request type is TRIM");
-ret = bdrv_discard(bs, (request.from + dev_offset) / 512,
+ret = b
[Qemu-devel] [PATCH 02/15] qemu-nbd: remove data_size argument to nbd_trip
The size of the buffer is in practice part of the protocol.
Signed-off-by: Paolo Bonzini
---
nbd.c |6 +++---
nbd.h |4 +++-
qemu-nbd.c |4 +---
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/nbd.c b/nbd.c
index a96c109..59c47ee 100644
--- a/nbd.c
+++ b/nbd.c
@@ -587,7 +587,7 @@ static int nbd_send_reply(int csock, struct nbd_reply
*reply)
int nbd_trip(BlockDriverState *bs, int csock, off_t size,
uint64_t dev_offset, uint32_t nbdflags,
- uint8_t *data, int data_size)
+ uint8_t *data)
{
struct nbd_request request;
struct nbd_reply reply;
@@ -598,9 +598,9 @@ int nbd_trip(BlockDriverState *bs, int csock, off_t size,
if (nbd_receive_request(csock, &request) == -1)
return -1;
-if (request.len + NBD_REPLY_SIZE > data_size) {
+if (request.len + NBD_REPLY_SIZE > NBD_BUFFER_SIZE) {
LOG("len (%u) is larger than max len (%u)",
-request.len + NBD_REPLY_SIZE, data_size);
+request.len + NBD_REPLY_SIZE, NBD_BUFFER_SIZE);
errno = EINVAL;
return -1;
}
diff --git a/nbd.h b/nbd.h
index ebdb2db..dbc4c0d 100644
--- a/nbd.h
+++ b/nbd.h
@@ -57,6 +57,8 @@ enum {
#define NBD_DEFAULT_PORT 10809
+#define NBD_BUFFER_SIZE (1024*1024)
+
size_t nbd_wr_sync(int fd, void *buffer, size_t size, bool do_read);
int tcp_socket_outgoing(const char *address, uint16_t port);
int tcp_socket_incoming(const char *address, uint16_t port);
@@ -72,7 +74,7 @@ int nbd_init(int fd, int csock, uint32_t flags, off_t size,
size_t blocksize);
int nbd_send_request(int csock, struct nbd_request *request);
int nbd_receive_reply(int csock, struct nbd_reply *reply);
int nbd_trip(BlockDriverState *bs, int csock, off_t size, uint64_t dev_offset,
- uint32_t nbdflags, uint8_t *data, int data_size);
+ uint32_t nbdflags, uint8_t *data);
int nbd_client(int fd);
int nbd_disconnect(int fd);
diff --git a/qemu-nbd.c b/qemu-nbd.c
index e2fe7cf..befbbfd 100644
--- a/qemu-nbd.c
+++ b/qemu-nbd.c
@@ -34,8 +34,6 @@
#define SOCKET_PATH"/var/lock/qemu-nbd-%s"
-#define NBD_BUFFER_SIZE (1024*1024)
-
static int verbose;
static void usage(const char *name)
@@ -461,7 +459,7 @@ int main(int argc, char **argv)
for (i = 1; i < nb_fds && ret; i++) {
if (FD_ISSET(sharing_fds[i], &fds)) {
if (nbd_trip(bs, sharing_fds[i], fd_size, dev_offset,
-nbdflags, data, NBD_BUFFER_SIZE) != 0) {
+ nbdflags, data) != 0) {
close(sharing_fds[i]);
nb_fds--;
sharing_fds[i] = sharing_fds[nb_fds];
--
1.7.6
Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
On 10/10/2011 12:21 PM, Alon Levy wrote: > A core file would be that format - for direct gdb processing. No > proprietary re-inventions please. Just a note: A core file to windows core dump file would be nice for windows guest crashes. That requires cooperation from a kernel driver in the Windows guest. The driver must call KeInitializeCrashDumpHeader and write somewhere the physical address of the buffer. Paolo
Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
On Mon, Oct 10, 2011 at 12:48:52PM +0200, Paolo Bonzini wrote: > On 10/10/2011 12:21 PM, Alon Levy wrote: > >> A core file would be that format - for direct gdb processing. No > >> proprietary re-inventions please. > > > >Just a note: A core file to windows core dump file would be nice for > >windows guest crashes. > > That requires cooperation from a kernel driver in the Windows guest. > The driver must call KeInitializeCrashDumpHeader and write somewhere > the physical address of the buffer. That won't be suitable for 'virsh dump' then, because we need this to work when the guest OS is in a crashed/non-responsive state, and so we cna't rely on talking to it. Daniel. -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
On 10/10/2011 01:04 PM, Daniel P. Berrange wrote: On Mon, Oct 10, 2011 at 12:48:52PM +0200, Paolo Bonzini wrote: > On 10/10/2011 12:21 PM, Alon Levy wrote: > >>A core file would be that format - for direct gdb processing. No > >>proprietary re-inventions please. > > > >Just a note: A core file to windows core dump file would be nice for > >windows guest crashes. > > That requires cooperation from a kernel driver in the Windows guest. > The driver must call KeInitializeCrashDumpHeader and write somewhere > the physical address of the buffer. That won't be suitable for 'virsh dump' then, because we need this to work when the guest OS is in a crashed/non-responsive state, and so we cna't rely on talking to it. Note that the guest can generate the buffer before it crashes. Paolo
Re: [Qemu-devel] [PATCH] rsqrte_f32: No need to copy sign bit.
On 09.10.2011 00:57, Peter Maydell wrote: On 3 October 2011 15:28, Christophe Lyon wrote: Indeed, the result is known to be always positive. -val = ((val64>> 63)& 0x8000) -| ((result_exp& 0xff)<< 23) +val = ((result_exp& 0xff)<< 23) | ((val64>> 29)& 0x7f); return make_float32(val); So we weren't generating incorrect results, we were just doing slightly more work than we really needed, right? I'm curious what prompted this patch :-) Exactly. And no way to expose a bug :-( I was reading 2 revisions of the ARM ARM, and noticed erratas in the descriptions of FPRecipEstimate and FPRSqrtEstimate. Sign propagation has been removed in the former, and not in the later, so I re-read both functions carefully as well as qemu's implementation and came to this conclusion :-) I have contacted ARM support and suggested them to fix both function accordingly :-) Christophe.
[Qemu-devel] [PATCH v2] target-xtensa: update qemu-doc.texi
Signed-off-by: Max Filippov
---
v1 -> v2 change: fix menu item text in qemu-tech.texi
---
qemu-doc.texi | 55 +++
qemu-tech.texi | 40 +---
2 files changed, 88 insertions(+), 7 deletions(-)
diff --git a/qemu-doc.texi b/qemu-doc.texi
index 31199f6..ad19b73 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -110,6 +110,7 @@ For system emulation, the following hardware targets are
supported:
@item Syborg SVP base model (ARM Cortex-A8).
@item AXIS-Devboard88 (CRISv32 ETRAX-FS).
@item Petalogix Spartan 3aDSP1800 MMU ref design (MicroBlaze).
+@item Avnet LX60/LX110/LX200 boards (Xtensa)
@end itemize
@cindex supported user mode targets
@@ -1446,6 +1447,7 @@ differences are mentioned in the following sections.
* Cris System emulator::
* Microblaze System emulator::
* SH4 System emulator::
+* Xtensa System emulator::
@end menu
@node PowerPC System emulator
@@ -2124,6 +2126,59 @@ TODO
TODO
+@node Xtensa System emulator
+@section Xtensa System emulator
+@cindex system emulation (Xtensa)
+
+Two executables cover simulation of both Xtensa endian options,
+@file{qemu-system-xtensa} and @file{qemu-system-xtensaeb}.
+Two different machine types are emulated:
+
+@itemize @minus
+@item
+Xtensa emulator pseudo board "sim"
+@item
+Avnet LX60/LX110/LX200 board
+@end itemize
+
+The sim pseudo board emulation provides an environment similiar
+to one provided by the proprietary Tensilica ISS.
+It supports:
+
+@itemize @minus
+@item
+A range of Xtensa CPUs, default is the DC232B
+@item
+Console and filesystem access via semihosting calls
+@end itemize
+
+The Avnet LX60/LX110/LX200 emulation supports:
+
+@itemize @minus
+@item
+A range of Xtensa CPUs, default is the DC232B
+@item
+16550 UART
+@item
+OpenCores 10/100 Mbps Ethernet MAC
+@end itemize
+
+@c man begin OPTIONS
+
+The following options are specific to the Xtensa emulation:
+
+@table @option
+
+@item -semihosting
+Enable semihosting syscall emulation.
+
+Xtensa semihosting provides basic file IO calls, such as
open/read/write/seek/select.
+Tensilica baremetal libc for ISS and linux platform "sim" use this interface.
+
+Note that this allows guest direct access to the host filesystem,
+so should only be used with trusted guest OS.
+
+@end table
@node QEMU User space emulator
@chapter QEMU User space emulator
diff --git a/qemu-tech.texi b/qemu-tech.texi
index 138e3ce..397b070 100644
--- a/qemu-tech.texi
+++ b/qemu-tech.texi
@@ -42,13 +42,14 @@
@chapter Introduction
@menu
-* intro_features::Features
-* intro_x86_emulation:: x86 and x86-64 emulation
-* intro_arm_emulation:: ARM emulation
-* intro_mips_emulation:: MIPS emulation
-* intro_ppc_emulation:: PowerPC emulation
-* intro_sparc_emulation:: Sparc32 and Sparc64 emulation
-* intro_other_emulation:: Other CPU emulation
+* intro_features:: Features
+* intro_x86_emulation::x86 and x86-64 emulation
+* intro_arm_emulation::ARM emulation
+* intro_mips_emulation:: MIPS emulation
+* intro_ppc_emulation::PowerPC emulation
+* intro_sparc_emulation:: Sparc32 and Sparc64 emulation
+* intro_xtensa_emulation:: Xtensa emulation
+* intro_other_emulation:: Other CPU emulation
@end menu
@node intro_features
@@ -259,6 +260,31 @@ Current QEMU limitations:
@end itemize
+@node intro_xtensa_emulation
+@section Xtensa emulation
+
+@itemize
+
+@item Core Xtensa ISA emulation, including most options: code density,
+loop, extended L32R, 16- and 32-bit multiplication, 32-bit division,
+MAC16, miscellaneous operations, boolean, multiprocessor synchronization,
+conditional store, exceptions, relocatable vectors, unaligned exception,
+interrupts (including high priority and timer), hardware alignment,
+region protection, region translation, MMU, windowed registers, thread
+pointer, processor ID.
+
+@item Not implemented options: FP coprocessor, coprocessor context,
+data/instruction cache (including cache prefetch and locking), XLMI,
+processor interface, debug. Also options not covered by the core ISA
+(e.g. FLIX, wide branches) are not implemented.
+
+@item Can run most Xtensa Linux binaries.
+
+@item New core configuration that requires no additional instructions
+may be created from overlay with minimal amount of hand-written code.
+
+@end itemize
+
@node intro_other_emulation
@section Other CPU emulation
--
1.7.2.5
[Qemu-devel] KVM call agenda for October 11th
Hi Please send in any agenda items you are interested in covering. Thanks, Juan. pgpsWpNSfkqQb.pgp Description: PGP signature
[Qemu-devel] windows crash dump header. was: Re: [Question] dump memory when host pci device is used by guest
On Mon, Oct 10, 2011 at 01:09:17PM +0200, Paolo Bonzini wrote: > On 10/10/2011 01:04 PM, Daniel P. Berrange wrote: > >On Mon, Oct 10, 2011 at 12:48:52PM +0200, Paolo Bonzini wrote: > >>> On 10/10/2011 12:21 PM, Alon Levy wrote: > > >>A core file would be that format - for direct gdb processing. No > > >>proprietary re-inventions please. > > > >Just a note: A core file to windows core dump file would be nice for > >windows guest crashes. > >>> > >>> That requires cooperation from a kernel driver in the Windows guest. > >>> The driver must call KeInitializeCrashDumpHeader and write somewhere > >>> the physical address of the buffer. > >That won't be suitable for 'virsh dump' then, because we need this to > >work when the guest OS is in a crashed/non-responsive state, and so > >we cna't rely on talking to it. > > Note that the guest can generate the buffer before it crashes. > Thanks. The contents seem to be undocumented (stubbed in reactos). I did find a link to a tool made for Xen, but it mentions being broken with Windows 2003 (where KeInitializeCrashDumpHeader was introduced). http://www.osronline.com/showThread.CFM?link=203490 > Paolo >
Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)
> For any major feature that you're targeting to the next release, you should: > > # Make sure that you've posted a patch series to qemu-devel > # Write a Feature page on the qemu.org wiki describing the feature and the > motivation > # On the release planning wiki page, link to your feature wiki page. Have done that for the target-xtensa. -- Thanks. -- Max
Re: [Qemu-devel] usb_packet_complete assert(p->owner != NULL)
Hi,
-usb_packet_complete(&s->dev, packet);
+s->dev.port->ops->complete(s->dev.port, packet);
}
The hub is now directly invoking .complete() and not messing with
packet->owner (which is already NULL). We don't hit the assertion
anymore.
Does the attached patch work for you?
cheers,
Gerd
>From 192f6ed2d669c10d29e8f7f1f5682357fb0ce9c3 Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann
Date: Mon, 10 Oct 2011 14:12:09 +0200
Subject: [PATCH] usb: fix packet owner tracking with hub
usb_packet_complete should only clear owner when called from the device
itself, not from a usb hub. Complements the special case for the hub in
usb_handle_packet().
Signed-off-by: Gerd Hoffmann
---
hw/usb.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/hw/usb.c b/hw/usb.c
index 0f163b4..0c2fe86 100644
--- a/hw/usb.c
+++ b/hw/usb.c
@@ -347,7 +347,9 @@ void usb_packet_complete(USBDevice *dev, USBPacket *p)
{
/* Note: p->owner != dev is possible in case dev is a hub */
assert(p->owner != NULL);
-p->owner = NULL;
+if (p->owner == dev) {
+p->owner = NULL;
+}
dev->port->ops->complete(dev->port, p);
}
--
1.7.1
Re: [Qemu-devel] [PATCH] rsqrte_f32: No need to copy sign bit.
On 10 October 2011 12:26, Christophe Lyon wrote: > On 09.10.2011 00:57, Peter Maydell wrote: >> So we weren't generating incorrect results, we were just doing >> slightly more work than we really needed, right? I'm curious >> what prompted this patch :-) >> > Exactly. And no way to expose a bug :-( If we always generate the correct results for all inputs, then by definition it's not a bug. It's just a slightly suboptimal calculation (both here and in the ARM ARM pseudocode). > I was reading 2 revisions of the ARM ARM, and noticed erratas in the > descriptions of FPRecipEstimate and FPRSqrtEstimate. > > Sign propagation has been removed in the former, and not in the later, so I > re-read both functions carefully as well as qemu's implementation and came > to this conclusion :-) For FPRecipEstimate the change in the sign handling was fixing a genuine erratum in the pseudocode. (QEMU's code for that is correct; I recall checking at the time that we were following the amended pseudocode rather than the old version.) For FPSqrtEstimate it's just a clarity of phrasing issue. Anyway, I agree we should make this change and have tested that we still generate correct results. So: Reviewed-by: Peter Maydell -- PMM
Re: [Qemu-devel] windows crash dump header. was: Re: [Question] dump memory when host pci device is used by guest
On 10/10/2011 02:00 PM, Alon Levy wrote: > Note that the guest can generate the buffer before it crashes. > Thanks. The contents seem to be undocumented (stubbed in reactos). Those lazy reactos authors. :) 32-bit: http://www.google.com/codesearch#s5CWGGZtI6g/trunk/Volatility/vtypes.py&q=MajorVersion&exact_package=http://volatility.googlecode.com/svn&ct=rc&cd=1 64-bit: https://singularity.svn.codeplex.com/svn/base/Windows/Inc/Dump.h Looks like most of the fields can be made up at crash time, with some luck the others are not needed for a basic debugging session. Paolo
[Qemu-devel] [PATCH] target-arm: Fix use of free() in cpu_arm_close()
env is allocated in cpu_arm_init() with g_malloc0(), so free with g_free().
Cc: Peter Maydell
Signed-off-by: Andreas Färber
---
target-arm/helper.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/target-arm/helper.c b/target-arm/helper.c
index d3a3ba2..8195c56 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -471,7 +471,7 @@ static uint32_t cpu_arm_find_by_name(const char *name)
void cpu_arm_close(CPUARMState *env)
{
-free(env);
+g_free(env);
}
uint32_t cpsr_read(CPUARMState *env)
--
1.7.6.4
[Qemu-devel] [BUG] USB assertion triggers in usb_packet_complete()
Hi! I am currently facing a problem when running QEMU (up-to-date git version) with OHCI and a lot of virtual USB devices. The emulator dies with the following assertion: qemu-system-arm: hw/usb.c:337: usb_packet_complete: Assertion `p->owner != ((void *)0)' failed. To reproduce this problem, you can run the configure script with "--target-list=arm-softmmu" for example, then download the files vmlinuz-2.6.26-2-versatile and initrd.img-2.6.26-2-versatile from http://people.debian.org/~aurel32/qemu/arm/ and then run qemu like this: qemu-system-arm -kernel vmlinuz-2.6.26-2-versatile \ -initrd initrd.img-2.6.26-2-versatile -M versatilepb -usb \ -drive if=none,file=/tmp/linux-0.2.img,cache=none,id=disk0 \ -device usb-storage,drive=disk0 -usbdevice mouse \ -usbdevice keyboard -usbdevice tablet It boots the Linux kernel for a while, then dies with the above assertion. Observations: - It could be related to the fact that QEMU puts a hub into the USB tree in that case ... when I specify less USB devices, I was not able to reproduce this problem, but in that case there are also no hubs in the tree. According to the comment in usb_packet_complete(), there might be problems with the assert() in case there is a hub ... ? - So far I was only able to reproduce this problem when the emulated platform uses an OHCI controller. I haven't seen the problem to occur with UHCI yet (but I have to admit that I also haven't done a lot of tests with UHCI). Do you have any ideas what could be wrong here? Regards, Thomas
Re: [Qemu-devel] Is realview-pb-a8 fully supported ?
On Mon, Oct 10, 2011 at 10:42 AM, Peter Maydell wrote: > On 10 October 2011 08:35, Francis Moreau wrote: >> I noticed another point for the realview platofrm: if I boot with "-M >> 512", it works however if I set "-M 256" then it doesn't. > > Perhaps your kernel is configured to load in the higher 256MB > address range hmm which options do you have in mind ? > or is configured/has a command line which assumes > it has 512MB of RAM? (In what way does it "not work" ?) I have no such thing in the command line. When I say "it doesn't work", it means that nothing happen when starting qemu: no trace, it looks like it's running an infinite loop. BTW I'm wondering which kernel source I should use to build kernels for such plateforms (realview, vexpress, versatile) ? I'm currently using the source from kernel.org (well similar since this server seems really dead). but I'm not sure if it's a good idea... Thanks. -- Francis
Re: [Qemu-devel] windows crash dump header. was: Re: [Question] dump memory when host pci device is used by guest
On Mon, Oct 10, 2011 at 02:38:35PM +0200, Paolo Bonzini wrote: > On 10/10/2011 02:00 PM, Alon Levy wrote: > >>> Note that the guest can generate the buffer before it crashes. > >>> > >Thanks. The contents seem to be undocumented (stubbed in reactos). > > Those lazy reactos authors. :) > > 32-bit: > > http://www.google.com/codesearch#s5CWGGZtI6g/trunk/Volatility/vtypes.py&q=MajorVersion&exact_package=http://volatility.googlecode.com/svn&ct=rc&cd=1 > > 64-bit: > > https://singularity.svn.codeplex.com/svn/base/Windows/Inc/Dump.h > > Looks like most of the fields can be made up at crash time, with > some luck the others are not needed for a basic debugging session. > Great. Nice that singularity exposes stuff not in WinDDK. > Paolo >
Re: [Qemu-devel] buildbot failure in qemu on default_openbsd_4.9
Hi, Gerd, Brad, does one of your buildbots have some resources left to build the block branch on OpenBSD (and for Gerd, possibly mingw) as well? No problem, can be added to both openbsd and mingw. cheers, Gerd
Re: [Qemu-devel] [PATCH] Probe PCI existence
On 09/21/11 08:16, Jan Kiszka wrote: From: Jan Kiszka This prevents lockups when trying to allocate PCI resources on an ISA-only system like QEMU can emulate. Looks good to me. Acked-by: Gerd Hoffmann cheers, Gerd
Re: [Qemu-devel] [PATCH 0/1] [PULL] qemu-kvm.git uq/master queue
On 10/03/2011 03:55 PM, Marcelo Tosatti wrote: The following changes since commit d11cf8cc80d946dfc9a23597cd9a0bb1c487cfa7: etrax-dma: Remove bogus if statement (2011-10-03 10:20:13 +0200) are available in the git repository at: git://github.com/avikivity/qemu.git uq/master Pulled. Thanks. Are ya'll planning on moving your repo back to kernel.org or sticking with github? Regards, Anthony Liguori Liu, Jinsong (1): kvm: support TSC deadline MSR target-i386/cpu.h |4 +++- target-i386/kvm.c | 14 ++ target-i386/machine.c |1 + 3 files changed, 18 insertions(+), 1 deletions(-)
Re: [Qemu-devel] [PULL 0/7] Trivial patches for September 22 to October 5 2011
On 10/05/2011 03:47 AM, Stefan Hajnoczi wrote: The following changes since commit d11cf8cc80d946dfc9a23597cd9a0bb1c487cfa7: etrax-dma: Remove bogus if statement (2011-10-03 10:20:13 +0200) are available in the git repository at: ssh://repo.or.cz/srv/git/qemu/stefanha.git trivial-patches Pulled. Thanks. Regards, Anthony Liguori Andreas Färber (1): target-arm: Fix typo Antony Pavlov (2): gt64xxx.c: fix length modifier in DPRINTF format string gt64xxx.c: remove reference to non-existing ISD_handle field Jan Kiszka (1): lsi: Fix tag reference in debug print Paolo Bonzini (1): makefile: extract tools-obj-y Stefan Weil (2): Fix mismatching allocation and deallocation linux-user: Remove unused code Makefile|9 + console.c |2 +- hw/gt64xxx.c| 13 +++-- hw/lsi53c895a.c |2 +- linux-user/signal.c |5 + target-arm/helper.c |2 +- 6 files changed, 16 insertions(+), 17 deletions(-)
Re: [Qemu-devel] [PULL 00/26]: QMP queue
On 10/05/2011 08:21 AM, Luiz Capitulino wrote: Anthony, This pull request contains only the first round of QAPI conversions series. I had to rebase it but the changes are rather simple. The changes (since d11cf8cc80d946dfc9a23597cd9a0bb1c487cfa7) are available in the following repository: git://repo.or.cz/qemu/qmp-unstable.git queue/qmp Pulled. Thanks. Regards, Anthony Liguori Anthony Liguori (6): error: let error_is_type take a NULL error qerror: add qerror_report_err() qapi: add code generation support for middle mode qapi: use middle mode in QMP server qapi: fixup command generation for functions that return list types qapi: convert query-name Luiz Capitulino (15): qapi: Don't use c_var() on enum strings qapi: Automatically generate a _MAX value for enums qapi: Convert query-version qapi: Convert query-kvm vl: Change qemu_vmstop_requested() to return a bool RunState: Drop the RSTATE_NO_STATE value RunState: Rename enum values as generated by the QAPI qapi: Convert query-status qapi: Convert query-uuid qapi: Convert query-chardev qapi: Convert query-commands qapi: Convert quit qapi: Convert stop qapi: Convert system_reset qapi: Convert system_powerdown Michael Roth (5): qapi: dealloc visitor, fix premature free and iteration logic qapi: generate qapi_free_* functions for *List types qapi: add test cases for generated free functions qapi: dealloc visitor, support freeing of nested lists qapi: modify visitor code generation for list iteration Makefile| 12 ++ Makefile.objs |3 + Makefile.target |6 +- error.c |4 + gdbstub.c | 26 ++-- hmp-commands.hx | 11 +- hmp.c | 116 ++ hmp.h | 31 + hw/ide/core.c |2 +- hw/scsi-disk.c |2 +- hw/virtio-blk.c |2 +- hw/watchdog.c |2 +- kvm-all.c |2 +- migration.c |6 +- monitor.c | 281 +-- qapi-schema.json| 273 + qapi/qapi-dealloc-visitor.c | 34 +- qapi/qapi-types-core.h |3 + qapi/qmp-input-visitor.c|4 +- qapi/qmp-output-visitor.c | 20 +++- qemu-char.c | 35 ++ qerror.c| 33 + qerror.h|2 + qmp-commands.hx | 57 +++-- qmp.c | 92 ++ savevm.c|4 +- scripts/qapi-commands.py| 98 --- scripts/qapi-types.py | 12 ++- scripts/qapi-visit.py |4 +- scripts/qapi.py |4 +- sysemu.h| 20 +--- test-qmp-commands.c | 29 + test-visitor.c | 48 ++-- vl.c| 133 ++--- 34 files changed, 959 insertions(+), 452 deletions(-)
Re: [Qemu-devel] [PATCH 0/1] [PULL] qemu-kvm.git uq/master queue
On 10/10/2011 04:41 PM, Anthony Liguori wrote: On 10/03/2011 03:55 PM, Marcelo Tosatti wrote: The following changes since commit d11cf8cc80d946dfc9a23597cd9a0bb1c487cfa7: etrax-dma: Remove bogus if statement (2011-10-03 10:20:13 +0200) are available in the git repository at: git://github.com/avikivity/qemu.git uq/master Pulled. Thanks. Um, this had a comment about it regarding s/version bump/subsection/ Are ya'll planning on moving your repo back to kernel.org or sticking with github? We'll move back to kernel.org as soon as we sort around the keys. -- error compiling committee.c: too many arguments to function
[Qemu-devel] FYI: Need to a make clean due to recently pushed commit
Due to: commit e3193601c84558c303b1773379da76fce80c0a56 Author: Anthony Liguori Date: Fri Sep 2 12:34:47 2011 -0500 qapi: use middle mode in QMP server It'll be necessary to do a make clean if you have a tree that has a build from before this commit. If you get compile errors about "qmp-commands-old.h" or "qmp-commands.h", this is most likely your problem. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH 1/1] kvm: support TSC deadline MSR
On 10/04/2011 05:20 PM, Marcelo Tosatti wrote: On Tue, Oct 04, 2011 at 07:53:42PM +0200, Avi Kivity wrote: On 10/03/2011 10:55 PM, Marcelo Tosatti wrote: From: "Liu, Jinsong" KVM add emulation of lapic tsc deadline timer for guest. This patch is co-operation work at qemu side. -#define CPU_SAVE_VERSION 12 +#define CPU_SAVE_VERSION 13 Unfortunate. Can't we use subsections? Yes, i'll look into it tomorrow. Subsections are still broken at the moment although Juan has some patches. Bumping the version is the safe thing to do. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH 0/1] [PULL] qemu-kvm.git uq/master queue
On 10/10/2011 09:48 AM, Avi Kivity wrote: On 10/10/2011 04:41 PM, Anthony Liguori wrote: On 10/03/2011 03:55 PM, Marcelo Tosatti wrote: The following changes since commit d11cf8cc80d946dfc9a23597cd9a0bb1c487cfa7: etrax-dma: Remove bogus if statement (2011-10-03 10:20:13 +0200) are available in the git repository at: git://github.com/avikivity/qemu.git uq/master Pulled. Thanks. Um, this had a comment about it regarding s/version bump/subsection/ Hrm, sorry about that. In the future, it would be helpful to explicitly withdrawal a PULL request. Do you want me to revert? FWIW, I think bumping the version is the right thing to do. Regards, Anthony Liguori Are ya'll planning on moving your repo back to kernel.org or sticking with github? We'll move back to kernel.org as soon as we sort around the keys.
Re: [Qemu-devel] [PATCH 1/1] kvm: support TSC deadline MSR
On 10/10/2011 04:54 PM, Anthony Liguori wrote: On 10/04/2011 05:20 PM, Marcelo Tosatti wrote: On Tue, Oct 04, 2011 at 07:53:42PM +0200, Avi Kivity wrote: On 10/03/2011 10:55 PM, Marcelo Tosatti wrote: From: "Liu, Jinsong" KVM add emulation of lapic tsc deadline timer for guest. This patch is co-operation work at qemu side. -#define CPU_SAVE_VERSION 12 +#define CPU_SAVE_VERSION 13 Unfortunate. Can't we use subsections? Yes, i'll look into it tomorrow. Subsections are still broken at the moment although Juan has some patches. Bumping the version is the safe thing to do. It's irreversible, once we release a version with a bumped ID we can't go back. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH 21/24] pc: Convert port92 to isa_register_ioport
From: Richard Henderson
Signed-off-by: Richard Henderson
Signed-off-by: Avi Kivity
---
hw/pc.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/hw/pc.c b/hw/pc.c
index 203627d..ded4758 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -428,6 +428,7 @@ void pc_cmos_init(ram_addr_t ram_size, ram_addr_t
above_4g_mem_size,
/* port 92 stuff: could be split off */
typedef struct Port92State {
ISADevice dev;
+MemoryRegion io;
uint8_t outport;
qemu_irq *a20_out;
} Port92State;
@@ -479,13 +480,22 @@ static void port92_reset(DeviceState *d)
s->outport &= ~1;
}
+static const MemoryRegionPortio port92_portio[] = {
+{ 0, 1, 1, .read = port92_read, .write = port92_write },
+PORTIO_END_OF_LIST(),
+};
+
+static const MemoryRegionOps port92_ops = {
+.old_portio = port92_portio
+};
+
static int port92_initfn(ISADevice *dev)
{
Port92State *s = DO_UPCAST(Port92State, dev, dev);
-register_ioport_read(0x92, 1, 1, port92_read, s);
-register_ioport_write(0x92, 1, 1, port92_write, s);
-isa_init_ioport(dev, 0x92);
+memory_region_init_io(&s->io, &port92_ops, s, "port92", 1);
+isa_register_ioport(dev, &s->io, 0x92);
+
s->outport = 0;
return 0;
}
--
1.7.6.3
[Qemu-devel] [PATCH 18/24] parallel: Convert to isa_register_portio_list
From: Richard Henderson
Signed-off-by: Richard Henderson
Signed-off-by: Avi Kivity
---
hw/parallel.c | 47 ---
1 files changed, 28 insertions(+), 19 deletions(-)
diff --git a/hw/parallel.c b/hw/parallel.c
index ecbc8c3..8494d94 100644
--- a/hw/parallel.c
+++ b/hw/parallel.c
@@ -448,6 +448,29 @@ static void parallel_reset(void *opaque)
static const int isa_parallel_io[MAX_PARALLEL_PORTS] = { 0x378, 0x278, 0x3bc };
+static const MemoryRegionPortio isa_parallel_portio_hw_list[] = {
+{ 0, 8, 1,
+ .read = parallel_ioport_read_hw,
+ .write = parallel_ioport_write_hw },
+{ 4, 1, 2,
+ .read = parallel_ioport_eppdata_read_hw2,
+ .write = parallel_ioport_eppdata_write_hw2 },
+{ 4, 1, 4,
+ .read = parallel_ioport_eppdata_read_hw4,
+ .write = parallel_ioport_eppdata_write_hw4 },
+{ 0x400, 8, 1,
+ .read = parallel_ioport_ecp_read,
+ .write = parallel_ioport_ecp_write },
+PORTIO_END_OF_LIST(),
+};
+
+static const MemoryRegionPortio isa_parallel_portio_sw_list[] = {
+{ 0, 8, 1,
+ .read = parallel_ioport_read_sw,
+ .write = parallel_ioport_write_sw },
+PORTIO_END_OF_LIST(),
+};
+
static int parallel_isa_initfn(ISADevice *dev)
{
static int index;
@@ -478,25 +501,11 @@ static int parallel_isa_initfn(ISADevice *dev)
s->status = dummy;
}
-if (s->hw_driver) {
-register_ioport_write(base, 8, 1, parallel_ioport_write_hw, s);
-register_ioport_read(base, 8, 1, parallel_ioport_read_hw, s);
-isa_init_ioport_range(dev, base, 8);
-
-register_ioport_write(base+4, 1, 2, parallel_ioport_eppdata_write_hw2,
s);
-register_ioport_read(base+4, 1, 2, parallel_ioport_eppdata_read_hw2,
s);
-register_ioport_write(base+4, 1, 4, parallel_ioport_eppdata_write_hw4,
s);
-register_ioport_read(base+4, 1, 4, parallel_ioport_eppdata_read_hw4,
s);
-isa_init_ioport(dev, base+4);
-register_ioport_write(base+0x400, 8, 1, parallel_ioport_ecp_write, s);
-register_ioport_read(base+0x400, 8, 1, parallel_ioport_ecp_read, s);
-isa_init_ioport_range(dev, base+0x400, 8);
-}
-else {
-register_ioport_write(base, 8, 1, parallel_ioport_write_sw, s);
-register_ioport_read(base, 8, 1, parallel_ioport_read_sw, s);
-isa_init_ioport_range(dev, base, 8);
-}
+isa_register_portio_list(dev, base,
+ (s->hw_driver
+ ? &isa_parallel_portio_hw_list[0]
+ : &isa_parallel_portio_sw_list[0]),
+ s, "parallel");
return 0;
}
--
1.7.6.3
[Qemu-devel] [PATCH 01/24] hw/lan9118.c: Convert to MemoryRegion
From: Peter Maydell
Signed-off-by: Peter Maydell
Signed-off-by: Avi Kivity
---
hw/lan9118.c | 29 +++--
1 files changed, 11 insertions(+), 18 deletions(-)
diff --git a/hw/lan9118.c b/hw/lan9118.c
index 73a8661..634b88e 100644
--- a/hw/lan9118.c
+++ b/hw/lan9118.c
@@ -152,7 +152,7 @@ enum tx_state {
NICState *nic;
NICConf conf;
qemu_irq irq;
-int mmio_index;
+MemoryRegion mmio;
ptimer_state *timer;
uint32_t irq_cfg;
@@ -895,7 +895,7 @@ static void lan9118_tick(void *opaque)
}
static void lan9118_writel(void *opaque, target_phys_addr_t offset,
- uint32_t val)
+ uint64_t val, unsigned size)
{
lan9118_state *s = (lan9118_state *)opaque;
offset &= 0xff;
@@ -1022,13 +1022,14 @@ static void lan9118_writel(void *opaque,
target_phys_addr_t offset,
break;
default:
-hw_error("lan9118_write: Bad reg 0x%x = %x\n", (int)offset, val);
+hw_error("lan9118_write: Bad reg 0x%x = %x\n", (int)offset, (int)val);
break;
}
lan9118_update(s);
}
-static uint32_t lan9118_readl(void *opaque, target_phys_addr_t offset)
+static uint64_t lan9118_readl(void *opaque, target_phys_addr_t offset,
+ unsigned size)
{
lan9118_state *s = (lan9118_state *)opaque;
@@ -1101,16 +1102,10 @@ static uint32_t lan9118_readl(void *opaque,
target_phys_addr_t offset)
return 0;
}
-static CPUReadMemoryFunc * const lan9118_readfn[] = {
-lan9118_readl,
-lan9118_readl,
-lan9118_readl
-};
-
-static CPUWriteMemoryFunc * const lan9118_writefn[] = {
-lan9118_writel,
-lan9118_writel,
-lan9118_writel
+static const MemoryRegionOps lan9118_mem_ops = {
+.read = lan9118_readl,
+.write = lan9118_writel,
+.endianness = DEVICE_NATIVE_ENDIAN,
};
static void lan9118_cleanup(VLANClientState *nc)
@@ -1135,10 +1130,8 @@ static int lan9118_init1(SysBusDevice *dev)
QEMUBH *bh;
int i;
-s->mmio_index = cpu_register_io_memory(lan9118_readfn,
- lan9118_writefn, s,
- DEVICE_NATIVE_ENDIAN);
-sysbus_init_mmio(dev, 0x100, s->mmio_index);
+memory_region_init_io(&s->mmio, &lan9118_mem_ops, s, "lan9118-mmio",
0x100);
+sysbus_init_mmio_region(dev, &s->mmio);
sysbus_init_irq(dev, &s->irq);
qemu_macaddr_default_if_unset(&s->conf.macaddr);
--
1.7.6.3
[Qemu-devel] [PATCH 23/24] ide: Convert to isa_register_portio_list
From: Richard Henderson
Signed-off-by: Richard Henderson
Signed-off-by: Avi Kivity
---
hw/ide/core.c | 30 +++---
hw/ide/internal.h |3 ++-
hw/ide/isa.c |4 +---
hw/ide/piix.c |7 ---
hw/ide/via.c |7 ---
5 files changed, 30 insertions(+), 21 deletions(-)
diff --git a/hw/ide/core.c b/hw/ide/core.c
index 4e76fc7..9eaf7f2 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include "qemu-error.h"
#include "qemu-timer.h"
#include "sysemu.h"
@@ -1969,20 +1970,27 @@ void ide_init2_with_non_qdev_drives(IDEBus *bus,
DriveInfo *hd0,
bus->dma = &ide_dma_nop;
}
-void ide_init_ioport(IDEBus *bus, int iobase, int iobase2)
+static const MemoryRegionPortio ide_portio_list[] = {
+{ 0, 8, 1, .read = ide_ioport_read, .write = ide_ioport_write },
+{ 0, 2, 2, .read = ide_data_readw, .write = ide_data_writew },
+{ 0, 4, 4, .read = ide_data_readl, .write = ide_data_writel },
+PORTIO_END_OF_LIST(),
+};
+
+static const MemoryRegionPortio ide_portio2_list[] = {
+{ 0, 1, 1, .read = ide_status_read, .write = ide_cmd_write },
+PORTIO_END_OF_LIST(),
+};
+
+void ide_init_ioport(IDEBus *bus, ISADevice *dev, int iobase, int iobase2)
{
-register_ioport_write(iobase, 8, 1, ide_ioport_write, bus);
-register_ioport_read(iobase, 8, 1, ide_ioport_read, bus);
+/* ??? Assume only ISA and PCI configurations, and that the PCI-ISA
+ bridge has been setup properly to always register with ISA. */
+isa_register_portio_list(dev, iobase, ide_portio_list, bus, "ide");
+
if (iobase2) {
-register_ioport_read(iobase2, 1, 1, ide_status_read, bus);
-register_ioport_write(iobase2, 1, 1, ide_cmd_write, bus);
+isa_register_portio_list(dev, iobase2, ide_portio2_list, bus, "ide");
}
-
-/* data ports */
-register_ioport_write(iobase, 2, 2, ide_data_writew, bus);
-register_ioport_read(iobase, 2, 2, ide_data_readw, bus);
-register_ioport_write(iobase, 4, 4, ide_data_writel, bus);
-register_ioport_read(iobase, 4, 4, ide_data_readl, bus);
}
static bool is_identify_set(void *opaque, int version_id)
diff --git a/hw/ide/internal.h b/hw/ide/internal.h
index 9046e96..c39dc05 100644
--- a/hw/ide/internal.h
+++ b/hw/ide/internal.h
@@ -7,6 +7,7 @@
* non-internal declarations are in hw/ide.h
*/
#include
+#include
#include "iorange.h"
#include "dma.h"
#include "sysemu.h"
@@ -600,7 +601,7 @@ int ide_init_drive(IDEState *s, BlockDriverState *bs,
IDEDriveKind kind,
void ide_init2(IDEBus *bus, qemu_irq irq);
void ide_init2_with_non_qdev_drives(IDEBus *bus, DriveInfo *hd0,
DriveInfo *hd1, qemu_irq irq);
-void ide_init_ioport(IDEBus *bus, int iobase, int iobase2);
+void ide_init_ioport(IDEBus *bus, ISADevice *isa, int iobase, int iobase2);
void ide_exec_cmd(IDEBus *bus, uint32_t val);
void ide_dma_cb(void *opaque, int ret);
diff --git a/hw/ide/isa.c b/hw/ide/isa.c
index 28b69d2..01a9e59 100644
--- a/hw/ide/isa.c
+++ b/hw/ide/isa.c
@@ -66,10 +66,8 @@ static int isa_ide_initfn(ISADevice *dev)
ISAIDEState *s = DO_UPCAST(ISAIDEState, dev, dev);
ide_bus_new(&s->bus, &s->dev.qdev, 0);
-ide_init_ioport(&s->bus, s->iobase, s->iobase2);
+ide_init_ioport(&s->bus, dev, s->iobase, s->iobase2);
isa_init_irq(dev, &s->irq, s->isairq);
-isa_init_ioport_range(dev, s->iobase, 8);
-isa_init_ioport(dev, s->iobase2);
ide_init2(&s->bus, s->irq);
vmstate_register(&dev->qdev, 0, &vmstate_ide_isa, s);
return 0;
diff --git a/hw/ide/piix.c b/hw/ide/piix.c
index 88d3181..08cbbe2 100644
--- a/hw/ide/piix.c
+++ b/hw/ide/piix.c
@@ -122,8 +122,7 @@ static void piix3_reset(void *opaque)
}
static void pci_piix_init_ports(PCIIDEState *d) {
-int i;
-struct {
+static const struct {
int iobase;
int iobase2;
int isairq;
@@ -131,10 +130,12 @@ static void pci_piix_init_ports(PCIIDEState *d) {
{0x1f0, 0x3f6, 14},
{0x170, 0x376, 15},
};
+int i;
for (i = 0; i < 2; i++) {
ide_bus_new(&d->bus[i], &d->dev.qdev, i);
-ide_init_ioport(&d->bus[i], port_info[i].iobase, port_info[i].iobase2);
+ide_init_ioport(&d->bus[i], NULL, port_info[i].iobase,
+port_info[i].iobase2);
ide_init2(&d->bus[i], isa_get_irq(port_info[i].isairq));
bmdma_init(&d->bus[i], &d->bmdma[i], d);
diff --git a/hw/ide/via.c b/hw/ide/via.c
index dab8a39..098f150 100644
--- a/hw/ide/via.c
+++ b/hw/ide/via.c
@@ -146,8 +146,7 @@ static void via_reset(void *opaque)
}
static void vt82c686b_init_ports(PCIIDEState *d) {
-int i;
-struct {
+static const struct {
int iobase;
int iobase2;
int isairq;
@@ -155,10 +154,12 @@ static void vt82c686b_init_ports(PCIIDEState *d) {
{0x1f0, 0x3f6, 14},
{0x170, 0x376, 15},
};
+int i;
Re: [Qemu-devel] [PATCH 0/1] [PULL] qemu-kvm.git uq/master queue
On 10/10/2011 04:55 PM, Anthony Liguori wrote: Hrm, sorry about that. In the future, it would be helpful to explicitly withdrawal a PULL request. Do you want me to revert? We'll send the revert together with the new patch. FWIW, I think bumping the version is the right thing to do. Why? -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH 1/1] kvm: support TSC deadline MSR
On 10/10/2011 09:58 AM, Avi Kivity wrote: On 10/10/2011 04:54 PM, Anthony Liguori wrote: On 10/04/2011 05:20 PM, Marcelo Tosatti wrote: On Tue, Oct 04, 2011 at 07:53:42PM +0200, Avi Kivity wrote: On 10/03/2011 10:55 PM, Marcelo Tosatti wrote: From: "Liu, Jinsong" KVM add emulation of lapic tsc deadline timer for guest. This patch is co-operation work at qemu side. -#define CPU_SAVE_VERSION 12 +#define CPU_SAVE_VERSION 13 Unfortunate. Can't we use subsections? Yes, i'll look into it tomorrow. Subsections are still broken at the moment although Juan has some patches. Bumping the version is the safe thing to do. It's irreversible, once we release a version with a bumped ID we can't go back. But the question is whether we've bumped *any* versions of common devices since 0.15 because if so, it's moot here. Once any device bumps a version id, migration is incompatible. Subsections are nice for stable branches, but they don't solve inter-version compatibility. Most importantly, subsections are broken today so until we straighten things out there, we can't rely on them. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH 0/1] [PULL] qemu-kvm.git uq/master queue
On 10/10/2011 10:00 AM, Avi Kivity wrote: On 10/10/2011 04:55 PM, Anthony Liguori wrote: Hrm, sorry about that. In the future, it would be helpful to explicitly withdrawal a PULL request. Do you want me to revert? We'll send the revert together with the new patch. FWIW, I think bumping the version is the right thing to do. Why? Because we still haven't fixed subsections. Juan's patches help but they can still result in sending bad data to and older QEMU that won't handle it properly. We need to figure out a proper fix for subsections, either Paolo's protocol change or moving subsections out to a detected section. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH 0/1] [PULL] qemu-kvm.git uq/master queue
On 10/10/2011 05:12 PM, Anthony Liguori wrote: On 10/10/2011 10:00 AM, Avi Kivity wrote: On 10/10/2011 04:55 PM, Anthony Liguori wrote: Hrm, sorry about that. In the future, it would be helpful to explicitly withdrawal a PULL request. Do you want me to revert? We'll send the revert together with the new patch. FWIW, I think bumping the version is the right thing to do. Why? Because we still haven't fixed subsections. Juan's patches help but they can still result in sending bad data to and older QEMU that won't handle it properly. We need to figure out a proper fix for subsections, either Paolo's protocol change or moving subsections out to a detected section. Ok. So bumping the version is only right if we don't fix subsections. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH 1/1] kvm: support TSC deadline MSR
On 10/10/2011 05:10 PM, Anthony Liguori wrote: It's irreversible, once we release a version with a bumped ID we can't go back. But the question is whether we've bumped *any* versions of common devices since 0.15 because if so, it's moot here. What's the answer? And if the answer is we did, why did we? Once any device bumps a version id, migration is incompatible. Subsections are nice for stable branches, but they don't solve inter-version compatibility. Why not? Though I agree it's a long shot to get it to work, since there are so many changes and it's easy to get any one of them wrong. You had an idea once to fingerprint the migration format and compare it across versions? I assume the almighty visitor can make this very simple? Most importantly, subsections are broken today so until we straighten things out there, we can't rely on them. Let's not throw a permanent baby out with the temporary bath water. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] buildbot failure in qemu on default_openbsd_4.9
Hi Gerd, Hi Kevin, On Monday, October 10, 2011 04:23:28 PM Gerd Hoffmann wrote: > > Gerd, Brad, does one of your buildbots have some resources left to build > > the block branch on OpenBSD (and for Gerd, possibly mingw) as well? > > No problem, can be added to both openbsd and mingw. Gerd, just added your hosts to the block branch factory: * block_mingw32 * block_openbsd_4.9 Kevin, Brads openbsd current host is already testing your block branch. Best Regards, Daniel -- Daniel Gollub Linux Consultant & Developer Tel.: +49-160 47 73 970 Mail: gol...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 signature.asc Description: This is a digitally signed message part.
Re: [Qemu-devel] [PATCH 0/1] [PULL] qemu-kvm.git uq/master queue
On 10/10/2011 10:24 AM, Avi Kivity wrote: On 10/10/2011 05:12 PM, Anthony Liguori wrote: On 10/10/2011 10:00 AM, Avi Kivity wrote: On 10/10/2011 04:55 PM, Anthony Liguori wrote: Hrm, sorry about that. In the future, it would be helpful to explicitly withdrawal a PULL request. Do you want me to revert? We'll send the revert together with the new patch. FWIW, I think bumping the version is the right thing to do. Why? Because we still haven't fixed subsections. Juan's patches help but they can still result in sending bad data to and older QEMU that won't handle it properly. We need to figure out a proper fix for subsections, either Paolo's protocol change or moving subsections out to a detected section. Ok. So bumping the version is only right if we don't fix subsections. If we bump *any* version from 0.15 -> 1.0, then there's no point at all in having a subsection. If we break compatibility by using Paolo's new protocol, or doing subsections as sections, then there's no point in making it a subsection either. Regards, Anthony Liguori
[Qemu-devel] [PATCH 24/24] isa: Remove isa_init_ioport_range and isa_init_ioport
From: Richard Henderson
All users have been converted to either isa_register_ioport
or isa_register_old_portio_list.
Signed-off-by: Richard Henderson
Signed-off-by: Avi Kivity
---
hw/isa-bus.c | 19 +--
hw/isa.h |2 --
2 files changed, 5 insertions(+), 16 deletions(-)
diff --git a/hw/isa-bus.c b/hw/isa-bus.c
index 5d8ff84..7c2c261 100644
--- a/hw/isa-bus.c
+++ b/hw/isa-bus.c
@@ -83,24 +83,17 @@ void isa_init_irq(ISADevice *dev, qemu_irq *p, int isairq)
dev->nirqs++;
}
-void isa_init_ioport_range(ISADevice *dev, uint16_t start, uint16_t length)
+static inline void isa_init_ioport(ISADevice *dev, uint16_t ioport)
{
-if (dev->ioport_id == 0 || start < dev->ioport_id) {
-dev->ioport_id = start;
+if (dev && (dev->ioport_id == 0 || ioport < dev->ioport_id)) {
+dev->ioport_id = ioport;
}
}
-void isa_init_ioport(ISADevice *dev, uint16_t ioport)
-{
-isa_init_ioport_range(dev, ioport, 1);
-}
-
void isa_register_ioport(ISADevice *dev, MemoryRegion *io, uint16_t start)
{
memory_region_add_subregion(isabus->address_space_io, start, io);
-if (dev != NULL) {
-isa_init_ioport(dev, start);
-}
+isa_init_ioport(dev, start);
}
void isa_register_portio_list(ISADevice *dev, uint16_t start,
@@ -112,9 +105,7 @@ void isa_register_portio_list(ISADevice *dev, uint16_t
start,
/* START is how we should treat DEV, regardless of the actual
contents of the portio array. This is how the old code
actually handled e.g. the FDC device. */
-if (dev) {
-isa_init_ioport(dev, start);
-}
+isa_init_ioport(dev, start);
portio_list_init(piolist, pio_start, opaque, name);
portio_list_add(piolist, isabus->address_space_io, start);
diff --git a/hw/isa.h b/hw/isa.h
index 177ef95..d3cae35 100644
--- a/hw/isa.h
+++ b/hw/isa.h
@@ -28,8 +28,6 @@ ISABus *isa_bus_new(DeviceState *dev, MemoryRegion
*address_space_io);
void isa_bus_irqs(qemu_irq *irqs);
qemu_irq isa_get_irq(int isairq);
void isa_init_irq(ISADevice *dev, qemu_irq *p, int isairq);
-void isa_init_ioport(ISADevice *dev, uint16_t ioport);
-void isa_init_ioport_range(ISADevice *dev, uint16_t start, uint16_t length);
void isa_qdev_register(ISADeviceInfo *info);
MemoryRegion *isa_address_space(ISADevice *dev);
ISADevice *isa_create(const char *name);
--
1.7.6.3
Re: [Qemu-devel] [PATCH 0/1] [PULL] qemu-kvm.git uq/master queue
On 10/10/2011 05:36 PM, Anthony Liguori wrote: Ok. So bumping the version is only right if we don't fix subsections. If we bump *any* version from 0.15 -> 1.0, then there's no point at all in having a subsection. Did we bump versions of relevant devices? If we break compatibility by using Paolo's new protocol, or doing subsections as sections, then there's no point in making it a subsection either. These are workaroundable. For example if you migrate 0.15 to 1.0 you start the destination with -old-subsection-format. Even if you don't, since subsections are rarely present, migration will succeed. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH 02/24] palm: convert to memory API
Signed-off-by: Avi Kivity
---
hw/palm.c | 53 +
1 files changed, 25 insertions(+), 28 deletions(-)
diff --git a/hw/palm.c b/hw/palm.c
index d8f50e3..094bfde 100644
--- a/hw/palm.c
+++ b/hw/palm.c
@@ -54,16 +54,12 @@ static void static_write(void *opaque, target_phys_addr_t
offset,
#endif
}
-static CPUReadMemoryFunc * const static_readfn[] = {
-static_readb,
-static_readh,
-static_readw,
-};
-
-static CPUWriteMemoryFunc * const static_writefn[] = {
-static_write,
-static_write,
-static_write,
+static const MemoryRegionOps static_ops = {
+.old_mmio = {
+.read = { static_readb, static_readh, static_readw, },
+.write = { static_write, static_write, static_write, },
+},
+.endianness = DEVICE_NATIVE_ENDIAN,
};
/* Palm Tunsgten|E support */
@@ -203,34 +199,35 @@ static void palmte_init(ram_addr_t ram_size,
struct omap_mpu_state_s *cpu;
int flash_size = 0x0080;
int sdram_size = palmte_binfo.ram_size;
-int io;
static uint32_t cs0val = 0x;
static uint32_t cs1val = 0xe1a0;
static uint32_t cs2val = 0xe1a0;
static uint32_t cs3val = 0xe1a0e1a0;
int rom_size, rom_loaded = 0;
DisplayState *ds = get_displaystate();
+MemoryRegion *flash = g_new(MemoryRegion, 1);
+MemoryRegion *cs = g_new(MemoryRegion, 4);
cpu = omap310_mpu_init(address_space_mem, sdram_size, cpu_model);
/* External Flash (EMIFS) */
-cpu_register_physical_memory(OMAP_CS0_BASE, flash_size,
- qemu_ram_alloc(NULL, "palmte.flash",
-flash_size) | IO_MEM_ROM);
-
-io = cpu_register_io_memory(static_readfn, static_writefn, &cs0val,
-DEVICE_NATIVE_ENDIAN);
-cpu_register_physical_memory(OMAP_CS0_BASE + flash_size,
-OMAP_CS0_SIZE - flash_size, io);
-io = cpu_register_io_memory(static_readfn, static_writefn, &cs1val,
-DEVICE_NATIVE_ENDIAN);
-cpu_register_physical_memory(OMAP_CS1_BASE, OMAP_CS1_SIZE, io);
-io = cpu_register_io_memory(static_readfn, static_writefn, &cs2val,
-DEVICE_NATIVE_ENDIAN);
-cpu_register_physical_memory(OMAP_CS2_BASE, OMAP_CS2_SIZE, io);
-io = cpu_register_io_memory(static_readfn, static_writefn, &cs3val,
-DEVICE_NATIVE_ENDIAN);
-cpu_register_physical_memory(OMAP_CS3_BASE, OMAP_CS3_SIZE, io);
+memory_region_init_ram(flash, NULL, "palmte.flash", flash_size);
+memory_region_set_readonly(flash, true);
+memory_region_add_subregion(address_space_mem, OMAP_CS0_BASE, flash);
+
+memory_region_init_io(&cs[0], &static_ops, &cs0val, "palmte-cs0",
+ OMAP_CS0_SIZE - flash_size);
+memory_region_add_subregion(address_space_mem, OMAP_CS0_BASE + flash_size,
+&cs[0]);
+memory_region_init_io(&cs[1], &static_ops, &cs1val, "palmte-cs1",
+ OMAP_CS1_SIZE);
+memory_region_add_subregion(address_space_mem, OMAP_CS1_BASE, &cs[1]);
+memory_region_init_io(&cs[2], &static_ops, &cs2val, "palmte-cs2",
+ OMAP_CS2_SIZE);
+memory_region_add_subregion(address_space_mem, OMAP_CS2_BASE, &cs[2]);
+memory_region_init_io(&cs[3], &static_ops, &cs3val, "palmte-cs3",
+ OMAP_CS3_SIZE);
+memory_region_add_subregion(address_space_mem, OMAP_CS3_BASE, &cs[3]);
palmte_microwire_setup(cpu);
--
1.7.6.3
[Qemu-devel] [PATCH 11/24] memory: Fix old portio word accesses
From: Jan Kiszka
As we register old portio regions via ioport_register, we are also
responsible for providing the word access wrapper.
Signed-off-by: Jan Kiszka
Signed-off-by: Avi Kivity
---
memory.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/memory.c b/memory.c
index 27abd3e..dc5e35d 100644
--- a/memory.c
+++ b/memory.c
@@ -404,6 +404,11 @@ static void memory_region_iorange_read(IORange *iorange,
*data = ((uint64_t)1 << (width * 8)) - 1;
if (mrp) {
*data = mrp->read(mr->opaque, offset + mr->offset);
+} else if (width == 2) {
+mrp = find_portio(mr, offset, 1, false);
+assert(mrp);
+*data = mrp->read(mr->opaque, offset + mr->offset) |
+(mrp->read(mr->opaque, offset + mr->offset + 1) << 8);
}
return;
}
@@ -426,6 +431,11 @@ static void memory_region_iorange_write(IORange *iorange,
if (mrp) {
mrp->write(mr->opaque, offset + mr->offset, data);
+} else if (width == 2) {
+mrp = find_portio(mr, offset, 1, false);
+assert(mrp);
+mrp->write(mr->opaque, offset + mr->offset, data & 0xff);
+mrp->write(mr->opaque, offset + mr->offset + 1, data >> 8);
}
return;
}
--
1.7.6.3
[Qemu-devel] [PATCH 05/24] ppc405_boards: convert to memory API
Signed-off-by: Avi Kivity
---
hw/ppc405_boards.c | 85 ++-
1 files changed, 37 insertions(+), 48 deletions(-)
diff --git a/hw/ppc405_boards.c b/hw/ppc405_boards.c
index 9136288..672e934 100644
--- a/hw/ppc405_boards.c
+++ b/hw/ppc405_boards.c
@@ -137,16 +137,16 @@ static void ref405ep_fpga_writel (void *opaque,
ref405ep_fpga_writeb(opaque, addr + 3, value & 0xFF);
}
-static CPUReadMemoryFunc * const ref405ep_fpga_read[] = {
-&ref405ep_fpga_readb,
-&ref405ep_fpga_readw,
-&ref405ep_fpga_readl,
-};
-
-static CPUWriteMemoryFunc * const ref405ep_fpga_write[] = {
-&ref405ep_fpga_writeb,
-&ref405ep_fpga_writew,
-&ref405ep_fpga_writel,
+static const MemoryRegionOps ref405ep_fpga_ops = {
+.old_mmio = {
+.read = {
+ref405ep_fpga_readb, ref405ep_fpga_readw, ref405ep_fpga_readl,
+},
+.write = {
+ref405ep_fpga_writeb, ref405ep_fpga_writew, ref405ep_fpga_writel,
+},
+},
+.endianness = DEVICE_NATIVE_ENDIAN,
};
static void ref405ep_fpga_reset (void *opaque)
@@ -158,16 +158,15 @@ static void ref405ep_fpga_reset (void *opaque)
fpga->reg1 = 0x0F;
}
-static void ref405ep_fpga_init (uint32_t base)
+static void ref405ep_fpga_init (MemoryRegion *sysmem, uint32_t base)
{
ref405ep_fpga_t *fpga;
-int fpga_memory;
+MemoryRegion *fpga_memory = g_new(MemoryRegion, 1);
fpga = g_malloc0(sizeof(ref405ep_fpga_t));
-fpga_memory = cpu_register_io_memory(ref405ep_fpga_read,
- ref405ep_fpga_write, fpga,
- DEVICE_NATIVE_ENDIAN);
-cpu_register_physical_memory(base, 0x0100, fpga_memory);
+memory_region_init_io(fpga_memory, &ref405ep_fpga_ops, fpga,
+ "fpga", 0x0100);
+memory_region_add_subregion(sysmem, base, fpga_memory);
qemu_register_reset(&ref405ep_fpga_reset, fpga);
}
@@ -183,7 +182,8 @@ static void ref405ep_init (ram_addr_t ram_size,
CPUPPCState *env;
qemu_irq *pic;
MemoryRegion *bios;
-ram_addr_t sram_offset, bdloc;
+MemoryRegion *sram = g_new(MemoryRegion, 1);
+ram_addr_t bdloc;
MemoryRegion *ram_memories = g_malloc(2 * sizeof(*ram_memories));
target_phys_addr_t ram_bases[2], ram_sizes[2];
target_ulong sram_size;
@@ -195,6 +195,7 @@ static void ref405ep_init (ram_addr_t ram_size,
int linux_boot;
int fl_idx, fl_sectors, len;
DriveInfo *dinfo;
+MemoryRegion *sysmem = get_system_memory();
/* XXX: fix this */
memory_region_init_ram(&ram_memories[0], NULL, "ef405ep.ram", 0x0800);
@@ -207,17 +208,12 @@ static void ref405ep_init (ram_addr_t ram_size,
#ifdef DEBUG_BOARD_INIT
printf("%s: register cpu\n", __func__);
#endif
-env = ppc405ep_init(get_system_memory(), ram_memories, ram_bases,
ram_sizes,
+env = ppc405ep_init(sysmem, ram_memories, ram_bases, ram_sizes,
, &pic, kernel_filename == NULL ? 0 : 1);
/* allocate SRAM */
sram_size = 512 * 1024;
-sram_offset = qemu_ram_alloc(NULL, "ef405ep.sram", sram_size);
-#ifdef DEBUG_BOARD_INIT
-printf("%s: register SRAM at offset " RAM_ADDR_FMT "\n",
- __func__, sram_offset);
-#endif
-cpu_register_physical_memory(0xFFF0, sram_size,
- sram_offset | IO_MEM_RAM);
+memory_region_init_ram(sram, NULL, "ef405ep.sram", sram_size);
+memory_region_add_subregion(sysmem, 0xFFF0, sram);
/* allocate and load BIOS */
#ifdef DEBUG_BOARD_INIT
printf("%s: register BIOS\n", __func__);
@@ -264,14 +260,13 @@ static void ref405ep_init (ram_addr_t ram_size,
}
bios_size = (bios_size + 0xfff) & ~0xfff;
memory_region_set_readonly(bios, true);
-memory_region_add_subregion(get_system_memory(),
-(uint32_t)(-bios_size), bios);
+memory_region_add_subregion(sysmem, (uint32_t)(-bios_size), bios);
}
/* Register FPGA */
#ifdef DEBUG_BOARD_INIT
printf("%s: register FPGA\n", __func__);
#endif
-ref405ep_fpga_init(0xF030);
+ref405ep_fpga_init(sysmem, 0xF030);
/* Register NVRAM */
#ifdef DEBUG_BOARD_INIT
printf("%s: register NVRAM\n", __func__);
@@ -469,16 +464,12 @@ static void taihu_cpld_writel (void *opaque,
taihu_cpld_writeb(opaque, addr + 3, value & 0xFF);
}
-static CPUReadMemoryFunc * const taihu_cpld_read[] = {
-&taihu_cpld_readb,
-&taihu_cpld_readw,
-&taihu_cpld_readl,
-};
-
-static CPUWriteMemoryFunc * const taihu_cpld_write[] = {
-&taihu_cpld_writeb,
-&taihu_cpld_writew,
-&taihu_cpld_writel,
+static const MemoryRegionOps taihu_cpld_ops = {
+.old_mmio = {
+.read = { taihu_cpld_readb, taihu_cpld_readw, taihu_cpld_readl, },
+.write = { taihu_cpld_writeb, taihu_cpld_writew, taihu_cpld_writel, },
+},
+.endianness = DEVICE_NATIVE_EN
[Qemu-devel] [PATCH 20/24] vga: Convert to isa_register_portio_list
From: Richard Henderson
[jan: fix cut'n'paste errors]
[avi: adjust pci variants not to use isa functions]
Signed-off-by: Richard Henderson
Signed-off-by: Jan Kiszka
Signed-off-by: Avi Kivity
---
hw/qxl.c|2 +-
hw/vga-isa.c| 17
hw/vga-pci.c|2 +-
hw/vga.c| 73 +++---
hw/vga_int.h|7 -
hw/vmware_vga.c |7 +++--
6 files changed, 59 insertions(+), 49 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index 6db2f1a..03848ed 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1601,7 +1601,7 @@ static int qxl_init_primary(PCIDevice *dev)
ram_size = 32 * 1024 * 1024;
}
vga_common_init(vga, ram_size);
-vga_init(vga, pci_address_space(dev));
+vga_init(vga, pci_address_space(dev), pci_address_space_io(dev), false);
register_ioport_write(0x3c0, 16, 1, qxl_vga_ioport_write, vga);
register_ioport_write(0x3b4, 2, 1, qxl_vga_ioport_write, vga);
register_ioport_write(0x3d4, 2, 1, qxl_vga_ioport_write, vga);
diff --git a/hw/vga-isa.c b/hw/vga-isa.c
index 6b5c8ed..4825313 100644
--- a/hw/vga-isa.c
+++ b/hw/vga-isa.c
@@ -47,24 +47,19 @@ static int vga_initfn(ISADevice *dev)
ISAVGAState *d = DO_UPCAST(ISAVGAState, dev, dev);
VGACommonState *s = &d->state;
MemoryRegion *vga_io_memory;
+const MemoryRegionPortio *vga_ports, *vbe_ports;
vga_common_init(s, VGA_RAM_SIZE);
s->legacy_address_space = isa_address_space(dev);
-vga_io_memory = vga_init_io(s);
+vga_io_memory = vga_init_io(s, &vga_ports, &vbe_ports);
+isa_register_portio_list(dev, 0x3b0, vga_ports, s, "vga");
+if (vbe_ports) {
+isa_register_portio_list(dev, 0x1ce, vbe_ports, s, "vbe");
+}
memory_region_add_subregion_overlap(isa_address_space(dev),
isa_mem_base + 0x000a,
vga_io_memory, 1);
memory_region_set_coalescing(vga_io_memory);
-isa_init_ioport(dev, 0x3c0);
-isa_init_ioport(dev, 0x3b4);
-isa_init_ioport(dev, 0x3ba);
-isa_init_ioport(dev, 0x3da);
-isa_init_ioport(dev, 0x3c0);
-#ifdef CONFIG_BOCHS_VBE
-isa_init_ioport(dev, 0x1ce);
-isa_init_ioport(dev, 0x1cf);
-isa_init_ioport(dev, 0x1d0);
-#endif /* CONFIG_BOCHS_VBE */
s->ds = graphic_console_init(s->update, s->invalidate,
s->screen_dump, s->text_update, s);
diff --git a/hw/vga-pci.c b/hw/vga-pci.c
index 3c8bcb0..14bfadb 100644
--- a/hw/vga-pci.c
+++ b/hw/vga-pci.c
@@ -54,7 +54,7 @@ static int pci_vga_initfn(PCIDevice *dev)
// vga + console init
vga_common_init(s, VGA_RAM_SIZE);
- vga_init(s, pci_address_space(dev));
+ vga_init(s, pci_address_space(dev), pci_address_space_io(dev), true);
s->ds = graphic_console_init(s->update, s->invalidate,
s->screen_dump, s->text_update, s);
diff --git a/hw/vga.c b/hw/vga.c
index f9a6014..5beaa99 100644
--- a/hw/vga.c
+++ b/hw/vga.c
@@ -2241,40 +2241,39 @@ void vga_common_init(VGACommonState *s, int
vga_ram_size)
vga_dirty_log_start(s);
}
-/* used by both ISA and PCI */
-MemoryRegion *vga_init_io(VGACommonState *s)
-{
-MemoryRegion *vga_mem;
-
-register_ioport_write(0x3c0, 16, 1, vga_ioport_write, s);
-
-register_ioport_write(0x3b4, 2, 1, vga_ioport_write, s);
-register_ioport_write(0x3d4, 2, 1, vga_ioport_write, s);
-register_ioport_write(0x3ba, 1, 1, vga_ioport_write, s);
-register_ioport_write(0x3da, 1, 1, vga_ioport_write, s);
-
-register_ioport_read(0x3c0, 16, 1, vga_ioport_read, s);
-
-register_ioport_read(0x3b4, 2, 1, vga_ioport_read, s);
-register_ioport_read(0x3d4, 2, 1, vga_ioport_read, s);
-register_ioport_read(0x3ba, 1, 1, vga_ioport_read, s);
-register_ioport_read(0x3da, 1, 1, vga_ioport_read, s);
+static const MemoryRegionPortio vga_portio_list[] = {
+{ 0x04, 2, 1, .read = vga_ioport_read, .write = vga_ioport_write }, /*
3b4 */
+{ 0x0a, 1, 1, .read = vga_ioport_read, .write = vga_ioport_write }, /*
3ba */
+{ 0x10, 16, 1, .read = vga_ioport_read, .write = vga_ioport_write }, /*
3c0 */
+{ 0x24, 2, 1, .read = vga_ioport_read, .write = vga_ioport_write }, /*
3d4 */
+{ 0x2a, 1, 1, .read = vga_ioport_read, .write = vga_ioport_write }, /*
3da */
+PORTIO_END_OF_LIST(),
+};
#ifdef CONFIG_BOCHS_VBE
-#if defined (TARGET_I386)
-register_ioport_read(0x1ce, 1, 2, vbe_ioport_read_index, s);
-register_ioport_read(0x1cf, 1, 2, vbe_ioport_read_data, s);
+static const MemoryRegionPortio vbe_portio_list[] = {
+{ 0, 1, 2, .read = vbe_ioport_read_index, .write = vbe_ioport_write_index
},
+# ifdef TARGET_I386
+{ 1, 1, 2, .read = vbe_ioport_read_data, .write = vbe_ioport_write_data },
+# else
+{ 2, 1, 2, .read = vbe_ioport_read_data, .write = vbe_ioport_write_data },
+# endif
+PORTIO_END_OF_LIST(),
+};
+#endif /* CONFIG_BOCHS_VBE */
-register
[Qemu-devel] [PATCH 07/24] hw/versatile_pci: Expose multiple sysbus mmio regions
From: Peter Maydell
Clean up versatile_pci to expose the various PCI mmio regions
properly as separate mmio regions rather than as a single mmio
which uses callbacks to map and unmap everything.
Signed-off-by: Peter Maydell
Signed-off-by: Avi Kivity
---
hw/realview.c | 12 ++--
hw/versatile_pci.c | 42 --
hw/versatilepb.c | 12 ++--
3 files changed, 28 insertions(+), 38 deletions(-)
diff --git a/hw/realview.c b/hw/realview.c
index 549bb15..11ffb8a 100644
--- a/hw/realview.c
+++ b/hw/realview.c
@@ -272,8 +272,16 @@ static void realview_init(ram_addr_t ram_size,
sysbus_create_simple("pl031", 0x10017000, pic[10]);
if (!is_pb) {
-dev = sysbus_create_varargs("realview_pci", 0x6000,
-pic[48], pic[49], pic[50], pic[51], NULL);
+dev = qdev_create(NULL, "realview_pci");
+busdev = sysbus_from_qdev(dev);
+qdev_init_nofail(dev);
+sysbus_mmio_map(busdev, 0, 0x6100); /* PCI self-config */
+sysbus_mmio_map(busdev, 1, 0x6200); /* PCI config */
+sysbus_mmio_map(busdev, 2, 0x6300); /* PCI I/O */
+sysbus_connect_irq(busdev, 0, pic[48]);
+sysbus_connect_irq(busdev, 1, pic[49]);
+sysbus_connect_irq(busdev, 2, pic[50]);
+sysbus_connect_irq(busdev, 3, pic[51]);
pci_bus = (PCIBus *)qdev_get_child_bus(dev, "pci");
if (usb_enabled) {
usb_ohci_init_pci(pci_bus, -1);
diff --git a/hw/versatile_pci.c b/hw/versatile_pci.c
index 98e56f1..8a88696 100644
--- a/hw/versatile_pci.c
+++ b/hw/versatile_pci.c
@@ -58,38 +58,6 @@ static void pci_vpb_set_irq(void *opaque, int irq_num, int
level)
qemu_set_irq(pic[irq_num], level);
}
-
-static void pci_vpb_map(SysBusDevice *dev, target_phys_addr_t base)
-{
-PCIVPBState *s = (PCIVPBState *)dev;
-/* Selfconfig area. */
-memory_region_add_subregion(get_system_memory(), base + 0x0100,
-&s->mem_config);
-/* Normal config area. */
-memory_region_add_subregion(get_system_memory(), base + 0x0200,
-&s->mem_config2);
-
-if (s->realview) {
-/* IO memory area. */
-memory_region_add_subregion(get_system_memory(), base + 0x0300,
-&s->isa);
-}
-}
-
-static void pci_vpb_unmap(SysBusDevice *dev, target_phys_addr_t base)
-{
-PCIVPBState *s = (PCIVPBState *)dev;
-/* Selfconfig area. */
-memory_region_del_subregion(get_system_memory(), &s->mem_config);
-/* Normal config area. */
-memory_region_del_subregion(get_system_memory(), &s->mem_config2);
-
-if (s->realview) {
-/* IO memory area. */
-memory_region_del_subregion(get_system_memory(), &s->isa);
-}
-}
-
static int pci_vpb_init(SysBusDevice *dev)
{
PCIVPBState *s = FROM_SYSBUS(PCIVPBState, dev);
@@ -106,16 +74,22 @@ static int pci_vpb_init(SysBusDevice *dev)
/* ??? Register memory space. */
+/* Our memory regions are:
+ * 0 : PCI self config window
+ * 1 : PCI config window
+ * 2 : PCI IO window (realview_pci only)
+ */
memory_region_init_io(&s->mem_config, &pci_vpb_config_ops, bus,
"pci-vpb-selfconfig", 0x100);
+sysbus_init_mmio_region(dev, &s->mem_config);
memory_region_init_io(&s->mem_config2, &pci_vpb_config_ops, bus,
"pci-vpb-config", 0x100);
+sysbus_init_mmio_region(dev, &s->mem_config2);
if (s->realview) {
isa_mmio_setup(&s->isa, 0x010);
+sysbus_init_mmio_region(dev, &s->isa);
}
-sysbus_init_mmio_cb2(dev, pci_vpb_map, pci_vpb_unmap);
-
pci_create_simple(bus, -1, "versatile_pci_host");
return 0;
}
diff --git a/hw/versatilepb.c b/hw/versatilepb.c
index 49f8f5f..68402cc 100644
--- a/hw/versatilepb.c
+++ b/hw/versatilepb.c
@@ -181,6 +181,7 @@ static void versatile_init(ram_addr_t ram_size,
qemu_irq pic[32];
qemu_irq sic[32];
DeviceState *dev, *sysctl;
+SysBusDevice *busdev;
PCIBus *pci_bus;
NICInfo *nd;
int n;
@@ -219,8 +220,15 @@ static void versatile_init(ram_addr_t ram_size,
sysbus_create_simple("pl050_keyboard", 0x10006000, sic[3]);
sysbus_create_simple("pl050_mouse", 0x10007000, sic[4]);
-dev = sysbus_create_varargs("versatile_pci", 0x4000,
-sic[27], sic[28], sic[29], sic[30], NULL);
+dev = qdev_create(NULL, "versatile_pci");
+busdev = sysbus_from_qdev(dev);
+qdev_init_nofail(dev);
+sysbus_mmio_map(busdev, 0, 0x4100); /* PCI self-config */
+sysbus_mmio_map(busdev, 1, 0x4200); /* PCI config */
+sysbus_connect_irq(busdev, 0, sic[27]);
+sysbus_connect_irq(busdev, 1, sic[28]);
+sysbus_connect_irq(busdev, 2, sic[29]);
+sysbus_connect_irq(busdev, 3, sic[30]);
pci_bus = (PCIBus *)qdev_get_child_bus(dev, "pci
[Qemu-devel] [PATCH 19/24] sb16: Convert to isa_register_portio_list
From: Richard Henderson
Signed-off-by: Richard Henderson
Signed-off-by: Avi Kivity
---
hw/sb16.c | 32 +---
1 files changed, 13 insertions(+), 19 deletions(-)
diff --git a/hw/sb16.c b/hw/sb16.c
index aca52e0..f0658ac 100644
--- a/hw/sb16.c
+++ b/hw/sb16.c
@@ -1341,12 +1341,21 @@ static int sb16_post_load (void *opaque, int version_id)
}
};
+static const MemoryRegionPortio sb16_ioport_list[] = {
+{ 4, 1, 1, .write = mixer_write_indexb },
+{ 4, 1, 2, .write = mixer_write_indexw },
+{ 5, 1, 1, .read = mixer_read, .write = mixer_write_datab },
+{ 6, 1, 1, .read = dsp_read, .write = dsp_write },
+{ 10, 1, 1, .read = dsp_read },
+{ 12, 1, 1, .write = dsp_write },
+{ 12, 4, 1, .read = dsp_read },
+PORTIO_END_OF_LIST(),
+};
+
+
static int sb16_initfn (ISADevice *dev)
{
-static const uint8_t dsp_write_ports[] = {0x6, 0xc};
-static const uint8_t dsp_read_ports[] = {0x6, 0xa, 0xc, 0xd, 0xe, 0xf};
SB16State *s;
-int i;
s = DO_UPCAST (SB16State, dev, dev);
@@ -1366,22 +1375,7 @@ static int sb16_initfn (ISADevice *dev)
dolog ("warning: Could not create auxiliary timer\n");
}
-for (i = 0; i < ARRAY_SIZE (dsp_write_ports); i++) {
-register_ioport_write (s->port + dsp_write_ports[i], 1, 1, dsp_write,
s);
-isa_init_ioport (dev, s->port + dsp_write_ports[i]);
-}
-
-for (i = 0; i < ARRAY_SIZE (dsp_read_ports); i++) {
-register_ioport_read (s->port + dsp_read_ports[i], 1, 1, dsp_read, s);
-isa_init_ioport (dev, s->port + dsp_read_ports[i]);
-}
-
-register_ioport_write (s->port + 0x4, 1, 1, mixer_write_indexb, s);
-register_ioport_write (s->port + 0x4, 1, 2, mixer_write_indexw, s);
-isa_init_ioport (dev, s->port + 0x4);
-register_ioport_read (s->port + 0x5, 1, 1, mixer_read, s);
-register_ioport_write (s->port + 0x5, 1, 1, mixer_write_datab, s);
-isa_init_ioport (dev, s->port + 0x5);
+isa_register_portio_list (dev, s->port, sb16_ioport_list, s, "sb16");
DMA_register_channel (s->hdma, SB_read_DMA, s);
DMA_register_channel (s->dma, SB_read_DMA, s);
--
1.7.6.3
[Qemu-devel] [PULL 00/24] Memory API, batch 11
Please pull from: git://github.com/avikivity memory/batch This has been on the list for a bit, with no comments so far. Avi Kivity (7): palm: convert to memory API petalogix_ml605: convert to memory API petalogix_s2adsp1800: convert to memory API ppc405_boards: convert to memory API ppc_newworld: convert to memory API Introduce PortioList isa: Add isa_register_portio_list() Jan Kiszka (1): memory: Fix old portio word accesses Peter Maydell (3): hw/lan9118.c: Convert to MemoryRegion hw/arm11mpcore: Clean up to avoid using sysbus_mmio_init_cb2 hw/versatile_pci: Expose multiple sysbus mmio regions Richard Henderson (13): isa: Tidy support code for isabus_get_fw_dev_path fdc: Convert to isa_register_portio_list gus: Convert to isa_register_portio_list m48t59: Convert to isa_register_ioport rtc: Convert to isa_register_ioport ne2000: Convert to isa_register_ioport parallel: Convert to isa_register_portio_list sb16: Convert to isa_register_portio_list vga: Convert to isa_register_portio_list pc: Convert port92 to isa_register_ioport vmport: Convert to isa_register_ioport ide: Convert to isa_register_portio_list isa: Remove isa_init_ioport_range and isa_init_ioport Makefile.objs |2 +- Makefile.target |2 +- hw/arm11mpcore.c | 13 +- hw/fdc.c | 34 ++--- hw/gus.c | 38 +++--- hw/ide/core.c | 30 +++ hw/ide/internal.h |3 +- hw/ide/isa.c |4 +- hw/ide/piix.c |7 ++- hw/ide/via.c |7 ++- hw/isa-bus.c | 45 +++-- hw/isa.h | 38 --- hw/lan9118.c | 29 --- hw/m48t59.c | 15 +- hw/mc146818rtc.c | 15 +- hw/ne2000-isa.c |5 +-- hw/palm.c | 53 +--- hw/parallel.c | 47 +++--- hw/pc.c | 16 +- hw/petalogix_ml605_mmu.c | 15 +++--- hw/petalogix_s3adsp1800_mmu.c | 18 --- hw/ppc405_boards.c| 85 ++-- hw/ppc_newworld.c | 39 ++ hw/qxl.c |2 +- hw/realview.c | 12 - hw/sb16.c | 32 +--- hw/versatile_pci.c| 42 +++- hw/versatilepb.c | 12 - hw/vga-isa.c | 17 ++ hw/vga-pci.c |2 +- hw/vga.c | 73 hw/vga_int.h |7 ++- hw/vmport.c | 16 +- hw/vmware_vga.c |7 ++- ioport.c | 108 + ioport.h | 21 memory.c | 18 +-- 37 files changed, 535 insertions(+), 394 deletions(-) -- 1.7.6.3
[Qemu-devel] [PATCH 12/24] isa: Add isa_register_portio_list()
Signed-off-by: Richard Henderson
Signed-off-by: Avi Kivity
---
hw/isa-bus.c | 17 +
hw/isa.h | 31 ++-
2 files changed, 47 insertions(+), 1 deletions(-)
diff --git a/hw/isa-bus.c b/hw/isa-bus.c
index e9c1712..5d8ff84 100644
--- a/hw/isa-bus.c
+++ b/hw/isa-bus.c
@@ -103,6 +103,23 @@ void isa_register_ioport(ISADevice *dev, MemoryRegion *io,
uint16_t start)
}
}
+void isa_register_portio_list(ISADevice *dev, uint16_t start,
+ const MemoryRegionPortio *pio_start,
+ void *opaque, const char *name)
+{
+PortioList *piolist = g_new(PortioList, 1);
+
+/* START is how we should treat DEV, regardless of the actual
+ contents of the portio array. This is how the old code
+ actually handled e.g. the FDC device. */
+if (dev) {
+isa_init_ioport(dev, start);
+}
+
+portio_list_init(piolist, pio_start, opaque, name);
+portio_list_add(piolist, isabus->address_space_io, start);
+}
+
static int isa_qdev_init(DeviceState *qdev, DeviceInfo *base)
{
ISADevice *dev = DO_UPCAST(ISADevice, qdev, qdev);
diff --git a/hw/isa.h b/hw/isa.h
index c5c2618..177ef95 100644
--- a/hw/isa.h
+++ b/hw/isa.h
@@ -28,7 +28,6 @@ ISABus *isa_bus_new(DeviceState *dev, MemoryRegion
*address_space_io);
void isa_bus_irqs(qemu_irq *irqs);
qemu_irq isa_get_irq(int isairq);
void isa_init_irq(ISADevice *dev, qemu_irq *p, int isairq);
-void isa_register_ioport(ISADevice *dev, MemoryRegion *io, uint16_t start);
void isa_init_ioport(ISADevice *dev, uint16_t ioport);
void isa_init_ioport_range(ISADevice *dev, uint16_t start, uint16_t length);
void isa_qdev_register(ISADeviceInfo *info);
@@ -37,6 +36,36 @@ ISADevice *isa_create(const char *name);
ISADevice *isa_try_create(const char *name);
ISADevice *isa_create_simple(const char *name);
+/**
+ * isa_register_ioport: Install an I/O port region on the ISA bus.
+ *
+ * Register an I/O port region via memory_region_add_subregion
+ * inside the ISA I/O address space.
+ *
+ * @dev: the ISADevice against which these are registered; may be NULL.
+ * @io: the #MemoryRegion being registered.
+ * @start: the base I/O port.
+ */
+void isa_register_ioport(ISADevice *dev, MemoryRegion *io, uint16_t start);
+
+/**
+ * isa_register_portio_list: Initialize a set of ISA io ports
+ *
+ * Several ISA devices have many dis-joint I/O ports. Worse, these I/O
+ * ports can be interleaved with I/O ports from other devices. This
+ * function makes it easy to create multiple MemoryRegions for a single
+ * device and use the legacy portio routines.
+ *
+ * @dev: the ISADevice against which these are registered; may be NULL.
+ * @start: the base I/O port against which the portio->offset is applied.
+ * @portio: the ports, sorted by offset.
+ * @opaque: passed into the old_portio callbacks.
+ * @name: passed into memory_region_init_io.
+ */
+void isa_register_portio_list(ISADevice *dev, uint16_t start,
+ const MemoryRegionPortio *portio,
+ void *opaque, const char *name);
+
extern target_phys_addr_t isa_mem_base;
void isa_mmio_setup(MemoryRegion *mr, target_phys_addr_t size);
--
1.7.6.3
[Qemu-devel] [PATCH 08/24] ppc_newworld: convert to memory API
Signed-off-by: Avi Kivity
---
hw/ppc_newworld.c | 39 +--
1 files changed, 17 insertions(+), 22 deletions(-)
diff --git a/hw/ppc_newworld.c b/hw/ppc_newworld.c
index b9a50db..8c84f9e 100644
--- a/hw/ppc_newworld.c
+++ b/hw/ppc_newworld.c
@@ -84,12 +84,13 @@
#endif
/* UniN device */
-static void unin_writel (void *opaque, target_phys_addr_t addr, uint32_t value)
+static void unin_write(void *opaque, target_phys_addr_t addr, uint64_t value,
+ unsigned size)
{
-UNIN_DPRINTF("writel addr " TARGET_FMT_plx " val %x\n", addr, value);
+UNIN_DPRINTF("write addr " TARGET_FMT_plx " val %"PRIx64"\n", addr, value);
}
-static uint32_t unin_readl (void *opaque, target_phys_addr_t addr)
+static uint64_t unin_read(void *opaque, target_phys_addr_t addr, unsigned size)
{
uint32_t value;
@@ -99,16 +100,10 @@ static uint32_t unin_readl (void *opaque,
target_phys_addr_t addr)
return value;
}
-static CPUWriteMemoryFunc * const unin_write[] = {
-&unin_writel,
-&unin_writel,
-&unin_writel,
-};
-
-static CPUReadMemoryFunc * const unin_read[] = {
-&unin_readl,
-&unin_readl,
-&unin_readl,
+static const MemoryRegionOps unin_ops = {
+.read = unin_read,
+.write = unin_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
};
static int fw_cfg_boot_set(void *opaque, const char *boot_device)
@@ -138,9 +133,9 @@ static void ppc_core99_init (ram_addr_t ram_size,
CPUState *env = NULL;
char *filename;
qemu_irq *pic, **openpic_irqs;
-int unin_memory;
+MemoryRegion *unin_memory = g_new(MemoryRegion, 1);
int linux_boot, i;
-ram_addr_t ram_offset, bios_offset;
+MemoryRegion *ram = g_new(MemoryRegion, 1), *bios = g_new(MemoryRegion, 1);
target_phys_addr_t kernel_base, initrd_base, cmdline_base = 0;
long kernel_size, initrd_size;
PCIBus *pci_bus;
@@ -176,15 +171,16 @@ static void ppc_core99_init (ram_addr_t ram_size,
}
/* allocate RAM */
-ram_offset = qemu_ram_alloc(NULL, "ppc_core99.ram", ram_size);
-cpu_register_physical_memory(0, ram_size, ram_offset);
+memory_region_init_ram(ram, NULL, "ppc_core99.ram", ram_size);
+memory_region_add_subregion(get_system_memory(), 0, ram);
/* allocate and load BIOS */
-bios_offset = qemu_ram_alloc(NULL, "ppc_core99.bios", BIOS_SIZE);
+memory_region_init_ram(bios, NULL, "ppc_core99.bios", BIOS_SIZE);
if (bios_name == NULL)
bios_name = PROM_FILENAME;
filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
-cpu_register_physical_memory(PROM_ADDR, BIOS_SIZE, bios_offset |
IO_MEM_ROM);
+memory_region_set_readonly(bios, true);
+memory_region_add_subregion(get_system_memory(), PROM_ADDR, bios);
/* Load OpenBIOS (ELF) */
if (filename) {
@@ -267,9 +263,8 @@ static void ppc_core99_init (ram_addr_t ram_size,
isa_mmio_init(0xf200, 0x0080);
/* UniN init */
-unin_memory = cpu_register_io_memory(unin_read, unin_write, NULL,
- DEVICE_NATIVE_ENDIAN);
-cpu_register_physical_memory(0xf800, 0x1000, unin_memory);
+memory_region_init_io(unin_memory, &unin_ops, NULL, "unin", 0x1000);
+memory_region_add_subregion(get_system_memory(), 0xf800, unin_memory);
openpic_irqs = g_malloc0(smp_cpus * sizeof(qemu_irq *));
openpic_irqs[0] =
--
1.7.6.3
[Qemu-devel] [PATCH 17/24] ne2000: Convert to isa_register_ioport
From: Richard Henderson Signed-off-by: Richard Henderson Signed-off-by: Avi Kivity --- hw/ne2000-isa.c |5 + 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/hw/ne2000-isa.c b/hw/ne2000-isa.c index 756ed5c..11ffee7 100644 --- a/hw/ne2000-isa.c +++ b/hw/ne2000-isa.c @@ -68,10 +68,7 @@ static int isa_ne2000_initfn(ISADevice *dev) NE2000State *s = &isa->ne2000; ne2000_setup_io(s, 0x20); -isa_init_ioport_range(dev, isa->iobase, 16); -isa_init_ioport_range(dev, isa->iobase + 0x10, 2); -isa_init_ioport(dev, isa->iobase + 0x1f); -memory_region_add_subregion(get_system_io(), isa->iobase, &s->io); +isa_register_ioport(dev, &s->io, isa->iobase); isa_init_irq(dev, &s->irq, isa->isairq); -- 1.7.6.3
[Qemu-devel] [PATCH 04/24] petalogix_s2adsp1800: convert to memory API
Signed-off-by: Avi Kivity
---
hw/petalogix_s3adsp1800_mmu.c | 18 ++
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/hw/petalogix_s3adsp1800_mmu.c b/hw/petalogix_s3adsp1800_mmu.c
index 66fb96d..17da2fd 100644
--- a/hw/petalogix_s3adsp1800_mmu.c
+++ b/hw/petalogix_s3adsp1800_mmu.c
@@ -35,6 +35,7 @@
#include "loader.h"
#include "elf.h"
#include "blockdev.h"
+#include "exec-memory.h"
#include "microblaze_pic_cpu.h"
@@ -125,9 +126,10 @@ static uint64_t translate_kernel_address(void *opaque,
uint64_t addr)
DriveInfo *dinfo;
int i;
target_phys_addr_t ddr_base = 0x9000;
-ram_addr_t phys_lmb_bram;
-ram_addr_t phys_ram;
+MemoryRegion *phys_lmb_bram = g_new(MemoryRegion, 1);
+MemoryRegion *phys_ram = g_new(MemoryRegion, 1);
qemu_irq irq[32], *cpu_irq;
+MemoryRegion *sysmem = get_system_memory();
/* init CPUs */
if (cpu_model == NULL) {
@@ -139,13 +141,13 @@ static uint64_t translate_kernel_address(void *opaque,
uint64_t addr)
qemu_register_reset(main_cpu_reset, env);
/* Attach emulated BRAM through the LMB. */
-phys_lmb_bram = qemu_ram_alloc(NULL, "petalogix_s3adsp1800.lmb_bram",
- LMB_BRAM_SIZE);
-cpu_register_physical_memory(0x, LMB_BRAM_SIZE,
- phys_lmb_bram | IO_MEM_RAM);
+memory_region_init_ram(phys_lmb_bram, NULL,
+ "petalogix_s3adsp1800.lmb_bram", LMB_BRAM_SIZE);
+memory_region_add_subregion(sysmem, 0x, phys_lmb_bram);
-phys_ram = qemu_ram_alloc(NULL, "petalogix_s3adsp1800.ram", ram_size);
-cpu_register_physical_memory(ddr_base, ram_size, phys_ram | IO_MEM_RAM);
+memory_region_init_ram(phys_ram, NULL, "petalogix_s3adsp1800.ram",
+ ram_size);
+memory_region_add_subregion(sysmem, ddr_base, phys_ram);
dinfo = drive_get(IF_PFLASH, 0, 0);
pflash_cfi01_register(0xa000,
--
1.7.6.3
[Qemu-devel] [PATCH 10/24] Introduce PortioList
Add a type and methods for manipulating a list of disjoint I/O ports,
used in some older hardware devices.
Based on original patch by Richard Henderson.
Signed-off-by: Richard Henderson
Signed-off-by: Avi Kivity
---
Makefile.objs |2 +-
Makefile.target |2 +-
ioport.c| 108 +++
ioport.h| 21 +++
memory.c|8 ++--
5 files changed, 135 insertions(+), 6 deletions(-)
diff --git a/Makefile.objs b/Makefile.objs
index c849e51..9e70253 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -82,7 +82,7 @@ common-obj-$(CONFIG_WIN32) += os-win32.o
common-obj-$(CONFIG_POSIX) += os-posix.o
common-obj-y += tcg-runtime.o host-utils.o
-common-obj-y += irq.o ioport.o input.o
+common-obj-y += irq.o input.o
common-obj-$(CONFIG_PTIMER) += ptimer.o
common-obj-$(CONFIG_MAX7310) += max7310.o
common-obj-$(CONFIG_WM8750) += wm8750.o
diff --git a/Makefile.target b/Makefile.target
index 1aa6fce..f24d0aa 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -183,7 +183,7 @@ endif #CONFIG_BSD_USER
# System emulator target
ifdef CONFIG_SOFTMMU
-obj-y = arch_init.o cpus.o monitor.o machine.o gdbstub.o balloon.o
+obj-y = arch_init.o cpus.o monitor.o machine.o gdbstub.o balloon.o ioport.o
# virtio has to be here due to weird dependency between PCI and virtio-net.
# need to fix this properly
obj-$(CONFIG_NO_PCI) += pci-stub.o
diff --git a/ioport.c b/ioport.c
index a32483b..36fa3a4 100644
--- a/ioport.c
+++ b/ioport.c
@@ -27,6 +27,7 @@
#include "ioport.h"
#include "trace.h"
+#include "memory.h"
/***/
/* IO Port */
@@ -313,3 +314,110 @@ uint32_t cpu_inl(pio_addr_t addr)
LOG_IOPORT("inl : %04"FMT_pioaddr" %08"PRIx32"\n", addr, val);
return val;
}
+
+void portio_list_init(PortioList *piolist,
+ const MemoryRegionPortio *callbacks,
+ void *opaque, const char *name)
+{
+unsigned n = 0;
+
+while (callbacks[n].size) {
+++n;
+}
+
+piolist->ports = callbacks;
+piolist->nr = 0;
+piolist->regions = g_new0(MemoryRegion *, n);
+piolist->address_space = NULL;
+piolist->opaque = opaque;
+piolist->name = name;
+}
+
+void portio_list_destroy(PortioList *piolist)
+{
+g_free(piolist->regions);
+}
+
+static void portio_list_add_1(PortioList *piolist,
+ const MemoryRegionPortio *pio_init,
+ unsigned count, unsigned start,
+ unsigned off_low, unsigned off_high)
+{
+MemoryRegionPortio *pio;
+MemoryRegionOps *ops;
+MemoryRegion *region;
+unsigned i;
+
+/* Copy the sub-list and null-terminate it. */
+pio = g_new(MemoryRegionPortio, count + 1);
+memcpy(pio, pio_init, sizeof(MemoryRegionPortio) * count);
+memset(pio + count, 0, sizeof(MemoryRegionPortio));
+
+/* Adjust the offsets to all be zero-based for the region. */
+for (i = 0; i < count; ++i) {
+pio[i].offset -= off_low;
+}
+
+ops = g_new0(MemoryRegionOps, 1);
+ops->old_portio = pio;
+
+region = g_new(MemoryRegion, 1);
+memory_region_init_io(region, ops, piolist->opaque, piolist->name,
+ off_high - off_low);
+memory_region_set_offset(region, start + off_low);
+memory_region_add_subregion(piolist->address_space,
+start + off_low, region);
+piolist->regions[piolist->nr++] = region;
+}
+
+void portio_list_add(PortioList *piolist,
+ MemoryRegion *address_space,
+ uint32_t start)
+{
+const MemoryRegionPortio *pio, *pio_start = piolist->ports;
+unsigned int off_low, off_high, off_last, count;
+
+piolist->address_space = address_space;
+
+/* Handle the first entry specially. */
+off_last = off_low = pio_start->offset;
+off_high = off_low + pio_start->len;
+count = 1;
+
+for (pio = pio_start + 1; pio->size != 0; pio++, count++) {
+/* All entries must be sorted by offset. */
+assert(pio->offset >= off_last);
+off_last = pio->offset;
+
+/* If we see a hole, break the region. */
+if (off_last > off_high) {
+portio_list_add_1(piolist, pio_start, count, start, off_low,
+ off_high);
+/* ... and start collecting anew. */
+pio_start = pio;
+off_low = off_last;
+off_high = off_low + pio->len;
+count = 0;
+} else if (off_last + pio->len > off_high) {
+off_high = off_last + pio->len;
+}
+}
+
+/* There will always be an open sub-list. */
+portio_list_add_1(piolist, pio_start, count, start, off_low, off_high);
+}
+
+void portio_list_del(PortioList *piolist)
+{
+MemoryRegion *mr;
+unsigned i;
+
+for (i = 0; i < piolist->nr; ++i) {
+mr = piolist->regions[i];
+
