[Qemu-devel] [Bug 646427] Re: VirtFS mapped symlinks resolved wrong
Why not using simple symlinks on the host with xattr like on normal files instead of those hacks which either don't work on client or don't work on the host? -- VirtFS mapped symlinks resolved wrong https://bugs.launchpad.net/bugs/646427 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: I tried to map a folder with qemu-kvm qemu-kvm-0.13.0-rc1-3-gc9c2179 (this is v0.13.0-rc1-16667-gc9c2179). I mounted it first in passthrough mode and saw all symlinks as expected. Then I used mapped and noticed that the target of a symlink changed to the actual data inside the linked folder as target instead of the target filename. So for example if you have a file abc with the content "omg, this is important stuff" and a symlink lnkme -> abc then it wiill look inside the kvm with mounted 9p virtio (mapped) like that: lnkme -> omg, this is important stuff Another problem I noticed was that I cannot mount it (mapped or passthrough) using /etc/rc.local or /etc/fstab, but after login as root using mount /mnt or mount -t 9p -o trans=virtio host_share /mnt (the same stuff i tried inside /etc/rc.local) The only output on a failed mount in rc.local/fstab I get is [ 15.035920] device: '9p-1': device_add [ 15.038180] 9p: no channels available [ 15.038937] device: '9p-1': device_unregister [ 15.049123] device: '9p-1': device_create_release
[Qemu-devel] [RESEND] Re: Introduce a new 'connected' xendev op called when Connected.
[The first time I sent this I didn't get a copy on qemu-devel which I
was expecting. Sorry if this is actually a duplicate.
I think I must be missing something. On 27th August, Stefano posted
two messages whose subjects were
[PATCH 1 of 2] Introduce a new 'connected' xendev op called when Connected.
and
[PATCH 2 of 2] Move the xenfb pointer handler to the connected method
and I still don't see them. Are they one some branch other than master
or staging? Or am I simply looking on the wrong place? (ie somewhere
other than git://git.sv.gnu.org/qemu.git)
jch
On 23/08/10 13:23, Anthony Liguori wrote:
On 08/23/2010 05:21 AM, John Haxby wrote:
Any reason why this (and its sister patch) were never picked up?
jch
It was likely missed originally because there wasn't a [PATCH] in the
subject. Can you resubmit? It's not obvious to me what it's sister
patch is so I'd suggest resubmitting that too.
Regards,
Anthony Liguori
On 27/07/10 15:54, Stefano Stabellini wrote:
Any comments?
On Wed, 21 Jul 2010, Stefano Stabellini wrote:
From: John Haxby
Introduce a new 'connected' xendev op called when Connected.
Rename the existing xendev 'connect' op to 'initialised' and introduce
a new 'connected' op. This new op, if defined, is called when the
backend is connected. Note that since there is no state transition
this
may be called more than once.
Signed-off-by: John Haxby
Signed-off-by: Stefano Stabellini
diff --git a/hw/xen_backend.c b/hw/xen_backend.c
index a2e408f..b99055a 100644
--- a/hw/xen_backend.c
+++ b/hw/xen_backend.c
@@ -400,13 +400,13 @@ static int xen_be_try_init(struct XenDevice
*xendev)
}
/*
- * Try to connect xendev. Depends on the frontend being ready
+ * Try to initialise xendev. Depends on the frontend being ready
* for it (shared ring and evtchn info in xenstore, state being
* Initialised or Connected).
*
* Goes to Connected on success.
*/
-static int xen_be_try_connect(struct XenDevice *xendev)
+static int xen_be_try_initialise(struct XenDevice *xendev)
{
int rc = 0;
@@ -420,10 +420,10 @@ static int xen_be_try_connect(struct
XenDevice *xendev)
}
}
-if (xendev->ops->connect)
-rc = xendev->ops->connect(xendev);
+if (xendev->ops->initialise)
+rc = xendev->ops->initialise(xendev);
if (rc != 0) {
-xen_be_printf(xendev, 0, "connect() failed\n");
+xen_be_printf(xendev, 0, "initialise() failed\n");
return rc;
}
@@ -432,6 +432,28 @@ static int xen_be_try_connect(struct XenDevice
*xendev)
}
/*
+ * Try to let xendev know that it is connected. Depends on the
+ * frontend being Connected. Note that this may be called more
+ * than once since the backend state is not modified.
+ */
+static void xen_be_try_connected(struct XenDevice *xendev)
+{
+if (!xendev->ops->connected)
+return;
+
+if (xendev->fe_state != XenbusStateConnected) {
+if (xendev->ops->flags& DEVOPS_FLAG_IGNORE_STATE) {
+xen_be_printf(xendev, 2, "frontend not ready, ignoring\n");
+} else {
+xen_be_printf(xendev, 2, "frontend not ready (yet)\n");
+return;
+}
+}
+
+xendev->ops->connected(xendev);
+}
+
+/*
* Teardown connection.
*
* Goes to Closed when done.
@@ -483,7 +505,12 @@ void xen_be_check_state(struct XenDevice *xendev)
rc = xen_be_try_init(xendev);
break;
case XenbusStateInitWait:
-rc = xen_be_try_connect(xendev);
+rc = xen_be_try_initialise(xendev);
+break;
+case XenbusStateConnected:
+/* xendev->be_state doesn't change */
+xen_be_try_connected(xendev);
+rc = -1;
break;
case XenbusStateClosed:
rc = xen_be_try_reset(xendev);
diff --git a/hw/xen_backend.h b/hw/xen_backend.h
index cc25f9d..154922a 100644
--- a/hw/xen_backend.h
+++ b/hw/xen_backend.h
@@ -23,7 +23,8 @@ struct XenDevOps {
uint32_t flags;
void (*alloc)(struct XenDevice *xendev);
int (*init)(struct XenDevice *xendev);
-int (*connect)(struct XenDevice *xendev);
+int (*initialise)(struct XenDevice *xendev);
+void (*connected)(struct XenDevice *xendev);
void (*event)(struct XenDevice *xendev);
void (*disconnect)(struct XenDevice *xendev);
int (*free)(struct XenDevice *xendev);
diff --git a/hw/xen_console.c b/hw/xen_console.c
index d2261f4..258c003 100644
--- a/hw/xen_console.c
+++ b/hw/xen_console.c
@@ -202,7 +202,7 @@ static int con_init(struct XenDevice *xendev)
return 0;
}
-static int con_connect(struct XenDevice *xendev)
+static int con_initialise(struct XenDevice *xendev)
{
struct XenConsole *con = container_of(xendev, struct
XenConsole, xendev);
int limit;
@@ -263,7 +263,7 @@ struct XenDevOps xen_console_ops = {
.size = sizeof(struct XenConsole),
.flags = DEVOPS_FLAG_IGNORE_STATE,
.init = con_init,
-.connect= con_connect,
+
Re: [Qemu-devel] [PATCH 1/7] qcow2: Make get_bits_from_size() common
On Fri, Sep 24, 2010 at 01:50:39AM +0400, malc wrote:
> On Thu, 23 Sep 2010, Stefan Hajnoczi wrote:
>
> > The get_bits_from_size() calculates the log base-2 of a number. This is
> > useful in bit manipulation code working with power-of-2s.
> >
> > Currently used by qcow2 and needed by qed in a follow-on patch.
>
> int ilog2 (size_t size)
> {
> if (size & (size - 1))
> return -1;
>
> return __builtin_ctzl (size);
> }
>
> Ifdef WIN64 omitted for brevity.
What is the situation with WIN64?
Stefan
[Qemu-devel] [Bug 646427] Re: VirtFS mapped symlinks resolved wrong
And maybe you should use lsetxattr and lgetxattr instead of the symlink resolving versions setxattr and getxattr -- VirtFS mapped symlinks resolved wrong https://bugs.launchpad.net/bugs/646427 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: I tried to map a folder with qemu-kvm qemu-kvm-0.13.0-rc1-3-gc9c2179 (this is v0.13.0-rc1-16667-gc9c2179). I mounted it first in passthrough mode and saw all symlinks as expected. Then I used mapped and noticed that the target of a symlink changed to the actual data inside the linked folder as target instead of the target filename. So for example if you have a file abc with the content "omg, this is important stuff" and a symlink lnkme -> abc then it wiill look inside the kvm with mounted 9p virtio (mapped) like that: lnkme -> omg, this is important stuff Another problem I noticed was that I cannot mount it (mapped or passthrough) using /etc/rc.local or /etc/fstab, but after login as root using mount /mnt or mount -t 9p -o trans=virtio host_share /mnt (the same stuff i tried inside /etc/rc.local) The only output on a failed mount in rc.local/fstab I get is [ 15.035920] device: '9p-1': device_add [ 15.038180] 9p: no channels available [ 15.038937] device: '9p-1': device_unregister [ 15.049123] device: '9p-1': device_create_release
Re: [Qemu-devel] [PATCH] virtio-net: Don't pass NULL peer to tap routines
Alex Williamson writes: > On Thu, 2010-09-23 at 12:43 -0500, Anthony Liguori wrote: >> On 09/22/2010 02:52 PM, Alex Williamson wrote: >> > During a hotplug, the netdev might be removed before the unplug? >> > connected virtio device. When this happens, the guest might >> > be running cleanup operations that can trigger a segfault in >> > qemu. Avoid one set of these by checking whether the peer >> > device is present before trying to do tap operations. >> > >> > Signed-off-by: Alex Williamson >> > >> >> Can you explain this scenario a little better? >> >> If nc.peer is NULL when set_features is called, it would seem to me like >> we're in a pretty critical state. I agree that we shouldn't set fault, >> but I wonder if the real bug is that this can happen at all. > > Unfortunately that critical state happens all the time since device_del > does an asynchronous ACPI call into the guest and libvirt isn't blocked > waiting for that to complete and doesn't poll to see if the device goes > away. So it's actually pretty common today that the netdev disappears > before the device. We talked about this in the community call on > Tuesday, and I think Michael is trying to think of a way to solve this, > perhaps by separating the guest releasing the device from the device > removal. > > In the mean time, virtio-net has this hole that seems like it can be > avoided by simply checking some pointers on a slow path. Since the > netdev has already disappeared, attempting to set features on it seems > pointless. The change in the load function is really just a paranoia > check since it followed the same model of calling tap_*() funcs w/o > checking the value of nc.peer. Thanks, I figure we should either make netdev_del fail when the netdev is in use, or make its users cope graciously with the netdev going away (make it look like somebody yanked the cable).
Re: [Qemu-devel] [PATCH] CMOS file support
Mathias Krause writes:
> Hi Kevin,
>
> On 17.09.2010 12:44, Kevin Wolf wrote:
>> Hi Mathias,
>>
>> Am 17.09.2010 08:42, schrieb Mathias Krause:
Using QEMU's block devices instead of a simple file would be
more consistent with the rest of QEMU and allow reading the
CMOS data not only from a file but also from an URL or other
sources.
>>> Thanks for the hint. Since this is my first contribution to the project
>>> I'm not that familiar with the code. Looking at other places, e.g. how
>>> the -kernel option gets handled, I just see FILE everywhere. Can you
>>> give me some pointers how to use this interface?
>>
>> Have a look at block.h which contains the prototypes for the public
>> block layer interface.
>>
>> Basically, you need to create a BlockDriverState with bdrv_new() and
>> then open it with bdrv_open(). You'll want to specify the raw block
>> driver for opening the image, you get it with bdrv_find_format("raw").
>> bdrv_pread/pwrite are the right functions to access the file with byte
>> granularity (other functions work on 512 byte sectors). bdrv_delete
>> frees the the BlockDriverState when you're done.
>
> Thank you for the detailed writeup. I think I should figure out how to
> use it myself now. Albeit there seem to be not many users of this
> interface right now. Looks like it's currently only used for storage
> devices. So I'm questioning myself: What _real_ benefit would it bring
> to use the QEMU block device layer for the CMOS file?
I'd view initial CMOS contents as configuration. We don't use the block
layer to access configuration files.
Re: [Qemu-devel] [PATCH] CMOS file support
Anthony Liguori writes: > On 09/16/2010 08:58 AM, Mathias Krause wrote: >> In contrast to the BIOS and Option ROMs the CMOS content cannot be >> predefined by the user. Also the amount of useable CMOS ARM is pretty >> limited, even though the amount of CMOS bytes emulated by qemu is >> already twice as much as of the original MC146818. Nevertheless those >> limitations are pretty annoying when testing different BIOS replacement >> implementations like coreboot in combination with FILO that use CMOS >> values above the basic RTC range for its own purpose to, e.g., control >> the boot device order using a string containing the boot devices to >> probe. >> >> This patch adds support to specify a file to read the initial CMOS >> content from. It also increases the CMOS size to 256 bytes and >> implements access to the extended memory range via I/O ports 0x72 and >> 0x73. >> >> Use it like: `qemu -global mc146818rtc.file=cmos.bin ...' where cmos.bin >> is a binary file, sized 256 bytes containing the CMOS RAM. >> >> Signed-off-by: Mathias Krause >> > > Instead of using FILE, I'd suggest using a BlockDriver to read and > write the data. > > I think it would be very nice to add write support too so that writes > to CMOS were persisted across boots. Persisting CMOS makes it state instead of configuration. Use of block layer (treat it like a drive) makes more sense then.
Re: [Qemu-devel] [PATCH] CMOS file support
Mathias Krause writes: > On 17.09.2010 15:27, Anthony Liguori wrote: >> On 09/17/2010 01:50 AM, Mathias Krause wrote: >>> Am 16.09.2010 19:20 schrieb Anthony Liguori: >>> Instead of using FILE, I'd suggest using a BlockDriver to read and write the data. >>> I'll fix that as soon as I figured how to use this interface. >>> >>> I think it would be very nice to add write support too so that writes to CMOS were persisted across boots. >>> Indeed. Also I would like to have a command line interface like '-cmos >>> cmos.bin' instead of the ugly '-global mc146818rtc.file=cmos.bin'. But >>> I'm not aware how to create such an alias. Any pointers? >>> >> >> Unfortunately, it's a little complicated although it should get better >> in the future. The right way to do this today would be: >> >> -drive file=cmos.bin,if=none,id=nvram -global mc146818rtc.drive=nvram >> >> The use of -drive is historic. We'll have a better option in the future >> that will look something like: >> >> -blockdev file=cmos.bin,id=nvram -global mc146818rtc.drive=nvram > > Well, I guess "better" lies in the eye of the beholder, then ;) > > >> But in either case, I'd suggest adding an -nvram option that was: >> >> -nvram >> >> Which would do: >> >> drive_add(optarg, "if=none,id=nvram"); >> >> And then in the RTC code, default drive to nvram. > > I managed to add the nvram option but how do I get a reference to the > drive back in the RTC code? Would I just loop with drive_get(IF_NONE, 0, > i) until the id of the returned drive is "nvram"? Doesn't sound right > but I've found no better solution due to the lack of an > drive_get_by_id() function. Use DEFINE_PROP_DRIVE() to define mc146818rtc's property drive, and it's automatic: qdev assigns a pointer to the BlockDriverState. To access DriveInfo, use drive_get_by_blockdev(). I doubt you need that. [...]
[Qemu-devel] Re: [PATCH 1/7] qcow2: Make get_bits_from_size() common
On 09/24/2010 10:37 AM, Stefan Hajnoczi wrote:
On Fri, Sep 24, 2010 at 01:50:39AM +0400, malc wrote:
On Thu, 23 Sep 2010, Stefan Hajnoczi wrote:
The get_bits_from_size() calculates the log base-2 of a number. This is
useful in bit manipulation code working with power-of-2s.
Currently used by qcow2 and needed by qed in a follow-on patch.
int ilog2 (size_t size)
{
if (size& (size - 1))
return -1;
return __builtin_ctzl (size);
}
Ifdef WIN64 omitted for brevity.
What is the situation with WIN64?
long is only 32 bit, so you need __builtin_ctzll.
Paolo
Re: [Qemu-devel] [PATCH] virtio-net: Don't pass NULL peer to tap routines
On Fri, 2010-09-24 at 11:31 +0200, Markus Armbruster wrote: > Alex Williamson writes: > > > On Thu, 2010-09-23 at 12:43 -0500, Anthony Liguori wrote: > >> On 09/22/2010 02:52 PM, Alex Williamson wrote: > >> > During a hotplug, the netdev might be removed before the > > unplug? yep > >> > connected virtio device. When this happens, the guest might > >> > be running cleanup operations that can trigger a segfault in > >> > qemu. Avoid one set of these by checking whether the peer > >> > device is present before trying to do tap operations. > >> > > >> > Signed-off-by: Alex Williamson > >> > > >> > >> Can you explain this scenario a little better? > >> > >> If nc.peer is NULL when set_features is called, it would seem to me like > >> we're in a pretty critical state. I agree that we shouldn't set fault, > >> but I wonder if the real bug is that this can happen at all. > > > > Unfortunately that critical state happens all the time since device_del > > does an asynchronous ACPI call into the guest and libvirt isn't blocked > > waiting for that to complete and doesn't poll to see if the device goes > > away. So it's actually pretty common today that the netdev disappears > > before the device. We talked about this in the community call on > > Tuesday, and I think Michael is trying to think of a way to solve this, > > perhaps by separating the guest releasing the device from the device > > removal. > > > > In the mean time, virtio-net has this hole that seems like it can be > > avoided by simply checking some pointers on a slow path. Since the > > netdev has already disappeared, attempting to set features on it seems > > pointless. The change in the load function is really just a paranoia > > check since it followed the same model of calling tap_*() funcs w/o > > checking the value of nc.peer. Thanks, > > I figure we should either make netdev_del fail when the netdev is in > use, or make its users cope graciously with the netdev going away (make > it look like somebody yanked the cable). I'm not sure how useful it is, but I like the idea that we can swap the netdev from under a running guest. I believe this is possible with the emulated drivers since they don't try to push features into the tap device. Perhaps something like you suggest where a netdev going away sets a link down on the device. If/when a netdev gets reattached, the link returns and features are renegotiated. Then we could move the guest between NAT'd bridges and transparent bridges and it'd look like we moved the network cable from one switch to another in the guest. Alex
Re: [Qemu-devel] Re: [PATCH 1/7] qcow2: Make get_bits_from_size() common
On Fri, Sep 24, 2010 at 1:56 PM, Paolo Bonzini wrote:
> On 09/24/2010 10:37 AM, Stefan Hajnoczi wrote:
>>
>> On Fri, Sep 24, 2010 at 01:50:39AM +0400, malc wrote:
>>>
>>> On Thu, 23 Sep 2010, Stefan Hajnoczi wrote:
>>>
The get_bits_from_size() calculates the log base-2 of a number. This is
useful in bit manipulation code working with power-of-2s.
Currently used by qcow2 and needed by qed in a follow-on patch.
>>>
>>> int ilog2 (size_t size)
>>> {
>>> if (size& (size - 1))
>>> return -1;
>>>
>>> return __builtin_ctzl (size);
>>> }
>>>
>>> Ifdef WIN64 omitted for brevity.
>>
>> What is the situation with WIN64?
>
> long is only 32 bit, so you need __builtin_ctzll.
Thanks Paolo and malc. It should be easy enough to use the builtin instead.
Stefan
[Qemu-devel] [PATCH] Watchdog: disable watchdog timer when hard-rebooting a guest.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
>From e3832105c372f59cce9058b48fbde229af89c518 Mon Sep 17 00:00:00 2001
From: Richard W.M. Jones
Date: Fri, 24 Sep 2010 16:08:06 +0100
Subject: [PATCH] Watchdog: disable watchdog timer when hard-rebooting a guest.
This commit causes the watchdog timer to be reset when a guest is
hard-rebooted.
The failure case previously was as follows:
(a) guest boots, watchdog is enabled
(b) guest does a reset eg:
echo 'b' > /proc/sysrq-trigger
(note that an ordinary /sbin/reboot wouldn't hit this case
since as the watchdog daemon is shut down, the daemon would
properly disable the watchdog device)
(c) the reboot takes longer than the remaining time on the
watchdog
(d) the watchdog therefore fires during the reboot
(e) probably the VM would just reboot again at this point which
is pretty benign, but it could depend on the action that the
user had selected for the watchdog
Now we use the qdev reset function to register a reset handler
which disables the timer. Note the handler is called _either_
just after init _or_ when the guest reboots.
In the i6300esb case there is a small refactoring of the code so
that the device's internal state is now fully restored to defaults
on a reboot.
Signed-off-by: Richard W.M. Jones
---
hw/wdt_i6300esb.c | 51 +--
hw/wdt_ib700.c| 20
2 files changed, 45 insertions(+), 26 deletions(-)
diff --git a/hw/wdt_i6300esb.c b/hw/wdt_i6300esb.c
index 46e1df8..dbd05ba 100644
--- a/hw/wdt_i6300esb.c
+++ b/hw/wdt_i6300esb.c
@@ -102,6 +102,8 @@ struct I6300State {
typedef struct I6300State I6300State;
+static void i6300esb_reset(DeviceState *dev);
+
/* This function is called when the watchdog has either been enabled
* (hence it starts counting down) or has been keep-alived.
*/
@@ -140,16 +142,6 @@ static void i6300esb_disable_timer(I6300State *d)
qemu_del_timer(d->timer);
}
-static void i6300esb_reset(I6300State *d)
-{
-/* XXX We should probably reset other parts of the state here,
- * but we should also reset our state on general machine reset
- * too. For now just disable the timer so it doesn't fire
- * again after the reboot.
- */
-i6300esb_disable_timer(d);
-}
-
/* This function is called when the watchdog expires. Note that
* the hardware has two timers, and so expiry happens in two stages.
* If d->stage == 1 then we perform the first stage action (usually,
@@ -181,7 +173,7 @@ static void i6300esb_timer_expired(void *vp)
if (d->reboot_enabled) {
d->previous_reboot_flag = 1;
watchdog_perform_action(); /* This reboots, exits, etc */
-i6300esb_reset(d);
+i6300esb_reset(&d->dev.qdev);
}
/* In "free running mode" we start stage 1 again. */
@@ -394,17 +386,9 @@ static int i6300esb_init(PCIDevice *dev)
I6300State *d = DO_UPCAST(I6300State, dev, dev);
uint8_t *pci_conf;
-d->reboot_enabled = 1;
-d->clock_scale = CLOCK_SCALE_1KHZ;
-d->int_type = INT_TYPE_IRQ;
-d->free_run = 0;
-d->locked = 0;
-d->enabled = 0;
+i6300esb_debug("watchdog init\n");
+
d->timer = qemu_new_timer(vm_clock, i6300esb_timer_expired, d);
-d->timer1_preload = 0xf;
-d->timer2_preload = 0xf;
-d->stage = 1;
-d->unlock_state = 0;
d->previous_reboot_flag = 0;
pci_conf = d->dev.config;
@@ -413,11 +397,33 @@ static int i6300esb_init(PCIDevice *dev)
pci_config_set_class(pci_conf, PCI_CLASS_SYSTEM_OTHER);
pci_register_bar(&d->dev, 0, 0x10,
-PCI_BASE_ADDRESS_SPACE_MEMORY, i6300esb_map);
+ PCI_BASE_ADDRESS_SPACE_MEMORY, i6300esb_map);
return 0;
}
+static void i6300esb_reset(DeviceState *dev)
+{
+I6300State *d = DO_UPCAST(I6300State, dev.qdev, dev);
+
+i6300esb_debug("watchdog reset\n");
+
+/* NB: Don't change d->previous_reboot_flag in this function. */
+
+d->reboot_enabled = 1;
+d->clock_scale = CLOCK_SCALE_1KHZ;
+d->int_type = INT_TYPE_IRQ;
+d->free_run = 0;
+d->locked = 0;
+d->enabled = 0;
+d->timer1_preload = 0xf;
+d->timer2_preload = 0xf;
+d->stage = 1;
+d->unlock_state = 0;
+
+i6300esb_disable_timer(d);
+}
+
static WatchdogTimerModel model = {
.wdt_name = "i6300esb",
.wdt_description = "Intel 6300ESB",
@@ -427,6 +433,7 @@ static PCIDeviceInfo i6300esb_info = {
.qdev.name= "i6300esb",
.qdev.size= sizeof(I6300State),
.qdev.vmsd= &vmstate_i6300esb,
+.qdev.reset = i6300esb_reset,
.config_read = i6300esb_config_read,
.config_write = i6300esb_config_write,
.init = i
[Qemu-devel] [Bug 646427] Re: VirtFS mapped symlinks resolved wrong
Responding to multiple issues raised above. - Let us track this bug for the security/symlink issue and open a different defect for the mount issue. - I tried to reproduce this defect with the QEMU mainline. I don't see the problem. More description on the environment (Host OS/Guest OS/ QEMU command line etc) and how to reproduce the problem will be helpful. [r...@localhost mmnt]# cat file1 omg it is important [r...@localhost mmnt]# ln -sf file1 sym1 [r...@localhost mmnt]# ls -l total 16 -rw-r--r-- 1 root root 20 2010-09-24 01:24 file1 lrwxrwxrwx 1 root root 6 2010-09-24 01:24 sym1 -> file1 [r...@localhost mmnt]# logout - Moshroom: - There are multiple security models here, if you use 'passthrough' same type of files are created on the host/guest. But if you use 'mapped' security model this is how we do it. This security model is for cloud use case scenarios. Please read more in this post http://www.mail-archive.com/qemu-devel@nongnu.org/msg31452.html - No need to use lsetattr/lgetattr here because we always create regular files in this model. -- VirtFS mapped symlinks resolved wrong https://bugs.launchpad.net/bugs/646427 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: I tried to map a folder with qemu-kvm qemu-kvm-0.13.0-rc1-3-gc9c2179 (this is v0.13.0-rc1-16667-gc9c2179). I mounted it first in passthrough mode and saw all symlinks as expected. Then I used mapped and noticed that the target of a symlink changed to the actual data inside the linked folder as target instead of the target filename. So for example if you have a file abc with the content "omg, this is important stuff" and a symlink lnkme -> abc then it wiill look inside the kvm with mounted 9p virtio (mapped) like that: lnkme -> omg, this is important stuff Another problem I noticed was that I cannot mount it (mapped or passthrough) using /etc/rc.local or /etc/fstab, but after login as root using mount /mnt or mount -t 9p -o trans=virtio host_share /mnt (the same stuff i tried inside /etc/rc.local) The only output on a failed mount in rc.local/fstab I get is [ 15.035920] device: '9p-1': device_add [ 15.038180] 9p: no channels available [ 15.038937] device: '9p-1': device_unregister [ 15.049123] device: '9p-1': device_create_release
[Qemu-devel] [PATCH] Don't exit with zero in the trap handler
When configure runs "exit 1", the trap handler is run to cleanup any
files created by configure, but this trap handler itself calls "exit"
with no argument (which means zero exit code):
[...]
+ echo Error: zlib check failed
Error: zlib check failed
+ echo Make sure to have the zlib libs and headers installed.
Make sure to have the zlib libs and headers installed.
+ echo
+ exit 1
+ rm -f /tmp/qemu-conf--2779-.c /tmp/qemu-conf--2779-.o
/tmp/qemu-conf--2779-.exe
+ exit
To fix this, remove the call to exit from the trap handler, leaving it
to the shell shell to exitafter the trap handler is run (honoring any
previously provided exit code).
---
configure |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure b/configure
index 3bfc5e9..e0147d1 100755
--- a/configure
+++ b/configure
@@ -15,7 +15,7 @@ TMPC="${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.c"
TMPO="${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.o"
TMPE="${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.exe"
-trap "rm -f $TMPC $TMPO $TMPE ; exit" EXIT INT QUIT TERM
+trap "rm -f $TMPC $TMPO $TMPE" EXIT INT QUIT TERM
compile_object() {
$cc $QEMU_CFLAGS -c -o $TMPO $TMPC > /dev/null 2> /dev/null
--
1.7.1
Re: [Qemu-devel] Re: [PATCH v7] Introduce qemu_madvise()
Am 20.09.2010 um 22:33 schrieb Blue Swirl: On Sun, Sep 19, 2010 at 10:11 AM, Andreas Färber > wrote: From: Andreas Färber vl.c has a Sun-specific hack to supply a prototype for madvise(), but the call site has apparently moved to arch_init.c. Haiku doesn't implement madvise() in favor of posix_madvise(). OpenBSD and Solaris 10 don't implement posix_madvise() but madvise(). Check for madvise() and posix_madvise() in configure and supply qemu_madvise() as wrapper. Prefer madvise() over posix_madvise() due to flag availability. Convert all callers to use qemu_madvise() and QEMU_MADV_*. Note that on Solaris the warning is fixed by moving the madvise() prototype, not by qemu_madvise() itself. It helps with porting though, and it simplifies most call sites. v6 -> v7: * Adopt madvise() rather than posix_madvise() semantics for returning errors. * Use EINVAL in place of ENOTSUP. v5 -> v6: * Replace two leftover instances of POSIX_MADV_NORMAL with QEMU_MADV_INVALID. Spotted by Blue Swirl. v4 -> v5: * Introduce QEMU_MADV_INVALID, suggested by Alexander Graf. Note that this relies on -1 not being a valid advice value. v3 -> v4: * Eliminate #ifdefs at qemu_advise() call sites. Requested by Blue Swirl. This will currently break the check in kvm-all.c by calling madvise() with a supported flag, which will not fail. Ideas/patches welcome. v2 -> v3: * Reuse the *_MADV_* defines for QEMU_MADV_*. Suggested by Alexander Graf. * Add configure check for madvise(), too. Add defines to Makefile, not QEMU_CFLAGS. Convert all callers, untested. Suggested by Blue Swirl. * Keep Solaris' madvise() prototype around. Pointed out by Alexander Graf. * Display configure check results. v1 -> v2: * Don't rely on posix_madvise() availability, add qemu_madvise(). Suggested by Blue Swirl. Signed-off-by: Andreas Färber Cc: Blue Swirl Cc: Alexander Graf Cc: Andrea Arcangeli --- arch_init.c |2 +- configure | 33 + exec.c |8 ++-- hw/virtio-balloon.c |4 ++-- kvm-all.c | 12 osdep.c | 20 osdep.h | 35 +++ vl.c|3 --- 8 files changed, 97 insertions(+), 20 deletions(-) diff --git a/osdep.c b/osdep.c index 30426ff..56c6944 100644 --- a/osdep.c +++ b/osdep.c @@ -28,6 +28,7 @@ #include #include #include +#include With the patch applied, I get a warning here with mingw from Debian stable: CCosdep.o /src/qemu/osdep.c:31:22: error: sys/mman.h: No such file or directory For some reason, it doesn't happen with newer mingw from Debian testing. Any suggestions what to do about that? Would it work without, i.e. could we enclose it in #ifndef _WIN32? Andreas
[Qemu-devel] [PULL] Missing patches in qemu master
Hello Anthony, could you please pull some patches which had been sent to qemu-devel some time ago? See these links: http://patchwork.ozlabs.org/patch/59044/ http://patchwork.ozlabs.org/patch/60469/ http://patchwork.ozlabs.org/patch/61150/ http://patchwork.ozlabs.org/patch/64624/ The original subject of the last one was 'linux-user: Fix type m86k -> m68k'. I fixed the typo (type -> typo) in the subject for the pull request. The first and the last patch are *-user related patches. I hope you will commit them nevertheless - people had time enough to make a comment. Thanks, Stefan The following changes since commit c973a36d178510790c148f88104b85016f59235a: fmopl: workaround for -Wempty-body (2010-09-24 04:09:01 +0400) are available in the git repository at: git://git.weilnetz.de/git/qemu for-anthony Stefan Weil (4): Add new user mode option -ignore-environment docs: Improve documentation Fix spelling in comments linux-user: Fix typo m86k -> m68k bsd-user/main.c |6 + docs/migration.txt| 56 hw/pci.c |2 +- linux-user/m68k-sim.c |6 ++-- linux-user/main.c |6 + posix-aio-compat.c|2 +- qemu-doc.texi | 14 ui/vnc-enc-tight.c|2 +- 8 files changed, 60 insertions(+), 34 deletions(-)
[Qemu-devel] [PATCH] block: Use GCC_FMT_ATTR and fix a format error
Adding the gcc format attribute detects a format bug
which is fixed here.
v2:
Don't use type cast. BDRV_SECTOR_SIZE is unsigned long long,
so %lld should be the correct format specifier.
Cc: Blue Swirl
Cc: Kevin Wolf
Signed-off-by: Stefan Weil
---
block/blkverify.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/block/blkverify.c b/block/blkverify.c
index 8083464..b2a12fe 100644
--- a/block/blkverify.c
+++ b/block/blkverify.c
@@ -53,7 +53,8 @@ static AIOPool blkverify_aio_pool = {
.cancel = blkverify_aio_cancel,
};
-static void blkverify_err(BlkverifyAIOCB *acb, const char *fmt, ...)
+static void GCC_FMT_ATTR(2, 3) blkverify_err(BlkverifyAIOCB *acb,
+ const char *fmt, ...)
{
va_list ap;
@@ -299,7 +300,7 @@ static void blkverify_verify_readv(BlkverifyAIOCB *acb)
{
ssize_t offset = blkverify_iovec_compare(acb->qiov, &acb->raw_qiov);
if (offset != -1) {
-blkverify_err(acb, "contents mismatch in sector %ld",
+blkverify_err(acb, "contents mismatch in sector %lld",
acb->sector_num + (offset / BDRV_SECTOR_SIZE));
}
}
--
1.7.1
[Qemu-devel] [Bug 498035] Re: qemu hangs on shutdown or reboot (XP guest)
Also happens in Ubunto 10.04LTS Linux bnesbitt-desktop 2.6.32-24-generic #43-Ubuntu SMP Thu Sep 16 14:58:24 UTC 2010 x86_64 GNU/Linux -- qemu hangs on shutdown or reboot (XP guest) https://bugs.launchpad.net/bugs/498035 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: Triaged Bug description: When I shut down or reboot my Windows XP guest, about half the time, it hangs at the point where it says "Windows is shutting down...". At that point qemu is using 100% of one host CPU, about 85% user, 15% system. (Core 2 Quad 2.66GHz) This is the command line I use to start qemu: qemu-system-x86_64 -hda winxp.img -k en-us -m 2048 -smp 2 -vnc :3100 -usbdevice tablet -boot c -enable-kvm &
[Qemu-devel] Re: [PATCH 0/2] powerpc: Improve BookE emulation (v2)
On Mon, Sep 20, 2010 at 07:30:38PM +0200, Edgar E. Iglesias wrote: > Improve BookE emulation in preparation for virtex 5 support. > Once this is OK, the Xilinx specific parts will follow. > > Cheers, > Edgar Pushed. > v2: > * Fix MMU emulation details and other comments from A. Graf. > > Edgar E. Iglesias (2): > powerpc: Improve emulation of the BookE MMU > powerpc: Make the decr interrupt type overridable > > hw/ppc.c| 16 +--- > hw/ppc.h|4 +++- > hw/ppc4xx_devs.c|2 +- > target-ppc/cpu.h|3 +++ > target-ppc/helper.c | 38 ++ > 5 files changed, 50 insertions(+), 13 deletions(-) >
[Qemu-devel] Re: [PATCH 4/4] powerpc: Add a virtex5 ml507 refdesign board
On Mon, Sep 20, 2010 at 12:53:42PM +0200, Alexander Graf wrote:
> Edgar E. Iglesias wrote:
> > Signed-off-by: Edgar E. Iglesias
> > ---
> > Makefile.target|8 +
> > default-configs/ppc-softmmu.mak|2 +
> > default-configs/ppc64-softmmu.mak |2 +
> > default-configs/ppcemb-softmmu.mak |2 +
> > hw/virtex_ml507.c | 283
> >
> > 5 files changed, 297 insertions(+), 0 deletions(-)
> > create mode 100644 hw/virtex_ml507.c
> >
> > diff --git a/Makefile.target b/Makefile.target
> > index a4e80b1..91d0381 100644
> > --- a/Makefile.target
> > +++ b/Makefile.target
> > @@ -217,9 +217,17 @@ obj-ppc-y += ppc4xx_devs.o ppc4xx_pci.o ppc405_uc.o
> > ppc405_boards.o
> > obj-ppc-y += ppc440.o ppc440_bamboo.o
> > # PowerPC E500 boards
> > obj-ppc-y += ppce500_mpc8544ds.o
> > +# PowerPC 440 Xilinx ML507 reference board.
> > +obj-ppc-y += virtex_ml507.o
> > obj-ppc-$(CONFIG_KVM) += kvm_ppc.o
> > obj-ppc-$(CONFIG_FDT) += device_tree.o
> >
> > +# Xilinx PPC peripherals
> > +obj-ppc-y += xilinx_intc.o
> > +obj-ppc-y += xilinx_timer.o
> > +obj-ppc-y += xilinx_uartlite.o
> > +obj-ppc-y += xilinx_ethlite.o
> > +
> > obj-mips-y = mips_r4k.o mips_jazz.o mips_malta.o mips_mipssim.o
> > obj-mips-y += mips_addr.o mips_timer.o mips_int.o
> > obj-mips-y += vga.o i8259.o
> > diff --git a/default-configs/ppc-softmmu.mak
> > b/default-configs/ppc-softmmu.mak
> > index c026bbb..940f4bf 100644
> > --- a/default-configs/ppc-softmmu.mak
> > +++ b/default-configs/ppc-softmmu.mak
> > @@ -32,4 +32,6 @@ CONFIG_IDE_MACIO=y
> > CONFIG_NE2000_ISA=y
> > CONFIG_SOUND=y
> > CONFIG_VIRTIO_PCI=y
> > +CONFIG_PFLASH_CFI01=y
> > CONFIG_PFLASH_CFI02=y
> > +CONFIG_PTIMER=y
> > diff --git a/default-configs/ppc64-softmmu.mak
> > b/default-configs/ppc64-softmmu.mak
> > index 0101a28..e1bc6b8 100644
> > --- a/default-configs/ppc64-softmmu.mak
> > +++ b/default-configs/ppc64-softmmu.mak
> > @@ -32,4 +32,6 @@ CONFIG_IDE_MACIO=y
> > CONFIG_NE2000_ISA=y
> > CONFIG_SOUND=y
> > CONFIG_VIRTIO_PCI=y
> > +CONFIG_PFLASH_CFI01=y
> > CONFIG_PFLASH_CFI02=y
> > +CONFIG_PTIMER=y
> > diff --git a/default-configs/ppcemb-softmmu.mak
> > b/default-configs/ppcemb-softmmu.mak
> > index 8ba9ac1..8f1cc09 100644
> > --- a/default-configs/ppcemb-softmmu.mak
> > +++ b/default-configs/ppcemb-softmmu.mak
> > @@ -32,4 +32,6 @@ CONFIG_IDE_MACIO=y
> > CONFIG_NE2000_ISA=y
> > CONFIG_SOUND=y
> > CONFIG_VIRTIO_PCI=y
> > +CONFIG_PFLASH_CFI01=y
> > CONFIG_PFLASH_CFI02=y
> > +CONFIG_PTIMER=y
> > diff --git a/hw/virtex_ml507.c b/hw/virtex_ml507.c
> > new file mode 100644
> > index 000..bc53cf4
> > --- /dev/null
> > +++ b/hw/virtex_ml507.c
> > @@ -0,0 +1,283 @@
> > +/*
> > + * Model of Xilinx Virtex5 ML507 PPC-440 refdesign.
> > + *
> > + * Copyright (c) 2010 Edgar E. Iglesias.
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a
> > copy
> > + * of this software and associated documentation files (the "Software"),
> > to deal
> > + * in the Software without restriction, including without limitation the
> > rights
> > + * to use, copy, modify, merge, publish, distribute, sublicense, and/or
> > sell
> > + * copies of the Software, and to permit persons to whom the Software is
> > + * furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be included
> > in
> > + * all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> > OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> > OTHER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > FROM,
> > + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> > IN
> > + * THE SOFTWARE.
> > + */
> > +
> > +#include "sysbus.h"
> > +#include "hw.h"
> > +#include "pc.h"
> > +#include "net.h"
> > +#include "flash.h"
> > +#include "sysemu.h"
> > +#include "devices.h"
> > +#include "boards.h"
> > +#include "device_tree.h"
> > +#include "loader.h"
> > +#include "elf.h"
> > +#include "qemu-log.h"
> > +
> > +#include "ppc.h"
> > +#include "ppc4xx.h"
> > +#include "ppc440.h"
> > +#include "ppc405.h"
> > +
> > +#include "blockdev.h"
> > +#include "xilinx.h"
> > +
> > +#define EPAPR_MAGIC(0x45504150)
> > +#define FLASH_SIZE (16 * 1024 * 1024)
> > +
> > +static struct
> > +{
> > +uint32_t bootstrap_pc;
> > +uint32_t cmdline;
> > +uint32_t fdt;
> > +uint32_t ima_size;
> > +void *vfdt;
> > +} boot_info;
> >
>
> Hrm. Any way you could make this be not a global? Maybe add CPUState *
> in there and pass it as opaque to the reset function instead of env.
OK, will fix.
> > +
> > +/* Cre
[Qemu-devel] [Bug 646427] Re: VirtFS mapped symlinks resolved wrong
Host OS is Debian sid/experimental amd64 with 2.6.32-5-amd64 (2.6.32-23). qemu-kvm version can be found above. As said before the symlink were created outside the vm and then tried to access inside the vm. So I have to use passthrough in host/client shared folders... which means I have to run kvm as root. :( -- VirtFS mapped symlinks resolved wrong https://bugs.launchpad.net/bugs/646427 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: I tried to map a folder with qemu-kvm qemu-kvm-0.13.0-rc1-3-gc9c2179 (this is v0.13.0-rc1-16667-gc9c2179). I mounted it first in passthrough mode and saw all symlinks as expected. Then I used mapped and noticed that the target of a symlink changed to the actual data inside the linked folder as target instead of the target filename. So for example if you have a file abc with the content "omg, this is important stuff" and a symlink lnkme -> abc then it wiill look inside the kvm with mounted 9p virtio (mapped) like that: lnkme -> omg, this is important stuff Another problem I noticed was that I cannot mount it (mapped or passthrough) using /etc/rc.local or /etc/fstab, but after login as root using mount /mnt or mount -t 9p -o trans=virtio host_share /mnt (the same stuff i tried inside /etc/rc.local) The only output on a failed mount in rc.local/fstab I get is [ 15.035920] device: '9p-1': device_add [ 15.038180] 9p: no channels available [ 15.038937] device: '9p-1': device_unregister [ 15.049123] device: '9p-1': device_create_release
[Qemu-devel] [Bug 646427] Re: VirtFS mapped symlinks resolved wrong
But mapped is also really confusing. Everything inside the vm: $ id uid=0(root) gid=0(root) groups=0(root) $ touch newfile $ -rw-r--r-- 1 root 1000 0 Sep 24 20:39 newfile So the gid is not set correctly. On thhe host: % xattr newfile user.virtfs.uid user.virtfs.mode I started it using: % /usr/local/kvm/bin/qemu-system-x86_64 -m 1024 -kernel linux-2.6.35.5.qemu -drive file=root.cow1,if=virtio -net nic,macaddr=02:ca:ff:ee:ba:be,model=virtio,vlan=1 -net tap,ifname=tap1,vlan=1,script=no -virtfs local,path=/shared,security_model=mapped,mount_tag=host -nographic -- VirtFS mapped symlinks resolved wrong https://bugs.launchpad.net/bugs/646427 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: I tried to map a folder with qemu-kvm qemu-kvm-0.13.0-rc1-3-gc9c2179 (this is v0.13.0-rc1-16667-gc9c2179). I mounted it first in passthrough mode and saw all symlinks as expected. Then I used mapped and noticed that the target of a symlink changed to the actual data inside the linked folder as target instead of the target filename. So for example if you have a file abc with the content "omg, this is important stuff" and a symlink lnkme -> abc then it wiill look inside the kvm with mounted 9p virtio (mapped) like that: lnkme -> omg, this is important stuff Another problem I noticed was that I cannot mount it (mapped or passthrough) using /etc/rc.local or /etc/fstab, but after login as root using mount /mnt or mount -t 9p -o trans=virtio host_share /mnt (the same stuff i tried inside /etc/rc.local) The only output on a failed mount in rc.local/fstab I get is [ 15.035920] device: '9p-1': device_add [ 15.038180] 9p: no channels available [ 15.038937] device: '9p-1': device_unregister [ 15.049123] device: '9p-1': device_create_release
TR : RE : [Qemu-devel] Re: Win2k host problem with {get, free}{addr, name}info()
Forget cc
-- Message transféré --
De : "Bastien ROUCARIES"
Date : 24 sept. 2010 23:21
Objet : RE : [Qemu-devel] Re: Win2k host problem with {get, free}{addr,
name}info()
À : "Blue Swirl"
If you see a recent thread on the gnulib mailling list, you will show that
gnulib could be compiled as a kind of library in its own directory. Autotool
stuff will be limited to this subdirectory.
I have even use cmake with gnulib using this approach. See the libposix
path on the documentation and/or gnulib mailling list
Bastien
Le 22 sept. 2010 19:17, "Blue Swirl" a écrit :
On Wed, Sep 22, 2010 at 1:40 PM, Paolo Bonzini wrote:
> On 09/21/2010 08:32 PM...
>
> gnulib-tool wants to patch configure.ac. After adding an empty one and
> running "gnulib-tool -...
> I think we want to avoid this path.
>
[Qemu-devel] [PATCH] Some tweaks to make some features only built-in when necessary
In trying to make the qemu binary size smaller, I've come across some things
that can be left out of the binary without affecting the binary working. I've
got more patches in the pipeline but the more I try to take out, the more
invasive the patch. These are pretty simple to get started.
Binary savings total for these patches is 606K.
---
Makefile.objs | 31 +--
configure | 20
migration.c | 12
net.c |4
4 files changed, 61 insertions(+), 6 deletions(-)
diff --git a/Makefile.objs b/Makefile.objs
index dad4593..0c74477 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -12,9 +12,24 @@ block-obj-y += nbd.o block.o aio.o aes.o osdep.o
qemu-config.o
block-obj-$(CONFIG_POSIX) += posix-aio-compat.o
block-obj-$(CONFIG_LINUX_AIO) += linux-aio.o
-block-nested-y += raw.o cow.o qcow.o vdi.o vmdk.o cloop.o dmg.o bochs.o vpc.o
vvfat.o
-block-nested-y += qcow2.o qcow2-refcount.o qcow2-cluster.o qcow2-snapshot.o
-block-nested-y += parallels.o nbd.o blkdebug.o sheepdog.o blkverify.o
+block-nested-$(CONFIG_BLK_RAW) += raw.o
+block-nested-$(CONFIG_BLK_QCOW) += cow.o qcow.o
+block-nested-$(CONFIG_BLK_VDI) += vdi.o
+block-nested-$(CONFIG_BLK_VMDK) += vmdk.o
+block-nested-$(CONFIG_BLK_CLOOP) += cloop.o
+block-nested-$(CONFIG_BLK_DMG) += dmg.o
+blcok-nested-$(CONFIG_BLK_BOCHS) += bochs.o
+block-nested-$(CONFIG_BLK_VPC) += vpc.o
+block-nested-$(CONFIG_BLK_VVFAT) += vvfat.o
+block-nested-$(CONFIG_BLK_QCOW2) += qcow2.o qcow2-refcount.o qcow2-cluster.o
qcow2-snapshot.o
+block-nested-$(CONFIG_BLK_PARALLELS) += parallels.o
+block-nested-$(CONFIG_BLK_NBD) += nbd.o
+block-nested-$(CONFIG_BLK_BLKDEBUG) += blkdebug.o
+block-nested-$(CONFIG_BLK_SHEEPDOG) += sheepdog.o
+block-nested-$(CONFIG_BLK_VERIFY) += blkverify.o
+block-nested-$(CONFIG_WIN32) += raw-win32.o
+block-nested-$(CONFIG_POSIX) += raw-posix.o
+block-nested-$(CONFIG_CURL) += curl.o
block-nested-$(CONFIG_WIN32) += raw-win32.o
block-nested-$(CONFIG_POSIX) += raw-posix.o
block-nested-$(CONFIG_CURL) += curl.o
@@ -23,8 +38,8 @@ block-obj-y += $(addprefix block/, $(block-nested-y))
net-obj-y = net.o
net-nested-y = queue.o checksum.o util.o
-net-nested-y += socket.o
-net-nested-y += dump.o
+net-nested-$(CONFIG_NET_SOCKET) += socket.o
+net-nested-$(CONFIG_NET_DUMP) += dump.o
net-nested-$(CONFIG_POSIX) += tap.o
net-nested-$(CONFIG_LINUX) += tap-linux.o
net-nested-$(CONFIG_WIN32) += tap-win32.o
@@ -85,7 +100,11 @@ common-obj-y += qdev.o qdev-properties.o
common-obj-y += block-migration.o
common-obj-$(CONFIG_BRLAPI) += baum.o
-common-obj-$(CONFIG_POSIX) += migration-exec.o migration-unix.o migration-fd.o
+ifdef CONFIG_POSIX
+common-obj-$(CONFIG_MIG_EXEC) += migration-exec.o
+common-obj-$(CONFIG_MIG_UNIX) += migration-unix.o
+common-obj-$(CONFIG_MIG_FD) += migration-fd.o
+endif
audio-obj-y = audio.o noaudio.o wavaudio.o mixeng.o
audio-obj-$(CONFIG_SDL) += sdlaudio.o
diff --git a/configure b/configure
index 3bfc5e9..681b678 100755
--- a/configure
+++ b/configure
@@ -2439,6 +2439,26 @@ if test "$bluez" = "yes" ; then
echo "CONFIG_BLUEZ=y" >> $config_host_mak
echo "BLUEZ_CFLAGS=$bluez_cflags" >> $config_host_mak
fi
+echo "CONFIG_BLK_RAW=y" >> $config_host_mak
+echo "CONFIG_BLK_QCOW2=y" >> $config_host_mak
+echo "CONFIG_BLK_VVFAT=y" >> $config_host_mak
+echo "CONFIG_BLK_VDI=y" >> $config_host_mak
+echo "CONFIG_BLK_DMG=y" >> $config_host_mak
+echo "CONFIG_BLK_QCOW=y" >> $config_host_mak
+echo "CONFIG_BLK_VMDK=y" >> $config_host_mak
+echo "CONFIG_BLK_CLOOP=y" >> $config_host_mak
+echo "CONFIG_BLK_BOCHS=y" >> $config_host_mak
+echo "CONFIG_BLK_VPC=y" >> $config_host_mak
+echo "CONFIG_BLK_PARALLELS=y" >> $config_host_mak
+echo "CONFIG_BLK_NBD=y" >> $config_host_mak
+echo "CONFIG_BLK_BLKDEBUG=y" >> $config_host_mak
+echo "CONFIG_BLK_SHEEPDOG=y" >> $config_host_mak
+echo "CONFIG_BLK_BLKDEBUG=y" >> $config_host_mak
+echo "CONFIG_NET_DUMP=y" >> $config_host_mak
+echo "CONFIG_NET_SOCKET=y" >> $config_host_mak
+echo "CONFIG_MIG_EXEC=y" >> $config_host_mak
+echo "CONFIG_MIG_UNIX=y" >> $config_host_mak
+echo "CONFIG_MIG_FD=y" >> $config_host_mak
if test "$xen" = "yes" ; then
echo "CONFIG_XEN=y" >> $config_host_mak
fi
diff --git a/migration.c b/migration.c
index 468d517..a22fa5f 100644
--- a/migration.c
+++ b/migration.c
@@ -44,13 +44,19 @@ int qemu_start_incoming_migration(const char *uri)
if (strstart(uri, "tcp:", &p))
ret = tcp_start_incoming_migration(p);
#if !defined(WIN32)
+#ifdef CONFIG_MIG_EXEC
else if (strstart(uri, "exec:", &p))
ret = exec_start_incoming_migration(p);
+#endif
+#ifdef CONFIG_MIG_UNIX
else if (strstart(uri, "unix:", &p))
ret = unix_start_incoming_migration(p);
+#endif
+#ifdef CONFIG_MIG_FD
else if (strstart(uri, "fd:", &p))
ret = fd_start_incoming_migration(p);
#endif
+#endif
else {
fprintf(stderr, "unknown migration protocol: %s\n", uri);
ret = -EPROTONOSUPPORT;
@@ -92,
[Qemu-devel] [PATCH] i386 debugging stubs: Consider segment bases
Hi,
QEMU has a bug that complicates GDB debugging of i386 targets when the
current code or data segment has a nonzero base. A fix is attached.
If the current code segment has a nonzero base, breakpoints don't work
as expected, because the breakpoint detector does not consider segment
bases.
If the current data segment has a nonzero base, memory inspection doesn't
work, because cpu_get_phys_page_debug does not consider segment bases.
A tiny 'operating system' demonstrating the problem is here:
http://read.cs.ucla.edu/~kohler/qemu-gdbseg-demo.tgz
The README enclosed in that tarball gives steps on how to replicate the
breakpoint problem. The 'kernel' runs with segment base 0x1000, so
that linear address 0xF0001000 is translated into physical address
0x1000. But breakpoints (which should use virtual addresses) at
a linear address (e.g. 0xF010) are ignored. You can stop execution
using a physical address, but all the addresses reported
back to GDB are linear addresses, so this isn't consistent.
This is a real problem that prevents us from using unpatched QEMU in
classwork. Any comments on the fix?? (A version was initially posted
several years ago.)
Thanks,
Eddie Kohler
>From 6784824c7576514456a989192e07e63352bdb4ae Mon Sep 17 00:00:00 2001
From: Eddie Kohler
Date: Fri, 24 Sep 2010 16:42:27 -0700
Subject: [PATCH] i386 debugging stubs: Consider segment bases
- Access dumpable memory relative to the current data segment base.
- Detect breakpoints relative to the current code segment base.
---
target-i386/helper.c|1 +
target-i386/translate.c |2 +-
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/target-i386/helper.c b/target-i386/helper.c
index e134340..0bfd4a9 100644
--- a/target-i386/helper.c
+++ b/target-i386/helper.c
@@ -831,6 +831,7 @@ target_phys_addr_t cpu_get_phys_page_debug(CPUState *env,
target_ulong addr)
target_phys_addr_t paddr;
uint32_t page_offset;
int page_size;
+addr += env->segs[R_DS].base;
if (env->cr[4] & CR4_PAE_MASK) {
target_ulong pdpe_addr;
diff --git a/target-i386/translate.c b/target-i386/translate.c
index 7b6e3c2..d9e5b79 100644
--- a/target-i386/translate.c
+++ b/target-i386/translate.c
@@ -7816,7 +7816,7 @@ static inline void
gen_intermediate_code_internal(CPUState *env,
for(;;) {
if (unlikely(!QTAILQ_EMPTY(&env->breakpoints))) {
QTAILQ_FOREACH(bp, &env->breakpoints, entry) {
-if (bp->pc == pc_ptr &&
+if (bp->pc == pc_ptr - dc->cs_base &&
!((bp->flags & BP_CPU) && (tb->flags & HF_RF_MASK))) {
gen_debug(dc, pc_ptr - dc->cs_base);
break;
--
1.7.0.4
[Qemu-devel] Re: [PATCH 0/4] cpu model corrections/updates
Any idea where in the queue this patch set may be? -john john cooper wrote: > This series is a synopsis of several patches correcting > problems found during use and test of the cpu model config > definitions, and usability in general. > > Please review and apply. > > -john > -- john.coo...@redhat.com
Re: [Qemu-devel] [PATCH] Don't exit with zero in the trap handler
Loïc Minier writes: > When configure runs "exit 1", the trap handler is run to cleanup any > files created by configure, but this trap handler itself calls "exit" > with no argument (which means zero exit code): > [...] > + echo Error: zlib check failed > Error: zlib check failed > + echo Make sure to have the zlib libs and headers installed. > Make sure to have the zlib libs and headers installed. > + echo > > + exit 1 > + rm -f /tmp/qemu-conf--2779-.c /tmp/qemu-conf--2779-.o > /tmp/qemu-conf--2779-.exe > + exit > > To fix this, remove the call to exit from the trap handler, leaving it > to the shell shell to exitafter the trap handler is run (honoring any > previously provided exit code). This suggests the old code screws up the exit code. It doesn't for me. Unless it does at least on some platforms, it's a cleanup, not a fix, and the commit message should reflect that.
