Re: [Qemu-devel] [SeaBIOS] [Qemu-stable] problems with freeBSD
On 03/08/13 08:47, Paolo Bonzini wrote: >> FWIW I find the binaries in git to be a PITA. I submitted a patch in >> January to fix the VGA BIOS but it's still broken in git. The one >> installed in /usr/share/qemu is fine, but whenever I build qemu from git >> I have to remember to *remove* the one in the git tree or it uses that >> instead... > > Wasn't that a fix for the SeaBIOS VGA BIOS? The one in qemu.git is > still built from the Bochs VGA BIOS. > > Last year, malc blocked the switch on the lack of protected mode > interface in SeaVGABIOS. Fedora switched though, so the distro binaries in /usr/share/qemu are the seavgabios ones. "make -C roms seavgabios" in the qemu source tree will upgrade the blobs in pc-bios/. cheers, Gerd
Re: [Qemu-devel] [PATCH v4] qdev: DEVICE_DELETED event
"Michael S. Tsirkin" writes: > On Thu, Mar 07, 2013 at 08:57:52PM +0100, Markus Armbruster wrote: >> "Michael S. Tsirkin" writes: >> >> > libvirt has a long-standing bug: when removing the device, >> > it can request removal but does not know when the >> > removal completes. Add an event so we can fix this in a robust way. >> > >> > Signed-off-by: Michael S. Tsirkin >> >> Speaking as the acting QMP maintainer, just to avoid misunderstandings: >> there's disagreement on the event's design, namely when it should fire, >> and how it should name the device. I don't want the discussion >> preempted by a commit. > > Yes, you are asking for more functionality, but can I add this in a > follow-up commit please? I prefer this patch as is, as it can be > backported to stable branches and downstreams. Upstream a follow up > patch can add fields and more triggers which won't apply to any > downstreams. If you want to address my review comments in a separate patch, go right ahead. Please post both together as a series, for coherent review and to simplify patch tracking. I'm asking for two things: 1. Event member path. Fair to call this "more functionality". I agree that backporting it to pre-QOM versions isn't practical. 2. Sane event trigger condition: on any device deletion, not just when the device happens to have a qdev ID. This isn't "more", it's "different". I'd definitely backport this part, because: * I abhor subtle semantic differences to upstream like a different event trigger. * Backporting it reduces the difference to event member path missing. Syntactic and in-your-face. * Without member path, the event triggered by deleting a device without a qdev ID can't tell us which device went away. But you can find out using the polling code you need anyway. Thus, the event trigger is not only simpler and consistent with upstream, it can also be more useful. [...]
Re: [Qemu-devel] [SeaBIOS] [Qemu-stable] problems with freeBSD
Il 08/03/2013 09:20, Gerd Hoffmann ha scritto: > On 03/08/13 08:47, Paolo Bonzini wrote: >>> FWIW I find the binaries in git to be a PITA. I submitted a patch in >>> January to fix the VGA BIOS but it's still broken in git. The one >>> installed in /usr/share/qemu is fine, but whenever I build qemu from git >>> I have to remember to *remove* the one in the git tree or it uses that >>> instead... >> >> Wasn't that a fix for the SeaBIOS VGA BIOS? The one in qemu.git is >> still built from the Bochs VGA BIOS. >> >> Last year, malc blocked the switch on the lack of protected mode >> interface in SeaVGABIOS. > > Fedora switched though, so the distro binaries in /usr/share/qemu are > the seavgabios ones. Did it? This is F18: $ rpm -q --requires qemu-system-x86|grep bios seabios-bin >= 0.6.0-2 sgabios-bin vgabios >= 0.6c-2 $ rpm -q vgabios vgabios-0.6c-5.fc18.noarch $ rpm -ql seabios-bin /usr/share/seabios /usr/share/seabios/bios.bin $ rpm -qf /usr/share/vgabios/ vgabios-0.6c-5.fc18.noarch Paolo > "make -C roms seavgabios" in the qemu source tree will upgrade the blobs > in pc-bios/. > > cheers, > Gerd > >
Re: [Qemu-devel] [PATCH 4/7] block: initial VHDX driver support framework - supports open and probe
Am 07.03.2013 um 17:12 hat Stefan Hajnoczi geschrieben:
> On Thu, Mar 07, 2013 at 10:23:54AM -0500, Jeff Cody wrote:
> > On Thu, Mar 07, 2013 at 03:30:44PM +0100, Stefan Hajnoczi wrote:
> > > On Wed, Mar 06, 2013 at 09:48:11AM -0500, Jeff Cody wrote:
> > > > +ret = bdrv_pread(bs->file, s->bat_offset, s->bat,
> > > > s->bat_rt.length);
> > > > +
> > > > +for (i = 0; i < s->bat_entries; i++) {
> > > > +le64_to_cpus(&s->bat[i]);
> > > > +}
> > >
> > > How does BAT size scale when the image size is increased? QCOW2 and QED
> > > use caches for metadata that would be too large or wasteful to keep in
> > > memory.
> >
> > The BAT size is dependent on the virtual disk size, and the block
> > size. The block size is allowed to range from 1MB - 256MB. There is
> > one BAT entry per block.
> >
> > In practice, the large block size keeps the BAT entry table reasonable
> > (for a 127GB file, the block size created by Hyper-V is 32MB, so the
> > table is pretty small - 32KB).
> >
> > However, I don't see anything in the spec that forces the block size
> > to be larger, for a large virtual disk size. So for the max size of
> > 64TB, and the smallest block size of 1MB, keeping the BAT in memory
> > would indeed be excessive.
> >
> > I'll re-read the spec, and see if there is anything that ties the
> > block size and virtual size together. If not, I'll have to add
> > caching.
>
> BTW the qcow2 cache code can be reused.
The add-cow series has patches to make it work outside of qcow2. I'm not
sure if there was something wrong with this part of the series, but at
least it could be a starting point.
Kevin
Re: [Qemu-devel] [PATCH 3/9] dataplane: remove EventPoll in favor of AioContext
On 04/03/13 10:15, Stefan Hajnoczi wrote:
> From: Paolo Bonzini
>
> During the review of the dataplane code, the EventPoll API morphed itself
> (not concidentially) into something very very similar to an AioContext.
> Thus, it is trivial to convert virtio-blk-dataplane to use AioContext,
> and a first baby step towards letting dataplane talk directly to the
> QEMU block layer.
>
> The only interesting note is the value-copy of EventNotifiers. At least
> in my opinion this is part of the EventNotifier API and is even portable
> to Windows. Of course, in this case you should not close the notifier's
> underlying file descriptors or handle with event_notifier_cleanup.
>
> Signed-off-by: Paolo Bonzini
> Signed-off-by: Stefan Hajnoczi
Hmm, this broke data plane on our internal notifier prototype code on virtio-ccw
(attached for reference)
[...]
> +/* Note that these EventNotifiers are assigned by value. This is
> + * fine as long as you do not call event_notifier_cleanup on them
> + * (because you don't own the file descriptor or handle; you just
> + * use it).
> + */
And this might be the reason. Currently we only have eventfd to wire up
guest_to_host notifiers. The host_to_guest notification is not done
via vectors/irqfd, instead we let our qemu transport listen to the irq
eventfd. Worked fine so far with vhost and dataplane without this patch.
Any ideas how to properly enable a transport that has full host notifiers
but only poor mans guest notifiers?
Christian
>From 76ceaec73c44f71b2e703accb157c09fef94ccd1 Mon Sep 17 00:00:00 2001
From: Cornelia Huck
Date: Tue, 19 Feb 2013 13:48:17 +0100
Subject: [PATCH 23/28] Re-add guest/host notifiers.
Signed-off-by: Cornelia Huck
---
hw/s390x/virtio-ccw.c | 90 +++
hw/s390x/virtio-ccw.h | 1 +
2 files changed, 91 insertions(+)
diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
index 63c851f..d4fa42a 100644
--- a/hw/s390x/virtio-ccw.c
+++ b/hw/s390x/virtio-ccw.c
@@ -95,6 +95,7 @@ static void virtio_ccw_start_ioeventfd(VirtioCcwDevice *dev)
int n, r;
if (!(dev->flags & VIRTIO_CCW_FLAG_USE_IOEVENTFD) ||
+dev->ioeventfd_disabled ||
dev->ioeventfd_started) {
return;
}
@@ -793,6 +794,89 @@ static void virtio_ccw_vmstate_change(DeviceState *d, bool running)
}
}
+static bool virtio_ccw_query_guest_notifiers(DeviceState *d)
+{
+VirtioCcwDevice *dev = VIRTIO_CCW_DEVICE(d);
+
+return !!(dev->sch->curr_status.pmcw.flags & PMCW_FLAGS_MASK_ENA);
+}
+
+static int virtio_ccw_set_host_notifier(DeviceState *d, int n, bool assign)
+{
+VirtioCcwDevice *dev = VIRTIO_CCW_DEVICE(d);
+
+/* Stop using the generic ioeventfd, we are doing eventfd handling
+ * ourselves below */
+dev->ioeventfd_disabled = assign;
+if (assign) {
+virtio_ccw_stop_ioeventfd(dev);
+}
+return virtio_ccw_set_guest2host_notifier(dev, n, assign, false);
+}
+
+static int virtio_ccw_set_guest_notifier(VirtioCcwDevice *dev, int n,
+ bool assign, bool with_irqfd)
+{
+VirtQueue *vq = virtio_get_queue(dev->vdev, n);
+EventNotifier *notifier = virtio_queue_get_guest_notifier(vq);
+
+if (assign) {
+int r = event_notifier_init(notifier, 0);
+
+if (r < 0) {
+return r;
+}
+virtio_queue_set_guest_notifier_fd_handler(vq, true, with_irqfd);
+/* We do not support irqfd for classic I/O interrupts, because the
+ * classic interrupts are intermixed with the subchannel status, that
+ * is queried with test subchannel. We want to use vhost, though.
+ * Lets make sure to have vhost running and wire up the irq fd to
+ * land in qemu (and only the irq fd) in this code.
+ */
+if (dev->vdev->guest_notifier_mask) {
+dev->vdev->guest_notifier_mask(dev->vdev, n, false);
+}
+/* get lost events and re-inject */
+if (dev->vdev->guest_notifier_pending &&
+dev->vdev->guest_notifier_pending(dev->vdev, n)) {
+event_notifier_set(notifier);
+}
+} else {
+if (dev->vdev->guest_notifier_mask) {
+dev->vdev->guest_notifier_mask(dev->vdev, n, true);
+}
+virtio_queue_set_guest_notifier_fd_handler(vq, false, with_irqfd);
+event_notifier_cleanup(notifier);
+}
+return 0;
+}
+
+static int virtio_ccw_set_guest_notifiers(DeviceState *d, int nvqs,
+ bool assigned)
+{
+VirtioCcwDevice *dev = VIRTIO_CCW_DEVICE(d);
+VirtIODevice *vdev = dev->vdev;
+int r, n;
+
+for (n = 0; n < nvqs; n++) {
+if (!virtio_queue_get_num(vdev, n)) {
+break;
+}
+/* false -> true, as soon as irqfd works */
+r = virtio_ccw_set_guest_notifier(dev, n, assigned, false);
+if (r < 0) {
+goto assign_error;
+}
+}
[Qemu-devel] [graphic & serial on sun4m]
Hi Artyom, Thanks again for your interest. Le 07/03/2013 23:58, Artyom Tarasenko a écrit : Hi Jean Michel, On Thu, Mar 7, 2013 at 4:09 PM, Jean-Michel SCHRAMM wrote: Hello Artyom, Thanks for taking time to consider my needs for serial ports. I went on board Thalassa this morning and started the system (not easy, the ship is laid along quay hardly powered). I gathered the informations you requested. Hope this is all you need. Please ask me if I missed something. I also attach the documentation of the board. Thanks, this looks interesting. What I wonder is where are those serial ports in the device tree? Are they connected to the VME-BUS, and OBP knows nothing about them? Do you know how does the SunOS find them? The original serial ports come from a SCSI terminal server. A third party software from this terminal server maker (Central Data) is loaded at boot and create the devices /dev/ttyCx and load the proprietary driver in kernel. That's why those port are not in the devs tree. I can switch off this and replace the /dev/ttyCx with true serial ports. If it is possible to add a few ports on top on basic a & b native serial port, with custom device name, I think that could make it. But those new port has to be linked to host computer real ports to. This is far above my competence. Though I used to (long ago...) be fluent in C and could get some support here, so I could volunteer to spend time on trying if I get just information of where to start and what to alter. By the way, I just subscribed to qemu-devel (was only to qemu-discuss). Mark said we should talk on this list and get nice cg3 and cg14 Bob's cards to the current release? This is definitely a good idea. Feel free to write or add a cc to demu-devel any time. I did. Many thanks again. Jean Michel Artyom Le 28/02/2013 15:45, Artyom Tarasenko a écrit : Hi Jean Michel, On Mon, Feb 18, 2013 at 6:36 PM, wrote: Hello Bob, Of course, with your full custom 0.15.50 tree it is much much better!! Got the zip file and configure only sparc-softmmu. I undesrtand my mistake. I thought I needed only the new files from the 0.15. Thanks you for that!! Now I need at least 4 real serial port from the host up to the guest ...and network. Network must be there. The lance ethernet is emulated (except for some test/loopback registers, but SunOS can live without those). As for the serial ports, one way to proceed may be adding your machine/board to qemu. Can you provide the OBP device tree of your machine? It can be done in the OBP "ok" prompt like this: ok show-devs ok cd / ok .attributes ok cd ok .attributes The "ok " parts above would come from the OBP, you don't need to enter them. If this listing shows that the machine is close to SS-5 or SS-20, adding more serial ports should be easy. Works with SS5. With SS20, I have an error saying that it can't find cpu definitions..? (was working with other verions). see tomorrow. Have you tried -cpu "TI SuperSparc 60" ? Artyom =~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2013.03.07 11:28:14 =~=~=~=~=~=~=~=~=~=~=~= SPARC CPU-5CE, No Keyboard ROM Rev. 2.ÿNL&¾ªªrj Ethernet address 0:80:42:b:11:73, Host ID: 808b5173. Testing Memory - Initializing Memory |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\ Type help for more information ok ok ok ok proe be-scsi Target 3 Unit 0 Disk QUANTUM VIKING II 4.5WLS5520 981006194912942263 Target 5 Unit 0 Device type 9 CenData ST-1008 V2.8 Send LUN Unit 1 Device type 9 CenData ST-1008 V2.8 Recv LUN ok shox-devs w-devs /FMI,MB86904 /sysconfig@0,7138 /virtual-memory@0,0 /memory@0,0 /obio /iommu@0,1000 /openprom /aliases /options /packages /obio/flash-memory@0,7130 /obio/SUNW,fdtwo@0,40 /obio/power@0,91 /obio/interrupt@0,e0 /obio/counter@0,d0 /obio/auxio@0,90 /obio/slavioconfig@0,80 /obio/eeprom@0,20 /obio/zs@0,0 /obio/zs@0,10 /iommu@0,1000/VME@0,3fe0 /iommu@0,1000/sbus@0,10001000 More [,,q] ? /iommu@0,1000/VME@0,3fe0/vmenet@2d,0 /iommu@0,1000/sbus@0,10001000/le@3,c0 /iommu@0,1000/sbus@0,10001000/cgsix@2,0 /iommu@0,1000/sbus@0,10001000/ledma@5,8400010 /iommu@0,1000/sbus@0,10001000/SUNW,bpp@5,c80 /iommu@0,1000/sbus@0,10001000/espdma@5,840 /iommu@0,1000/sbus@0,10001000/ledma@5,8400010/le@5,8c0 /iommu@0,1000/sbus@0,10001000/espdma@5,840/esp@5,880 /iommu@0,1000/sbus@0,10001000/espdma@5,840/esp@5,880/st /iommu@0,1000/sbus@0,10001000/espdma@5,840/esp@5,880/sd /packages/obp-tftp /packages/deblocker /packages/disk-label ok cd / ok .attributes modelSPARC CPU-5CE/32-85-X clock-frequency 0510ff40 name SPARC,C
Re: [Qemu-devel] [PER] Re: socket, mcast looping back frames -> IPv6 broken
On Thu, Mar 07, 2013 at 06:14:28PM +0100, Samuel Thibault wrote: > Stefan Hajnoczi, le Thu 07 Mar 2013 10:38:26 +0100, a écrit : > > On Wed, Mar 06, 2013 at 02:15:25PM +0100, Samuel Thibault wrote: > > > Stefan Hajnoczi, le Wed 06 Mar 2013 13:29:37 +0100, a écrit : > > > > On Tue, Mar 05, 2013 at 05:35:10PM +0100, Samuel Thibault wrote: > > > > Unfortunately net/socket.c does not have the concept of a link-layer > > > > address, so we cannot easily filter out multicast packets coming from > > > > our NIC's address. > > > > > > > > Are you aware of a way to filter out just the packets sent by *this* > > > > process? > > > > > > I haven't seen any in the Linux source code. One thing that should > > > work, however, is to use recvfrom, and drop whatever comes from our > > > sockname. > > > > Sounds like a plan :). > > Except that the sockname is the multicast address itself... I'll have a > closer look. What about the port number? Stefan
Re: [Qemu-devel] [Bug 1151986] Re: buffer overflow after block-stream via QMP
On Thu, Mar 07, 2013 at 06:14:27PM -, Helge Rausch wrote: > I cannot reproduce it anymore on master. One option we now have without > building it ourselves is using 1.4.0 from Ubuntu's raring derivate. > Would you consider that stable enough for production use (the qemu > package, not raring)? QEMU 1.4.0 is a stable release, it is intended for production use. I can't speak for Ubuntu packaging of QEMU 1.4.0, perhaps check the bug tracker to see if there are known issues with the package. Stefan
Re: [Qemu-devel] [PATCH] qdev: DEVICE_DELETED event
Osier Yang writes: > I'm wondering if it could be long time to wait for the device_del > completes (AFAIK from previous bugs, it can be, though it should be > fine for most of the cases). If it's too long, it will be a problem > for management, because it looks like hanging. We can have a timeout > for the device_del in libvirt, but the problem is the device_del > can be still in progress by qemu, which could cause the inconsistency. > Unless qemu has some command to cancel the device_del. I'm afraid cancelling isn't possible, at least not for PCI. Here's how device_del works for PCI when it works, roughly: 1. device_del asks the device model to unplug itself. 2. PCI device models delegate the job to the device model providing their PCI bus. Let's assume it's our PIIX3/PIIX4 mongrel. That one puts an unplug request into PIIX4 function 3 where guest ACPI can see it, and triggers its interrupt. Then it immediately sends the QMP success reply. 3. Guest ACPI (SeaBIOS) services the interrupt. It finds the unplug request, and asks the guest OS nicely to give up the device. 4. If the guest OS has a working ACPI driver, and it feels like giving up the device, it does so, and tells ACPI when it's done. 5. Guest ACPI cleans up whatever it needs cleaned up, and signals successful unplug by writing the slog number to a PIIX4 function 3 register. 6. The PIIX device destroys the device in that slot. I call this the ACPI unplug dance. We don't control steps 3..5. There's no way for the guest to tell us "I got your unplug request, but I'm not going to honor it". Even if their was, a guest without a working ACPI driver wouldn't use it, so we couldn't rely on it anyway. There's no way for us to tell the guest "I changed my mind on this unplug". All we can do is wait and see. Either the device goes away, or it stays. Native PCIe is different, I'm told, but I know even less of that than I know of PCI/ACPI.
Re: [Qemu-devel] [PER] Re: socket, mcast looping back frames -> IPv6 broken
Stefan Hajnoczi, le Fri 08 Mar 2013 09:43:18 +0100, a écrit : > On Thu, Mar 07, 2013 at 06:14:28PM +0100, Samuel Thibault wrote: > > Stefan Hajnoczi, le Thu 07 Mar 2013 10:38:26 +0100, a écrit : > > > On Wed, Mar 06, 2013 at 02:15:25PM +0100, Samuel Thibault wrote: > > > > Stefan Hajnoczi, le Wed 06 Mar 2013 13:29:37 +0100, a écrit : > > > > > On Tue, Mar 05, 2013 at 05:35:10PM +0100, Samuel Thibault wrote: > > > > > Unfortunately net/socket.c does not have the concept of a link-layer > > > > > address, so we cannot easily filter out multicast packets coming from > > > > > our NIC's address. > > > > > > > > > > Are you aware of a way to filter out just the packets sent by *this* > > > > > process? > > > > > > > > I haven't seen any in the Linux source code. One thing that should > > > > work, however, is to use recvfrom, and drop whatever comes from our > > > > sockname. > > > > > > Sounds like a plan :). > > > > Except that the sockname is the multicast address itself... I'll have a > > closer look. > > What about the port number? It needs to be the same. There does exist some unique address, which is returned by recvfrom, I'll have a look at how to get access to it. Samuel
Re: [Qemu-devel] [Qemu-trivial] [PATCH][RESENT] configure: Create link to icon bitmap for out-of-tree builds
On Fri, Feb 22, 2013 at 09:05:01PM +0100, Jan Kiszka wrote: > This allows to pick up the icon when starting QEMU directly from an > out-of-tree build directory. > > Signed-off-by: Jan Kiszka > --- > configure |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) Thanks, applied to the trivial patches tree: https://github.com/stefanha/qemu/commits/trivial-patches Stefan
Re: [Qemu-devel] [Qemu-trivial] [PATCH] rtc-test: Fix test failures with recent glib
On Tue, Feb 26, 2013 at 07:31:32PM -0500, Cole Robinson wrote: > As of glib 2.35.4, glib changed its logic for ordering test cases: > > https://bugzilla.gnome.org/show_bug.cgi?id=694487 > > This was causing failures in rtc-test. Group the reordered test > cases into their own suite, which maintains the original ordering. > > CC: qemu-sta...@nongnu.org > Signed-off-by: Cole Robinson > --- > tests/rtc-test.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) It's best to make test cases independent of order (no side-effects), but this small patch fixes the problem. Thanks, applied to the trivial patches tree: https://github.com/stefanha/qemu/commits/trivial-patches Stefan
Re: [Qemu-devel] [PATCH] lm32: remove unused function
On Mon, Mar 04, 2013 at 06:11:47PM +0100, Paolo Bonzini wrote: > The milkymist-minimac device in fact does not exist at all. > > Signed-off-by: Paolo Bonzini > --- > hw/milkymist-hw.h | 16 > 1 file changed, 16 deletions(-) Thanks, applied to the trivial patches tree: https://github.com/stefanha/qemu/commits/trivial-patches Stefan
Re: [Qemu-devel] [PATCH] Use proper term in TCG README
On Thu, Mar 07, 2013 at 11:33:01AM +0800, 陳韋任 (Wei-Ren Chen) wrote: > In TCG, "target" means the host architecture for which TCG generates the > code. Using "guest" rather than "target" to make the document more consistent. > > Signed-off-by: Chen Wei-Ren > --- > tcg/README | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tcg/README b/tcg/README > index 934e7af..22174c0 100644 > --- a/tcg/README > +++ b/tcg/README > @@ -379,7 +379,7 @@ double-word product T0. The later is returned in two > single-word outputs. > > Similar to mulu2, except the two inputs T1 and T2 are signed. > > -* 64-bit target on 32-bit host support > +* 64-bit guest on 32-bit host support > > The following opcodes are internal to TCG. Thus they are to be implemented > by > 32-bit host code generators, but are not to be emitted by guest translators. Review from TCG experts please. It seems we have multiple meanings for "target" (e.g. ./configure --target-list= does not mean "the host architecture for which TCG generates code"), if this is really the way TCG uses the term then fine. Stefan
Re: [Qemu-devel] [PATCH v2] osdep: replace setsockopt by qemu_setsockopt
On Wed, Mar 06, 2013 at 10:29:16PM +0800, Lei Li wrote: > Fix the compiler warning when cross build qemu-ga > for windows by using qemu_setsockopt() instead of > setsockopt(). > > util/osdep.c: In function 'socket_set_nodelay': > util/osdep.c:69:5: warning: passing argument 4 of 'setsockopt' from >incompatible pointer type [enabled by default] > In file included from /home/lei/qemu_b/include/sysemu/os-win32.h:30:0, > from /home/lei/qemu_b/include/qemu-common.h:46, > from util/osdep.c:48: > /usr/i686-w64-mingw32/sys-root/mingw/include/winsock2.h:990:63: note: > expected 'const char *' but argument is of type 'int *' > > Signed-off-by: Lei Li > --- > > Change since v1: > - Use qemu_setsockopt() instead of open-coding suggested by Stefan. > > --- > util/osdep.c |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) Thanks, applied to the trivial patches tree: https://github.com/stefanha/qemu/commits/trivial-patches Stefan
Re: [Qemu-devel] [PATCH 3/9] dataplane: remove EventPoll in favor of AioContext
Il 08/03/2013 09:37, Christian Borntraeger ha scritto:
> +if (assign) {
> +int r = event_notifier_init(notifier, 0);
> +
> +if (r < 0) {
> +return r;
> +}
> +virtio_queue_set_guest_notifier_fd_handler(vq, true, with_irqfd);
Perhaps you can simply hard-code with_irqfd to false in this call to
virtio_queue_set_guest_notifier_fd_handler and the one below? Then the
guest notifier will be emulated in userspace and processed via
vdev->binding->notify.
You will not need to overwrite the EventNotifier which is IMO a pretty
ufly violation of encapsulation. :)
Paolo
> +/* We do not support irqfd for classic I/O interrupts, because the
> + * classic interrupts are intermixed with the subchannel status, that
> + * is queried with test subchannel. We want to use vhost, though.
> + * Lets make sure to have vhost running and wire up the irq fd to
> + * land in qemu (and only the irq fd) in this code.
> + */
> +if (dev->vdev->guest_notifier_mask) {
> +dev->vdev->guest_notifier_mask(dev->vdev, n, false);
> +}
> +/* get lost events and re-inject */
> +if (dev->vdev->guest_notifier_pending &&
> +dev->vdev->guest_notifier_pending(dev->vdev, n)) {
> +event_notifier_set(notifier);
> +}
> +} else {
> +if (dev->vdev->guest_notifier_mask) {
> +dev->vdev->guest_notifier_mask(dev->vdev, n, true);
> +}
> +virtio_queue_set_guest_notifier_fd_handler(vq, false, with_irqfd);
> +event_notifier_cleanup(notifier);
Re: [Qemu-devel] [PATCH 1/7] block: only force IO completion in .bdrv_truncate if we are shrinking
Il 08/03/2013 08:53, Peter Lieven ha scritto: >> >> I think the fix is to only call it for the monitor command. Optionally, >> when shrinking, assert that there are no requests in flight. > > Okay. > > What is the plan? just fix this or fix the whole thing (which seems to > be some > work). > > The suggested patch from Jeff will break iscsi_truncate as bs->growable > is 1 currently. I guess it's up to Kevin and Jeff. Paolo
Re: [Qemu-devel] [PATCH] qdev: DEVICE_DELETED event
On Fri, Mar 08, 2013 at 09:50:55 +0100, Markus Armbruster wrote: > Osier Yang writes: > > > I'm wondering if it could be long time to wait for the device_del > > completes (AFAIK from previous bugs, it can be, though it should be > > fine for most of the cases). If it's too long, it will be a problem > > for management, because it looks like hanging. We can have a timeout > > for the device_del in libvirt, but the problem is the device_del > > can be still in progress by qemu, which could cause the inconsistency. > > Unless qemu has some command to cancel the device_del. > > I'm afraid cancelling isn't possible, at least not for PCI. I don't think we need anything like that. We just need the device deletion API to return immediately without actually removing stuff from domain definition (unless the device was really removed fast enough, e.g., USB devices are removed before device_del returns) and then remove the device from domain definition when we get the event from QEMU or when libvirtd reconnects to a domain and sees a particular device is no longer present. After all, devices may be removed even if we didn't ask for it (when the removal is initiated by a guest OS). And we should also provide similar event for higher level apps. The question is whether we can make use of our existing API or if we need to introduce a new one. But that's of little relevance to qemu-devel I guess. Jirka
Re: [Qemu-devel] [PATCH] Use proper term in TCG README
On 8 March 2013 17:21, Stefan Hajnoczi wrote: > On Thu, Mar 07, 2013 at 11:33:01AM +0800, 陳韋任 (Wei-Ren Chen) wrote: >> In TCG, "target" means the host architecture for which TCG generates the >> code. Using "guest" rather than "target" to make the document more >> consistent. >> @@ -379,7 +379,7 @@ double-word product T0. The later is returned in two >> single-word outputs. >> >> Similar to mulu2, except the two inputs T1 and T2 are signed. >> >> -* 64-bit target on 32-bit host support >> +* 64-bit guest on 32-bit host support >> >> The following opcodes are internal to TCG. Thus they are to be implemented >> by >> 32-bit host code generators, but are not to be emitted by guest translators. > > Review from TCG experts please. > > It seems we have multiple meanings for "target" (e.g. ./configure > --target-list= does not mean "the host architecture for which TCG > generates code"), if this is really the way TCG uses the term then fine. Yes, this is an unfortunate terminology clash, but in a TCG context 'target' does mean 'host architecture which the backend compiles for' (see the tcg/README definition in section 2). This is partly because of TCG's history as a C compiler backend, where 'target' is unambiguous and may be different from the 'host' architecture the compiler itself executes on. There are several places in tcg/README which use 'target' in the sense 'QEMU target, ie guest' (as well as lots of uses in the 'TCG target, ie host' sense), not just this one; it might be a good idea to put a note in the Definitions section that this document uses 'guest' when it means what in other areas of QEMU is often referred to as the 'target', and fix the places where we've accidentally used 'target' and 'guest would be better. -- PMM
[Qemu-devel] [Bug 1151986] Re: buffer overflow after block-stream via QMP
Alright. Thank you! -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1151986 Title: buffer overflow after block-stream via QMP Status in QEMU: New Bug description: When a block-stream is initiated via QMP and the QMP socket is closed on client side before the job is finished, QEMU crashes with a buffer overflow, somewhere at the end of the streaming process. Without QMP I can stream via the HMP without problems. After crashing, I cannot boot from the active image anymore. I was able to reproduce this with qemu-kvm and qemu-system-x86_64 on two different machines. Version: QEMU emulator version 1.2.0 (qemu-kvm-1.2.0), Copyright (c) 2003-2008 Fabrice Bellard I started QEMU with the following script: qemu-kvm \ -monitor vc \ -m 512 \ -hda "$1" \ -net nic,vlan=0 \ -net user,vlan=0 \ -localtime \ -smp 2 \ -qmp tcp:localhost:,server,nowait Backtrace: Formatting '/home/helge/images/vm01.2013-03-07_11:30:13.qcow2', fmt=qcow2 size=1048576 backing_file='/home/helge/images/vm01.qcow2' backing_fmt='qcow2' encryption=off cluster_size=65536 lazy_refcounts=off *** buffer overflow detected ***: qemu-kvm terminated === Backtrace: = /usr/lib/libc.so.6(__fortify_fail+0x37)[0x7f054e91a8c7] /usr/lib/libc.so.6(+0xfc9a0)[0x7f054e9189a0] /usr/lib/libc.so.6(+0xfe837)[0x7f054e91a837] qemu-kvm(+0xdb0dc)[0x7f055220b0dc] qemu-kvm(+0x15f581)[0x7f055228f581] qemu-kvm(main+0xf93)[0x7f05521a3e93] /usr/lib/libc.so.6(__libc_start_main+0xf5)[0x7f054e83da15] qemu-kvm(+0x77e8d)[0x7f05521a7e8d] === Memory map: 7f051bdff000-7f051be0 rw-p 00:00 0 7f051be0-7f053be0 rw-p 00:00 0 7f053be0-7f053c00 rw-p 00:00 0 7f053c00-7f053c021000 rw-p 00:00 0 7f053c021000-7f054000 ---p 00:00 0 7f05421e2000-7f05421f7000 r-xp 08:12 1175478 /usr/lib/libgcc_s.so.1 7f05421f7000-7f05423f6000 ---p 00015000 08:12 1175478 /usr/lib/libgcc_s.so.1 7f05423f6000-7f05423f7000 rw-p 00014000 08:12 1175478 /usr/lib/libgcc_s.so.1 7f05423f7000-7f05423f8000 ---p 00:00 0 7f05423f8000-7f0542bf8000 rw-p 00:00 0 [stack:27848] 7f0542bf8000-7f0542bfd000 r-xp 08:12 1198566 /usr/lib/libXfixes.so.3.1.0 7f0542bfd000-7f0542dfd000 ---p 5000 08:12 1198566 /usr/lib/libXfixes.so.3.1.0 7f0542dfd000-7f0542dfe000 r--p 5000 08:12 1198566 /usr/lib/libXfixes.so.3.1.0 7f0542dfe000-7f0542dff000 rw-p 6000 08:12 1198566 /usr/lib/libXfixes.so.3.1.0 7f0542dff000-7f0542e0 rw-p 00:00 0 7f0542e0-7f0543e0 rw-p 00:00 0 7f0543e0-7f054400 rw-p 00:00 0 7f054400-7f0544139000 rw-p 00:00 0 7f0544139000-7f054800 ---p 00:00 0 7f0548014000-7f054801e000 r-xp 08:12 1198746 /usr/lib/libXrender.so.1.3.0 7f054801e000-7f054821d000 ---p a000 08:12 1198746 /usr/lib/libXrender.so.1.3.0 7f054821d000-7f054821e000 r--p 9000 08:12 1198746 /usr/lib/libXrender.so.1.3.0 7f054821e000-7f054821f000 rw-p a000 08:12 1198746 /usr/lib/libXrender.so.1.3.0 7f054821f000-7f0548228000 r-xp 08:12 1199189 /usr/lib/libXcursor.so.1.0.2 7f0548228000-7f0548427000 ---p 9000 08:12 1199189 /usr/lib/libXcursor.so.1.0.2 7f0548427000-7f0548428000 r--p 8000 08:12 1199189 /usr/lib/libXcursor.so.1.0.2 7f0548428000-7f0548429000 rw-p 9000 08:12 1199189 /usr/lib/libXcursor.so.1.0.2 7f0548429000-7f0548721000 r--p 08:12 1175421 /usr/lib/locale/locale-archive 7f0548721000-7f0548733000 r-xp 08:12 1198126 /usr/lib/libXext.so.6.4.0 7f0548733000-7f0548932000 ---p 00012000 08:12 1198126 /usr/lib/libXext.so.6.4.0 7f0548932000-7f0548933000 r--p 00011000 08:12 1198126 /usr/lib/libXext.so.6.4.0 7f0548933000-7f0548934000 rw-p 00012000 08:12 1198126 /usr/lib/libXext.so.6.4.0 7f054895d000-7f05489c rw-p 00:00 0 7f054895d000-7f05489c rw-p 00:00 0 [118/1982] 7f05489d3000-7f0548aed000 rw-s 00:04 69697543 /SYSV (deleted) 7f0548aed000-7f0548aee000 ---p 00:00 0 7f0548aee000-7f05492ee000 rw-p 00:00 0 [stack:27612] 7f05492ee000-7f05492ef000 ---p 00:00 0 7f05492ef000-7f0549aef000 rw-p 00:00 0
Re: [Qemu-devel] [PATCH 1/7] block: only force IO completion in .bdrv_truncate if we are shrinking
Am 08.03.2013 um 10:23 hat Paolo Bonzini geschrieben: > Il 08/03/2013 08:53, Peter Lieven ha scritto: > >> > >> I think the fix is to only call it for the monitor command. Optionally, > >> when shrinking, assert that there are no requests in flight. > > > > Okay. > > > > What is the plan? just fix this or fix the whole thing (which seems to > > be some > > work). > > > > The suggested patch from Jeff will break iscsi_truncate as bs->growable > > is 1 currently. > > I guess it's up to Kevin and Jeff. Someone needs to send a fix for the qcow1 (and probably vmdk) regression, otherwise I'll have to revert the patch. Kevin
[Qemu-devel] [PULL 0/5] Trivial patches for 22 February to 8 March 2013
The following changes since commit 0bc472a9d6b80567c212023c5eae413f4dfb53ad: hw/nand.c: correct the sense of the BUSY/READY status bit (2013-03-07 09:27:11 +0100) are available in the git repository at: git://github.com/stefanha/qemu.git trivial-patches for you to fetch changes up to 5ccbb63abba9034b265a34282ccf4ae2164df501: osdep: replace setsockopt by qemu_setsockopt (2013-03-08 10:46:00 +0100) Lei Li (2): Fix the wrong description in qemu manual osdep: replace setsockopt by qemu_setsockopt Michal Privoznik (1): configure: Require at least spice-protocol-0.12.3 Peter Maydell (1): pci_host: Drop write-only address_space field Stefan Berger (1): rng-random: Use qemu_open / qemu_close backends/rng-random.c | 4 ++-- configure | 2 +- hw/pci/pci_host.h | 1 - hw/piix_pci.c | 1 - hw/ppc/prep.c | 1 - qemu-options.hx | 2 +- util/osdep.c | 4 ++-- 7 files changed, 6 insertions(+), 9 deletions(-) -- 1.8.1.4
[Qemu-devel] [PATCH 1/5] configure: Require at least spice-protocol-0.12.3
From: Michal Privoznik As of 5a49d3e9 we assume SPICE_PORT_EVENT_BREAK to be defined. However, it is defined not in 0.12.2 what we require now, but in 0.12.3. Therefore in order to prevent build failure we must adjust our minimal requirements. Signed-off-by: Stefan Hajnoczi --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index 2f98c5a..44842db 100755 --- a/configure +++ b/configure @@ -2871,7 +2871,7 @@ EOF spice_cflags=$($pkg_config --cflags spice-protocol spice-server 2>/dev/null) spice_libs=$($pkg_config --libs spice-protocol spice-server 2>/dev/null) if $pkg_config --atleast-version=0.12.0 spice-server >/dev/null 2>&1 && \ - $pkg_config --atleast-version=0.12.2 spice-protocol > /dev/null 2>&1 && \ + $pkg_config --atleast-version=0.12.3 spice-protocol > /dev/null 2>&1 && \ compile_prog "$spice_cflags" "$spice_libs" ; then spice="yes" libs_softmmu="$libs_softmmu $spice_libs" -- 1.8.1.4
[Qemu-devel] [PATCH 5/5] osdep: replace setsockopt by qemu_setsockopt
From: Lei Li
Fix the compiler warning when cross build qemu-ga
for windows by using qemu_setsockopt() instead of
setsockopt().
util/osdep.c: In function 'socket_set_nodelay':
util/osdep.c:69:5: warning: passing argument 4 of 'setsockopt' from
incompatible pointer type [enabled by default]
In file included from /home/lei/qemu_b/include/sysemu/os-win32.h:30:0,
from /home/lei/qemu_b/include/qemu-common.h:46,
from util/osdep.c:48:
/usr/i686-w64-mingw32/sys-root/mingw/include/winsock2.h:990:63: note:
expected 'const char *' but argument is of type 'int *'
Signed-off-by: Lei Li
Signed-off-by: Stefan Hajnoczi
---
util/osdep.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/util/osdep.c b/util/osdep.c
index c408261..bd59ac9 100644
--- a/util/osdep.c
+++ b/util/osdep.c
@@ -57,7 +57,7 @@ static const char *qemu_version = QEMU_VERSION;
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));
+return qemu_setsockopt(fd, SOL_TCP, TCP_CORK, &v, sizeof(v));
#else
return 0;
#endif
@@ -66,7 +66,7 @@ int socket_set_cork(int fd, int v)
int socket_set_nodelay(int fd)
{
int v = 1;
-return setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &v, sizeof(v));
+return qemu_setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &v, sizeof(v));
}
int qemu_madvise(void *addr, size_t len, int advice)
--
1.8.1.4
[Qemu-devel] [PATCH 4/5] Fix the wrong description in qemu manual
From: Lei Li
Fix LP#1151450 the wrong description in qemu manual:
'qemu-system-x86_84' should be 'qemu-system-x86_64'.
Signed-off-by: Lei Li
Signed-off-by: Stefan Hajnoczi
---
qemu-options.hx | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index 6f9334a..cd76f2a 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2132,7 +2132,7 @@
gluster[+transport]://[server[:port]]/volname/image[?socket=...]
Example
@example
-qemu-system-x86_84 --drive file=gluster://192.0.2.1/testvol/a.img
+qemu-system-x86_64 --drive file=gluster://192.0.2.1/testvol/a.img
@end example
See also @url{http://www.gluster.org}.
--
1.8.1.4
[Qemu-devel] [PATCH 3/5] pci_host: Drop write-only address_space field
From: Peter Maydell
The address_space field of PCIHostState was only ever written, never used.
Drop it completely.
Signed-off-by: Peter Maydell
Reviewed-by: Andreas Färber
Signed-off-by: Stefan Hajnoczi
---
hw/pci/pci_host.h | 1 -
hw/piix_pci.c | 1 -
hw/ppc/prep.c | 1 -
3 files changed, 3 deletions(-)
diff --git a/hw/pci/pci_host.h b/hw/pci/pci_host.h
index 1845d4d..236cd0f 100644
--- a/hw/pci/pci_host.h
+++ b/hw/pci/pci_host.h
@@ -40,7 +40,6 @@ struct PCIHostState {
MemoryRegion conf_mem;
MemoryRegion data_mem;
MemoryRegion mmcfg;
-MemoryRegion *address_space;
uint32_t config_reg;
PCIBus *bus;
};
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index 6c77e49..9246983 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -244,7 +244,6 @@ static PCIBus *i440fx_common_init(const char *device_name,
dev = qdev_create(NULL, "i440FX-pcihost");
s = PCI_HOST_BRIDGE(dev);
-s->address_space = address_space_mem;
b = pci_bus_new(dev, NULL, pci_address_space,
address_space_io, 0);
s->bus = b;
diff --git a/hw/ppc/prep.c b/hw/ppc/prep.c
index e06dded..2920911 100644
--- a/hw/ppc/prep.c
+++ b/hw/ppc/prep.c
@@ -567,7 +567,6 @@ static void ppc_prep_init(QEMUMachineInitArgs *args)
dev = qdev_create(NULL, "raven-pcihost");
pcihost = PCI_HOST_BRIDGE(dev);
-pcihost->address_space = get_system_memory();
object_property_add_child(qdev_get_machine(), "raven", OBJECT(dev), NULL);
qdev_init_nofail(dev);
pci_bus = (PCIBus *)qdev_get_child_bus(dev, "pci.0");
--
1.8.1.4
[Qemu-devel] [PATCH 2/5] rng-random: Use qemu_open / qemu_close
From: Stefan Berger
In the rng backend use qemu_open and qemu_close rather than POSIX
open/close.
Signed-off-by: Stefan Berger
Reviewed-by: Eric Blake
Signed-off-by: Stefan Hajnoczi
---
backends/rng-random.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/backends/rng-random.c b/backends/rng-random.c
index 0d11088..acd20af 100644
--- a/backends/rng-random.c
+++ b/backends/rng-random.c
@@ -74,7 +74,7 @@ static void rng_random_opened(RngBackend *b, Error **errp)
error_set(errp, QERR_INVALID_PARAMETER_VALUE,
"filename", "a valid filename");
} else {
-s->fd = open(s->filename, O_RDONLY | O_NONBLOCK);
+s->fd = qemu_open(s->filename, O_RDONLY | O_NONBLOCK);
if (s->fd == -1) {
error_set(errp, QERR_OPEN_FILE_FAILED, s->filename);
@@ -130,7 +130,7 @@ static void rng_random_finalize(Object *obj)
qemu_set_fd_handler(s->fd, NULL, NULL, NULL);
if (s->fd != -1) {
-close(s->fd);
+qemu_close(s->fd);
}
g_free(s->filename);
--
1.8.1.4
Re: [Qemu-devel] [SeaBIOS] [Qemu-stable] problems with freeBSD
> Did it? This is F18: > > $ rpm -q --requires qemu-system-x86|grep bios > seabios-bin >= 0.6.0-2 > sgabios-bin > vgabios >= 0.6c-2 Oops. There is a seavgabios-bin package too, and I through cole switched qemu over, but apparently this didn't happen (or maybe in rawhide only) ... cheers, Gerd
Re: [Qemu-devel] [PATCH] Use proper term in TCG README
On Fri, Mar 08, 2013 at 05:29:29PM +0800, Peter Maydell wrote: > On 8 March 2013 17:21, Stefan Hajnoczi wrote: > > On Thu, Mar 07, 2013 at 11:33:01AM +0800, 陳韋任 (Wei-Ren Chen) wrote: > >> In TCG, "target" means the host architecture for which TCG generates the > >> code. Using "guest" rather than "target" to make the document more > >> consistent. > > >> @@ -379,7 +379,7 @@ double-word product T0. The later is returned in two > >> single-word outputs. > >> > >> Similar to mulu2, except the two inputs T1 and T2 are signed. > >> > >> -* 64-bit target on 32-bit host support > >> +* 64-bit guest on 32-bit host support > >> > >> The following opcodes are internal to TCG. Thus they are to be > >> implemented by > >> 32-bit host code generators, but are not to be emitted by guest > >> translators. > > > > Review from TCG experts please. > > > > It seems we have multiple meanings for "target" (e.g. ./configure > > --target-list= does not mean "the host architecture for which TCG > > generates code"), if this is really the way TCG uses the term then fine. > > Yes, this is an unfortunate terminology clash, but in a TCG context > 'target' does mean 'host architecture which the backend compiles for' > (see the tcg/README definition in section 2). This is partly because > of TCG's history as a C compiler backend, where 'target' is unambiguous > and may be different from the 'host' architecture the compiler itself > executes on. > > There are several places in tcg/README which use 'target' in the > sense 'QEMU target, ie guest' (as well as lots of uses in the > 'TCG target, ie host' sense), not just this one; it might be a good > idea to put a note in the Definitions section that this document uses > 'guest' when it means what in other areas of QEMU is often referred to > as the 'target', and fix the places where we've accidentally used 'target' > and 'guest would be better. Wei-Ren, can you please convert the other instances in tcg/README where 'target' is used in the 'guest' sense, too? Stefan
Re: [Qemu-devel] [PATCH] qdev: DEVICE_DELETED event
On 2013年03月08日 17:25, Jiri Denemark wrote: On Fri, Mar 08, 2013 at 09:50:55 +0100, Markus Armbruster wrote: Osier Yang writes: I'm wondering if it could be long time to wait for the device_del completes (AFAIK from previous bugs, it can be, though it should be fine for most of the cases). If it's too long, it will be a problem for management, because it looks like hanging. We can have a timeout for the device_del in libvirt, but the problem is the device_del can be still in progress by qemu, which could cause the inconsistency. Unless qemu has some command to cancel the device_del. I'm afraid cancelling isn't possible, at least not for PCI. I don't think we need anything like that. We just need the device deletion API to return immediately without actually removing stuff from domain definition (unless the device was really removed fast enough, e.g., USB devices are removed before device_del returns) and then remove the device from domain definition when we get the event from QEMU or when libvirtd reconnects to a domain and sees a particular device is no longer present. After all, devices may be removed even if we didn't ask for it (when the removal is initiated by a guest OS). And we should also provide similar event for higher level apps. Removing the device from domain config unless we get the event from qemu or find the device disappeared by polling makes sense. That's the mainly reason for we want the event and polling actually. But the problem is our APIs don't want to have long time hanging. If we don't change the APIs and return quickly just like what we do currently, it's confused for user, because when he wants to attach the device again while the device_del is still in progress, he will get the error like "Device ID *** is in used", however, our detaching APIs return success prior to that. I.E, if device_del needs long time to complete in some cases? can we live with it? Osier
[Qemu-devel] [PATCH] Add search path support for qemu data files.
This patch allows to specify multiple directories where qemu should look
for data files. To implement that the behavior of the -L switch is
slightly different now: Instead of replacing the data directory the
path specified will be appended to the data directory list. So when
specifiying -L multiple times all directories specified will be checked,
in the order they are specified on the command line, instead of just the
last one.
Additionally the default paths are always appended to the directory
data list. This allows to specify a incomplete directory (such as the
seabios out/ directory) via -L. Anything not found there will be loaded
from the default paths, so you don't have to create a symlink farm for
all the rom blobs.
For trouble-shooting a tracepoint has been added, logging which blob
has been loaded from which location.
Signed-off-by: Gerd Hoffmann
---
trace-events |1 +
vl.c | 36 +++-
2 files changed, 24 insertions(+), 13 deletions(-)
diff --git a/trace-events b/trace-events
index a27ae43..402504f 100644
--- a/trace-events
+++ b/trace-events
@@ -472,6 +472,7 @@ scsi_request_sense(int target, int lun, int tag) "target %d
lun %d tag %d"
# vl.c
vm_state_notify(int running, int reason) "running %d reason %d"
+load_file(const char *name, const char *path) "name %s location %s"
# block/qcow2.c
qcow2_writev_start_req(void *co, int64_t sector, int nb_sectors) "co %p sector
%" PRIx64 " nb_sectors %d"
diff --git a/vl.c b/vl.c
index c03edf1..d94c3fa 100644
--- a/vl.c
+++ b/vl.c
@@ -178,7 +178,8 @@ int main(int argc, char **argv)
#define MAX_VIRTIO_CONSOLES 1
#define MAX_SCLP_CONSOLES 1
-static const char *data_dir;
+static const char *data_dir[16];
+static int data_dir_idx;
const char *bios_name = NULL;
enum vga_retrace_method vga_retrace_method = VGA_RETRACE_DUMB;
DisplayType display_type = DT_DEFAULT;
@@ -2251,14 +2252,16 @@ static int balloon_parse(const char *arg)
char *qemu_find_file(int type, const char *name)
{
-int len;
+int i;
const char *subdir;
char *buf;
/* Try the name as a straight path first */
if (access(name, R_OK) == 0) {
+trace_load_file(name, name);
return g_strdup(name);
}
+
switch (type) {
case QEMU_FILE_TYPE_BIOS:
subdir = "";
@@ -2269,14 +2272,16 @@ char *qemu_find_file(int type, const char *name)
default:
abort();
}
-len = strlen(data_dir) + strlen(name) + strlen(subdir) + 2;
-buf = g_malloc0(len);
-snprintf(buf, len, "%s/%s%s", data_dir, subdir, name);
-if (access(buf, R_OK)) {
+
+for (i = 0; i < data_dir_idx; i++) {
+buf = g_strdup_printf("%s/%s%s", data_dir[i], subdir, name);
+if (access(buf, R_OK) == 0) {
+trace_load_file(name, buf);
+return buf;
+}
g_free(buf);
-return NULL;
}
-return buf;
+return NULL;
}
static int device_help_func(QemuOpts *opts, void *opaque)
@@ -3252,7 +3257,9 @@ int main(int argc, char **argv, char **envp)
add_device_config(DEV_GDB, optarg);
break;
case QEMU_OPTION_L:
-data_dir = optarg;
+if (data_dir_idx < ARRAY_SIZE(data_dir)) {
+data_dir[data_dir_idx++] = optarg;
+}
break;
case QEMU_OPTION_bios:
bios_name = optarg;
@@ -3892,12 +3899,15 @@ int main(int argc, char **argv, char **envp)
/* If no data_dir is specified then try to find it relative to the
executable path. */
-if (!data_dir) {
-data_dir = os_find_datadir(argv[0]);
+if (data_dir_idx < ARRAY_SIZE(data_dir)) {
+data_dir[data_dir_idx] = os_find_datadir(argv[0]);
+if (data_dir[data_dir_idx] != NULL) {
+data_dir_idx++;
+}
}
/* If all else fails use the install path specified when building. */
-if (!data_dir) {
-data_dir = CONFIG_QEMU_DATADIR;
+if (data_dir_idx < ARRAY_SIZE(data_dir)) {
+data_dir[data_dir_idx++] = CONFIG_QEMU_DATADIR;
}
/*
--
1.7.9.7
Re: [Qemu-devel] [PATCH v4 3/6] add backup related monitor commands
On Thu, Mar 07, 2013 at 09:28:40AM +, Dietmar Maurer wrote: > > > When we run backup, we need to read such block on every write from the > > guest. > > > So if we increase block size we get additional delays. > > > > Don't increase the bitmap block size. > > > > Just let the block job do larger reads. This is the bulk of the I/O > > workload. You > > can use large reads here independently of the bitmap block size. > > > > That way guest writes still only have a 64 KB read overhead but you reduce > > the > > overhead of doing so many 64 KB writes from the backup block job. > > If there are many writes from the guest, you still get many 64KB block. In the common case the backup block job does significantly more I/O than the guest, unless your workload is dd if=/dev/vda of=/dev/null. Remember the block job is reading the *entire* disk! > Anyways, and additional RPC layer always adds overhead, and It can be > completely avoided. > Maybe not much, but I want to make backup as efficient as possible. The drawbacks outweight the performance advantage: 1. QEMU can neither backup nor restore without help from the management tool. This is a strong indicator that the backup archive code should live outside QEMU. I doesn't make sense for proxmox, oVirt, OpenStack, and others to each maintain their backup archive code inside qemu.git, tied to QEMU's C codebase, release cycle, and license. 2. QEMU already has interfaces to export the vmstate and block device snapshots: migration/savevm and BlockDriverState (NBD for IPC or raw/qcow2/vmdk for file). It is not necessary to add a special-purpose interface just for backup. 3. The backup block job can be composed together with other QMP commands to achieve scenarios besides just VMA backup. It's more flexible to add simple primitives that can be combined instead of adding a monolithic backup command. For these reasons, I'm against putting backup archive code into QEMU. If performance is key, please look into incremental backups. Taking a full copy of the disk image every time affects guest performance much more than IPC overhead. Plus there'll be less IPC if only dirty blocks are backed up :). Stefan
Re: [Qemu-devel] [PATCH] qcow2: make is_allocated return true for zero clusters
On Wed, Mar 06, 2013 at 06:02:01PM +0100, Paolo Bonzini wrote: > Otherwise, live migration of the top layer will miss zero clusters and > let the backing file show through. This also matches what is done in qed. > > QCOW2_CLUSTER_ZERO clusters are invalid in v2 image files. Check this > directly in qcow2_get_cluster_offset instead of replicating the test > everywhere. > > Cc: qemu-sta...@nongnu.org > Signed-off-by: Paolo Bonzini > --- > block/qcow2.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Stefan Hajnoczi The qcow2 spec says: Bit 0:If set to 1, the cluster reads as all zeros. The host cluster offset can be used to describe a preallocation, but it won't be used for reading data from this cluster, nor is data read from the backing file if the cluster is unallocated. Your patch makes zero clusters "allocated", which does not violate the preallocation case.
Re: [Qemu-devel] [PATCH] qdev: DEVICE_DELETED event
On 2013年03月08日 16:50, Markus Armbruster wrote: Osier Yang writes: I'm wondering if it could be long time to wait for the device_del completes (AFAIK from previous bugs, it can be, though it should be fine for most of the cases). If it's too long, it will be a problem for management, because it looks like hanging. We can have a timeout for the device_del in libvirt, but the problem is the device_del can be still in progress by qemu, which could cause the inconsistency. Unless qemu has some command to cancel the device_del. I'm afraid cancelling isn't possible, at least not for PCI. Here's how device_del works for PCI when it works, roughly: 1. device_del asks the device model to unplug itself. 2. PCI device models delegate the job to the device model providing their PCI bus. Let's assume it's our PIIX3/PIIX4 mongrel. That one puts an unplug request into PIIX4 function 3 where guest ACPI can see it, and triggers its interrupt. Then it immediately sends the QMP success reply. 3. Guest ACPI (SeaBIOS) services the interrupt. It finds the unplug request, and asks the guest OS nicely to give up the device. 4. If the guest OS has a working ACPI driver, and it feels like giving up the device, it does so, and tells ACPI when it's done. 5. Guest ACPI cleans up whatever it needs cleaned up, and signals successful unplug by writing the slog number to a PIIX4 function 3 register. 6. The PIIX device destroys the device in that slot. I call this the ACPI unplug dance. We don't control steps 3..5. There's no way for the guest to tell us "I got your unplug request, but I'm not going to honor it". Even if their was, a guest without a working ACPI driver wouldn't use it, so we couldn't rely on it anyway. There's no way for us to tell the guest "I changed my mind on this unplug". All we can do is wait and see. Either the device goes away, or it stays. Hum, as I replied to Jirka in later mail, IMHO it needs to change libvirt detaching APIs to either wait for the event or find the device is really removed by polling before returning success. But it sounds to me that how long it takes to wait or polling is really depended? Osier
Re: [Qemu-devel] [PATCH v4 3/6] add backup related monitor commands
> > Anyways, and additional RPC layer always adds overhead, and It can be > completely avoided. > > Maybe not much, but I want to make backup as efficient as possible. > > The drawbacks outweight the performance advantage: not for me. > 1. QEMU can neither backup nor restore without help from the management >tool. Backup works perfectly with the current patches. You can easily trigger a backup using a HMP command. This is not really important, but works. > This is a strong indicator that the backup archive code should >live outside QEMU. I doesn't make sense for proxmox, oVirt, >OpenStack, and others to each maintain their backup archive code >inside qemu.git, tied to QEMU's C codebase, release cycle, and >license. > 2. QEMU already has interfaces to export the vmstate and block device >snapshots: migration/savevm and BlockDriverState (NBD for IPC or >raw/qcow2/vmdk for file). It is not necessary to add a >special-purpose interface just for backup. > > 3. The backup block job can be composed together with other QMP commands >to achieve scenarios besides just VMA backup. It's more flexible to >add simple primitives that can be combined instead of adding a >monolithic backup command. > > For these reasons, I'm against putting backup archive code into QEMU. That is OK for me - I already maintain the code outside of qemu.
Re: [Qemu-devel] [PATCH V7 0/5] Send the gratuitous by guest
On Thu, Mar 07, 2013 at 12:52:42PM +0200, Michael S. Tsirkin wrote: > On Thu, Mar 07, 2013 at 06:33:30PM +0800, Jason Wang wrote: > > On 03/07/2013 06:25 PM, Michael S. Tsirkin wrote: > > > On Thu, Mar 07, 2013 at 06:13:41PM +0800, Jason Wang wrote: > > >> On 03/07/2013 06:04 PM, Michael S. Tsirkin wrote: > > >>> On Thu, Mar 07, 2013 at 04:23:46PM +0800, Jason Wang wrote: > > This series tries to let guest instead of qemu to send the gratuitous > > packets > > after migration when guest is capable of doing this. This is needed > > since it's > > impossible for qemu to keep track of all configurations (e.g 802.1Q) > > and mac > > addresses (more than one mac address may be used by guest). So qemu > > can't build > > gratuitous packets for all those configurations properly. The only > > solution is > > let guest driver who knew all needed information to do this. > > > > The series first introduces a new runstate which just tracks the state > > when the > > migration is finished and guest is about to start. And then we can > > just trying > > to notify the guest to send the GARP after changing from this state to > > running. A model specific announcing method were also also introduced > > to let > > each kinds of nic do its own notification. When there's no such method > > register > > for the nic, the old style of sending RARP were kept. And the last two > > patches > > implemented the virtio-net method of notification. > > >>> Do we want to retry SELF_ANNOUNCE_ROUNDS? > > >> Yes, we do the announcement several times like in the past. > > Changes from V6: > > - introduce a new runstate instead of using a global variable check > > the state > > > > Changes from V5: > > - use a global variable to decide whether an announcement is needed > > after migration > > - align with virtio spec and let guest ack the announcement > > notification through > > control vq instead of config status writing > > > > Changes from V4: > > - keep the old behavior that send the gratuitous packets only after > > migration > > >>> I wonder why it's a sane thing to do. How about simply sending the > > >>> event after load? > > >> The aim is to limit the change of the behaviour to focus on migration. > > >> We may also need this after cont, > > > Hmm why after cont? > > > > If we stop the vm for a long period, the mac will be missed in the > > forward table of the bridge also. > > Hmm okay, needs some thought. One case where a physical machine is offline for a long time is Wake-on-LAN. Broadcast is used exactly for this reason. If a switch receives a packet to an unknown MAC it must broadcast. If a host doesn't have a IP-to-MAC table entry (due to timeout) it must send an ARP request. So I think this is all handled by existing behavior. If other hosts have forgotten about the VM's MAC they will send an ARP request, which the VM will respond to if it is running again. Stefan
[Qemu-devel] Host kernel crash at pci_find_upstream_pcie_bridge on VM exit
Hi, I am running qemu with kvm and VT-d enabled and a couple of PCI devices assigned to the guest VM. Both host and guest are running linux 2.6 kernel. The passthrough works fine, but when I exit the VM, the host kernel crashes with the following backtrace: <4>[ 5569.836893] Process qemu-system-x86 (pid: 2925, threadinfo 8801f5f4, task 88024fa28720) <0>[ 5569.944946] Stack: <4>[ 5569.968845] 8801f5f41aa8 811a45fb 88024f04b680 88024f049980 <4>[ 5570.057156] 88024f04b680 88024f049988 8801f5f41b08 811a6371 <4>[ 5570.145470] 8801f5f41ad8 81391045 0246 88024f049990 <0>[ 5570.233785] Call Trace: <4>[ 5570.262880] [] iommu_detach_dependent_devices+0x25/0x91 <4>[ 5570.344958] [] vm_domain_exit+0xf8/0x28b <4>[ 5570.411457] [] ? sub_preempt_count+0x92/0xa6 <4>[ 5570.482106] [] intel_iommu_domain_destroy+0x16/0x18 <4>[ 5570.560030] [] iommu_domain_free+0x16/0x22 <4>[ 5570.628611] [] kvm_iommu_unmap_guest+0x22/0x28 [kvm] <4>[ 5570.707570] [] kvm_arch_destroy_vm+0x19/0x12a [kvm] <4>[ 5570.785492] [] kvm_put_kvm+0xe6/0x129 [kvm] <4>[ 5570.855102] [] kvm_vcpu_release+0x13/0x17 [kvm] <4>[ 5570.928867] [] fput+0x117/0x1be <4>[ 5570.986013] [] filp_close+0x63/0x6d <4>[ 5571.047314] [] put_files_struct+0x6f/0xda <4>[ 5571.114845] [] exit_files+0x46/0x4e <4>[ 5571.176145] [] do_exit+0x1fc/0x681 <4>[ 5571.236416] [] ? kvm_arch_vcpu_ioctl_run+0xc2d/0xc55 [kvm] <4>[ 5571.321605] [] ? __mutex_lock_slowpath+0x26c/0x294 <4>[ 5571.398490] [] do_group_exit+0x72/0x9a <4>[ 5571.462907] [] get_signal_to_deliver+0x331/0x350 <4>[ 5571.537719] [] do_signal+0x6d/0x69a <4>[ 5571.599013] [] ? put_ldisc+0x92/0x97 <4>[ 5571.661353] [] ? do_vfs_ioctl+0x527/0x576 <4>[ 5571.728887] [] do_notify_resume+0x27/0x51 <4>[ 5571.796419] [] ? sys_ioctl+0x53/0x65 <4>[ 5571.858758] [] int_signal+0x12/0x17 <0>[ 5571.920058] Code: 48 85 d2 0f 95 c0 c9 c3 55 80 7f 4a 00 48 89 f8 48 89 e5 75 46 31 d2 48 8b 40 10 48 83 78 10 00 75 05 48 89 d0 eb 36 48 8b 40 38 <80> 78 4a 00 48 89 c2 74 e3 80 78 4b 07 74 23 80 3d 86 b5 5a 00 <1>[ 5572.145516] RIP [] pci_find_upstream_pcie_bridge+0x23/0x57 <4>[ 5572.230712] RSP Here is my qemu command line: qemu-system-x86_64 -M q35 --enable-kvm -m 2048 -nographic -vga std -usb -drive file=,if=none,id=drive-sata-disk0,format=raw -device ahci,id=ahci -device ide-drive,bus=ahci.0,drive=drive-sata-disk0,id=sata-disk0,bootindex=1 -device pci-assign,host=04:00.0 -device pci-assign,host=03:00.0 The two PCI devices in question are behind a PCIe bridge which is connected to the rootport. The crash seems to be happening when cleaning up the PCIe tree of the passed-through PCI devices. I tried passing through the downstream ports of the bridge as well, but that is not supported by qemu. Am I doing something wrong/unexpected here ? Any help in understanding this issue will help me fix the issue properly. Thanks, Ganesh
[Qemu-devel] [PULL] chardev: qapi conversion continued
Hi, This pull adds support for the missing chardev types and finally re-enabling the hmp monitor chardev-add chardev-remove commands as qmp is on par with hmp feature-wise now. Patches have been posted for review here: https://lists.nongnu.org/archive/html/qemu-devel/2013-02/msg05273.html There are no changes (except for a conflict-less rebase to master), so I'm not sending them again to the list. please pull, Gerd The following changes since commit 0bc472a9d6b80567c212023c5eae413f4dfb53ad: hw/nand.c: correct the sense of the BUSY/READY status bit (2013-03-07 09:27:11 +0100) are available in the git repository at: git://git.kraxel.org/qemu chardev.2 for you to fetch changes up to e15c7f86c0e0f5cf0b0ea71da7fb79d76b15e52c: Revert "hmp: Disable chardev-add and chardev-remove" (2013-03-08 07:27:40 +0100) Gerd Hoffmann (17): chardev: add support for qapi-based chardev initialization chardev: add mux chardev support to qapi chardev: switch null init to qapi chardev: add msmouse support to qapi chardev: add braille support to qapi chardev: switch file init to qapi chardev: add stdio support to qapi chardev: switch serial/tty init to qapi chardev: switch parallel init to qapi chardev: switch pty init to qapi chardev: add console support to qapi chardev: add pipe support to qapi chardev: add spice support to qapi chardev: add vc support to qapi chardev: add memory (ringbuf) support to qapi chardev: add udp support to qapi Revert "hmp: Disable chardev-add and chardev-remove" hmp-commands.hx | 63 --- hw/baum.c |2 +- hw/baum.h |2 +- hw/msmouse.c|2 +- hw/msmouse.h|2 +- include/qemu/sockets.h |1 + include/ui/console.h|4 +- include/ui/qemu-spice.h |7 +- qapi-schema.json| 104 ++- qemu-char.c | 440 +++ spice-qemu-char.c | 26 ++- ui/console.c| 26 +-- ui/gtk.c|2 +- util/qemu-sockets.c | 25 +++ 14 files changed, 491 insertions(+), 215 deletions(-)
Re: [Qemu-devel] [SeaBIOS] problems with freeBSD
On 03/08/13 04:35, Kevin O'Connor wrote: > On Thu, Mar 07, 2013 at 09:43:04AM +0100, Aurelien Jarno wrote: >> On Wed, Mar 06, 2013 at 07:53:51PM -0500, Kevin O'Connor wrote: >>> That change is definitely just build related - I don't see how it >>> could impact the final SeaBIOS binary. How did you conclude that this >>> commit is what fixes the issue? >>> >> >> I did a git bisect to find the commit fixing the issue. Then, as I was >> not believing the result, I tried the following sequence a dozen of >> times (for some unknown reasons the FreeBSD install CD doesn't exhibit >> the issue, so I used the Debian GNU/kFreeBSD installer): > [...] > > Thanks for the detailed bug report. Here's what I see going on: > > - the SeaBIOS 4219149a commit does change the resulting binary ever so > slightly - the src/virtio_ring.c code has a reference to __FILE__ > (the only code in SeaBIOS that does that), and due to slightly > different build rules in this commit it evaluates to a slightly > different string. > > - the freebsd crash has nothing to do with 4219149a or > src/virtio_ring.c - instead, random changes in the seabios binary > layout can cause (or avoid) the crash. You can see this in action > by modifying seabios to have higher debug levels, commenting out > code, adding dprintf statements, etc. > > - the crash happens when freebsd attempts to emulate the bios code (!) > in order to determine the keyboard typematic rate (!). (See > sys/dev/atkbdc/atkbd.c.) Since SeaBIOS doesn't support the typematic > callback rate (int 0x16 ax=0x0306) this doesn't actually achieve > anything in practice were the call to not crash. However, a crash > does (sometimes) result. > > - the freebsd x86bios_get_pages() code is buggy (See > sys/compat/x86bios/x86bios.c). It attempts to check that its x86 > emulater (!) doesn't access a page it hasn't mapped. However, it > does not check for the case where a two byte access spans two pages. > If the first page is mapped, but the second is not - splat. The > crash I've seen in QEMU had a two byte access to 0xff815fff > with the fault at 0xff816000. > > - I have not been able to determine why an attempt was made to access > a non-mapped page. My best guess is that the x86emu code (!) goes > off the deep-end in all cases - just some cases lead it to the bug > above and other cases lead it to a more friendly termination. > (Recall that SeaBIOS doesn't support the typematic call anyway.) It > should be possible to track this down by adding debug statements to > the freebsd code if anyone is familiar with the freebsd kernel > compile-deploy-run cycle. Great analysis! Laszlo (sorry for the noise)
Re: [Qemu-devel] [PATCH 1/7] block: only force IO completion in .bdrv_truncate if we are shrinking
Am 08.03.2013 um 10:35 schrieb Kevin Wolf : > Am 08.03.2013 um 10:23 hat Paolo Bonzini geschrieben: >> Il 08/03/2013 08:53, Peter Lieven ha scritto: I think the fix is to only call it for the monitor command. Optionally, when shrinking, assert that there are no requests in flight. >>> >>> Okay. >>> >>> What is the plan? just fix this or fix the whole thing (which seems to >>> be some >>> work). >>> >>> The suggested patch from Jeff will break iscsi_truncate as bs->growable >>> is 1 currently. >> >> I guess it's up to Kevin and Jeff. > > Someone needs to send a fix for the qcow1 (and probably vmdk) > regression, otherwise I'll have to revert the patch. What about Paolos suggestion to call bdrv_drain_all() from the block_resize command and not in bdrv_truncate? It is not a the complete solution, but it will fix the regression. However, what happens if someone resizes a qcow2 device? Peter > > Kevin
Re: [Qemu-devel] [PATCH 1/7] block: only force IO completion in .bdrv_truncate if we are shrinking
Am 08.03.2013 um 12:46 hat Peter Lieven geschrieben: > > Am 08.03.2013 um 10:35 schrieb Kevin Wolf : > > > Am 08.03.2013 um 10:23 hat Paolo Bonzini geschrieben: > >> Il 08/03/2013 08:53, Peter Lieven ha scritto: > > I think the fix is to only call it for the monitor command. Optionally, > when shrinking, assert that there are no requests in flight. > >>> > >>> Okay. > >>> > >>> What is the plan? just fix this or fix the whole thing (which seems to > >>> be some > >>> work). > >>> > >>> The suggested patch from Jeff will break iscsi_truncate as bs->growable > >>> is 1 currently. > >> > >> I guess it's up to Kevin and Jeff. > > > > Someone needs to send a fix for the qcow1 (and probably vmdk) > > regression, otherwise I'll have to revert the patch. > > What about Paolos suggestion to call bdrv_drain_all() from the block_resize > command and not in bdrv_truncate? It is not a the complete solution, but it > will fix the regression. However, what happens if someone resizes a qcow2 > device? I suppose you mean qcow1? It doesn't support resizing images, but even if it did, this shouldn't be a problem: The problematic case is the call of bdrv_drain_all() during a read/write function, which would have to wait for itself to complete. As soon as you restrict the bdrv_drain_all() to the monitor, waiting for in-flight I/Os should just work. Kevin
Re: [Qemu-devel] [PATCH] qdev: DEVICE_DELETED event
Osier Yang writes: > On 2013年03月08日 16:50, Markus Armbruster wrote: >> Osier Yang writes: >> >>> I'm wondering if it could be long time to wait for the device_del >>> completes (AFAIK from previous bugs, it can be, though it should be >>> fine for most of the cases). If it's too long, it will be a problem >>> for management, because it looks like hanging. We can have a timeout >>> for the device_del in libvirt, but the problem is the device_del >>> can be still in progress by qemu, which could cause the inconsistency. >>> Unless qemu has some command to cancel the device_del. >> >> I'm afraid cancelling isn't possible, at least not for PCI. >> >> Here's how device_del works for PCI when it works, roughly: >> >> 1. device_del asks the device model to unplug itself. >> >> 2. PCI device models delegate the job to the device model providing >> their PCI bus. Let's assume it's our PIIX3/PIIX4 mongrel. That one >> puts an unplug request into PIIX4 function 3 where guest ACPI can see >> it, and triggers its interrupt. Then it immediately sends the QMP >> success reply. >> >> 3. Guest ACPI (SeaBIOS) services the interrupt. It finds the unplug >> request, and asks the guest OS nicely to give up the device. >> >> 4. If the guest OS has a working ACPI driver, and it feels like giving >> up the device, it does so, and tells ACPI when it's done. >> >> 5. Guest ACPI cleans up whatever it needs cleaned up, and signals >> successful unplug by writing the slog number to a PIIX4 function 3 >> register. >> >> 6. The PIIX device destroys the device in that slot. >> >> I call this the ACPI unplug dance. >> >> We don't control steps 3..5. >> >> There's no way for the guest to tell us "I got your unplug request, but >> I'm not going to honor it". Even if their was, a guest without a >> working ACPI driver wouldn't use it, so we couldn't rely on it anyway. >> >> There's no way for us to tell the guest "I changed my mind on this >> unplug". All we can do is wait and see. Either the device goes away, >> or it stays. > > Hum, as I replied to Jirka in later mail, IMHO it needs to change > libvirt detaching APIs to either wait for the event or find the > device is really removed by polling before returning success. But > it sounds to me that how long it takes to wait or polling is really > depended? Time between device_del and event DEVICE_DELETED event is *unbounded*. Could be instantaneous, could be never, could be anything in between. I'd expect it to be either fairly short or never most of the time in practice.
Re: [Qemu-devel] [PULL 0/5] Trivial patches for 22 February to 8 March 2013
On Fri, Mar 8, 2013 at 10:48 AM, Stefan Hajnoczi wrote: > The following changes since commit 0bc472a9d6b80567c212023c5eae413f4dfb53ad: > > hw/nand.c: correct the sense of the BUSY/READY status bit (2013-03-07 > 09:27:11 +0100) > > are available in the git repository at: > > git://github.com/stefanha/qemu.git trivial-patches > > for you to fetch changes up to 5ccbb63abba9034b265a34282ccf4ae2164df501: > > osdep: replace setsockopt by qemu_setsockopt (2013-03-08 10:46:00 +0100) Please ignore this pull request. I will resend with missing patches that I dropped by accident. Stefan
[Qemu-devel] [PULL v2 0/8] Trivial patches for 22 February to 8 March 2013
I misplaced some patches by accident, this is the fixed pull request. The following changes since commit 0bc472a9d6b80567c212023c5eae413f4dfb53ad: hw/nand.c: correct the sense of the BUSY/READY status bit (2013-03-07 09:27:11 +0100) are available in the git repository at: git://github.com/stefanha/qemu.git trivial-patches for you to fetch changes up to db2d5eba652ecb7420ac4ef79fc747ef391ad0d9: Fix the wrong description in qemu manual (2013-03-08 13:15:27 +0100) Cole Robinson (1): rtc-test: Fix test failures with recent glib Jan Kiszka (1): configure: Create link to icon bitmap for out-of-tree builds Lei Li (2): osdep: replace setsockopt by qemu_setsockopt Fix the wrong description in qemu manual Michal Privoznik (1): configure: Require at least spice-protocol-0.12.3 Paolo Bonzini (1): lm32: remove unused function Peter Maydell (1): pci_host: Drop write-only address_space field Stefan Berger (1): rng-random: Use qemu_open / qemu_close backends/rng-random.c | 4 ++-- configure | 3 ++- hw/milkymist-hw.h | 16 hw/pci/pci_host.h | 1 - hw/piix_pci.c | 1 - hw/ppc/prep.c | 1 - qemu-options.hx | 2 +- tests/rtc-test.c | 4 ++-- util/osdep.c | 4 ++-- 9 files changed, 9 insertions(+), 27 deletions(-) -- 1.8.1.4
[Qemu-devel] [PATCH 1/8] configure: Create link to icon bitmap for out-of-tree builds
From: Jan Kiszka This allows to pick up the icon when starting QEMU directly from an out-of-tree build directory. Signed-off-by: Jan Kiszka Reviewed-by: Stefan Weil Signed-off-by: Stefan Hajnoczi --- configure | 1 + 1 file changed, 1 insertion(+) diff --git a/configure b/configure index 2f98c5a..87b2e73 100755 --- a/configure +++ b/configure @@ -4369,6 +4369,7 @@ FILES="$FILES tests/tcg/lm32/Makefile po/Makefile" FILES="$FILES pc-bios/optionrom/Makefile pc-bios/keymaps" FILES="$FILES pc-bios/spapr-rtas/Makefile" FILES="$FILES roms/seabios/Makefile roms/vgabios/Makefile" +FILES="$FILES pc-bios/qemu-icon.bmp" for bios_file in \ $source_path/pc-bios/*.bin \ $source_path/pc-bios/*.aml \ -- 1.8.1.4
[Qemu-devel] [PATCH 2/8] rtc-test: Fix test failures with recent glib
From: Cole Robinson
As of glib 2.35.4, glib changed its logic for ordering test cases:
https://bugzilla.gnome.org/show_bug.cgi?id=694487
This was causing failures in rtc-test. Group the reordered test
cases into their own suite, which maintains the original ordering.
CC: qemu-sta...@nongnu.org
Signed-off-by: Cole Robinson
Signed-off-by: Stefan Hajnoczi
---
tests/rtc-test.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/rtc-test.c b/tests/rtc-test.c
index c5fd042..9ab583b 100644
--- a/tests/rtc-test.c
+++ b/tests/rtc-test.c
@@ -565,8 +565,8 @@ int main(int argc, char **argv)
qtest_add_func("/rtc/basic/bcd-12h", basic_12h_bcd);
qtest_add_func("/rtc/set-year/20xx", set_year_20xx);
qtest_add_func("/rtc/set-year/1980", set_year_1980);
-qtest_add_func("/rtc/register_b_set_flag", register_b_set_flag);
-qtest_add_func("/rtc/fuzz-registers", fuzz_registers);
+qtest_add_func("/rtc/misc/register_b_set_flag", register_b_set_flag);
+qtest_add_func("/rtc/misc/fuzz-registers", fuzz_registers);
ret = g_test_run();
if (s) {
--
1.8.1.4
[Qemu-devel] [PATCH 3/8] lm32: remove unused function
From: Paolo Bonzini
The milkymist-minimac device in fact does not exist at all.
Signed-off-by: Paolo Bonzini
Acked-by: Michael Walle
Signed-off-by: Stefan Hajnoczi
---
hw/milkymist-hw.h | 16
1 file changed, 16 deletions(-)
diff --git a/hw/milkymist-hw.h b/hw/milkymist-hw.h
index c8bd7e9..5def311 100644
--- a/hw/milkymist-hw.h
+++ b/hw/milkymist-hw.h
@@ -170,22 +170,6 @@ static inline DeviceState *milkymist_ac97_create(hwaddr
base,
return dev;
}
-static inline DeviceState *milkymist_minimac_create(hwaddr base,
-qemu_irq rx_irq, qemu_irq tx_irq)
-{
-DeviceState *dev;
-
-qemu_check_nic_model(&nd_table[0], "minimac");
-dev = qdev_create(NULL, "milkymist-minimac");
-qdev_set_nic_properties(dev, &nd_table[0]);
-qdev_init_nofail(dev);
-sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, base);
-sysbus_connect_irq(SYS_BUS_DEVICE(dev), 0, rx_irq);
-sysbus_connect_irq(SYS_BUS_DEVICE(dev), 1, tx_irq);
-
-return dev;
-}
-
static inline DeviceState *milkymist_minimac2_create(hwaddr base,
hwaddr buffers_base, qemu_irq rx_irq, qemu_irq tx_irq)
{
--
1.8.1.4
[Qemu-devel] [PATCH 4/8] osdep: replace setsockopt by qemu_setsockopt
From: Lei Li
Fix the compiler warning when cross build qemu-ga
for windows by using qemu_setsockopt() instead of
setsockopt().
util/osdep.c: In function 'socket_set_nodelay':
util/osdep.c:69:5: warning: passing argument 4 of 'setsockopt' from
incompatible pointer type [enabled by default]
In file included from /home/lei/qemu_b/include/sysemu/os-win32.h:30:0,
from /home/lei/qemu_b/include/qemu-common.h:46,
from util/osdep.c:48:
/usr/i686-w64-mingw32/sys-root/mingw/include/winsock2.h:990:63: note:
expected 'const char *' but argument is of type 'int *'
Signed-off-by: Lei Li
Signed-off-by: Stefan Hajnoczi
---
util/osdep.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/util/osdep.c b/util/osdep.c
index c408261..bd59ac9 100644
--- a/util/osdep.c
+++ b/util/osdep.c
@@ -57,7 +57,7 @@ static const char *qemu_version = QEMU_VERSION;
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));
+return qemu_setsockopt(fd, SOL_TCP, TCP_CORK, &v, sizeof(v));
#else
return 0;
#endif
@@ -66,7 +66,7 @@ int socket_set_cork(int fd, int v)
int socket_set_nodelay(int fd)
{
int v = 1;
-return setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &v, sizeof(v));
+return qemu_setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &v, sizeof(v));
}
int qemu_madvise(void *addr, size_t len, int advice)
--
1.8.1.4
[Qemu-devel] [PATCH 5/8] configure: Require at least spice-protocol-0.12.3
From: Michal Privoznik As of 5a49d3e9 we assume SPICE_PORT_EVENT_BREAK to be defined. However, it is defined not in 0.12.2 what we require now, but in 0.12.3. Therefore in order to prevent build failure we must adjust our minimal requirements. Signed-off-by: Stefan Hajnoczi --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index 87b2e73..f2c46b2 100755 --- a/configure +++ b/configure @@ -2871,7 +2871,7 @@ EOF spice_cflags=$($pkg_config --cflags spice-protocol spice-server 2>/dev/null) spice_libs=$($pkg_config --libs spice-protocol spice-server 2>/dev/null) if $pkg_config --atleast-version=0.12.0 spice-server >/dev/null 2>&1 && \ - $pkg_config --atleast-version=0.12.2 spice-protocol > /dev/null 2>&1 && \ + $pkg_config --atleast-version=0.12.3 spice-protocol > /dev/null 2>&1 && \ compile_prog "$spice_cflags" "$spice_libs" ; then spice="yes" libs_softmmu="$libs_softmmu $spice_libs" -- 1.8.1.4
[Qemu-devel] [PATCH 6/8] rng-random: Use qemu_open / qemu_close
From: Stefan Berger
In the rng backend use qemu_open and qemu_close rather than POSIX
open/close.
Signed-off-by: Stefan Berger
Reviewed-by: Eric Blake
Signed-off-by: Stefan Hajnoczi
---
backends/rng-random.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/backends/rng-random.c b/backends/rng-random.c
index 0d11088..acd20af 100644
--- a/backends/rng-random.c
+++ b/backends/rng-random.c
@@ -74,7 +74,7 @@ static void rng_random_opened(RngBackend *b, Error **errp)
error_set(errp, QERR_INVALID_PARAMETER_VALUE,
"filename", "a valid filename");
} else {
-s->fd = open(s->filename, O_RDONLY | O_NONBLOCK);
+s->fd = qemu_open(s->filename, O_RDONLY | O_NONBLOCK);
if (s->fd == -1) {
error_set(errp, QERR_OPEN_FILE_FAILED, s->filename);
@@ -130,7 +130,7 @@ static void rng_random_finalize(Object *obj)
qemu_set_fd_handler(s->fd, NULL, NULL, NULL);
if (s->fd != -1) {
-close(s->fd);
+qemu_close(s->fd);
}
g_free(s->filename);
--
1.8.1.4
[Qemu-devel] [PATCH 8/8] Fix the wrong description in qemu manual
From: Lei Li
Fix LP#1151450 the wrong description in qemu manual:
'qemu-system-x86_84' should be 'qemu-system-x86_64'.
Signed-off-by: Lei Li
Signed-off-by: Stefan Hajnoczi
---
qemu-options.hx | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index 6f9334a..cd76f2a 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2132,7 +2132,7 @@
gluster[+transport]://[server[:port]]/volname/image[?socket=...]
Example
@example
-qemu-system-x86_84 --drive file=gluster://192.0.2.1/testvol/a.img
+qemu-system-x86_64 --drive file=gluster://192.0.2.1/testvol/a.img
@end example
See also @url{http://www.gluster.org}.
--
1.8.1.4
[Qemu-devel] [PATCH 7/8] pci_host: Drop write-only address_space field
From: Peter Maydell
The address_space field of PCIHostState was only ever written, never used.
Drop it completely.
Signed-off-by: Peter Maydell
Reviewed-by: Andreas Färber
Signed-off-by: Stefan Hajnoczi
---
hw/pci/pci_host.h | 1 -
hw/piix_pci.c | 1 -
hw/ppc/prep.c | 1 -
3 files changed, 3 deletions(-)
diff --git a/hw/pci/pci_host.h b/hw/pci/pci_host.h
index 1845d4d..236cd0f 100644
--- a/hw/pci/pci_host.h
+++ b/hw/pci/pci_host.h
@@ -40,7 +40,6 @@ struct PCIHostState {
MemoryRegion conf_mem;
MemoryRegion data_mem;
MemoryRegion mmcfg;
-MemoryRegion *address_space;
uint32_t config_reg;
PCIBus *bus;
};
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index 6c77e49..9246983 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -244,7 +244,6 @@ static PCIBus *i440fx_common_init(const char *device_name,
dev = qdev_create(NULL, "i440FX-pcihost");
s = PCI_HOST_BRIDGE(dev);
-s->address_space = address_space_mem;
b = pci_bus_new(dev, NULL, pci_address_space,
address_space_io, 0);
s->bus = b;
diff --git a/hw/ppc/prep.c b/hw/ppc/prep.c
index e06dded..2920911 100644
--- a/hw/ppc/prep.c
+++ b/hw/ppc/prep.c
@@ -567,7 +567,6 @@ static void ppc_prep_init(QEMUMachineInitArgs *args)
dev = qdev_create(NULL, "raven-pcihost");
pcihost = PCI_HOST_BRIDGE(dev);
-pcihost->address_space = get_system_memory();
object_property_add_child(qdev_get_machine(), "raven", OBJECT(dev), NULL);
qdev_init_nofail(dev);
pci_bus = (PCIBus *)qdev_get_child_bus(dev, "pci.0");
--
1.8.1.4
[Qemu-devel] [PATCH] .gitignore: add tracing/generated-events.[ch]
Don't display autogenerated files in git-status(1). Signed-off-by: Stefan Hajnoczi --- A quick follow-up to Lluís Vilanova's generic event state description series. .gitignore | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.gitignore b/.gitignore index 27ad002..af4e3e6 100644 --- a/.gitignore +++ b/.gitignore @@ -7,6 +7,8 @@ trace/generated-tracers.h trace/generated-tracers.c trace/generated-tracers-dtrace.h trace/generated-tracers-dtrace.dtrace +trace/generated-events.h +trace/generated-events.c libcacard/trace/generated-tracers.c *-timestamp *-softmmu -- 1.8.1.4
Re: [Qemu-devel] [PATCH 3/9] dataplane: remove EventPoll in favor of AioContext
On Fri, 08 Mar 2013 10:22:36 +0100
Paolo Bonzini wrote:
> Il 08/03/2013 09:37, Christian Borntraeger ha scritto:
> > +if (assign) {
> > +int r = event_notifier_init(notifier, 0);
> > +
> > +if (r < 0) {
> > +return r;
> > +}
> > +virtio_queue_set_guest_notifier_fd_handler(vq, true, with_irqfd);
>
> Perhaps you can simply hard-code with_irqfd to false in this call to
> virtio_queue_set_guest_notifier_fd_handler and the one below? Then the
> guest notifier will be emulated in userspace and processed via
> vdev->binding->notify.
Well, effectively with_irqfd is already hardcoded to false (as
virtio_ccw_set_guest_notifiers() always calls this function with
with_irqfd=false), so that doesn't seem to be the problem here.
>
> You will not need to overwrite the EventNotifier which is IMO a pretty
> ufly violation of encapsulation. :)
>
> Paolo
>
> > +/* We do not support irqfd for classic I/O interrupts, because the
> > + * classic interrupts are intermixed with the subchannel status,
> > that
> > + * is queried with test subchannel. We want to use vhost, though.
> > + * Lets make sure to have vhost running and wire up the irq fd to
> > + * land in qemu (and only the irq fd) in this code.
> > + */
> > +if (dev->vdev->guest_notifier_mask) {
> > +dev->vdev->guest_notifier_mask(dev->vdev, n, false);
> > +}
> > +/* get lost events and re-inject */
> > +if (dev->vdev->guest_notifier_pending &&
> > +dev->vdev->guest_notifier_pending(dev->vdev, n)) {
> > +event_notifier_set(notifier);
> > +}
> > +} else {
> > +if (dev->vdev->guest_notifier_mask) {
> > +dev->vdev->guest_notifier_mask(dev->vdev, n, true);
> > +}
> > +virtio_queue_set_guest_notifier_fd_handler(vq, false, with_irqfd);
> > +event_notifier_cleanup(notifier);
>
Re: [Qemu-devel] [PER] Re: socket, mcast looping back frames -> IPv6 broken
Samuel Thibault, le Fri 08 Mar 2013 10:08:55 +0100, a écrit : > There does exist some unique address, which is returned by recvfrom, > I'll have a look at how to get access to it. Ah, no, it's not unique... It's just the host IP address and the same port as the multicast address, so it'll be the same for all qemus on the same host. I've checked how Linux bounces the datagram, it's through the loopback interface, and thus dispatched over all listeners without distinction. I don't see any way to get the information that the packet comes from us, except using the ethernet content. Samuel
Re: [Qemu-devel] [PATCH] .gitignore: add tracing/generated-events.[ch]
Stefan Hajnoczi writes: > Don't display autogenerated files in git-status(1). > Signed-off-by: Stefan Hajnoczi Reviewed-by: Lluís Vilanova > --- > A quick follow-up to Lluís Vilanova's generic event state description series. > .gitignore | 2 ++ > 1 file changed, 2 insertions(+) > diff --git a/.gitignore b/.gitignore > index 27ad002..af4e3e6 100644 > --- a/.gitignore > +++ b/.gitignore > @@ -7,6 +7,8 @@ trace/generated-tracers.h > trace/generated-tracers.c > trace/generated-tracers-dtrace.h > trace/generated-tracers-dtrace.dtrace > +trace/generated-events.h > +trace/generated-events.c > libcacard/trace/generated-tracers.c > *-timestamp > *-softmmu > -- > 1.8.1.4 -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth
Re: [Qemu-devel] [PATCH] .gitignore: add tracing/generated-events.[ch]
BTW, a minor thing. I just noticed the subject should be ".gitignore: add trace/generated-events.[ch]" ;) Lluis Stefan Hajnoczi writes: > Don't display autogenerated files in git-status(1). > Signed-off-by: Stefan Hajnoczi > --- > A quick follow-up to Lluís Vilanova's generic event state description series. > .gitignore | 2 ++ > 1 file changed, 2 insertions(+) > diff --git a/.gitignore b/.gitignore > index 27ad002..af4e3e6 100644 > --- a/.gitignore > +++ b/.gitignore > @@ -7,6 +7,8 @@ trace/generated-tracers.h > trace/generated-tracers.c > trace/generated-tracers-dtrace.h > trace/generated-tracers-dtrace.dtrace > +trace/generated-events.h > +trace/generated-events.c > libcacard/trace/generated-tracers.c > *-timestamp > *-softmmu > -- > 1.8.1.4 -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth
Re: [Qemu-devel] [PATCH v4] qdev: DEVICE_DELETED event
Markus Armbruster writes: > "Michael S. Tsirkin" writes: > >> On Thu, Mar 07, 2013 at 08:57:52PM +0100, Markus Armbruster wrote: >>> "Michael S. Tsirkin" writes: >>> >>> > libvirt has a long-standing bug: when removing the device, >>> > it can request removal but does not know when the >>> > removal completes. Add an event so we can fix this in a robust way. >>> > >>> > Signed-off-by: Michael S. Tsirkin >>> >>> Speaking as the acting QMP maintainer, just to avoid misunderstandings: >>> there's disagreement on the event's design, namely when it should fire, >>> and how it should name the device. I don't want the discussion >>> preempted by a commit. >> >> Yes, you are asking for more functionality, but can I add this in a >> follow-up commit please? I prefer this patch as is, as it can be >> backported to stable branches and downstreams. Upstream a follow up >> patch can add fields and more triggers which won't apply to any >> downstreams. > > If you want to address my review comments in a separate patch, go right > ahead. Please post both together as a series, for coherent review and > to simplify patch tracking. > > I'm asking for two things: > > 1. Event member path. Fair to call this "more functionality". I agree >that backporting it to pre-QOM versions isn't practical. > > 2. Sane event trigger condition: on any device deletion, not just when >the device happens to have a qdev ID. This isn't "more", it's >"different". Ack. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH 3/9] dataplane: remove EventPoll in favor of AioContext
Il 08/03/2013 13:44, Cornelia Huck ha scritto: >> > Perhaps you can simply hard-code with_irqfd to false in this call to >> > virtio_queue_set_guest_notifier_fd_handler and the one below? Then the >> > guest notifier will be emulated in userspace and processed via >> > vdev->binding->notify. > > Well, effectively with_irqfd is already hardcoded to false (as > virtio_ccw_set_guest_notifiers() always calls this function with > with_irqfd=false), so that doesn't seem to be the problem here. Actually, the guest->host notifier is not touched by either the old or the new code. The code I modified only worries about the host->guest notifier. How did you track the problem to the assignment by value of EventNotifiers? BTW: >> You will not need to overwrite the EventNotifier which is IMO a pretty >> ufly violation of encapsulation. This was nonsense. :) Paolo
Re: [Qemu-devel] [Qemu-stable] [SeaBIOS] problems with freeBSD
On Fri, Mar 08, 2013 at 12:03:15AM +0800, Peter Maydell wrote: > Earlier in this thread it's been stated that this often produces > subtly broken blobs... I think there have been some far reaching conclusions in this thread based on incorrect premises. SeaBIOS has had problems with mis-compilations in the past. To handle this, the SeaBIOS build runs test cases on every compilation to verify the tool chain (see tools/test-build.sh). I have not seen a report of a guest visible SeaBIOS mis-compilation in many years. There have been a few cases of guest bugs that get tickled when changes to SeaBIOS cause slightly different memory layouts. The last case of this that comes to mind is the JunOS bug that was tracked down a year and a half ago. The root cause of the FreeBSD issue raised in this thread is very similar - the full details aren't known yet, but we do know that a slightly different memory layout is ticking a bug in a FreeBSD page presence check. Since changes are inevitable anyway (the only alternative would be to never enhance SeaBIOS), I don't believe that dictating one "true compiler" or one "true blob" is necessary or desirable. -Kevin
[Qemu-devel] [PATCH v2 1/2] input: make QEMUPutLEDEntry + QEMUPutMouseEntry private
There is no need for anybody outside ui/input.c to access the
struct elements. Move the definitions, leaving only the typedefs
in the header files.
Signed-off-by: Gerd Hoffmann
---
include/ui/console.h | 19 ++-
ui/input.c | 18 ++
2 files changed, 20 insertions(+), 17 deletions(-)
diff --git a/include/ui/console.h b/include/ui/console.h
index c42bca6..ce5a550 100644
--- a/include/ui/console.h
+++ b/include/ui/console.h
@@ -27,23 +27,8 @@ typedef void QEMUPutKBDEvent(void *opaque, int keycode);
typedef void QEMUPutLEDEvent(void *opaque, int ledstate);
typedef void QEMUPutMouseEvent(void *opaque, int dx, int dy, int dz, int
buttons_state);
-typedef struct QEMUPutMouseEntry {
-QEMUPutMouseEvent *qemu_put_mouse_event;
-void *qemu_put_mouse_event_opaque;
-int qemu_put_mouse_event_absolute;
-char *qemu_put_mouse_event_name;
-
-int index;
-
-/* used internally by qemu for handling mice */
-QTAILQ_ENTRY(QEMUPutMouseEntry) node;
-} QEMUPutMouseEntry;
-
-typedef struct QEMUPutLEDEntry {
-QEMUPutLEDEvent *put_led;
-void *opaque;
-QTAILQ_ENTRY(QEMUPutLEDEntry) next;
-} QEMUPutLEDEntry;
+typedef struct QEMUPutMouseEntry QEMUPutMouseEntry;
+typedef struct QEMUPutLEDEntry QEMUPutLEDEntry;
void qemu_add_kbd_event_handler(QEMUPutKBDEvent *func, void *opaque);
void qemu_remove_kbd_event_handler(void);
diff --git a/ui/input.c b/ui/input.c
index 9abef0c..87a23df 100644
--- a/ui/input.c
+++ b/ui/input.c
@@ -29,6 +29,24 @@
#include "qmp-commands.h"
#include "qapi-types.h"
+struct QEMUPutMouseEntry {
+QEMUPutMouseEvent *qemu_put_mouse_event;
+void *qemu_put_mouse_event_opaque;
+int qemu_put_mouse_event_absolute;
+char *qemu_put_mouse_event_name;
+
+int index;
+
+/* used internally by qemu for handling mice */
+QTAILQ_ENTRY(QEMUPutMouseEntry) node;
+};
+
+struct QEMUPutLEDEntry {
+QEMUPutLEDEvent *put_led;
+void *opaque;
+QTAILQ_ENTRY(QEMUPutLEDEntry) next;
+};
+
static QEMUPutKBDEvent *qemu_put_kbd_event;
static void *qemu_put_kbd_event_opaque;
static QTAILQ_HEAD(, QEMUPutLEDEntry) led_handlers =
QTAILQ_HEAD_INITIALIZER(led_handlers);
--
1.7.9.7
[Qemu-devel] [PATCH v2 2/2] input: introduce keyboard handler list
Add a linked list of keyboard handlers. Added handlers will go
to the head of the list. Removed handlers will be zapped from
the list. The head of the list will be used for events.
This fixes the keyboard-dead-after-usb-kbd-unplug issue, key events
will be re-routed to the ps/2 kbd instead of being discarded.
[ v2: fix cut+paste bug found my Markus ]
Signed-off-by: Gerd Hoffmann
---
hw/hid.c |4 ++--
hw/hid.h |1 +
include/ui/console.h |6 --
ui/input.c | 37 +
4 files changed, 32 insertions(+), 16 deletions(-)
diff --git a/hw/hid.c b/hw/hid.c
index 89b5415..6be00ec 100644
--- a/hw/hid.c
+++ b/hw/hid.c
@@ -415,7 +415,7 @@ void hid_free(HIDState *hs)
{
switch (hs->kind) {
case HID_KEYBOARD:
-qemu_remove_kbd_event_handler();
+qemu_remove_kbd_event_handler(hs->kbd.eh_entry);
break;
case HID_MOUSE:
case HID_TABLET:
@@ -431,7 +431,7 @@ void hid_init(HIDState *hs, int kind, HIDEventFunc event)
hs->event = event;
if (hs->kind == HID_KEYBOARD) {
-qemu_add_kbd_event_handler(hid_keyboard_event, hs);
+hs->kbd.eh_entry = qemu_add_kbd_event_handler(hid_keyboard_event, hs);
} else if (hs->kind == HID_MOUSE) {
hs->ptr.eh_entry = qemu_add_mouse_event_handler(hid_pointer_event, hs,
0, "QEMU HID Mouse");
diff --git a/hw/hid.h b/hw/hid.h
index 56c71ed..2567879 100644
--- a/hw/hid.h
+++ b/hw/hid.h
@@ -31,6 +31,7 @@ typedef struct HIDKeyboardState {
uint8_t leds;
uint8_t key[16];
int32_t keys;
+QEMUPutKbdEntry *eh_entry;
} HIDKeyboardState;
struct HIDState {
diff --git a/include/ui/console.h b/include/ui/console.h
index ce5a550..fd39d94 100644
--- a/include/ui/console.h
+++ b/include/ui/console.h
@@ -28,10 +28,12 @@ typedef void QEMUPutLEDEvent(void *opaque, int ledstate);
typedef void QEMUPutMouseEvent(void *opaque, int dx, int dy, int dz, int
buttons_state);
typedef struct QEMUPutMouseEntry QEMUPutMouseEntry;
+typedef struct QEMUPutKbdEntry QEMUPutKbdEntry;
typedef struct QEMUPutLEDEntry QEMUPutLEDEntry;
-void qemu_add_kbd_event_handler(QEMUPutKBDEvent *func, void *opaque);
-void qemu_remove_kbd_event_handler(void);
+QEMUPutKbdEntry *qemu_add_kbd_event_handler(QEMUPutKBDEvent *func,
+void *opaque);
+void qemu_remove_kbd_event_handler(QEMUPutKbdEntry *entry);
QEMUPutMouseEntry *qemu_add_mouse_event_handler(QEMUPutMouseEvent *func,
void *opaque, int absolute,
const char *name);
diff --git a/ui/input.c b/ui/input.c
index 87a23df..57e963b 100644
--- a/ui/input.c
+++ b/ui/input.c
@@ -41,18 +41,25 @@ struct QEMUPutMouseEntry {
QTAILQ_ENTRY(QEMUPutMouseEntry) node;
};
+struct QEMUPutKbdEntry {
+QEMUPutKBDEvent *put_kbd;
+void *opaque;
+QTAILQ_ENTRY(QEMUPutKbdEntry) next;
+};
+
struct QEMUPutLEDEntry {
QEMUPutLEDEvent *put_led;
void *opaque;
QTAILQ_ENTRY(QEMUPutLEDEntry) next;
};
-static QEMUPutKBDEvent *qemu_put_kbd_event;
-static void *qemu_put_kbd_event_opaque;
-static QTAILQ_HEAD(, QEMUPutLEDEntry) led_handlers =
QTAILQ_HEAD_INITIALIZER(led_handlers);
+static QTAILQ_HEAD(, QEMUPutLEDEntry) led_handlers =
+QTAILQ_HEAD_INITIALIZER(led_handlers);
+static QTAILQ_HEAD(, QEMUPutKbdEntry) kbd_handlers =
+QTAILQ_HEAD_INITIALIZER(kbd_handlers);
static QTAILQ_HEAD(, QEMUPutMouseEntry) mouse_handlers =
QTAILQ_HEAD_INITIALIZER(mouse_handlers);
-static NotifierList mouse_mode_notifiers =
+static NotifierList mouse_mode_notifiers =
NOTIFIER_LIST_INITIALIZER(mouse_mode_notifiers);
static const int key_defs[] = {
@@ -306,16 +313,20 @@ void qmp_send_key(KeyValueList *keys, bool has_hold_time,
int64_t hold_time,
muldiv64(get_ticks_per_sec(), hold_time, 1000));
}
-void qemu_add_kbd_event_handler(QEMUPutKBDEvent *func, void *opaque)
+QEMUPutKbdEntry *qemu_add_kbd_event_handler(QEMUPutKBDEvent *func, void
*opaque)
{
-qemu_put_kbd_event_opaque = opaque;
-qemu_put_kbd_event = func;
+QEMUPutKbdEntry *entry;
+
+entry = g_malloc0(sizeof(QEMUPutKbdEntry));
+entry->put_kbd = func;
+entry->opaque = opaque;
+QTAILQ_INSERT_HEAD(&kbd_handlers, entry, next);
+return entry;
}
-void qemu_remove_kbd_event_handler(void)
+void qemu_remove_kbd_event_handler(QEMUPutKbdEntry *entry)
{
-qemu_put_kbd_event_opaque = NULL;
-qemu_put_kbd_event = NULL;
+QTAILQ_REMOVE(&kbd_handlers, entry, next);
}
static void check_mode_change(void)
@@ -399,11 +410,13 @@ void qemu_remove_led_event_handler(QEMUPutLEDEntry *entry)
void kbd_put_keycode(int keycode)
{
+QEMUPutKbdEntry *entry = QTAILQ_FIRST(&kbd_handlers);
+
if (!runstate_is_running() && !runstate_check(RUN_STATE_SUSPENDED)) {
return;
}
-if (qemu_put_kb
[Qemu-devel] [PATCH v2 0/2] input: add keyboard handler list
Hi, Little input patch series, first patch being a small cleanup, second patch adds a linked list of keyboard handlers, so removing a handler (on usb kbd unplug) will not make keyboard stop working but fallback to another keyboard (if present). cheers, Gerd Gerd Hoffmann (2): input: make QEMUPutLEDEntry + QEMUPutMouseEntry private input: introduce keyboard handler list hw/hid.c |4 ++-- hw/hid.h |1 + include/ui/console.h | 25 ++- ui/input.c | 55 +++--- 4 files changed, 52 insertions(+), 33 deletions(-) -- 1.7.9.7
[Qemu-devel] Mentors and project ideas wanted for GSoC 2013
QEMU will apply to Google Summer of Code 2013 on Monday 18th March. We need the have project ideas ready as part of QEMU's application as a GSoC 2013 organization. The wiki is still sparse so I'm asking that everyone posts their project ideas: http://wiki.qemu.org/Google_Summer_of_Code_2013 Quick recap: Google Summer of Code is a 12-week program where university students are funded to contribute to open source projects. QEMU will apply and we need project ideas that students can work on this summer. The experience can be very rewarding for students and mentors, and QEMU has participated in past years. Each project idea needs a QEMU contributor who is willing to mentor a student. At the bottom of the wiki page there is information if you want to find out what mentoring is all about. If you have questions about posting project ideas or mentoring, please respond or ping me on IRC! CCed a subset of folks who might be interested. Thanks, Stefan
Re: [Qemu-devel] [PATCH] .gitignore: add tracing/generated-events.[ch]
On Fri, Mar 8, 2013 at 2:11 PM, Lluís Vilanova wrote: > BTW, a minor thing. I just noticed the subject should be > ".gitignore: add trace/generated-events.[ch]" ;) Thanks. I also forgot to add trace/generated-events.dtrace. Stefan
[Qemu-devel] [PATCH] trace: rebuild generated-events.o when configuration changes
Make sure to rebuild generated-events.o when ./configure options change. This prevents linker errors when a stale generated-events.o gets linked with code compiled against fresh headers. For example, try building with ./configure --enable-trace-backend=stderr followed by ./configure --enable-trace-backend=dtrace. Signed-off-by: Stefan Hajnoczi --- trace/Makefile.objs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/trace/Makefile.objs b/trace/Makefile.objs index 156aa25..a043072 100644 --- a/trace/Makefile.objs +++ b/trace/Makefile.objs @@ -11,7 +11,7 @@ $(obj)/generated-events.h-timestamp: $(SRC_PATH)/trace-events < $< > $@," GEN $(patsubst %-timestamp,%,$@)") @cmp -s $@ $(patsubst %-timestamp,%,$@) || cp $@ $(patsubst %-timestamp,%,$@) -$(obj)/generated-events.c: $(obj)/generated-events.c-timestamp +$(obj)/generated-events.c: $(obj)/generated-events.c-timestamp $(BUILD_DIR)/config-host.mak $(obj)/generated-events.c-timestamp: $(SRC_PATH)/trace-events $(call quiet-command,$(TRACETOOL) \ --format=events-c \ -- 1.8.1.4
Re: [Qemu-devel] [PATCH] .gitignore: add tracing/generated-events.[ch]
On Fri, Mar 8, 2013 at 3:49 PM, Stefan Hajnoczi wrote: > On Fri, Mar 8, 2013 at 2:11 PM, Lluís Vilanova wrote: >> BTW, a minor thing. I just noticed the subject should be >> ".gitignore: add trace/generated-events.[ch]" ;) > > Thanks. I also forgot to add trace/generated-events.dtrace. I meant trace/generated-tracers.dtrace. Stefan
Re: [Qemu-devel] [SeaBIOS] [Qemu-stable] problems with freeBSD
Kevin O'Connor wrote: > I don't believe that dictating one "true compiler" or one "true > blob" is necessary or desirable. Sure. The point isn't to have only one correct way, but to have reliable results in the common case. A reference toolchain and a reference blob both help accomplish that, but they're by no means the only, or even best, methods. //Peter
[Qemu-devel] [PATCH v2 1/2] .gitignore: add trace/generated-events.[ch]
Don't display autogenerated files in git-status(1). Signed-off-by: Stefan Hajnoczi --- .gitignore | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.gitignore b/.gitignore index 27ad002..af4e3e6 100644 --- a/.gitignore +++ b/.gitignore @@ -7,6 +7,8 @@ trace/generated-tracers.h trace/generated-tracers.c trace/generated-tracers-dtrace.h trace/generated-tracers-dtrace.dtrace +trace/generated-events.h +trace/generated-events.c libcacard/trace/generated-tracers.c *-timestamp *-softmmu -- 1.8.1.4
[Qemu-devel] [PATCH v2 2/2] .gitignore: rename trace/generated-tracers.dtrace
For a while the file was called trace/generated-tracers-dtrace.dtrace but today it's called trace/generated-tracers.dtrace. Signed-off-by: Stefan Hajnoczi --- .gitignore | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.gitignore b/.gitignore index af4e3e6..87ef1f5 100644 --- a/.gitignore +++ b/.gitignore @@ -6,7 +6,7 @@ config-target.* trace/generated-tracers.h trace/generated-tracers.c trace/generated-tracers-dtrace.h -trace/generated-tracers-dtrace.dtrace +trace/generated-tracers.dtrace trace/generated-events.h trace/generated-events.c libcacard/trace/generated-tracers.c -- 1.8.1.4
[Qemu-devel] [PATCH v2 0/2] .gitignore: tracing updates
The .gitignore file no longer covers all autogenerated tracing file. These patches update .gitignore. Stefan Hajnoczi (2): .gitignore: add trace/generated-events.[ch] .gitignore: rename trace/generated-tracers.dtrace .gitignore | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- 1.8.1.4
[Qemu-devel] [Bug 1151986] Re: buffer overflow after block-stream via QMP
1.4.0 is the intended stable release for Ubuntu raring. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1151986 Title: buffer overflow after block-stream via QMP Status in QEMU: New Bug description: When a block-stream is initiated via QMP and the QMP socket is closed on client side before the job is finished, QEMU crashes with a buffer overflow, somewhere at the end of the streaming process. Without QMP I can stream via the HMP without problems. After crashing, I cannot boot from the active image anymore. I was able to reproduce this with qemu-kvm and qemu-system-x86_64 on two different machines. Version: QEMU emulator version 1.2.0 (qemu-kvm-1.2.0), Copyright (c) 2003-2008 Fabrice Bellard I started QEMU with the following script: qemu-kvm \ -monitor vc \ -m 512 \ -hda "$1" \ -net nic,vlan=0 \ -net user,vlan=0 \ -localtime \ -smp 2 \ -qmp tcp:localhost:,server,nowait Backtrace: Formatting '/home/helge/images/vm01.2013-03-07_11:30:13.qcow2', fmt=qcow2 size=1048576 backing_file='/home/helge/images/vm01.qcow2' backing_fmt='qcow2' encryption=off cluster_size=65536 lazy_refcounts=off *** buffer overflow detected ***: qemu-kvm terminated === Backtrace: = /usr/lib/libc.so.6(__fortify_fail+0x37)[0x7f054e91a8c7] /usr/lib/libc.so.6(+0xfc9a0)[0x7f054e9189a0] /usr/lib/libc.so.6(+0xfe837)[0x7f054e91a837] qemu-kvm(+0xdb0dc)[0x7f055220b0dc] qemu-kvm(+0x15f581)[0x7f055228f581] qemu-kvm(main+0xf93)[0x7f05521a3e93] /usr/lib/libc.so.6(__libc_start_main+0xf5)[0x7f054e83da15] qemu-kvm(+0x77e8d)[0x7f05521a7e8d] === Memory map: 7f051bdff000-7f051be0 rw-p 00:00 0 7f051be0-7f053be0 rw-p 00:00 0 7f053be0-7f053c00 rw-p 00:00 0 7f053c00-7f053c021000 rw-p 00:00 0 7f053c021000-7f054000 ---p 00:00 0 7f05421e2000-7f05421f7000 r-xp 08:12 1175478 /usr/lib/libgcc_s.so.1 7f05421f7000-7f05423f6000 ---p 00015000 08:12 1175478 /usr/lib/libgcc_s.so.1 7f05423f6000-7f05423f7000 rw-p 00014000 08:12 1175478 /usr/lib/libgcc_s.so.1 7f05423f7000-7f05423f8000 ---p 00:00 0 7f05423f8000-7f0542bf8000 rw-p 00:00 0 [stack:27848] 7f0542bf8000-7f0542bfd000 r-xp 08:12 1198566 /usr/lib/libXfixes.so.3.1.0 7f0542bfd000-7f0542dfd000 ---p 5000 08:12 1198566 /usr/lib/libXfixes.so.3.1.0 7f0542dfd000-7f0542dfe000 r--p 5000 08:12 1198566 /usr/lib/libXfixes.so.3.1.0 7f0542dfe000-7f0542dff000 rw-p 6000 08:12 1198566 /usr/lib/libXfixes.so.3.1.0 7f0542dff000-7f0542e0 rw-p 00:00 0 7f0542e0-7f0543e0 rw-p 00:00 0 7f0543e0-7f054400 rw-p 00:00 0 7f054400-7f0544139000 rw-p 00:00 0 7f0544139000-7f054800 ---p 00:00 0 7f0548014000-7f054801e000 r-xp 08:12 1198746 /usr/lib/libXrender.so.1.3.0 7f054801e000-7f054821d000 ---p a000 08:12 1198746 /usr/lib/libXrender.so.1.3.0 7f054821d000-7f054821e000 r--p 9000 08:12 1198746 /usr/lib/libXrender.so.1.3.0 7f054821e000-7f054821f000 rw-p a000 08:12 1198746 /usr/lib/libXrender.so.1.3.0 7f054821f000-7f0548228000 r-xp 08:12 1199189 /usr/lib/libXcursor.so.1.0.2 7f0548228000-7f0548427000 ---p 9000 08:12 1199189 /usr/lib/libXcursor.so.1.0.2 7f0548427000-7f0548428000 r--p 8000 08:12 1199189 /usr/lib/libXcursor.so.1.0.2 7f0548428000-7f0548429000 rw-p 9000 08:12 1199189 /usr/lib/libXcursor.so.1.0.2 7f0548429000-7f0548721000 r--p 08:12 1175421 /usr/lib/locale/locale-archive 7f0548721000-7f0548733000 r-xp 08:12 1198126 /usr/lib/libXext.so.6.4.0 7f0548733000-7f0548932000 ---p 00012000 08:12 1198126 /usr/lib/libXext.so.6.4.0 7f0548932000-7f0548933000 r--p 00011000 08:12 1198126 /usr/lib/libXext.so.6.4.0 7f0548933000-7f0548934000 rw-p 00012000 08:12 1198126 /usr/lib/libXext.so.6.4.0 7f054895d000-7f05489c rw-p 00:00 0 7f054895d000-7f05489c rw-p 00:00 0 [118/1982] 7f05489d3000-7f0548aed000 rw-s 00:04 69697543 /SYSV (deleted) 7f0548aed000-7f0548aee000 ---p 00:00 0 7f0548aee000-7f05492ee000 rw-p 00:00 0 [stack:27612] 7f05492ee000-7f05492ef000 ---p 00:00 0 7f05492ef000-7f0549aef0
Re: [Qemu-devel] [PATCH v4 3/6] add backup related monitor commands
On Fri, Mar 8, 2013 at 12:01 PM, Dietmar Maurer wrote: >> > Anyways, and additional RPC layer always adds overhead, and It can be >> completely avoided. >> > Maybe not much, but I want to make backup as efficient as possible. >> >> The drawbacks outweight the performance advantage: > > not for me. > >> 1. QEMU can neither backup nor restore without help from the management >>tool. > > Backup works perfectly with the current patches. You can easily trigger a > backup using > a HMP command. This is not really important, but works. If you send me a VMA file I can't restore it without knowing your command-line and possibly setting up the environment. QEMU just can't do that, it's out of scope. That is why the backup archive is a management tool concept. >> This is a strong indicator that the backup archive code should >>live outside QEMU. I doesn't make sense for proxmox, oVirt, >>OpenStack, and others to each maintain their backup archive code >>inside qemu.git, tied to QEMU's C codebase, release cycle, and >>license. >> 2. QEMU already has interfaces to export the vmstate and block device >>snapshots: migration/savevm and BlockDriverState (NBD for IPC or >>raw/qcow2/vmdk for file). It is not necessary to add a >>special-purpose interface just for backup. >> >> 3. The backup block job can be composed together with other QMP commands >>to achieve scenarios besides just VMA backup. It's more flexible to >>add simple primitives that can be combined instead of adding a >>monolithic backup command. >> >> For these reasons, I'm against putting backup archive code into QEMU. > > That is OK for me - I already maintain the code outside of qemu. Does this mean you will keep this patch series out-of-tree? What I am looking for is a stripped down patch series with just a backup block job (no backup archive writer or migration code). That would be easily merged and saves you front rebasing this series as QEMU changes. Stefan
Re: [Qemu-devel] [PATCH 16/17] chardev: add udp support to qapi
On 02/28/2013 12:50 AM, Gerd Hoffmann wrote: > This patch adds 'udb' support to qapi. If it's not too late: s/udb/udp/ > > Signed-off-by: Gerd Hoffmann > --- -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
[Qemu-devel] [PATCH 2/2] qga: add windows implementation for guest-set-time
Signed-off-by: Lei Li
---
qga/commands-win32.c | 35 +++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/qga/commands-win32.c b/qga/commands-win32.c
index 0a2bb34..b5d4bd3 100644
--- a/qga/commands-win32.c
+++ b/qga/commands-win32.c
@@ -140,6 +140,41 @@ int64_t qmp_guest_get_time(Error **errp)
return time_ns;
}
+void qmp_guest_set_time(int64_t time_ns, Error **errp)
+{
+SYSTEMTIME ts;
+FILETIME tf;
+LONGLONG time;
+
+acquire_privilege(SE_SYSTEMTIME_NAME, errp);
+if (error_is_set(errp)) {
+error_setg(errp, "Failed to acquire privilege");
+return;
+}
+
+time = time_ns / 100 + W32_FT_OFFSET;
+/* FILETIME values should be less than 0x8000
+ for function FileTimeToSystemTime. */
+if (time & 0x8000) {
+error_setg(errp, "Time %" PRId64 "is too large", time);
+return;
+}
+
+tf.dwLowDateTime = (DWORD) time;
+tf.dwHighDateTime = (DWORD) (time >> 32);
+
+if (!FileTimeToSystemTime(&tf, &ts)) {
+error_setg(errp, "Failed to convert system time");
+return;
+}
+
+if (!SetSystemTime(&ts)) {
+slog("guest-set-time failed: %d", GetLastError());
+error_setg_errno(errp, errno, "Failed to set time to guest");
+return;
+}
+}
+
int64_t qmp_guest_file_open(const char *path, bool has_mode, const char *mode,
Error **err)
{
error_set(err, QERR_UNSUPPORTED);
--
1.7.7.6
[Qemu-devel] [PATCH 0/2 v2] Add Windows support for time resync by qemu-ga
This patch series attempts to add Windows implementation for qemu-ga commands guest-get-time and guest-set-time. The previous thread about the interfaces introduced and the POSIX-specific command implementation has already been accepted, the reference link: http://article.gmane.org/gmane.comp.emulators.qemu/198472 Notes: Now It was just tested on Windows XP SP3. I planed to test it on Windows 7 today, unfortunately did not find the ISO, so I have to download it. Since it's still on going, I'd like to send this series out to have your suggestions. Please comment! Thanks. Changes since v1: - Make the macro for the offset between windows baseline and Unix Epoch more readable from Eric. - Overflow check for filetime pointed by Eric. Lei Li (2): qga: add windows implementation for guest-get-time qga: add windows implementation for guest-set-time
[Qemu-devel] [PATCH 1/2] qga: add windows implementation for guest-get-time
Signed-off-by: Lei Li
---
qga/commands-win32.c | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/qga/commands-win32.c b/qga/commands-win32.c
index 7e8ecb3..0a2bb34 100644
--- a/qga/commands-win32.c
+++ b/qga/commands-win32.c
@@ -22,6 +22,12 @@
#define SHTDN_REASON_FLAG_PLANNED 0x8000
#endif
+/* multiple of 100 nanoseconds elapsed between windows baseline
+ (1/1/1601) and Unix Epoch (1/1/1970), accounting for leap years */
+#define W32_FT_OFFSET (1000ULL * 60 * 60 * 24 * \
+ (365 * (1970 - 1601) + \
+(1970 - 1601) / 4 - 3))
+
static void acquire_privilege(const char *name, Error **err)
{
HANDLE token;
@@ -108,6 +114,32 @@ void qmp_guest_shutdown(bool has_mode, const char *mode,
Error **err)
}
}
+int64_t qmp_guest_get_time(Error **errp)
+{
+ SYSTEMTIME *ts = g_malloc0(sizeof(SYSTEMTIME));
+ int64_t time_ns;
+ union {
+ UINT64 ns100;
+ FILETIME tf;
+ } time;
+
+ GetSystemTime(ts);
+ if (!ts) {
+ slog("guest-get-time failed: %d", GetLastError());
+ error_setg_errno(errp, errno, "Failed to get time");
+ return -1;
+ }
+
+ if (!SystemTimeToFileTime(ts, &time.tf)) {
+ error_setg_errno(errp, errno, "Failed to convert system time");
+ return -1;
+ }
+
+ time_ns = (int64_t)((time.ns100 - W32_FT_OFFSET) * 100);
+
+ return time_ns;
+}
+
int64_t qmp_guest_file_open(const char *path, bool has_mode, const char *mode,
Error **err)
{
error_set(err, QERR_UNSUPPORTED);
--
1.7.7.6
Re: [Qemu-devel] [PATCH] RTC: enable lost_tick_policy=slew as default (v2)
On Thu, Mar 07, 2013 at 09:25:17AM +0100, Paolo Bonzini wrote:
> Il 12/12/2012 22:36, Marcelo Tosatti ha scritto:
> >
> > RTC interrupt reinjection has no known negative effect. Lack of
> > RTC interrupt reinjection, though, has negative effects: time drift
> > for Windows guests which use it as a timer source.
> >
> > Based on that, enable lost_tick_policy=slew option as default.
> >
> > Signed-off-by: Marcelo Tosatti
> >
> > v2: do not change default for older machines types (Paolo Bonzini)
> >
> > diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
> > index c79fca7..c9e007d 100644
> > --- a/hw/mc146818rtc.c
> > +++ b/hw/mc146818rtc.c
> > @@ -884,7 +884,7 @@ ISADevice *rtc_init(ISABus *bus, int base_year,
> > qemu_irq intercept_irq)
> > static Property mc146818rtc_properties[] = {
> > DEFINE_PROP_INT32("base_year", RTCState, base_year, 1980),
> > DEFINE_PROP_LOSTTICKPOLICY("lost_tick_policy", RTCState,
> > - lost_tick_policy, LOST_TICK_DISCARD),
> > + lost_tick_policy, LOST_TICK_SLEW),
> > DEFINE_PROP_END_OF_LIST(),
> > };
> >
> > diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> > index 19e342a..475bb4c 100644
> > --- a/hw/pc_piix.c
> > +++ b/hw/pc_piix.c
> > @@ -295,6 +295,10 @@ static QEMUMachine pc_machine_v1_4 = {
> > .driver = "usb-tablet",\
> > .property = "usb_version",\
> > .value= stringify(1),\
> > +},{\
> > +.driver = "mc146818rtc",\
> > +.property = "lost_tick_policy",\
> > +.value= "discard",\
> > }
> >
> > static QEMUMachine pc_machine_v1_3 = {
> >
> >
>
> Looks like this was never applied. Can you redo it for the new 1.5
> machine (compatibility defines are now in hw/pc.h)?
>
> Paolo
Anthony mentioned that this
http://article.gmane.org/gmane.comp.emulators.qemu/160699
Is the proper way to do it.
Re: [Qemu-devel] [PATCH v4 3/6] add backup related monitor commands
> >> 1. QEMU can neither backup nor restore without help from the management > >>tool. > > > > Backup works perfectly with the current patches. You can easily > > trigger a backup using a HMP command. This is not really important, but > > works. > > If you send me a VMA file I can't restore it without knowing your command-line > and possibly setting up the environment. QEMU just can't do that, it's out of > scope. That is why the backup archive is a management tool concept. I don't really know why you insist on that claim. I can do a backup with hmp command, and then restore that later using the management tools. I just need to issue the correct hmp backup command. But this is not relevant for this discussion, so let us continue. We talked about the overhead of the additional IPC layer. > > >> This is a strong indicator that the backup archive code should > >>live outside QEMU. I doesn't make sense for proxmox, oVirt, > >>OpenStack, and others to each maintain their backup archive code > >>inside qemu.git, tied to QEMU's C codebase, release cycle, and > >>license. > >> 2. QEMU already has interfaces to export the vmstate and block device > >>snapshots: migration/savevm and BlockDriverState (NBD for IPC or > >>raw/qcow2/vmdk for file). It is not necessary to add a > >>special-purpose interface just for backup. > >> > >> 3. The backup block job can be composed together with other QMP > commands > >>to achieve scenarios besides just VMA backup. It's more flexible to > >>add simple primitives that can be combined instead of adding a > >>monolithic backup command. > >> > >> For these reasons, I'm against putting backup archive code into QEMU. > > > > That is OK for me - I already maintain the code outside of qemu. > > Does this mean you will keep this patch series out-of-tree? > > What I am looking for is a stripped down patch series with just a backup block > job (no backup archive writer or migration code). That would be easily merged > and saves you front rebasing this series as QEMU changes. That is Patch 2/6?
Re: [Qemu-devel] [PATCH] RTC: enable lost_tick_policy=slew as default (v2)
Marcelo Tosatti writes:
> On Thu, Mar 07, 2013 at 09:25:17AM +0100, Paolo Bonzini wrote:
>> Il 12/12/2012 22:36, Marcelo Tosatti ha scritto:
>> >
>> > RTC interrupt reinjection has no known negative effect. Lack of
>> > RTC interrupt reinjection, though, has negative effects: time drift
>> > for Windows guests which use it as a timer source.
>> >
>> > Based on that, enable lost_tick_policy=slew option as default.
>> >
>> > Signed-off-by: Marcelo Tosatti
>> >
>> > v2: do not change default for older machines types (Paolo Bonzini)
>> >
>> > diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
>> > index c79fca7..c9e007d 100644
>> > --- a/hw/mc146818rtc.c
>> > +++ b/hw/mc146818rtc.c
>> > @@ -884,7 +884,7 @@ ISADevice *rtc_init(ISABus *bus, int base_year,
>> > qemu_irq intercept_irq)
>> > static Property mc146818rtc_properties[] = {
>> > DEFINE_PROP_INT32("base_year", RTCState, base_year, 1980),
>> > DEFINE_PROP_LOSTTICKPOLICY("lost_tick_policy", RTCState,
>> > - lost_tick_policy, LOST_TICK_DISCARD),
>> > + lost_tick_policy, LOST_TICK_SLEW),
>> > DEFINE_PROP_END_OF_LIST(),
>> > };
>> >
>> > diff --git a/hw/pc_piix.c b/hw/pc_piix.c
>> > index 19e342a..475bb4c 100644
>> > --- a/hw/pc_piix.c
>> > +++ b/hw/pc_piix.c
>> > @@ -295,6 +295,10 @@ static QEMUMachine pc_machine_v1_4 = {
>> > .driver = "usb-tablet",\
>> > .property = "usb_version",\
>> > .value= stringify(1),\
>> > +},{\
>> > +.driver = "mc146818rtc",\
>> > +.property = "lost_tick_policy",\
>> > +.value= "discard",\
>> > }
>> >
>> > static QEMUMachine pc_machine_v1_3 = {
>> >
>> >
>>
>> Looks like this was never applied. Can you redo it for the new 1.5
>> machine (compatibility defines are now in hw/pc.h)?
>>
>> Paolo
>
> Anthony mentioned that this
>
> http://article.gmane.org/gmane.comp.emulators.qemu/160699
>
> Is the proper way to do it.
That breaks too. I don't have a solution but I also don't remember what
the exact failures are.
I'm planning on running this patch through testing again so I can
provide better feedback.
Regards,
Anthony Liguori
[Qemu-devel] [PATCH] MinGW: Replace setsockopt by qemu_setsocketopt
Instead of adding missing type casts which are needed by MinGW for the
4th argument, the patch uses qemu_setsockopt which was invented for this
purpose.
Signed-off-by: Stefan Weil
---
I did not fix some coding style issues in modified slirp code
(tabs, line length). Nor did I replace setsockopt in code which
is unused for MinGW (linux-user, tests).
- Stefan W.
bt-host.c |2 +-
gdbstub.c |2 +-
net/socket.c| 21 ++---
slirp/misc.c|4 ++--
slirp/socket.c |4 ++--
slirp/tcp_subr.c|8
slirp/udp.c |2 +-
util/osdep.c|4 ++--
util/qemu-sockets.c | 10 +-
9 files changed, 28 insertions(+), 29 deletions(-)
diff --git a/bt-host.c b/bt-host.c
index 2092754..2da3c32 100644
--- a/bt-host.c
+++ b/bt-host.c
@@ -171,7 +171,7 @@ struct HCIInfo *bt_host_hci(const char *id)
hci_filter_all_ptypes(&flt);
hci_filter_all_events(&flt);
-if (setsockopt(fd, SOL_HCI, HCI_FILTER, &flt, sizeof(flt)) < 0) {
+if (qemu_setsockopt(fd, SOL_HCI, HCI_FILTER, &flt, sizeof(flt)) < 0) {
fprintf(stderr, "qemu: Can't set HCI filter on socket (%i)\n", errno);
return 0;
}
diff --git a/gdbstub.c b/gdbstub.c
index e414ad9..d82181b 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -2887,7 +2887,7 @@ static int gdbserver_open(int port)
/* allow fast reuse */
val = 1;
-setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, (char *)&val, sizeof(val));
+qemu_setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &val, sizeof(val));
sockaddr.sin_family = AF_INET;
sockaddr.sin_port = htons(port);
diff --git a/net/socket.c b/net/socket.c
index 396dc8c..d8b35a2 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -262,8 +262,7 @@ static int net_socket_mcast_create(struct sockaddr_in
*mcastaddr, struct in_addr
}
val = 1;
-ret=setsockopt(fd, SOL_SOCKET, SO_REUSEADDR,
- (const char *)&val, sizeof(val));
+ret = qemu_setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &val, sizeof(val));
if (ret < 0) {
perror("setsockopt(SOL_SOCKET, SO_REUSEADDR)");
goto fail;
@@ -283,8 +282,8 @@ static int net_socket_mcast_create(struct sockaddr_in
*mcastaddr, struct in_addr
imr.imr_interface.s_addr = htonl(INADDR_ANY);
}
-ret = setsockopt(fd, IPPROTO_IP, IP_ADD_MEMBERSHIP,
- (const char *)&imr, sizeof(struct ip_mreq));
+ret = qemu_setsockopt(fd, IPPROTO_IP, IP_ADD_MEMBERSHIP,
+ &imr, sizeof(struct ip_mreq));
if (ret < 0) {
perror("setsockopt(IP_ADD_MEMBERSHIP)");
goto fail;
@@ -292,8 +291,8 @@ static int net_socket_mcast_create(struct sockaddr_in
*mcastaddr, struct in_addr
/* Force mcast msgs to loopback (eg. several QEMUs in same host */
loop = 1;
-ret=setsockopt(fd, IPPROTO_IP, IP_MULTICAST_LOOP,
- (const char *)&loop, sizeof(loop));
+ret = qemu_setsockopt(fd, IPPROTO_IP, IP_MULTICAST_LOOP,
+ &loop, sizeof(loop));
if (ret < 0) {
perror("setsockopt(SOL_IP, IP_MULTICAST_LOOP)");
goto fail;
@@ -301,8 +300,8 @@ static int net_socket_mcast_create(struct sockaddr_in
*mcastaddr, struct in_addr
/* If a bind address is given, only send packets from that address */
if (localaddr != NULL) {
-ret = setsockopt(fd, IPPROTO_IP, IP_MULTICAST_IF,
- (const char *)localaddr, sizeof(*localaddr));
+ret = qemu_setsockopt(fd, IPPROTO_IP, IP_MULTICAST_IF,
+ localaddr, sizeof(*localaddr));
if (ret < 0) {
perror("setsockopt(IP_MULTICAST_IF)");
goto fail;
@@ -521,7 +520,7 @@ static int net_socket_listen_init(NetClientState *peer,
/* allow fast reuse */
val = 1;
-setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, (const char *)&val, sizeof(val));
+qemu_setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &val, sizeof(val));
ret = bind(fd, (struct sockaddr *)&saddr, sizeof(saddr));
if (ret < 0) {
@@ -659,8 +658,8 @@ static int net_socket_udp_init(NetClientState *peer,
return -1;
}
val = 1;
-ret = setsockopt(fd, SOL_SOCKET, SO_REUSEADDR,
- (const char *)&val, sizeof(val));
+ret = qemu_setsockopt(fd, SOL_SOCKET, SO_REUSEADDR,
+ &val, sizeof(val));
if (ret < 0) {
perror("setsockopt(SOL_SOCKET, SO_REUSEADDR)");
closesocket(fd);
diff --git a/slirp/misc.c b/slirp/misc.c
index d4df972..6b9c2c4 100644
--- a/slirp/misc.c
+++ b/slirp/misc.c
@@ -212,9 +212,9 @@ fork_exec(struct socket *so, const char *ex, int do_pty)
} while (so->s < 0 && errno == EINTR);
closesocket(s);
opt = 1;
-setsockopt(so->s, SOL_SOCKET, SO_REUSEADDR, (char *)&opt,
sizeof(int));
+qemu_setsockopt(so->s, SOL_SOCKET, SO_REUSEADDR, &opt,
sizeof(int));
[Qemu-devel] [PATCH 05/66] target-ppc: Drop nested TARGET_PPC64 guard for POWER7
From: Andreas Färber It is within a large TARGET_PPC64 section from 970 to 620, so an #endif /* TARGET_PPC64 */ is confusing. Clean this up. Signed-off-by: Andreas Färber Signed-off-by: Alexander Graf --- target-ppc/translate_init.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c index d00c737..98a64e1 100644 --- a/target-ppc/translate_init.c +++ b/target-ppc/translate_init.c @@ -6671,7 +6671,6 @@ static void init_proc_970MP (CPUPPCState *env) vscr_init(env, 0x0001); } -#if defined(TARGET_PPC64) /* POWER7 */ #define POWERPC_INSNS_POWER7 (PPC_INSNS_BASE | PPC_STRING | PPC_MFTB | \ PPC_FLOAT | PPC_FLOAT_FSEL | PPC_FLOAT_FRES | \ @@ -6755,7 +6754,6 @@ static void init_proc_POWER7 (CPUPPCState *env) * value is the one used by 74xx processors. */ vscr_init(env, 0x0001); } -#endif /* TARGET_PPC64 */ /* PowerPC 620 */ #define POWERPC_INSNS_620(PPC_INSNS_BASE | PPC_STRING | PPC_MFTB |\ -- 1.6.0.2
[Qemu-devel] [PATCH 03/66] target-ppc: Fix "G2leGP3" PVR
From: Andreas Färber
Unlike derived PVR constants mapped to CPU_POWERPC_G2LEgp3, the
"G2leGP3" model definition itself used the CPU_POWERPC_G2LEgp1 PVR.
Fixing this will allow to alias CPU_POWERPC_G2LEgp3-using types to
"G2leGP3".
Signed-off-by: Andreas Färber
Signed-off-by: Alexander Graf
---
target-ppc/translate_init.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index a2e1fc9..d2706f7 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -8243,7 +8243,7 @@ static const ppc_def_t ppc_defs[] = {
/* PowerPC G2LE GP1 core */
POWERPC_DEF("G2leGP1", CPU_POWERPC_G2LEgp1,G2LE),
/* PowerPC G2LE GP3 core */
-POWERPC_DEF("G2leGP3", CPU_POWERPC_G2LEgp1,G2LE),
+POWERPC_DEF("G2leGP3", CPU_POWERPC_G2LEgp3,G2LE),
/* PowerPC MPC603 microcontrollers */
/* MPC8240 */
POWERPC_DEF("MPC8240", CPU_POWERPC_MPC8240,603E),
--
1.6.0.2
[Qemu-devel] [PATCH 08/66] target-ppc: Make -cpu "ppc" an alias to "ppc32"
From: Andreas Färber
Drop the #if 0'ed alternative to make it "ppc64" for TARGET_PPC64.
If we ever want to change it, we can more easily do so now.
Signed-off-by: Andreas Färber
Signed-off-by: Alexander Graf
---
target-ppc/translate_init.c | 29 +
1 files changed, 1 insertions(+), 28 deletions(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 862f40a..8923105 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -6824,33 +6824,6 @@ static void init_proc_620 (CPUPPCState *env)
#define check_pow_PPC64 check_pow_970FX
#define init_proc_PPC64 init_proc_970FX
-/* Default PowerPC target will be PowerPC 32 */
-#if defined (TARGET_PPC64) && 0 // XXX: TODO
-#define CPU_POWERPC_DEFAULTCPU_POWERPC_PPC64
-#define POWERPC_INSNS_DEFAULT POWERPC_INSNS_PPC64
-#define POWERPC_INSNS2_DEFAULT POWERPC_INSNS2_PPC64
-#define POWERPC_MSRM_DEFAULT POWERPC_MSRM_PPC64
-#define POWERPC_MMU_DEFAULTPOWERPC_MMU_PPC64
-#define POWERPC_EXCP_DEFAULT POWERPC_EXCP_PPC64
-#define POWERPC_INPUT_DEFAULT POWERPC_INPUT_PPC64
-#define POWERPC_BFDM_DEFAULT POWERPC_BFDM_PPC64
-#define POWERPC_FLAG_DEFAULT POWERPC_FLAG_PPC64
-#define check_pow_DEFAULT check_pow_PPC64
-#define init_proc_DEFAULT init_proc_PPC64
-#else
-#define CPU_POWERPC_DEFAULTCPU_POWERPC_PPC32
-#define POWERPC_INSNS_DEFAULT POWERPC_INSNS_PPC32
-#define POWERPC_INSNS2_DEFAULT POWERPC_INSNS2_PPC32
-#define POWERPC_MSRM_DEFAULT POWERPC_MSRM_PPC32
-#define POWERPC_MMU_DEFAULTPOWERPC_MMU_PPC32
-#define POWERPC_EXCP_DEFAULT POWERPC_EXCP_PPC32
-#define POWERPC_INPUT_DEFAULT POWERPC_INPUT_PPC32
-#define POWERPC_BFDM_DEFAULT POWERPC_BFDM_PPC32
-#define POWERPC_FLAG_DEFAULT POWERPC_FLAG_PPC32
-#define check_pow_DEFAULT check_pow_PPC32
-#define init_proc_DEFAULT init_proc_PPC32
-#endif
-
/*/
/* PVR definitions for most known PowerPC*/
enum {
@@ -9321,7 +9294,6 @@ static const ppc_def_t ppc_defs[] = {
POWERPC_DEF("ppc64", CPU_POWERPC_PPC64, PPC64)
#endif
POWERPC_DEF("ppc32", CPU_POWERPC_PPC32, PPC32)
-POWERPC_DEF("ppc", CPU_POWERPC_DEFAULT,DEFAULT)
};
typedef struct PowerPCCPUAlias {
@@ -9375,6 +9347,7 @@ static const PowerPCCPUAlias ppc_cpu_aliases[] = {
{ "RSC2", "POWER2" },
{ "P2SC", "POWER2" },
+{ "ppc", "ppc32" },
{ "default", "ppc" },
};
--
1.6.0.2
[Qemu-devel] [PATCH 11/66] target-ppc: Extract 40x aliases
From: Andreas Färber
Signed-off-by: Andreas Färber
Signed-off-by: Alexander Graf
---
target-ppc/translate_init.c | 25 +++--
1 files changed, 7 insertions(+), 18 deletions(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 6a86e10..8a3cf9f 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -6852,8 +6852,6 @@ enum {
CPU_POWERPC_XIPCHIP= xxx,
#endif
/* PowerPC 403 family */
-/* Generic PowerPC 403 */
-#define CPU_POWERPC_403 CPU_POWERPC_403GC
/* PowerPC 403 microcontrollers */
CPU_POWERPC_403GA = 0x00200011,
CPU_POWERPC_403GB = 0x00200100,
@@ -6863,8 +6861,6 @@ enum {
CPU_POWERPC_403GP = xxx,
#endif
/* PowerPC 405 family */
-/* Generic PowerPC 405 */
-#define CPU_POWERPC_405 CPU_POWERPC_405D4
/* PowerPC 405 cores */
#if 0
CPU_POWERPC_405A3 = xxx,
@@ -6906,7 +6902,6 @@ enum {
#endif
/* PowerPC 405 microcontrolers */
/* XXX: missing 0x200108a0 */
-#define CPU_POWERPC_405CRCPU_POWERPC_405CRc
CPU_POWERPC_405CRa = 0x40110041,
CPU_POWERPC_405CRb = 0x401100C5,
CPU_POWERPC_405CRc = 0x40110145,
@@ -6918,7 +6913,6 @@ enum {
#if 0
CPU_POWERPC_405FX = xxx,
#endif
-#define CPU_POWERPC_405GPCPU_POWERPC_405GPd
CPU_POWERPC_405GPa = 0x4011,
CPU_POWERPC_405GPb = 0x40110040,
CPU_POWERPC_405GPc = 0x40110082,
@@ -6979,9 +6973,7 @@ enum {
#endif
/* Xilinx cores */
CPU_POWERPC_X2VP4 = 0x20010820,
-#define CPU_POWERPC_X2VP7CPU_POWERPC_X2VP4
CPU_POWERPC_X2VP20 = 0x20010860,
-#define CPU_POWERPC_X2VP50 CPU_POWERPC_X2VP20
#if 0
CPU_POWERPC_ZL10310= xxx,
#endif
@@ -7701,8 +7693,6 @@ static const ppc_def_t ppc_defs[] = {
POWERPC_DEF("Xipchip", CPU_POWERPC_XIPCHIP,401)
#endif
/* PowerPC 403 family*/
-/* Generic PowerPC 403 */
-POWERPC_DEF("403", CPU_POWERPC_403,403)
/* PowerPC 403 microcontrolers */
/* PowerPC 403 GA*/
POWERPC_DEF("403GA", CPU_POWERPC_403GA, 403)
@@ -7717,8 +7707,6 @@ static const ppc_def_t ppc_defs[] = {
POWERPC_DEF("403GP", CPU_POWERPC_403GP, 403)
#endif
/* PowerPC 405 family*/
-/* Generic PowerPC 405 */
-POWERPC_DEF("405", CPU_POWERPC_405,405)
/* PowerPC 405 cores */
#if defined (TODO)
/* PowerPC 405 A3*/
@@ -7773,8 +7761,6 @@ static const ppc_def_t ppc_defs[] = {
POWERPC_DEF("405F6", CPU_POWERPC_405F6, 405)
#endif
/* PowerPC 405 microcontrolers */
-/* PowerPC 405 CR*/
-POWERPC_DEF("405CR", CPU_POWERPC_405CR, 405)
/* PowerPC 405 CRa */
POWERPC_DEF("405CRa",CPU_POWERPC_405CRa, 405)
/* PowerPC 405 CRb */
@@ -7793,8 +7779,6 @@ static const ppc_def_t ppc_defs[] = {
/* PowerPC 405 FX*/
POWERPC_DEF("405FX", CPU_POWERPC_405FX, 405)
#endif
-/* PowerPC 405 GP*/
-POWERPC_DEF("405GP", CPU_POWERPC_405GP, 405)
/* PowerPC 405 GPa */
POWERPC_DEF("405GPa",CPU_POWERPC_405GPa, 405)
/* PowerPC 405 GPb */
@@ -7880,9 +7864,7 @@ static const ppc_def_t ppc_defs[] = {
#endif
/* Xilinx PowerPC 405 cores */
POWERPC_DEF("x2vp4", CPU_POWERPC_X2VP4, 405)
-POWERPC_DEF("x2vp7", CPU_POWERPC_X2VP7, 405)
POWERPC_DEF("x2vp20",CPU_POWERPC_X2VP20, 405)
-POWERPC_DEF("x2vp50",CPU_POWERPC_X2VP50, 405)
#if defined (TODO)
/* Zarlink ZL10310 */
POWERPC_DEF("zl10310", CPU_POWERPC_ZL10310,405)
@@ -9160,6 +9142,13 @@ typedef s
[Qemu-devel] [PATCH 16/66] target-ppc: Extract 74x1 aliases
From: Andreas Färber
Signed-off-by: Andreas Färber
Signed-off-by: Alexander Graf
---
target-ppc/translate_init.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index b7c9781..bd3076c 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -7357,7 +7357,6 @@ enum {
CPU_POWERPC_7450_v12 = 0x8102,
CPU_POWERPC_7450_v20 = 0x8200, /* aka A, B, C, D: 2.04 */
CPU_POWERPC_7450_v21 = 0x8201, /* aka E */
-#define CPU_POWERPC_74x1 CPU_POWERPC_74x1_v23
CPU_POWERPC_74x1_v23 = 0x8203, /* aka G: 2.3 */
/* XXX: this entry might be a bug in some documentation */
CPU_POWERPC_74x1_v210 = 0x8210, /* aka G: 2.3 ? */
@@ -,10 +8887,6 @@ static const ppc_def_t ppc_defs[] = {
POWERPC_DEF("7450_v2.0", CPU_POWERPC_7450_v20, 7450)
/* PowerPC 7450 v2.1 (G4)*/
POWERPC_DEF("7450_v2.1", CPU_POWERPC_7450_v21, 7450)
-/* PowerPC 7441 (G4) */
-POWERPC_DEF("7441", CPU_POWERPC_74x1, 7440)
-/* PowerPC 7451 (G4) */
-POWERPC_DEF("7451", CPU_POWERPC_74x1, 7450)
/* PowerPC 7441 v2.1 (G4)*/
POWERPC_DEF("7441_v2.1", CPU_POWERPC_7450_v21, 7440)
/* PowerPC 7441 v2.3 (G4)*/
@@ -9142,6 +9137,8 @@ static const PowerPCCPUAlias ppc_cpu_aliases[] = {
{ "G4", "7400" },
{ "Nitro", "7410" },
{ "Vger", "7450" },
+{ "7441", "7441_v2.3" },
+{ "7451", "7451_v2.3" },
{ "7445", "7445_v3.2" },
{ "7455", "7455_v3.2" },
{ "Apollo6", "7455" },
--
1.6.0.2
[Qemu-devel] [PATCH 02/66] target-ppc: Fix CPU_POWERPC_MPC8547E
From: Andreas Färber
It was defined to ..._MPC8545E_v21 rather than ..._MPC8547E_v21.
Due to both resolving to CPU_POWERPC_e500v2_v21 this did not show.
Fixing this nontheless helps with QOM'ifying CPU aliases.
Signed-off-by: Andreas Färber
Signed-off-by: Alexander Graf
---
target-ppc/translate_init.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index f5fc9b1..a2e1fc9 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -7282,7 +7282,7 @@ enum {
#define CPU_POWERPC_MPC8545E_v10 CPU_POWERPC_e500v2_v10
#define CPU_POWERPC_MPC8545E_v20 CPU_POWERPC_e500v2_v20
#define CPU_POWERPC_MPC8545E_v21 CPU_POWERPC_e500v2_v21
-#define CPU_POWERPC_MPC8547E CPU_POWERPC_MPC8545E_v21
+#define CPU_POWERPC_MPC8547E CPU_POWERPC_MPC8547E_v21
#define CPU_POWERPC_MPC8547E_v10 CPU_POWERPC_e500v2_v10
#define CPU_POWERPC_MPC8547E_v20 CPU_POWERPC_e500v2_v20
#define CPU_POWERPC_MPC8547E_v21 CPU_POWERPC_e500v2_v21
--
1.6.0.2
[Qemu-devel] [PATCH 04/66] target-ppc: Update error handling in ppc_cpu_realize()
From: Andreas Färber
Commit fe828a4d4b7a5617cda7b24e95e327bfb71d790e added a new fatal error
message while QOM realize'ification was in flight.
Convert it to return an Error instead of exit()ing.
Signed-off-by: Andreas Färber
Signed-off-by: Alexander Graf
---
target-ppc/translate_init.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index d2706f7..d00c737 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -10043,9 +10043,9 @@ static void ppc_cpu_realizefn(DeviceState *dev, Error
**errp)
#if !defined(CONFIG_USER_ONLY)
if (smp_threads > max_smt) {
-fprintf(stderr, "Cannot support more than %d threads on PPC with %s\n",
-max_smt, kvm_enabled() ? "KVM" : "TCG");
-exit(1);
+error_setg(errp, "Cannot support more than %d threads on PPC with %s",
+ max_smt, kvm_enabled() ? "KVM" : "TCG");
+return;
}
#endif
--
1.6.0.2
[Qemu-devel] [PATCH 26/66] target-ppc: Extract 601/601v aliases
From: Andreas Färber
Signed-off-by: Andreas Färber
Signed-off-by: Alexander Graf
---
target-ppc/translate_init.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 69455c4..03284c7 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -7225,10 +7225,8 @@ enum {
#define CPU_POWERPC_MPC8641 CPU_POWERPC_e600
#define CPU_POWERPC_MPC8641D CPU_POWERPC_e600
/* PowerPC 6xx cores */
-#define CPU_POWERPC_601 CPU_POWERPC_601_v2
CPU_POWERPC_601_v0 = 0x00010001,
CPU_POWERPC_601_v1 = 0x00010001,
-#define CPU_POWERPC_601v CPU_POWERPC_601_v2
CPU_POWERPC_601_v2 = 0x00010002,
CPU_POWERPC_602= 0x00050100,
CPU_POWERPC_603= 0x00030100,
@@ -8593,14 +8591,10 @@ static const ppc_def_t ppc_defs[] = {
CPU_POWERPC_MPC8641D, POWERPC_SVR_8641D, 7400)
/* 32 bits "classic" PowerPC */
/* PowerPC 6xx family*/
-/* PowerPC 601 */
-POWERPC_DEF("601", CPU_POWERPC_601,601v)
/* PowerPC 601v0 */
POWERPC_DEF("601_v0",CPU_POWERPC_601_v0, 601)
/* PowerPC 601v1 */
POWERPC_DEF("601_v1",CPU_POWERPC_601_v1, 601)
-/* PowerPC 601v */
-POWERPC_DEF("601v", CPU_POWERPC_601v, 601v)
/* PowerPC 601v2 */
POWERPC_DEF("601_v2",CPU_POWERPC_601_v2, 601v)
/* PowerPC 602 */
@@ -9075,6 +9069,8 @@ static const PowerPCCPUAlias ppc_cpu_aliases[] = {
{ "PowerQUICC-II", "MPC82xx" },
{ "e500", "e500v2_v22" },
+{ "601", "601_v2" },
+{ "601v", "601_v2" },
{ "Vanilla", "603" },
{ "603e", "603e_v4.1" },
{ "Stretch", "603e" },
--
1.6.0.2
[Qemu-devel] [PATCH 17/66] target-ppc: Extract 7450 alias
From: Andreas Färber
Signed-off-by: Andreas Färber
Signed-off-by: Alexander Graf
---
target-ppc/translate_init.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index bd3076c..7bc401b 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -7351,7 +7351,6 @@ enum {
CPU_POWERPC_7448_v11 = 0x80040101,
CPU_POWERPC_7448_v20 = 0x80040200,
CPU_POWERPC_7448_v21 = 0x80040201,
-#define CPU_POWERPC_7450 CPU_POWERPC_7450_v21
CPU_POWERPC_7450_v10 = 0x8100,
CPU_POWERPC_7450_v11 = 0x8101,
CPU_POWERPC_7450_v12 = 0x8102,
@@ -8875,8 +8874,6 @@ static const ppc_def_t ppc_defs[] = {
POWERPC_DEF("7448_v2.0", CPU_POWERPC_7448_v20, 7400)
/* PowerPC 7448 v2.1 (G4)*/
POWERPC_DEF("7448_v2.1", CPU_POWERPC_7448_v21, 7400)
-/* PowerPC 7450 (G4) */
-POWERPC_DEF("7450", CPU_POWERPC_7450, 7450)
/* PowerPC 7450 v1.0 (G4)*/
POWERPC_DEF("7450_v1.0", CPU_POWERPC_7450_v10, 7450)
/* PowerPC 7450 v1.1 (G4)*/
@@ -9136,6 +9133,7 @@ static const PowerPCCPUAlias ppc_cpu_aliases[] = {
{ "Max", "7400" },
{ "G4", "7400" },
{ "Nitro", "7410" },
+{ "7450", "7450_v2.1" },
{ "Vger", "7450" },
{ "7441", "7441_v2.3" },
{ "7451", "7451_v2.3" },
--
1.6.0.2
[Qemu-devel] [PATCH 10/66] target-ppc: Extract MGT823/MPC8xx as aliases
From: Andreas Färber
They used different PVRs but were defined to MPC8xx.
Signed-off-by: Andreas Färber
Signed-off-by: Alexander Graf
---
target-ppc/translate_init.c | 93 ---
1 files changed, 17 insertions(+), 76 deletions(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 6a5f7e8..6a86e10 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -7059,21 +7059,6 @@ enum {
CPU_POWERPC_MPC5xx = 0x00020020,
/* PowerPC MPC 8xx cores (aka PowerQUICC) */
CPU_POWERPC_MPC8xx = 0x0050,
-#define CPU_POWERPC_MGT823 CPU_POWERPC_MPC8xx
-#define CPU_POWERPC_MPC821 CPU_POWERPC_MPC8xx
-#define CPU_POWERPC_MPC823 CPU_POWERPC_MPC8xx
-#define CPU_POWERPC_MPC850 CPU_POWERPC_MPC8xx
-#define CPU_POWERPC_MPC852T CPU_POWERPC_MPC8xx
-#define CPU_POWERPC_MPC855T CPU_POWERPC_MPC8xx
-#define CPU_POWERPC_MPC857 CPU_POWERPC_MPC8xx
-#define CPU_POWERPC_MPC859 CPU_POWERPC_MPC8xx
-#define CPU_POWERPC_MPC860 CPU_POWERPC_MPC8xx
-#define CPU_POWERPC_MPC862 CPU_POWERPC_MPC8xx
-#define CPU_POWERPC_MPC866 CPU_POWERPC_MPC8xx
-#define CPU_POWERPC_MPC870 CPU_POWERPC_MPC8xx
-#define CPU_POWERPC_MPC875 CPU_POWERPC_MPC8xx
-#define CPU_POWERPC_MPC880 CPU_POWERPC_MPC8xx
-#define CPU_POWERPC_MPC885 CPU_POWERPC_MPC8xx
/* G2 cores (aka PowerQUICC-II) */
CPU_POWERPC_G2 = 0x00810011,
CPU_POWERPC_G2H4 = 0x80811010,
@@ -8048,67 +8033,6 @@ static const ppc_def_t ppc_defs[] = {
/* Generic MPC8xx core */
POWERPC_DEF("MPC8xx",CPU_POWERPC_MPC8xx, MPC8xx)
#endif
-/* MPC8xx microcontrollers */
-#if defined(TODO_USER_ONLY)
-/* MGT823*/
-POWERPC_DEF("MGT823",CPU_POWERPC_MGT823, MPC8xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC821*/
-POWERPC_DEF("MPC821",CPU_POWERPC_MPC821, MPC8xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC823*/
-POWERPC_DEF("MPC823",CPU_POWERPC_MPC823, MPC8xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC850*/
-POWERPC_DEF("MPC850",CPU_POWERPC_MPC850, MPC8xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC852T */
-POWERPC_DEF("MPC852T", CPU_POWERPC_MPC852T,MPC8xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC855T */
-POWERPC_DEF("MPC855T", CPU_POWERPC_MPC855T,MPC8xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC857*/
-POWERPC_DEF("MPC857",CPU_POWERPC_MPC857, MPC8xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC859*/
-POWERPC_DEF("MPC859",CPU_POWERPC_MPC859, MPC8xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC860*/
-POWERPC_DEF("MPC860",CPU_POWERPC_MPC860, MPC8xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC862*/
-POWERPC_DEF("MPC862",CPU_POWERPC_MPC862, MPC8xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC866*/
-POWERPC_DEF("MPC866",CPU_POWERPC_MPC866, MPC8xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC870*/
-POWERPC_DEF("MPC870",CPU_POWERPC_MPC870, MPC8xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC875*/
-POWERPC_DEF("MPC875",CPU_POWERPC_MPC875, MPC8xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC880*/
-POWERPC_DEF("MPC880",CPU_POWERPC_MPC880, MPC8xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC885*/
-POWERPC_DEF("MPC885",CPU_POWERPC_MPC885, MPC8xx)
-#endif
/* MPC82xx family (aka PowerQUICC-II)*/
/* Generic MPC52xx core
[Qemu-devel] [PATCH 12/66] target-ppc: Extract 440 aliases
From: Andreas Färber
Signed-off-by: Andreas Färber
Signed-off-by: Alexander Graf
---
target-ppc/translate_init.c | 23 +--
1 files changed, 5 insertions(+), 18 deletions(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 8a3cf9f..fb0a366 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -7013,17 +7013,13 @@ enum {
CPU_POWERPC_440H6 = xxx,
#endif
/* PowerPC 440 microcontrolers */
-#define CPU_POWERPC_440EPCPU_POWERPC_440EPb
CPU_POWERPC_440EPa = 0x42221850,
CPU_POWERPC_440EPb = 0x422218D3,
-#define CPU_POWERPC_440GPCPU_POWERPC_440GPc
CPU_POWERPC_440GPb = 0x40120440,
CPU_POWERPC_440GPc = 0x40120481,
-#define CPU_POWERPC_440GRCPU_POWERPC_440GRa
#define CPU_POWERPC_440GRa CPU_POWERPC_440EPb
CPU_POWERPC_440GRX = 0x28D0,
#define CPU_POWERPC_440EPX CPU_POWERPC_440GRX
-#define CPU_POWERPC_440GXCPU_POWERPC_440GXf
CPU_POWERPC_440GXa = 0x51B21850,
CPU_POWERPC_440GXb = 0x51B21851,
CPU_POWERPC_440GXc = 0x51B21892,
@@ -7922,8 +7918,6 @@ static const ppc_def_t ppc_defs[] = {
POWERPC_DEF("440H6", CPU_POWERPC_440H6, 440Gx5)
#endif
/* PowerPC 440 microcontrolers */
-/* PowerPC 440 EP*/
-POWERPC_DEF("440EP", CPU_POWERPC_440EP, 440EP)
/* PowerPC 440 EPa */
POWERPC_DEF("440EPa",CPU_POWERPC_440EPa, 440EP)
/* PowerPC 440 EPb */
@@ -7931,10 +7925,6 @@ static const ppc_def_t ppc_defs[] = {
/* PowerPC 440 EPX */
POWERPC_DEF("440EPX",CPU_POWERPC_440EPX, 440EP)
#if defined(TODO_USER_ONLY)
-/* PowerPC 440 GP*/
-POWERPC_DEF("440GP", CPU_POWERPC_440GP, 440GP)
-#endif
-#if defined(TODO_USER_ONLY)
/* PowerPC 440 GPb */
POWERPC_DEF("440GPb",CPU_POWERPC_440GPb, 440GP)
#endif
@@ -7943,10 +7933,6 @@ static const ppc_def_t ppc_defs[] = {
POWERPC_DEF("440GPc",CPU_POWERPC_440GPc, 440GP)
#endif
#if defined(TODO_USER_ONLY)
-/* PowerPC 440 GR*/
-POWERPC_DEF("440GR", CPU_POWERPC_440GR, 440x5)
-#endif
-#if defined(TODO_USER_ONLY)
/* PowerPC 440 GRa */
POWERPC_DEF("440GRa",CPU_POWERPC_440GRa, 440x5)
#endif
@@ -7955,10 +7941,6 @@ static const ppc_def_t ppc_defs[] = {
POWERPC_DEF("440GRX",CPU_POWERPC_440GRX, 440x5)
#endif
#if defined(TODO_USER_ONLY)
-/* PowerPC 440 GX*/
-POWERPC_DEF("440GX", CPU_POWERPC_440GX, 440EP)
-#endif
-#if defined(TODO_USER_ONLY)
/* PowerPC 440 GXa */
POWERPC_DEF("440GXa",CPU_POWERPC_440GXa, 440EP)
#endif
@@ -9149,6 +9131,11 @@ static const PowerPCCPUAlias ppc_cpu_aliases[] = {
{ "x2vp7", "x2vp4" },
{ "x2vp50", "x2vp20" },
+{ "440EP", "440EPb" },
+{ "440GP", "440GPc" },
+{ "440GR", "440GRa" },
+{ "440GX", "440GXf" },
+
{ "RCPU", "MPC5xx" },
/* MPC5xx microcontrollers */
{ "MGT560", "MPC5xx" },
--
1.6.0.2
[Qemu-devel] [PATCH 23/66] target-ppc: Extract 740/750 aliases
From: Andreas Färber
Signed-off-by: Andreas Färber
Signed-off-by: Alexander Graf
---
target-ppc/translate_init.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 86db9a5..e6be35c 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -7265,7 +7265,6 @@ enum {
#endif
/* PowerPC 740/750 cores (aka G3) */
/* XXX: missing 0x00084202 */
-#define CPU_POWERPC_7x0 CPU_POWERPC_7x0_v31
CPU_POWERPC_7x0_v10= 0x00080100,
CPU_POWERPC_7x0_v20= 0x00080200,
CPU_POWERPC_7x0_v21= 0x00080201,
@@ -8659,10 +8658,6 @@ static const ppc_def_t ppc_defs[] = {
POWERPC_DEF("604ev", CPU_POWERPC_604EV, 604E)
#endif
/* PowerPC 7xx family*/
-/* Generic PowerPC 740 (G3) */
-POWERPC_DEF("740", CPU_POWERPC_7x0,740)
-/* Generic PowerPC 750 (G3) */
-POWERPC_DEF("750", CPU_POWERPC_7x0,750)
/* PowerPC 740 v1.0 (G3) */
POWERPC_DEF("740_v1.0", CPU_POWERPC_7x0_v10,740)
/* PowerPC 750 v1.0 (G3) */
@@ -9092,7 +9087,9 @@ static const PowerPCCPUAlias ppc_cpu_aliases[] = {
{ "Goldeneye", "603r" },
{ "Sirocco", "604e" },
{ "Mach5", "604r" },
+{ "740", "740_v3.1" },
{ "Arthur", "740" },
+{ "750", "750_v3.1" },
{ "Typhoon", "750" },
{ "G3", "750" },
{ "Conan/Doyle", "750p" },
--
1.6.0.2
[Qemu-devel] [PULL 00/66] ppc patch queue 2013-03-08
Hi Blue / Aurelien,
This is my current patch queue for ppc. Please pull.
Alex
The following changes since commit 0bc472a9d6b80567c212023c5eae413f4dfb53ad:
Kuo-Jung Su (1):
hw/nand.c: correct the sense of the BUSY/READY status bit
are available in the git repository at:
git://github.com/agraf/qemu.git ppc-for-upstream
Amadeusz SÅawiÅski (2):
PPC: Fix dma interrupt
PPC: xnu kernel expects FLUSH to be cleared on STOP
Andreas Färber (58):
target-ppc: Fix CPU_POWERPC_MPC8547E
target-ppc: Fix "G2leGP3" PVR
target-ppc: Update error handling in ppc_cpu_realize()
target-ppc: Drop nested TARGET_PPC64 guard for POWER7
target-ppc: Inline comma into POWERPC_DEF_SVR() macro
target-ppc: Extract aliases from definitions list
target-ppc: Make -cpu "ppc" an alias to "ppc32"
target-ppc: Extract MPC5xx aliases
target-ppc: Extract MGT823/MPC8xx as aliases
target-ppc: Extract 40x aliases
target-ppc: Extract 440 aliases
target-ppc: Turn "ppc32" and "ppc64" CPUs into aliases
target-ppc: Extract 74x7[A] aliases
target-ppc: Extract 74x5 as aliases
target-ppc: Extract 74x1 aliases
target-ppc: Extract 7450 alias
target-ppc: Extract 7448 alias
target-ppc: Extract 7410 alias
target-ppc: Extract 7400 alias
target-ppc: Extract 7x5 aliases
target-ppc: Extract 750 aliases
target-ppc: Extract 740/750 aliases
target-ppc: Extract 603e alias
target-ppc: Extract 603r alias
target-ppc: Extract 601/601v aliases
target-ppc: Extract 604e alias
target-ppc: Extract MPC85xx aliases
target-ppc: Extract e500v1/e500v2 aliases
target-ppc: Extract MPC83xx aliases
target-ppc: Extract e300 alias
target-ppc: Extract e200 alias
target-ppc: Extract MPC82xx alias
target-ppc: Extract MPC8247/MPC8248/MPC8270-80 aliases
target-ppc: Extract MPC82xx aliases to *_HiP4
target-ppc: Extract MPC82xx_HiP{3, 4} aliases
target-ppc: Extract MPC52xx alias
target-ppc: Extract MPC5200/MPC5200B aliases
target-ppc: Extract MPC8240 alias
target-ppc: Extract 405GPe alias
target-ppc: Extract 970 aliases
target-ppc: Extract POWER7 alias
target-ppc: Get model name from type name
target-ppc: Convert CPU definitions
target-ppc: Introduce abstract CPU family types
target-ppc: Set instruction flags on CPU family classes
target-ppc: Register all types for TARGET_PPCEMB
target-ppc: Set remaining fields on CPU family classes
target-ppc: Turn descriptive CPU family comments into device descriptions
target-ppc: Turn descriptive CPU model comments into device descriptions
target-ppc: Update Coding Style for CPU models
target-ppc: Split model definitions out of translate_init.c
target-ppc: Fix remaining microcontroller typos among models
target-ppc: Change "POWER7" CPU alias
target-ppc: Fix PPC_DUMP_SPR_ACCESS build
target-ppc: Make host CPU a subclass of the host's CPU model
target-ppc: List alias names alongside CPU models
target-ppc: Report CPU aliases for QMP
target-ppc: Move CPU aliases out of translate_init.c
David Gibson (4):
pseries: Add cleanup hook for PAPR virtual LAN device
target-ppc: Add mechanism for synchronizing SPRs with KVM
target-ppc: Synchronize FPU state with KVM
pseries: Add compatible property to root of device tree
Erlon Cruz (1):
pseries: Implement h_read hcall
Fabien Chouteau (1):
Save memory allocation in the elf loader
hw/elf_ops.h| 19 +-
hw/loader.c | 75 +-
hw/loader.h |2 +
hw/mac_dbdma.c |4 +
hw/ppc/mac_newworld.c |2 +-
hw/spapr.c |1 +
hw/spapr_hcall.c| 31 +
hw/spapr_llan.c |8 +
target-ppc/Makefile.objs|1 +
target-ppc/cpu-models.c | 1419
target-ppc/cpu-models.h | 741 ++
target-ppc/cpu-qom.h| 17 +-
target-ppc/cpu.h| 26 +-
target-ppc/kvm.c| 311 +++-
target-ppc/translate_init.c | 5275 +--
15 files changed, 4117 insertions(+), 3815 deletions(-)
create mode 100644 target-ppc/cpu-models.c
create mode 100644 target-ppc/cpu-models.h
[Qemu-devel] [PATCH 07/66] target-ppc: Extract aliases from definitions list
From: Andreas Färber
Move definitions that were 100% identical except for the name into a
list of aliases so that we don't register duplicate CPU types.
Drop the accompanying comments since they don't really add value.
We need to support recursive lookup due to code names referencing a
generic name referencing a specific model revision.
List aliases separately for -cpu ?.
Signed-off-by: Andreas Färber
Signed-off-by: Alexander Graf
---
target-ppc/translate_init.c | 145 +--
1 files changed, 72 insertions(+), 73 deletions(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 3f75bef..862f40a 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -8083,10 +8083,6 @@ static const ppc_def_t ppc_defs[] = {
/* Generic MPC5xx core */
POWERPC_DEF("MPC5xx",CPU_POWERPC_MPC5xx, MPC5xx)
#endif
-#if defined(TODO_USER_ONLY)
-/* Codename for MPC5xx core */
-POWERPC_DEF("RCPU", CPU_POWERPC_MPC5xx, MPC5xx)
-#endif
/* MPC5xx microcontrollers */
#if defined(TODO_USER_ONLY)
/* MGT560*/
@@ -8145,10 +8141,6 @@ static const ppc_def_t ppc_defs[] = {
/* Generic MPC8xx core */
POWERPC_DEF("MPC8xx",CPU_POWERPC_MPC8xx, MPC8xx)
#endif
-#if defined(TODO_USER_ONLY)
-/* Codename for MPC8xx core */
-POWERPC_DEF("PowerQUICC",CPU_POWERPC_MPC8xx, MPC8xx)
-#endif
/* MPC8xx microcontrollers */
#if defined(TODO_USER_ONLY)
/* MGT823*/
@@ -8216,8 +8208,6 @@ static const ppc_def_t ppc_defs[] = {
CPU_POWERPC_MPC52xx, POWERPC_SVR_52xx, G2LE)
/* Generic MPC82xx core */
POWERPC_DEF("MPC82xx", CPU_POWERPC_MPC82xx,G2)
-/* Codename for MPC82xx */
-POWERPC_DEF("PowerQUICC-II", CPU_POWERPC_MPC82xx,G2)
/* PowerPC G2 core */
POWERPC_DEF("G2",CPU_POWERPC_G2, G2)
/* PowerPC G2 H4 core*/
@@ -8612,8 +8602,6 @@ static const ppc_def_t ppc_defs[] = {
POWERPC_DEF_SVR("MPC8379E",
CPU_POWERPC_MPC837x, POWERPC_SVR_8379E, e300)
/* e500 family */
-/* PowerPC e500 core */
-POWERPC_DEF("e500", CPU_POWERPC_e500v2_v22, e500v2)
/* PowerPC e500v1 core */
POWERPC_DEF("e500v1",CPU_POWERPC_e500v1, e500v1)
/* PowerPC e500 v1.0 core*/
@@ -8868,12 +8856,8 @@ static const ppc_def_t ppc_defs[] = {
POWERPC_DEF("602", CPU_POWERPC_602,602)
/* PowerPC 603 */
POWERPC_DEF("603", CPU_POWERPC_603,603)
-/* Code name for PowerPC 603 */
-POWERPC_DEF("Vanilla", CPU_POWERPC_603,603)
/* PowerPC 603e (aka PID6) */
POWERPC_DEF("603e", CPU_POWERPC_603E, 603E)
-/* Code name for PowerPC 603e*/
-POWERPC_DEF("Stretch", CPU_POWERPC_603E, 603E)
/* PowerPC 603e v1.1 */
POWERPC_DEF("603e_v1.1", CPU_POWERPC_603E_v11, 603E)
/* PowerPC 603e v1.2 */
@@ -8896,8 +8880,6 @@ static const ppc_def_t ppc_defs[] = {
POWERPC_DEF("603e7t",CPU_POWERPC_603E7t, 603E)
/* PowerPC 603e7v*/
POWERPC_DEF("603e7v",CPU_POWERPC_603E7v, 603E)
-/* Code name for PowerPC 603ev */
-POWERPC_DEF("Vaillant", CPU_POWERPC_603E7v, 603E)
/* PowerPC 603e7v1 */
POWERPC_DEF("603e7v1", CPU_POWERPC_603E7v1,603E)
/* PowerPC 603e7v2 */
@@
[Qemu-devel] [PATCH 20/66] target-ppc: Extract 7400 alias
From: Andreas Färber
Signed-off-by: Andreas Färber
Signed-off-by: Alexander Graf
---
target-ppc/translate_init.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 3fd8fd7..a97dfb7 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -7330,7 +7330,6 @@ enum {
#endif
/* PowerPC 74xx cores (aka G4) */
/* XXX: missing 0x000C1101 */
-#define CPU_POWERPC_7400 CPU_POWERPC_7400_v29
CPU_POWERPC_7400_v10 = 0x000C0100,
CPU_POWERPC_7400_v11 = 0x000C0101,
CPU_POWERPC_7400_v20 = 0x000C0200,
@@ -8830,8 +8829,6 @@ static const ppc_def_t ppc_defs[] = {
POWERPC_DEF("755p", CPU_POWERPC_7x5P, 755)
#endif
/* PowerPC 74xx family */
-/* PowerPC 7400 (G4) */
-POWERPC_DEF("7400", CPU_POWERPC_7400, 7400)
/* PowerPC 7400 v1.0 (G4)*/
POWERPC_DEF("7400_v1.0", CPU_POWERPC_7400_v10, 7400)
/* PowerPC 7400 v1.1 (G4)*/
@@ -9124,6 +9121,7 @@ static const PowerPCCPUAlias ppc_cpu_aliases[] = {
{ "Conan/Doyle", "750p" },
{ "LoneStar", "750l" },
{ "Goldfinger", "755" },
+{ "7400", "7400_v2.9" },
{ "Max", "7400" },
{ "G4", "7400" },
{ "7410", "7410_v1.4" },
--
1.6.0.2
[Qemu-devel] [PATCH 39/66] target-ppc: Extract MPC8240 alias
From: Andreas Färber
Signed-off-by: Andreas Färber
Signed-off-by: Alexander Graf
---
target-ppc/translate_init.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 2e41f0b..4e5278d 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -7042,8 +7042,6 @@ enum {
#define CPU_POWERPC_MPC5200_v12 CPU_POWERPC_G2LEgp1
#define CPU_POWERPC_MPC5200B_v20 CPU_POWERPC_G2LEgp1
#define CPU_POWERPC_MPC5200B_v21 CPU_POWERPC_G2LEgp1
-/* MPC82xx microcontrollers */
-#define CPU_POWERPC_MPC8240 CPU_POWERPC_MPC603
/* e200 family */
/* e200 cores */
#if 0
@@ -7899,9 +7897,6 @@ static const ppc_def_t ppc_defs[] = {
POWERPC_DEF("G2leGP1", CPU_POWERPC_G2LEgp1,G2LE)
/* PowerPC G2LE GP3 core */
POWERPC_DEF("G2leGP3", CPU_POWERPC_G2LEgp3,G2LE)
-/* PowerPC MPC603 microcontrollers */
-/* MPC8240 */
-POWERPC_DEF("MPC8240", CPU_POWERPC_MPC8240,603E)
/* PowerPC G2 microcontrollers */
#if defined(TODO)
/* MPC5121 */
@@ -8852,6 +8847,9 @@ static const PowerPCCPUAlias ppc_cpu_aliases[] = {
{ "MPC880", "MPC8xx" },
{ "MPC885", "MPC8xx" },
+/* PowerPC MPC603 microcontrollers */
+{ "MPC8240", "603" },
+
{ "MPC52xx", "MPC5200" },
{ "MPC5200", "MPC5200_v12" },
{ "MPC5200B", "MPC5200B_v21" },
--
1.6.0.2
[Qemu-devel] [PATCH 13/66] target-ppc: Turn "ppc32" and "ppc64" CPUs into aliases
From: Andreas Färber
Signed-off-by: Andreas Färber
Signed-off-by: Alexander Graf
---
target-ppc/translate_init.c | 36 +---
1 files changed, 5 insertions(+), 31 deletions(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index fb0a366..86b5c91 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -6798,32 +6798,6 @@ static void init_proc_620 (CPUPPCState *env)
}
#endif /* defined (TARGET_PPC64) */
-/* Default 32 bits PowerPC target will be 604 */
-#define CPU_POWERPC_PPC32 CPU_POWERPC_604
-#define POWERPC_INSNS_PPC32 POWERPC_INSNS_604
-#define POWERPC_INSNS2_PPC32 POWERPC_INSNS2_604
-#define POWERPC_MSRM_PPC32POWERPC_MSRM_604
-#define POWERPC_MMU_PPC32 POWERPC_MMU_604
-#define POWERPC_EXCP_PPC32POWERPC_EXCP_604
-#define POWERPC_INPUT_PPC32 POWERPC_INPUT_604
-#define POWERPC_BFDM_PPC32POWERPC_BFDM_604
-#define POWERPC_FLAG_PPC32POWERPC_FLAG_604
-#define check_pow_PPC32 check_pow_604
-#define init_proc_PPC32 init_proc_604
-
-/* Default 64 bits PowerPC target will be 970 FX */
-#define CPU_POWERPC_PPC64 CPU_POWERPC_970FX
-#define POWERPC_INSNS_PPC64 POWERPC_INSNS_970FX
-#define POWERPC_INSNS2_PPC64 POWERPC_INSNS2_970FX
-#define POWERPC_MSRM_PPC64POWERPC_MSRM_970FX
-#define POWERPC_MMU_PPC64 POWERPC_MMU_970FX
-#define POWERPC_EXCP_PPC64POWERPC_EXCP_970FX
-#define POWERPC_INPUT_PPC64 POWERPC_INPUT_970FX
-#define POWERPC_BFDM_PPC64POWERPC_BFDM_970FX
-#define POWERPC_FLAG_PPC64POWERPC_FLAG_970FX
-#define check_pow_PPC64 check_pow_970FX
-#define init_proc_PPC64 init_proc_970FX
-
/*/
/* PVR definitions for most known PowerPC*/
enum {
@@ -9111,11 +9085,6 @@ static const ppc_def_t ppc_defs[] = {
/* PA PA6T */
POWERPC_DEF("PA6T", CPU_POWERPC_PA6T, PA6T)
#endif
-/* Generic PowerPCs */
-#if defined (TARGET_PPC64)
-POWERPC_DEF("ppc64", CPU_POWERPC_PPC64, PPC64)
-#endif
-POWERPC_DEF("ppc32", CPU_POWERPC_PPC32, PPC32)
};
typedef struct PowerPCCPUAlias {
@@ -9213,6 +9182,11 @@ static const PowerPCCPUAlias ppc_cpu_aliases[] = {
{ "RSC2", "POWER2" },
{ "P2SC", "POWER2" },
+/* Generic PowerPCs */
+#if defined(TARGET_PPC64)
+{ "ppc64", "970fx" },
+#endif
+{ "ppc32", "604" },
{ "ppc", "ppc32" },
{ "default", "ppc" },
};
--
1.6.0.2
[Qemu-devel] [PATCH 09/66] target-ppc: Extract MPC5xx aliases
From: Andreas Färber
Their PVR differed but was defined to MPC5xx.
Signed-off-by: Andreas Färber
Signed-off-by: Alexander Graf
---
target-ppc/translate_init.c | 81 ---
1 files changed, 15 insertions(+), 66 deletions(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 8923105..6a5f7e8 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -7057,19 +7057,6 @@ enum {
/* Freescale embedded PowerPC cores */
/* PowerPC MPC 5xx cores (aka RCPU) */
CPU_POWERPC_MPC5xx = 0x00020020,
-#define CPU_POWERPC_MGT560 CPU_POWERPC_MPC5xx
-#define CPU_POWERPC_MPC509 CPU_POWERPC_MPC5xx
-#define CPU_POWERPC_MPC533 CPU_POWERPC_MPC5xx
-#define CPU_POWERPC_MPC534 CPU_POWERPC_MPC5xx
-#define CPU_POWERPC_MPC555 CPU_POWERPC_MPC5xx
-#define CPU_POWERPC_MPC556 CPU_POWERPC_MPC5xx
-#define CPU_POWERPC_MPC560 CPU_POWERPC_MPC5xx
-#define CPU_POWERPC_MPC561 CPU_POWERPC_MPC5xx
-#define CPU_POWERPC_MPC562 CPU_POWERPC_MPC5xx
-#define CPU_POWERPC_MPC563 CPU_POWERPC_MPC5xx
-#define CPU_POWERPC_MPC564 CPU_POWERPC_MPC5xx
-#define CPU_POWERPC_MPC565 CPU_POWERPC_MPC5xx
-#define CPU_POWERPC_MPC566 CPU_POWERPC_MPC5xx
/* PowerPC MPC 8xx cores (aka PowerQUICC) */
CPU_POWERPC_MPC8xx = 0x0050,
#define CPU_POWERPC_MGT823 CPU_POWERPC_MPC8xx
@@ -8056,59 +8043,6 @@ static const ppc_def_t ppc_defs[] = {
/* Generic MPC5xx core */
POWERPC_DEF("MPC5xx",CPU_POWERPC_MPC5xx, MPC5xx)
#endif
-/* MPC5xx microcontrollers */
-#if defined(TODO_USER_ONLY)
-/* MGT560*/
-POWERPC_DEF("MGT560",CPU_POWERPC_MGT560, MPC5xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC509*/
-POWERPC_DEF("MPC509",CPU_POWERPC_MPC509, MPC5xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC533*/
-POWERPC_DEF("MPC533",CPU_POWERPC_MPC533, MPC5xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC534*/
-POWERPC_DEF("MPC534",CPU_POWERPC_MPC534, MPC5xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC555*/
-POWERPC_DEF("MPC555",CPU_POWERPC_MPC555, MPC5xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC556*/
-POWERPC_DEF("MPC556",CPU_POWERPC_MPC556, MPC5xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC560*/
-POWERPC_DEF("MPC560",CPU_POWERPC_MPC560, MPC5xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC561*/
-POWERPC_DEF("MPC561",CPU_POWERPC_MPC561, MPC5xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC562*/
-POWERPC_DEF("MPC562",CPU_POWERPC_MPC562, MPC5xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC563*/
-POWERPC_DEF("MPC563",CPU_POWERPC_MPC563, MPC5xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC564*/
-POWERPC_DEF("MPC564",CPU_POWERPC_MPC564, MPC5xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC565*/
-POWERPC_DEF("MPC565",CPU_POWERPC_MPC565, MPC5xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC566*/
-POWERPC_DEF("MPC566",CPU_POWERPC_MPC566, MPC5xx)
-#endif
/* MPC8xx family (aka PowerQUICC)*/
#if defined(TODO_USER_ONLY)
/* Generic MPC8xx core */
@@ -9303,6 +9237,21 @@ typedef struct PowerPCCPUAlias {
static const PowerPCCPUAlias ppc_cpu_aliases[] = {
{ "RCPU", "MPC5xx" },
+/* MPC5xx microcontrollers */
+{ "MGT560", "MPC5xx" },
+{ "MPC509", "MPC5xx" },
+{ "MPC533", "MPC5xx" },
+{ "MPC534", "MPC5xx" },
+{ "MPC555", "MPC5xx" },
+{ "MPC556", "MPC5xx" },
+{ "MPC560", "MPC5xx" },
+{ "MPC561", "MPC5xx" },
+{ "MPC562", "MPC5xx" },
+{ "MPC563
[Qemu-devel] [PATCH 32/66] target-ppc: Extract e200 alias
From: Andreas Färber
Signed-off-by: Andreas Färber
Signed-off-by: Alexander Graf
---
target-ppc/translate_init.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index d2cee80..a4eae26 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -7077,7 +7077,6 @@ enum {
#define CPU_POWERPC_MPC8280 CPU_POWERPC_G2LEgp3
/* e200 family */
/* e200 cores */
-#define CPU_POWERPC_e200 CPU_POWERPC_e200z6
#if 0
CPU_POWERPC_e200z0 = xxx,
#endif
@@ -8024,8 +8023,6 @@ static const ppc_def_t ppc_defs[] = {
/* MPC8280 */
POWERPC_DEF("MPC8280", CPU_POWERPC_MPC8280,G2LE)
/* e200 family */
-/* Generic PowerPC e200 core */
-POWERPC_DEF("e200", CPU_POWERPC_e200, e200)
/* Generic MPC55xx core */
#if defined (TODO)
POWERPC_DEF_SVR("MPC55xx",
@@ -8955,6 +8952,7 @@ static const PowerPCCPUAlias ppc_cpu_aliases[] = {
{ "MPC885", "MPC8xx" },
{ "PowerQUICC-II", "MPC82xx" },
+{ "e200", "e200z6" },
{ "e300", "e300c3" },
{ "MPC8347", "MPC8347T" },
{ "MPC8347A", "MPC8347AT" },
--
1.6.0.2
