[Qemu-devel] [PATCH] monitor: properly handle invalid fd/vhostfd from command line

[Jason Wang]

monitor_get_fd() may also be used to parse fd or vhostfd from command line, so
we need to check whether the pointer of mon is NULL to avoid segmentation fault
when user pass invalid name of fd or vhostfd.

Signed-off-by: Jason Wang 
---
 monitor.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/monitor.c b/monitor.c
index e602480..5bb4ff0 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2345,6 +2345,10 @@ int monitor_get_fd(Monitor *mon, const char *fdname)
 {
 mon_fd_t *monfd;
 
+if (mon == NULL) {
+return -1;
+}
+
 QLIST_FOREACH(monfd, &mon->fds, next) {
 int fd;
 

Re: [Qemu-devel] [PATCH 2/2] trace: avoid unnecessary recompilation if nothing changed

[Markus Armbruster]

Blue Swirl  writes:

> Add logic to detect changes in generated files. If the old
> and new files are identical, don't touch the generated file.
> This avoids a lot of churn since many files depend on trace.h.
>
> Signed-off-by: Blue Swirl 
> ---
>  Makefile |   18 --
>  1 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index ff39025..085e8ed 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -107,10 +107,24 @@ ui/vnc.o: QEMU_CFLAGS += $(VNC_TLS_CFLAGS)
>  bt-host.o: QEMU_CFLAGS += $(BLUEZ_CFLAGS)
>
>  trace.h: $(SRC_PATH)/trace-events config-host.mak
> - $(call quiet-command,sh $(SRC_PATH)/tracetool --$(TRACE_BACKEND) -h
> < $< > $@,"  GEN   $@")
> + $(call quiet-command,sh $(SRC_PATH)/tracetool --$(TRACE_BACKEND) -h
> < $< > $...@.tmp,"  GEN   $@")
> + @if test -f $@; then \
> +   if ! cmp -s $@ $...@.tmp; then \
> + mv $...@.tmp $@; \
> +   fi; \
> +  else \
> +   mv $...@.tmp $@; \
> +  fi

Why the conditional?  cmp -s fails fine when argument files don't exist.

Note that common versions of make including GNU Make do not stat a
rule's target to check whether the rule changed it.  Instead, they
assume it changed, and remake everything depending on it.

arm...@blackfin:~/tmp$ cat Makefile 
foo: bar
echo "Remaking foo"

bar:
[ -f $@ ] || touch $@ && echo "Touched bar"
arm...@blackfin:~/tmp$ rm -f foo
arm...@blackfin:~/tmp$ make
[ -f bar ] || touch bar && echo "Touched bar"
Touched bar
echo "Remaking foo"
Remaking foo
arm...@blackfin:~/tmp$ make
echo "Remaking foo"
Remaking foo

I doubt your patch avoids churn as advertized with such makes.

[...]

Re: [Qemu-devel] [PATCH 0/7] qed: Add QEMU Enhanced Disk format

[Avi Kivity]

 On 09/23/2010 05:41 PM, Stefan Hajnoczi wrote:

Later patches will address the following points:
  * Fine-grained L2 cache to allow for better request parallelism.  Allocating
write requests are currently serialized.  This will also fix the corner
case where a read request to the same sectors as a pending write request
looks at the backing file or zeroes instead of using the write request data.


Is this really an issue? AFAIK a read is allowed to pass a previous 
uncompleted write.


--
error compiling committee.c: too many arguments to function

[Qemu-devel] Re: [PATCH 2/2] trace: avoid unnecessary recompilation if nothing changed

[Paolo Bonzini]

On 09/27/2010 10:32 AM, Markus Armbruster wrote:
> Why the conditional?  cmp -s fails fine when argument files don't exist.
> 
> Note that common versions of make including GNU Make do not stat a
> rule's target to check whether the rule changed it.  Instead, they
> assume it changed, and remake everything depending on it.
> 
>  arm...@blackfin:~/tmp$ cat Makefile
>  foo: bar
>  echo "Remaking foo"
> 
>  bar:
>  [ -f $@ ] || touch $@&&  echo "Touched bar"
>  arm...@blackfin:~/tmp$ rm -f foo
>  arm...@blackfin:~/tmp$ make
>  [ -f bar ] || touch bar&&  echo "Touched bar"
>  Touched bar
>  echo "Remaking foo"
>  Remaking foo
>  arm...@blackfin:~/tmp$ make
>  echo "Remaking foo"
>  Remaking foo
> 
> I doubt your patch avoids churn as advertized with such makes.

Indeed, see how it's done for config-*.h.

# Uses generic rule in rules.mak
trace.h: trace.h-timestamp
trace.h-timestamp: $(SRC_PATH)/trace-events config-host.mak
$(call quiet-command,sh $(SRC_PATH)/tracetool --$(TRACE_BACKEND) -h < 
$< > $@,"  GEN  trace.h)
@cmp $@ trace.h >/dev/null 2>&1 || cp $@ trace.h

(untested).

Paolo

Re: [Qemu-devel] [PATCH 6/7] qed: Read/write support

[Avi Kivity]

 On 09/23/2010 05:41 PM, Stefan Hajnoczi wrote:

This patch implements the read/write state machine.  Operations are
fully asynchronous and multiple operations may be active at any time.

Allocating writes are serialized to make metadata updates consistent.
For example, two write requests to the same unallocated cluster should
only allocate the new cluster once and then update it, rather than
racing to allocate the cluster twice and losing on of the writes.  This
scheme can be made more fine-grained in the future so that independent
metadata updates can be active at the same time.



A comment re prefill-postfill - it seems to generate excessive I/O, for 
example an allocating write into the middle of a cluster will generate 
two reads (if a backing file exists) and three writes.  It would be 
simpler and more efficient to read the backing cluster, splice in the 
guest iovec, and issue a single write.  That is one read and two writes 
fewer.


(assuming I read the code right)

--
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH 0/7] qed: Add QEMU Enhanced Disk format

[Avi Kivity]

 On 09/23/2010 05:41 PM, Stefan Hajnoczi wrote:

QEMU Enhanced Disk format is a disk image format that forgoes features
found in qcow2 in favor of better levels of performance and data
integrity.  Due to its simpler on-disk layout, it is possible to safely
perform metadata updates more efficiently.

Installations, suspend-to-disk, and other allocation-heavy I/O workloads
will see increased performance due to fewer I/Os and syncs.  Workloads
that do not cause new clusters to be allocated will perform similar to
raw images due to in-memory metadata caching.

The format supports sparse disk images.  It does not rely on the host
filesystem holes feature, making it a good choice for sparse disk images
that need to be transferred over channels where holes are not supported.

Backing files are supported so only deltas against a base image can be
stored.

The file format is extensible so that additional features can be added
later with graceful compatibility handling.

Internal snapshots are not supported.  This eliminates the need for
additional metadata to track copy-on-write clusters.

Compression and encryption are not supported.  They add complexity and can be
implemented at other layers in the stack (i.e. inside the guest or on the
host).  Encryption has been identified as a potential future extension and the
file format allows for this.



IMO the file format should be part of this patchset.  Wikis are nice but 
they aren't a good place for authoritative documentation.


--
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH 0/7] qed: Add QEMU Enhanced Disk format

[Stefan Hajnoczi]

On Mon, Sep 27, 2010 at 11:13 AM, Avi Kivity  wrote:
>  On 09/23/2010 05:41 PM, Stefan Hajnoczi wrote:
>>
>> QEMU Enhanced Disk format is a disk image format that forgoes features
>> found in qcow2 in favor of better levels of performance and data
>> integrity.  Due to its simpler on-disk layout, it is possible to safely
>> perform metadata updates more efficiently.
>>
>> Installations, suspend-to-disk, and other allocation-heavy I/O workloads
>> will see increased performance due to fewer I/Os and syncs.  Workloads
>> that do not cause new clusters to be allocated will perform similar to
>> raw images due to in-memory metadata caching.
>>
>> The format supports sparse disk images.  It does not rely on the host
>> filesystem holes feature, making it a good choice for sparse disk images
>> that need to be transferred over channels where holes are not supported.
>>
>> Backing files are supported so only deltas against a base image can be
>> stored.
>>
>> The file format is extensible so that additional features can be added
>> later with graceful compatibility handling.
>>
>> Internal snapshots are not supported.  This eliminates the need for
>> additional metadata to track copy-on-write clusters.
>>
>> Compression and encryption are not supported.  They add complexity and can
>> be
>> implemented at other layers in the stack (i.e. inside the guest or on the
>> host).  Encryption has been identified as a potential future extension and
>> the
>> file format allows for this.
>>
>
> IMO the file format should be part of this patchset.  Wikis are nice but
> they aren't a good place for authoritative documentation.

Good idea.  Will add the specification in v2.

Stefan

Re: [Qemu-devel] [PATCH 6/7] qed: Read/write support

[Stefan Hajnoczi]

On Mon, Sep 27, 2010 at 11:12 AM, Avi Kivity  wrote:
>  On 09/23/2010 05:41 PM, Stefan Hajnoczi wrote:
>>
>> This patch implements the read/write state machine.  Operations are
>> fully asynchronous and multiple operations may be active at any time.
>>
>> Allocating writes are serialized to make metadata updates consistent.
>> For example, two write requests to the same unallocated cluster should
>> only allocate the new cluster once and then update it, rather than
>> racing to allocate the cluster twice and losing on of the writes.  This
>> scheme can be made more fine-grained in the future so that independent
>> metadata updates can be active at the same time.
>>
>
> A comment re prefill-postfill - it seems to generate excessive I/O, for
> example an allocating write into the middle of a cluster will generate two
> reads (if a backing file exists) and three writes.  It would be simpler and
> more efficient to read the backing cluster, splice in the guest iovec, and
> issue a single write.  That is one read and two writes fewer.
>
> (assuming I read the code right)

Yes, you read it correctly.  I haven't tried out other write-out
approaches yet but it is something I've been thinking about.  For a
first version of QED the current approach works but we should be able
to get better performance with an improved write-out strategy.

Stefan

[Qemu-devel] Re: [PATCH v3 06/13] pcie/aer: helper functions for pcie aer capability.

[Michael S. Tsirkin]

On Mon, Sep 27, 2010 at 03:03:24PM +0900, Isaku Yamahata wrote:
> On Sun, Sep 26, 2010 at 02:46:51PM +0200, Michael S. Tsirkin wrote:
> > > > > +static inline void pcie_aer_errmsg(PCIDevice *dev, const 
> > > > > PCIE_AERErrMsg *msg)
> > > > > +{
> > > > > +assert(pci_is_express(dev));
> > > > > +assert(dev->exp.aer_errmsg);
> > > > > +dev->exp.aer_errmsg(dev, msg);
> > > > 
> > > > Why do we want the indirection? Why not have users just call the 
> > > > function?
> > > 
> > > To handle error signaling uniformly.
> > > Please see 
> > > 6.2.5. Sequence of Device Error Signaling and Logging Operations
> > > and figure 6-2 and 6-3.
> > 
> > My question was: the only difference appears to be between bridge and
> > non-bridge devices: bridge has to do more stuff, but most code is
> > common.  So this seems to be a very roundabout way to do this.
> > Can't we just have a common function with an if (bridge) statement up front?
> > If we ever only expect 2 implementations, I think a function pointer
> > is overkill.
> 
> Not 2, but 3. root port, upstream or downstream and normal device.
> So you want something like the following?
> More than 2 is a good reason for me, I prefer function pointer.

Heh, shall we change all switch statements to pointers then?
That's not a good idea IMO, automated tools like ctags
become useless for navigation, you have to look up where it's
actually set. We do have these things in places where
it brings benefit, which is typically where it can take
different values at runtime.

> switch (pcie_cap_get_type(dev))
> case PCI_EXP_TYPE_ROOT_PORT:
> pcie_aer_errmsg_root_port();
> break;
> case PCI_EXP_TYPE_DOWNSTREAM:
> case PCI_EXP_TYPE_UPSTREAM:
> pcie_aer_errmsg_vbridge();
> break;
> default:
>pcie_aer_errmsg_alldev();
>break;

Yes, and note that in fact it's not even that:
all of root and ports are also devices, so we end up
with:
if (pcie_is_root_port(dev)) {
pcie_aer_errmsg_root_port();
} else if (pcie_is_bridge_port(dev)) {
 pcie_aer_errmsg_vbridge();
}
pcie_aer_errmsg_alldev();

which is in fact cleaner than calling pcie_aer_errmsg_alldev
from pcie_aer_errmsg_vbridge, I think.

> 
> -- 
> yamahata

[Qemu-devel] Re: [PATCH v3 08/13] pcie root port: implement pcie root port.

[Michael S. Tsirkin]

On Mon, Sep 27, 2010 at 03:22:43PM +0900, Isaku Yamahata wrote:
> On Sun, Sep 26, 2010 at 02:50:42PM +0200, Michael S. Tsirkin wrote:
> > On Fri, Sep 24, 2010 at 02:38:09PM +0900, Isaku Yamahata wrote:
> > > On Wed, Sep 22, 2010 at 01:25:59PM +0200, Michael S. Tsirkin wrote:
> > > 
> > > > > +PCIESlot *pcie_root_init(PCIBus *bus, int devfn, bool multifunction,
> > > > > + const char *bus_name, pci_map_irq_fn 
> > > > > map_irq,
> > > > > + uint8_t port, uint8_t chassis, uint16_t 
> > > > > slot);
> > > > > +
> > > > 
> > > > I am a bit unhappy about all these _init functions.
> > > > Can devices be created with qdev? If they were
> > > > it would be possible to configure the system completely
> > > > from qemu command line.
> > > 
> > > That's very reasonable question.
> > > Once machine configuration file is supported, those initialization
> > > functions will go away.
> > > I.e. when the initialization code like pc_init1() in pc_piix.c disappears,
> > > those functions will also go away.
> > > 
> > > Until that, those initialization glues will stay like pci_create family
> > > or other many initialization glues unfortunately.
> > > This is the result of qdev missing a feature, not the cause.
> > > It would be a long-term issue to add machine configuration file support.
> > 
> > Just to clarify, if I wanted to have a flag to make virtio-net
> > a pci express device, how would I do this?
> 
> the following preparation is needed.
> - register PCIDeviceInfo with name like "virtio-net-pci-xen"
>   with PCIDeviceInfo::is_express = true.
> - in initialization function, initialize express capability.
> - in write config function, call related function.
> 
> And then,
> if (express)
>create "virtio-net-pci-xen"
> else
>create "virtio-net-pci"

Sounds pretty bad: we can't double the number of devices
with each capability we add.
Can we make it so setting is_express on command line
will convert the device to PCI express?


> -- 
> yamahata

[Qemu-devel] Re: [PATCH] monitor: properly handle invalid fd/vhostfd from command line

[Michael S. Tsirkin]

On Mon, Sep 27, 2010 at 03:52:44PM +0800, Jason Wang wrote:
> monitor_get_fd() may also be used to parse fd or vhostfd from command line, so
> we need to check whether the pointer of mon is NULL to avoid segmentation 
> fault
> when user pass invalid name of fd or vhostfd.
> 
> Signed-off-by: Jason Wang 

Acked-by: Michael S. Tsirkin 

> ---
>  monitor.c |4 
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/monitor.c b/monitor.c
> index e602480..5bb4ff0 100644
> --- a/monitor.c
> +++ b/monitor.c
> @@ -2345,6 +2345,10 @@ int monitor_get_fd(Monitor *mon, const char *fdname)
>  {
>  mon_fd_t *monfd;
>  
> +if (mon == NULL) {
> +return -1;
> +}
> +
>  QLIST_FOREACH(monfd, &mon->fds, next) {
>  int fd;
>  
> 

[Qemu-devel] [Bug 643430] Re: system_powerdown is working in qemu-kvm with KVM enabled for FreeBSD guests

[Dennis Krul]

I have the same issue with FreeBSD 8.1-RELEASE (i386 and x86_64) on
qemu-kvm 0.12.5 (Fedora 13)

system_powerdown works properly for Linux and Windows 2008 guests, but
not for FreeBSD The ACPI power button event is not received by the
FreeBSD guest.

I found this (unconfirmed) status report:
http://www.spinics.net/lists/kvm/msg40064.html

So it seems to be a regression...

-- 
system_powerdown is working in qemu-kvm with KVM enabled for FreeBSD guests
https://bugs.launchpad.net/bugs/643430
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:
system_powerdown stops working in qemu-kvm for FreeBSD guests if KVM is enabled.

How to reproduce:

1. qemu -cdrom ~/.VirtualBox/libvirt/FreeBSD-8.1-RELEASE-i386-bootonly.iso
2. Enter system_powerdown in the qemu console
3. Nothing happens.

Adding --no-kvm option makes system_powerdown work:

1. qemu --no-kvm -cdrom 
~/.VirtualBox/libvirt/FreeBSD-8.1-RELEASE-i386-bootonly.iso
2. system_powerdown
3. FreeBSD installer shows the shutdown dialog as expected

Tested on FreeBSD 6.4, 7.2, and 8.0 with qemu-kvm 0.12.5 and older versions.

[Qemu-devel] [PATCH] Hostfwd: let hostnames be used

[Lauri Kasanen]

Hi

This is an usability issue, one that bugs me every time I need to use hostfwd.
If I want to bind to localhost, I instinctively type localhost, not 127.0.0.1. 
Likewise the machine's host name if I want an external connection.


Thus, make it so it can take hostnames :)

- Lauri

-- 
___
Surf the Web in a faster, safer and easier way:
Download Opera 9 at http://www.opera.com



0001-Hostfwd-let-hostnames-be-used.patch
Description: Binary data

Re: TR : RE : [Qemu-devel] Re: Win2k host problem with {get, free}{addr, name}info()

[Bastien ROUCARIES]

On Sat, Sep 25, 2010 at 10:15 AM, Blue Swirl  wrote:
> On Fri, Sep 24, 2010 at 9:21 PM, Bastien ROUCARIES
>  wrote:
>> 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.
>
> Which thread, this one "Re: module libposix":
> http://lists.gnu.org/archive/html/bug-gnulib/2010-09/msg00334.html

Exact this is the thread.

>> I have even use cmake with gnulib using this approach.  See the libposix
>> path on the documentation and/or gnulib mailling list
>
> Which path?

http://www.gnu.org/software/gnulib/manual/html_node/POSIX-Substitutes-Library.html#POSIX-Substitutes-Library

Thank

Bastien

[Qemu-devel] [RFC PATCH 0/4] Model specific function for nic announcement

[Jason Wang]

This series of patch tries to solve the problem of migration with nics who have
multiple mac addresses or vlans. Qemu currently only send gratuitous packet for
first mac address, so after migration other mac addresses or vlans were broken.

The information of mac addresses and vlans were often stored in model specific
structure, so a model specific function were introduced and used after
migration during self announcement. A sample announcing function for virtio-net
is also implemented in this series. Other model could be also done in this
way. The previous method is kept for the model who does not implement model
specific function.

While there's still issues which need your comments and need to be solved.

1 Virtio specification allows filtering any number of destination mac addresses
  which looks impossible for the migration. Then we need to record an unlimited
  numbers of mac address which is not safe.

2 Virtio specification allows filtering of vlan and mac address but neither the
spec nor the implementation could decide the mappings between vlans and mac
addresses. This could make it impossible to send correct tagged gratuitous
packet.

For issue 1, the number of mac addresses were limited in this series.
For issue 2, I suspect it needs the modification of guest drivers to send the
mappings in order to make migration work. Or is there any method to get this
without touching guest drivers? For safety, all the mac addresses were only
announced when there's no vlan in guest which means the vlan after migration is
still broken.

This patchset is just an RFC and need your suggestions and comments.

Thanks.

---

Jason Wang (4):
  net: move announce_self_create to net.c
  net: Introduce model specific nic announce function
  virtio-net: Limit the num of uni/multicast mac addresses
  virtio-net: implement virtio-net specific announce function


 hw/virtio-net.c |   47 ++-
 net.c   |   31 +++
 net.h   |3 +++
 savevm.c|   42 --
 4 files changed, 84 insertions(+), 39 deletions(-)

-- 
Jason Wang

[Qemu-devel] [RFC PATCH 1/4] net: move announce_self_create to net.c

[Jason Wang]

Export and move announce_self_create to net.c in order to be used by model
specific announcing function.

Signed-off-by: Jason Wang 
---
 net.c|   31 +++
 net.h|1 +
 savevm.c |   32 
 3 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/net.c b/net.c
index 3d0fde7..5ec6912 100644
--- a/net.c
+++ b/net.c
@@ -42,6 +42,37 @@ static QTAILQ_HEAD(, VLANClientState) non_vlan_clients;
 
 int default_net = 1;
 
+#ifndef ETH_P_RARP
+#define ETH_P_RARP 0x8035
+#endif
+#define ARP_HTYPE_ETH 0x0001
+#define ARP_PTYPE_IP 0x0800
+#define ARP_OP_REQUEST_REV 0x3
+
+int announce_self_create(uint8_t *buf, uint8_t *mac_addr)
+{
+/* Ethernet header. */
+memset(buf, 0xff, 6); /* destination MAC addr */
+memcpy(buf + 6, mac_addr, 6); /* source MAC addr */
+*(uint16_t *)(buf + 12) = htons(ETH_P_RARP); /* ethertype */
+
+/* RARP header. */
+*(uint16_t *)(buf + 14) = htons(ARP_HTYPE_ETH); /* hardware addr space */
+*(uint16_t *)(buf + 16) = htons(ARP_PTYPE_IP); /* protocol addr space */
+*(buf + 18) = 6; /* hardware addr length (ethernet) */
+*(buf + 19) = 4; /* protocol addr length (IPv4) */
+*(uint16_t *)(buf + 20) = htons(ARP_OP_REQUEST_REV); /* opcode */
+memcpy(buf + 22, mac_addr, 6); /* source hw addr */
+memset(buf + 28, 0x00, 4); /* source protocol addr */
+memcpy(buf + 32, mac_addr, 6); /* target hw addr */
+memset(buf + 38, 0x00, 4); /* target protocol addr */
+
+/* Padding to get up to 60 bytes (ethernet min packet size, minus FCS). */
+memset(buf + 42, 0x00, 18);
+
+return 60; /* len (FCS will be added by hardware) */
+}
+
 /***/
 /* network device redirectors */
 
diff --git a/net.h b/net.h
index 518cf9c..e3f643c 100644
--- a/net.h
+++ b/net.h
@@ -177,5 +177,6 @@ int do_netdev_del(Monitor *mon, const QDict *qdict, QObject 
**ret_data);
 void qdev_set_nic_properties(DeviceState *dev, NICInfo *nd);
 
 int net_handle_fd_param(Monitor *mon, const char *param);
+int announce_self_create(uint8_t *buf, uint8_t *mac_addr);
 
 #endif
diff --git a/savevm.c b/savevm.c
index 6fa7a5f..545d511 100644
--- a/savevm.c
+++ b/savevm.c
@@ -86,38 +86,6 @@
 
 #define SELF_ANNOUNCE_ROUNDS 5
 
-#ifndef ETH_P_RARP
-#define ETH_P_RARP 0x8035
-#endif
-#define ARP_HTYPE_ETH 0x0001
-#define ARP_PTYPE_IP 0x0800
-#define ARP_OP_REQUEST_REV 0x3
-
-static int announce_self_create(uint8_t *buf,
-   uint8_t *mac_addr)
-{
-/* Ethernet header. */
-memset(buf, 0xff, 6); /* destination MAC addr */
-memcpy(buf + 6, mac_addr, 6); /* source MAC addr */
-*(uint16_t *)(buf + 12) = htons(ETH_P_RARP); /* ethertype */
-
-/* RARP header. */
-*(uint16_t *)(buf + 14) = htons(ARP_HTYPE_ETH); /* hardware addr space */
-*(uint16_t *)(buf + 16) = htons(ARP_PTYPE_IP); /* protocol addr space */
-*(buf + 18) = 6; /* hardware addr length (ethernet) */
-*(buf + 19) = 4; /* protocol addr length (IPv4) */
-*(uint16_t *)(buf + 20) = htons(ARP_OP_REQUEST_REV); /* opcode */
-memcpy(buf + 22, mac_addr, 6); /* source hw addr */
-memset(buf + 28, 0x00, 4); /* source protocol addr */
-memcpy(buf + 32, mac_addr, 6); /* target hw addr */
-memset(buf + 38, 0x00, 4); /* target protocol addr */
-
-/* Padding to get up to 60 bytes (ethernet min packet size, minus FCS). */
-memset(buf + 42, 0x00, 18);
-
-return 60; /* len (FCS will be added by hardware) */
-}
-
 static void qemu_announce_self_iter(NICState *nic, void *opaque)
 {
 uint8_t buf[60];

[Qemu-devel] [RFC PATCH 2/4] net: Introduce model specific nic announce function

[Jason Wang]

This patch introduce a function pointer in NetClientInfo which is called during
self announcement to do the model specific mac address announcement. Previous
method were kept for the model without its own implementation.

Signed-off-by: Jason Wang 
---
 net.h|2 ++
 savevm.c |   10 --
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/net.h b/net.h
index e3f643c..4fa5603 100644
--- a/net.h
+++ b/net.h
@@ -42,6 +42,7 @@ typedef ssize_t (NetReceive)(VLANClientState *, const uint8_t 
*, size_t);
 typedef ssize_t (NetReceiveIOV)(VLANClientState *, const struct iovec *, int);
 typedef void (NetCleanup) (VLANClientState *);
 typedef void (LinkStatusChanged)(VLANClientState *);
+typedef void (NetAnnounce)(VLANClientState *);
 
 typedef struct NetClientInfo {
 net_client_type type;
@@ -53,6 +54,7 @@ typedef struct NetClientInfo {
 NetCleanup *cleanup;
 LinkStatusChanged *link_status_changed;
 NetPoll *poll;
+NetAnnounce *announce;
 } NetClientInfo;
 
 struct VLANClientState {
diff --git a/savevm.c b/savevm.c
index 545d511..c16ee1b 100644
--- a/savevm.c
+++ b/savevm.c
@@ -90,10 +90,16 @@ static void qemu_announce_self_iter(NICState *nic, void 
*opaque)
 {
 uint8_t buf[60];
 int len;
+NetAnnounce *func = nic->nc.info->announce;
 
-len = announce_self_create(buf, nic->conf->macaddr.a);
+if (func == NULL) {
+len = announce_self_create(buf, nic->conf->macaddr.a);
 
-qemu_send_packet_raw(&nic->nc, buf, len);
+qemu_send_packet_raw(&nic->nc, buf, len);
+}
+else {
+func(&nic->nc);
+}
 }
 
 

[Qemu-devel] [RFC PATCH 4/4] virtio-net: implement virtio-net specific announce function

[Jason Wang]

This patch tries to announce every mac address for one virtio nic after
migration. The primary mac address is announced unconditionally and other
macaddress are only announced when no vlan is configurated in guest.

For guest with vlan, what we need do is to send tagged gratutious packet, but
current virtio-net implementation can not distinguish the mapping between mac
addresses and vlan. And I believe this function must be implemented with the
modifications of guest drivers ( vlan_dev_info ).

Signed-off-by: Jason Wang 
---
 hw/virtio-net.c |   30 ++
 1 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/hw/virtio-net.c b/hw/virtio-net.c
index 79afb65..0b47ac2 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -922,6 +922,35 @@ static void virtio_net_cleanup(VLANClientState *nc)
 n->nic = NULL;
 }
 
+static void virtio_net_announce(VLANClientState *nc)
+{
+uint8_t buf[60];
+bool has_vlan = false;
+int len;
+int i;
+VirtIONet *n = DO_UPCAST(NICState, nc, nc)->opaque;
+
+len = announce_self_create(buf, &n->mac[0]);
+qemu_send_packet_raw(nc, buf, len);
+
+for (i = 0; i < (MAX_VLAN >> 5); i++) {
+if (n->vlans[i] & ~0u) {
+has_vlan = true;
+break;
+}
+}
+
+if (!has_vlan) {
+   /* It's safe to announce the rest of mac addresses when there's no vlan
+* in guest */
+for (i = 0; i < n->mac_table.in_use; i++) {
+mac_debug(&n->mac_table.macs[i * ETH_ALEN]);
+len = announce_self_create(buf, &n->mac_table.macs[i * ETH_ALEN]);
+qemu_send_packet_raw(nc, buf, len);
+}
+}
+}
+
 static NetClientInfo net_virtio_info = {
 .type = NET_CLIENT_TYPE_NIC,
 .size = sizeof(NICState),
@@ -929,6 +958,7 @@ static NetClientInfo net_virtio_info = {
 .receive = virtio_net_receive,
 .cleanup = virtio_net_cleanup,
 .link_status_changed = virtio_net_set_link_status,
+.announce = virtio_net_announce,
 };
 
 static void virtio_net_set_status(struct VirtIODevice *vdev, uint8_t status)

[Qemu-devel] [RFC PATCH 3/4] virtio-net: Limit the num of uni/multicast mac addresses

[Jason Wang]

In order to send gratuitous packet for each mac address, we need to keep
track every macaddress after migration which is obviously conflicted with the
overload policy currently used in qemu which just forward all packets to guest
when it can't record all the macaddress. So we need to limit the num of
uni/multicast mac addresses in qemu.

Signed-off-by: Jason Wang 
---
 hw/virtio-net.c |   17 -
 1 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/hw/virtio-net.c b/hw/virtio-net.c
index 0a9cae2..79afb65 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -291,7 +291,9 @@ static int virtio_net_handle_mac(VirtIONet *n, uint8_t cmd,
mac_data.entries * ETH_ALEN);
 n->mac_table.in_use += mac_data.entries;
 } else {
-n->mac_table.uni_overflow = 1;
+/* Gratuitous packet could not be built properly in overflow mode, so 
we
+ * never allow uni_overflow here. */
+return VIRTIO_NET_ERR;
 }
 
 n->mac_table.first_multi = n->mac_table.in_use;
@@ -309,7 +311,9 @@ static int virtio_net_handle_mac(VirtIONet *n, uint8_t cmd,
mac_data.entries * ETH_ALEN);
 n->mac_table.in_use += mac_data.entries;
 } else {
-n->mac_table.multi_overflow = 1;
+/* Gratuitous packet could not be built properly in overflow mode,
+ * so we never allow multi_overflow here. */
+return VIRTIO_NET_ERR;
 }
 }
 
@@ -844,9 +848,8 @@ static int virtio_net_load(QEMUFile *f, void *opaque, int 
version_id)
 qemu_get_buffer(f, n->mac_table.macs,
 n->mac_table.in_use * ETH_ALEN);
 } else if (n->mac_table.in_use) {
-qemu_fseek(f, n->mac_table.in_use * ETH_ALEN, SEEK_CUR);
-n->mac_table.multi_overflow = n->mac_table.uni_overflow = 1;
-n->mac_table.in_use = 0;
+error_report("virtio-net: Overflow was not permitted.");
+return -EINVAL;
 }
 }
  
@@ -873,6 +876,10 @@ static int virtio_net_load(QEMUFile *f, void *opaque, int 
version_id)
 if (version_id >= 9) {
 n->mac_table.multi_overflow = qemu_get_byte(f);
 n->mac_table.uni_overflow = qemu_get_byte(f);
+if (n->mac_table.multi_overflow || n->mac_table.uni_overflow) {
+error_report("virtio-net: Overflow was not permitted");
+return -EINVAL;
+}
 }
 
 if (version_id >= 10) {

[Qemu-devel] [PATCH] net: delay freeing peer host device

[Michael S. Tsirkin]

With -netdev, virtio devices present offload
features to guest, depending on the backend used.
Thus, removing host netdev peer while guest is
active leads to guest-visible inconsistency and/or crashes.

As a solution, while guest (NIC) peer device exists,
we prevent the host peer from being deleted.
This patch does this by adding peer_deleted flag in nic state:
if host device is going away while guest device
is around, set this flag and keep a shell of
the host device around for as long as guest device exists.

The link is put down so all packets will get discarded.

At the moment, management can detect that device deletion
is delayed by doing info net. As a next step, we shall add
commands that control hotplug/unplug without
removing the device, and an event to report that
guest has responded to the hotplug event.

Signed-off-by: Michael S. Tsirkin 
---
 net.c |   40 +---
 net.h |1 +
 2 files changed, 34 insertions(+), 7 deletions(-)

diff --git a/net.c b/net.c
index 3d0fde7..edb87af 100644
--- a/net.c
+++ b/net.c
@@ -281,29 +281,55 @@ NICState *qemu_new_nic(NetClientInfo *info,
 return nic;
 }
 
-void qemu_del_vlan_client(VLANClientState *vc)
+static void qemu_free_vlan_client(VLANClientState *vc)
 {
 if (vc->vlan) {
 QTAILQ_REMOVE(&vc->vlan->clients, vc, next);
 } else {
+QTAILQ_REMOVE(&non_vlan_clients, vc, next);
 if (vc->send_queue) {
 qemu_del_net_queue(vc->send_queue);
 }
-QTAILQ_REMOVE(&non_vlan_clients, vc, next);
 if (vc->peer) {
 vc->peer->peer = NULL;
 }
 }
-
-if (vc->info->cleanup) {
-vc->info->cleanup(vc);
-}
-
 qemu_free(vc->name);
 qemu_free(vc->model);
 qemu_free(vc);
 }
 
+void qemu_del_vlan_client(VLANClientState *vc)
+{
+/* If there is a peer NIC, delete and cleanup client, but do not free. */
+if (!vc->vlan && vc->peer && vc->peer->info->type == NET_CLIENT_TYPE_NIC) {
+NICState *nic = DO_UPCAST(NICState, nc, vc->peer);
+if (nic->peer_deleted) {
+return;
+}
+nic->peer_deleted = true;
+/* Let NIC know peer is gone. */
+vc->peer->link_down = true;
+if (vc->peer->info->link_status_changed) {
+vc->peer->info->link_status_changed(vc->peer);
+}
+if (vc->info->cleanup) {
+vc->info->cleanup(vc);
+}
+return;
+}
+
+/* If this is a peer NIC and peer has already been deleted, free it now. */
+if (!vc->vlan && vc->peer && vc->info->type == NET_CLIENT_TYPE_NIC) {
+NICState *nic = DO_UPCAST(NICState, nc, vc);
+if (nic->peer_deleted) {
+qemu_free_vlan_client(vc->peer);
+}
+}
+
+qemu_free_vlan_client(vc);
+}
+
 VLANClientState *
 qemu_find_vlan_client_by_name(Monitor *mon, int vlan_id,
   const char *client_str)
diff --git a/net.h b/net.h
index 518cf9c..44c31a9 100644
--- a/net.h
+++ b/net.h
@@ -72,6 +72,7 @@ typedef struct NICState {
 VLANClientState nc;
 NICConf *conf;
 void *opaque;
+bool peer_deleted;
 } NICState;
 
 struct VLANState {
-- 
1.7.3-rc1

[Qemu-devel] [PATCH 0/3] SVM feature support for qemu v3

[Joerg Roedel]

Hi,

here is the third round of the patches to add svm-features support to
qemu. The patches are rebases against latest qemu/master. Other changes
since v2:

* Made kvm64 the default model only for qemu-versions >= 0.14.0
* Removed clean-bits from the phenom cpu-model

Feedback and/or merge appreciated :-)

Joerg

[Qemu-devel] [PATCH 2/3] Set cpuid definition to 0 before initializing it

[Joerg Roedel]

This patch cleans the (stack-allocated) cpuid definition to
0 before actually initializing it.

Signed-off-by: Joerg Roedel 
---
 target-i386/cpuid.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/target-i386/cpuid.c b/target-i386/cpuid.c
index 04ba8d5..3fcf78f 100644
--- a/target-i386/cpuid.c
+++ b/target-i386/cpuid.c
@@ -788,6 +788,8 @@ int cpu_x86_register (CPUX86State *env, const char 
*cpu_model)
 {
 x86_def_t def1, *def = &def1;
 
+memset(def, 0, sizeof(*def));
+
 if (cpu_x86_find_by_name(def, cpu_model) < 0)
 return -1;
 if (def->vendor1) {
-- 
1.7.0.4

[Qemu-devel] [PATCH 1/3] Make kvm64 the default cpu model when kvm_enabled()

[Joerg Roedel]

As requested by Alex this patch makes kvm64 the default CPU
model when qemu is started with -enable-kvm. This takes only
effect for qemu-versions newer or equal to 0.14.0.

Signed-off-by: Joerg Roedel 
---
 hw/boards.h|1 +
 hw/pc.c|   21 -
 hw/pc_piix.c   |6 ++
 qemu-version.h |   35 +++
 vl.c   |4 
 5 files changed, 62 insertions(+), 5 deletions(-)
 create mode 100644 qemu-version.h

diff --git a/hw/boards.h b/hw/boards.h
index 6f0f0d7..2d41b2d 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -19,6 +19,7 @@ typedef struct QEMUMachine {
 QEMUMachineInitFunc *init;
 int use_scsi;
 int max_cpus;
+unsigned int compat_version;
 unsigned int no_serial:1,
 no_parallel:1,
 use_virtcon:1,
diff --git a/hw/pc.c b/hw/pc.c
index 69b13bf..372ec4c 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -40,6 +40,16 @@
 #include "sysbus.h"
 #include "sysemu.h"
 #include "blockdev.h"
+#include "kvm.h"
+#include "qemu-version.h"
+
+#ifdef TARGET_X86_64
+#define DEFAULT_KVM_CPU_MODEL "kvm64"
+#define DEFAULT_QEMU_CPU_MODEL "qemu64"
+#else
+#define DEFAULT_KVM_CPU_MODEL "kvm32"
+#define DEFAULT_QEMU_CPU_MODEL "qemu32"
+#endif
 
 /* output Bochs bios info messages */
 //#define DEBUG_BIOS
@@ -867,11 +877,12 @@ void pc_cpus_init(const char *cpu_model)
 
 /* init CPUs */
 if (cpu_model == NULL) {
-#ifdef TARGET_X86_64
-cpu_model = "qemu64";
-#else
-cpu_model = "qemu32";
-#endif
+if (kvm_enabled() &&
+qemu_compat_version >= QEMU_COMPAT_VERSION(0, 14, 0)) {
+cpu_model = DEFAULT_KVM_CPU_MODEL;
+} else {
+cpu_model = DEFAULT_QEMU_CPU_MODEL;
+}
 }
 
 for(i = 0; i < smp_cpus; i++) {
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 12359a7..9e46b71 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -35,6 +35,7 @@
 #include "sysemu.h"
 #include "sysbus.h"
 #include "blockdev.h"
+#include "qemu-version.h"
 
 #define MAX_IDE_BUS 2
 
@@ -217,6 +218,7 @@ static QEMUMachine pc_machine = {
 .desc = "Standard PC",
 .init = pc_init_pci,
 .max_cpus = 255,
+.compat_version = QEMU_COMPAT_VERSION(0, 13, 0),
 .is_default = 1,
 };
 
@@ -225,6 +227,7 @@ static QEMUMachine pc_machine_v0_12 = {
 .desc = "Standard PC",
 .init = pc_init_pci,
 .max_cpus = 255,
+.compat_version = QEMU_COMPAT_VERSION(0, 12, 0),
 .compat_props = (GlobalProperty[]) {
 {
 .driver   = "virtio-serial-pci",
@@ -244,6 +247,7 @@ static QEMUMachine pc_machine_v0_11 = {
 .desc = "Standard PC, qemu 0.11",
 .init = pc_init_pci,
 .max_cpus = 255,
+.compat_version = QEMU_COMPAT_VERSION(0, 11, 0),
 .compat_props = (GlobalProperty[]) {
 {
 .driver   = "virtio-blk-pci",
@@ -279,6 +283,7 @@ static QEMUMachine pc_machine_v0_10 = {
 .desc = "Standard PC, qemu 0.10",
 .init = pc_init_pci,
 .max_cpus = 255,
+.compat_version = QEMU_COMPAT_VERSION(0, 10, 0),
 .compat_props = (GlobalProperty[]) {
 {
 .driver   = "virtio-blk-pci",
@@ -325,6 +330,7 @@ static QEMUMachine isapc_machine = {
 .name = "isapc",
 .desc = "ISA-only PC",
 .init = pc_init_isa,
+.compat_version = QEMU_COMPAT_VERSION(0, 10, 0),
 .max_cpus = 1,
 };
 
diff --git a/qemu-version.h b/qemu-version.h
new file mode 100644
index 000..b4bfe48
--- /dev/null
+++ b/qemu-version.h
@@ -0,0 +1,35 @@
+/*
+ * qemu-version.h
+ *
+ * Defines needed for handling QEMU version compatibility
+ *
+ * Copyright (c) 2010 Joerg Roedel 
+ *
+ * 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.
+ */
+
+#ifndef _QEMU_VERSION_H_
+#define _QEMU_VERSION_H_
+
+extern unsigned int qemu_compat_version;
+
+#define QEMU_COMPAT_VERSION(major, minor, patchlevel) \
+((unsigned int)(major << 16) | (minor << 8) | (patchlevel))
+
+#endif
diff --git a/vl.c b/vl.c
index d352d18..37727f3 100644
--- a

[Qemu-devel] [PATCH 3/3] Add svm cpuid features

[Joerg Roedel]

This patch adds the svm cpuid feature flags to the qemu
intialization path. It also adds the svm features available
on phenom to its cpu-definition and extends the host cpu
type to support all svm features KVM can provide.

Signed-off-by: Joerg Roedel 
---
 target-i386/cpu.h   |   12 
 target-i386/cpuid.c |   77 +++---
 target-i386/kvm.c   |3 ++
 3 files changed, 75 insertions(+), 17 deletions(-)

diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 1144d4e..77eeab1 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -405,6 +405,17 @@
 #define CPUID_EXT3_IBS (1 << 10)
 #define CPUID_EXT3_SKINIT  (1 << 12)
 
+#define CPUID_SVM_NPT  (1 << 0)
+#define CPUID_SVM_LBRV (1 << 1)
+#define CPUID_SVM_SVMLOCK  (1 << 2)
+#define CPUID_SVM_NRIPSAVE (1 << 3)
+#define CPUID_SVM_TSCSCALE (1 << 4)
+#define CPUID_SVM_VMCBCLEAN(1 << 5)
+#define CPUID_SVM_FLUSHASID(1 << 6)
+#define CPUID_SVM_DECODEASSIST (1 << 7)
+#define CPUID_SVM_PAUSEFILTER  (1 << 10)
+#define CPUID_SVM_PFTHRESHOLD  (1 << 12)
+
 #define CPUID_VENDOR_INTEL_1 0x756e6547 /* "Genu" */
 #define CPUID_VENDOR_INTEL_2 0x49656e69 /* "ineI" */
 #define CPUID_VENDOR_INTEL_3 0x6c65746e /* "ntel" */
@@ -702,6 +713,7 @@ typedef struct CPUX86State {
 uint8_t has_error_code;
 uint32_t sipi_vector;
 uint32_t cpuid_kvm_features;
+uint32_t cpuid_svm_features;
 
 /* in order to simplify APIC support, we leave this pointer to the
user */
diff --git a/target-i386/cpuid.c b/target-i386/cpuid.c
index 3fcf78f..0e0bf60 100644
--- a/target-i386/cpuid.c
+++ b/target-i386/cpuid.c
@@ -79,6 +79,17 @@ static const char *kvm_feature_name[] = {
 NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
 };
 
+static const char *svm_feature_name[] = {
+"npt", "lbrv", "svm_lock", "nrip_save",
+"tsc_scale", "vmcb_clean",  "flushbyasid", "decodeassists",
+NULL, NULL, "pause_filter", NULL,
+"pfthreshold", NULL, NULL, NULL,
+NULL, NULL, NULL, NULL,
+NULL, NULL, NULL, NULL,
+NULL, NULL, NULL, NULL,
+NULL, NULL, NULL, NULL,
+};
+
 /* collects per-function cpuid data
  */
 typedef struct model_features_t {
@@ -192,13 +203,15 @@ static void add_flagname_to_bitmaps(const char *flagname, 
uint32_t *features,
 uint32_t *ext_features,
 uint32_t *ext2_features,
 uint32_t *ext3_features,
-uint32_t *kvm_features)
+uint32_t *kvm_features,
+uint32_t *svm_features)
 {
 if (!lookup_feature(features, flagname, NULL, feature_name) &&
 !lookup_feature(ext_features, flagname, NULL, ext_feature_name) &&
 !lookup_feature(ext2_features, flagname, NULL, ext2_feature_name) &&
 !lookup_feature(ext3_features, flagname, NULL, ext3_feature_name) &&
-!lookup_feature(kvm_features, flagname, NULL, kvm_feature_name))
+!lookup_feature(kvm_features, flagname, NULL, kvm_feature_name) &&
+!lookup_feature(svm_features, flagname, NULL, svm_feature_name))
 fprintf(stderr, "CPU feature %s not found\n", flagname);
 }
 
@@ -210,7 +223,8 @@ typedef struct x86_def_t {
 int family;
 int model;
 int stepping;
-uint32_t features, ext_features, ext2_features, ext3_features, 
kvm_features;
+uint32_t features, ext_features, ext2_features, ext3_features;
+uint32_t kvm_features, svm_features;
 uint32_t xlevel;
 char model_id[48];
 int vendor_override;
@@ -253,6 +267,7 @@ typedef struct x86_def_t {
   CPUID_EXT2_PDPE1GB */
 #define TCG_EXT3_FEATURES (CPUID_EXT3_LAHF_LM | CPUID_EXT3_SVM | \
   CPUID_EXT3_CR8LEG | CPUID_EXT3_ABM | CPUID_EXT3_SSE4A)
+#define TCG_SVM_FEATURES 0
 
 /* maintains list of cpu model definitions
  */
@@ -305,6 +320,7 @@ static x86_def_t builtin_x86_defs[] = {
 CPUID_EXT3_OSVW, CPUID_EXT3_IBS */
 .ext3_features = CPUID_EXT3_LAHF_LM | CPUID_EXT3_SVM |
 CPUID_EXT3_ABM | CPUID_EXT3_SSE4A,
+.svm_features = CPUID_SVM_NPT | CPUID_SVM_LBRV,
 .xlevel = 0x801A,
 .model_id = "AMD Phenom(tm) 9550 Quad-Core Processor"
 },
@@ -505,6 +521,15 @@ static int cpu_x86_fill_host(x86_def_t *x86_cpu_def)
 cpu_x86_fill_model_id(x86_cpu_def->model_id);
 x86_cpu_def->vendor_override = 0;
 
+
+/*
+ * Every SVM feature requires emulation support in KVM - so we can't just
+ * read the host features here. KVM might even support SVM features not
+ * available on the host hardware. Just set all bits and mask out the
+ * unsupported ones later.
+ */
+x86_cpu_def->svm_features = -1;
+
 return 0;
 }
 
@@ -560,8 +585,14 @@ static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def, 
const char *cpu_model)
 
 char *s = strdup(cpu_model);
 char *featurestr, *na

[Qemu-devel] [RFC][PATCH 1/2] Add option to disable PS/2 mouse.

[Michal Suchanek]

Hello

I tried to patch qemu to allow disabling the PS/2 mouse.

This patch works for me, when I disable the mouse Windows no longer
detects it.

I am not sure this is entirely correct. Specifically there is
KBD_MODE_DISABLE_MOUSE bit which can probably still be disabled and
KBD_MODE_MOUSE_INT is enabled.

Thanks

Michal


Signed-off-by: Michal Suchanek 
---
 hw/isa.h|1 +
 hw/pckbd.c  |   36 +---
 qemu-options.hx |9 +
 vl.c|4 
 4 files changed, 35 insertions(+), 15 deletions(-)

diff --git a/hw/isa.h b/hw/isa.h
index aaf0272..80ab6bb 100644
--- a/hw/isa.h
+++ b/hw/isa.h
@@ -31,6 +31,7 @@ ISADevice *isa_create(const char *name);
 ISADevice *isa_create_simple(const char *name);
 
 extern target_phys_addr_t isa_mem_base;
+extern int isa_psaux;
 
 void isa_mmio_init(target_phys_addr_t base, target_phys_addr_t size, int be);
 
diff --git a/hw/pckbd.c b/hw/pckbd.c
index 6e4e406..4557e14 100644
--- a/hw/pckbd.c
+++ b/hw/pckbd.c
@@ -169,7 +169,7 @@ static void kbd_update_irq(KBDState *s)
 }
 }
 qemu_set_irq(s->irq_kbd, irq_kbd_level);
-qemu_set_irq(s->irq_mouse, irq_mouse_level);
+if (s->mouse) qemu_set_irq(s->irq_mouse, irq_mouse_level);
 }
 
 static void kbd_update_kbd_irq(void *opaque, int level)
@@ -205,10 +205,11 @@ static uint32_t kbd_read_status(void *opaque, uint32_t 
addr)
 
 static void kbd_queue(KBDState *s, int b, int aux)
 {
-if (aux)
-ps2_queue(s->mouse, b);
-else
+if (aux) {
+if (s->mouse) ps2_queue(s->mouse, b);
+} else {
 ps2_queue(s->kbd, b);
+}
 }
 
 static void ioport92_write(void *opaque, uint32_t addr, uint32_t val)
@@ -323,12 +324,13 @@ static void kbd_write_command(void *opaque, uint32_t 
addr, uint32_t val)
 static uint32_t kbd_read_data(void *opaque, uint32_t addr)
 {
 KBDState *s = opaque;
-uint32_t val;
+uint32_t val = 0;
 
-if (s->pending == KBD_PENDING_AUX)
-val = ps2_read_data(s->mouse);
-else
+if (s->pending == KBD_PENDING_AUX) {
+if (s->mouse) val = ps2_read_data(s->mouse);
+} else {
 val = ps2_read_data(s->kbd);
+}
 
 DPRINTF("kbd: read data=0x%02x\n", val);
 return val;
@@ -354,13 +356,13 @@ static void kbd_write_data(void *opaque, uint32_t addr, 
uint32_t val)
 kbd_queue(s, val, 0);
 break;
 case KBD_CCMD_WRITE_AUX_OBUF:
-kbd_queue(s, val, 1);
+if (s->mouse) kbd_queue(s, val, 1);
 break;
 case KBD_CCMD_WRITE_OUTPORT:
 ioport92_write(s, 0, val);
 break;
 case KBD_CCMD_WRITE_MOUSE:
-ps2_write_mouse(s->mouse, val);
+if (s->mouse) ps2_write_mouse(s->mouse, val);
 break;
 default:
 break;
@@ -430,9 +432,10 @@ void i8042_mm_init(qemu_irq kbd_irq, qemu_irq mouse_irq,
 {
 KBDState *s = qemu_mallocz(sizeof(KBDState));
 int s_io_memory;
+int mouse_enabled = isa_psaux;
 
 s->irq_kbd = kbd_irq;
-s->irq_mouse = mouse_irq;
+if (mouse_enabled) s->irq_mouse = mouse_irq;
 s->mask = mask;
 
 vmstate_register(NULL, 0, &vmstate_kbd, s);
@@ -440,7 +443,8 @@ void i8042_mm_init(qemu_irq kbd_irq, qemu_irq mouse_irq,
 cpu_register_physical_memory(base, size, s_io_memory);
 
 s->kbd = ps2_kbd_init(kbd_update_kbd_irq, s);
-s->mouse = ps2_mouse_init(kbd_update_aux_irq, s);
+s->mouse = NULL;
+if (mouse_enabled) s->mouse = ps2_mouse_init(kbd_update_aux_irq, s);
 qemu_register_reset(kbd_reset, s);
 }
 
@@ -454,7 +458,7 @@ void i8042_isa_mouse_fake_event(void *opaque)
 ISADevice *dev = opaque;
 KBDState *s = &(DO_UPCAST(ISAKBDState, dev, dev)->kbd);
 
-ps2_mouse_fake_event(s->mouse);
+if (s->mouse) ps2_mouse_fake_event(s->mouse);
 }
 
 void i8042_setup_a20_line(ISADevice *dev, qemu_irq *a20_out)
@@ -478,9 +482,10 @@ static const VMStateDescription vmstate_kbd_isa = {
 static int i8042_initfn(ISADevice *dev)
 {
 KBDState *s = &(DO_UPCAST(ISAKBDState, dev, dev)->kbd);
+int mouse_enabled = isa_psaux;
 
 isa_init_irq(dev, &s->irq_kbd, 1);
-isa_init_irq(dev, &s->irq_mouse, 12);
+if (mouse_enabled) isa_init_irq(dev, &s->irq_mouse, 12);
 
 register_ioport_read(0x60, 1, 1, kbd_read_data, s);
 register_ioport_write(0x60, 1, 1, kbd_write_data, s);
@@ -490,7 +495,8 @@ static int i8042_initfn(ISADevice *dev)
 register_ioport_write(0x92, 1, 1, ioport92_write, s);
 
 s->kbd = ps2_kbd_init(kbd_update_kbd_irq, s);
-s->mouse = ps2_mouse_init(kbd_update_aux_irq, s);
+s->mouse = NULL;
+if (mouse_enabled) s->mouse = ps2_mouse_init(kbd_update_aux_irq, s);
 qemu_register_reset(kbd_reset, s);
 return 0;
 }
diff --git a/qemu-options.hx b/qemu-options.hx
index a0b5ae9..fd96b6a 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1746,6 +1746,15 @@ Three button serial mouse. Configure the guest to use 
Microsoft protocol.
 @end table
 ETEXI
 
+DEF("no-psaux", 0, QEMU_OPTION_nopsaux, \
+"-no-psa

[Qemu-devel] [PATCH 2/2] Add option to preserve aspect in SDL display scaling.

[Michal Suchanek]

The output is not centered.

I am not sure how to achieve that because SDL just sets a "video mode"
which starts at upper left corner of the window.

It would be possible to make the mode larger but then the zoom routines
would have to take an offset.


Signed-off-by: Michal Suchanek 
---
 qemu-options.hx |   13 +
 ui/sdl.c|   13 +++--
 vl.c|4 
 3 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index fd96b6a..bd25396 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -629,6 +629,19 @@ workspace more convenient.
 ETEXI
 
 #ifdef CONFIG_SDL
+DEF("keep-aspect", 0, QEMU_OPTION_preserve_aspect,
+"-keep-aspectpreserve aspect ratio of display output\n",
+QEMU_ARCH_ALL)
+#endif
+STEXI
+...@item -keep-aspect
+...@findex -keep-aspect
+Normally the SDL output scales the guest display to fill the SDL window. With
+this option the guest display is scaled as large as possible preserving the
+aspect ratio possibly leaving some empty space in the window.
+ETEXI
+
+#ifdef CONFIG_SDL
 DEF("alt-grab", 0, QEMU_OPTION_alt_grab,
 "-alt-grab   use Ctrl-Alt-Shift to grab mouse (instead of Ctrl-Alt)\n",
 QEMU_ARCH_ALL)
diff --git a/ui/sdl.c b/ui/sdl.c
index f599d42..5ac9a77 100644
--- a/ui/sdl.c
+++ b/ui/sdl.c
@@ -38,6 +38,7 @@
 #include "x_keymap.h"
 #include "sdl_zoom.h"
 
+int sdl_preserve_aspect = 0;
 static DisplayChangeListener *dcl;
 static SDL_Surface *real_screen;
 static SDL_Surface *guest_screen = NULL;
@@ -65,12 +66,12 @@ static Notifier mouse_mode_notifier;
 
 static void sdl_update(DisplayState *ds, int x, int y, int w, int h)
 {
-//printf("updating x=%d y=%d w=%d h=%d\n", x, y, w, h);
 SDL_Rect rec;
 rec.x = x;
 rec.y = y;
 rec.w = w;
 rec.h = h;
+//fprintf(stderr, "SDL updating x=%d y=%d w=%d h=%d\n", x, y, w, h);
 
 if (guest_screen) {
 if (!scaling_active) {
@@ -105,7 +106,7 @@ static void do_sdl_resize(int new_width, int new_height, 
int bpp)
 {
 int flags;
 
-//printf("resizing to %d %d\n", w, h);
+fprintf(stderr, "SDL resizing to %d %d\n", new_width, new_height);
 
 flags = SDL_HWSURFACE|SDL_ASYNCBLIT|SDL_HWACCEL|SDL_RESIZABLE;
 if (gui_fullscreen)
@@ -113,6 +114,14 @@ static void do_sdl_resize(int new_width, int new_height, 
int bpp)
 if (gui_noframe)
 flags |= SDL_NOFRAME;
 
+if (guest_screen) {
+float wr = (float)new_width / (float) guest_screen->w,
+  hr = (float)new_height / (float) guest_screen->h,
+  r = (wr > hr) ? hr : wr;
+new_width = (float)guest_screen->w * r + 0.5;
+new_height = (float)guest_screen->h * r + 0.5;
+fprintf(stderr, "SDL adjusting resize to %d %d\n", new_width, 
new_height);
+}
 width = new_width;
 height = new_height;
 real_screen = SDL_SetVideoMode(width, height, bpp, flags);
diff --git a/vl.c b/vl.c
index ee641bc..67d35bb 100644
--- a/vl.c
+++ b/vl.c
@@ -193,6 +193,7 @@ QEMUClock *rtc_clock;
 int vga_interface_type = VGA_NONE;
 static int full_screen = 0;
 #ifdef CONFIG_SDL
+extern int sdl_preserve_aspect;
 static int no_frame = 0;
 #endif
 int no_quit = 0;
@@ -2421,6 +2422,9 @@ int main(int argc, char **argv, char **envp)
 case QEMU_OPTION_no_frame:
 no_frame = 1;
 break;
+case QEMU_OPTION_preserve_aspect:
+sdl_preserve_aspect = 1;
+break;
 case QEMU_OPTION_alt_grab:
 alt_grab = 1;
 break;
-- 
1.7.1

[Qemu-devel] Re: [RFC PATCH 0/4] Model specific function for nic announcement

[Michael S. Tsirkin]

On Mon, Sep 27, 2010 at 08:50:44PM +0800, Jason Wang wrote:
> This series of patch tries to solve the problem of migration with nics who 
> have
> multiple mac addresses or vlans. Qemu currently only send gratuitous packet 
> for
> first mac address, so after migration other mac addresses or vlans were 
> broken.
> 
> The information of mac addresses and vlans were often stored in model specific
> structure, so a model specific function were introduced and used after
> migration during self announcement. A sample announcing function for 
> virtio-net
> is also implemented in this series. Other model could be also done in this
> way. The previous method is kept for the model who does not implement model
> specific function.
> 
> While there's still issues which need your comments and need to be solved.
> 
> 1 Virtio specification allows filtering any number of destination mac 
> addresses
>   which looks impossible for the migration. Then we need to record an 
> unlimited
>   numbers of mac address which is not safe.
> 
> 2 Virtio specification allows filtering of vlan and mac address but neither 
> the
> spec nor the implementation could decide the mappings between vlans and mac
> addresses. This could make it impossible to send correct tagged gratuitous
> packet.
> For issue 1, the number of mac addresses were limited in this series.
> For issue 2, I suspect it needs the modification of guest drivers to send the
> mappings in order to make migration work. Or is there any method to get this
> without touching guest drivers? For safety, all the mac addresses were only
> announced when there's no vlan in guest which means the vlan after migration 
> is
> still broken.
> 
> This patchset is just an RFC and need your suggestions and comments.
> 
> Thanks.

For 1, all guests actually do is on error status is print
a warning. This does not sound all that useful, does it?
I note that we also have a similar issue with promisc mode.

For 2, we could at least make it work for a common case of 1 mac,
which would already cover many users.

> ---
> 
> Jason Wang (4):
>   net: move announce_self_create to net.c
>   net: Introduce model specific nic announce function
>   virtio-net: Limit the num of uni/multicast mac addresses
>   virtio-net: implement virtio-net specific announce function
> 
> 
>  hw/virtio-net.c |   47 ++-
>  net.c   |   31 +++
>  net.h   |3 +++
>  savevm.c|   42 --
>  4 files changed, 84 insertions(+), 39 deletions(-)
> 
> -- 
> Jason Wang

[Qemu-devel] Re: [PATCH 3/3] Add svm cpuid features

[Avi Kivity]

 On 09/27/2010 03:16 PM, Joerg Roedel wrote:

This patch adds the svm cpuid feature flags to the qemu
intialization path. It also adds the svm features available
on phenom to its cpu-definition and extends the host cpu
type to support all svm features KVM can provide.



This should really be "all svm features" since we'll later mask them 
with kvm capabilities.  This way, if we later add more capabilities, we 
automatically gain support in userspace.


(or rather, all svm features that don't need save/restore support in 
userspace; I don't think any do, beyond svm itself)


--
error compiling committee.c: too many arguments to function

[Qemu-devel] Re: [PATCH 3/3] Add svm cpuid features

[Avi Kivity]

 On 09/27/2010 04:58 PM, Avi Kivity wrote:

 On 09/27/2010 03:16 PM, Joerg Roedel wrote:

This patch adds the svm cpuid feature flags to the qemu
intialization path. It also adds the svm features available
on phenom to its cpu-definition and extends the host cpu
type to support all svm features KVM can provide.



This should really be "all svm features" since we'll later mask them 
with kvm capabilities.  This way, if we later add more capabilities, 
we automatically gain support in userspace.


(or rather, all svm features that don't need save/restore support in 
userspace; I don't think any do, beyond svm itself)




I applied 2 and 3 (to branch uq/master).  If you want to add more svm 
features, please send a patch.  For patch 1, I'd like a review by 
someone who understands the compat code.


--
error compiling committee.c: too many arguments to function

[Qemu-devel] Re: [PATCH 3/3] Add svm cpuid features

[Roedel, Joerg]

On Mon, Sep 27, 2010 at 11:02:23AM -0400, Avi Kivity wrote:
>   On 09/27/2010 04:58 PM, Avi Kivity wrote:
> >  On 09/27/2010 03:16 PM, Joerg Roedel wrote:
> >> This patch adds the svm cpuid feature flags to the qemu
> >> intialization path. It also adds the svm features available
> >> on phenom to its cpu-definition and extends the host cpu
> >> type to support all svm features KVM can provide.
> >>
> >
> > This should really be "all svm features" since we'll later mask them 
> > with kvm capabilities.  This way, if we later add more capabilities, 
> > we automatically gain support in userspace.

Yes, that is what -cpu host does with these patches applied. The
svm_features variable is set to -1 in this case and masked out later
with the KVM capabilities.

> >
> > (or rather, all svm features that don't need save/restore support in 
> > userspace; I don't think any do, beyond svm itself)
> >
> 
> I applied 2 and 3 (to branch uq/master).  If you want to add more svm 
> features, please send a patch.  For patch 1, I'd like a review by 
> someone who understands the compat code.

Great, thanks.

Joerg
-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

[Qemu-devel] Re: [PATCH 2/2] trace: avoid unnecessary recompilation if nothing changed

[Blue Swirl]

On Mon, Sep 27, 2010 at 9:51 AM, Paolo Bonzini  wrote:
> On 09/27/2010 10:32 AM, Markus Armbruster wrote:
>> Why the conditional?  cmp -s fails fine when argument files don't exist.
>>
>> Note that common versions of make including GNU Make do not stat a
>> rule's target to check whether the rule changed it.  Instead, they
>> assume it changed, and remake everything depending on it.
>>
>>      arm...@blackfin:~/tmp$ cat Makefile
>>      foo: bar
>>              echo "Remaking foo"
>>
>>      bar:
>>              [ -f $@ ] || touch $@&&  echo "Touched bar"
>>      arm...@blackfin:~/tmp$ rm -f foo
>>      arm...@blackfin:~/tmp$ make
>>      [ -f bar ] || touch bar&&  echo "Touched bar"
>>      Touched bar
>>      echo "Remaking foo"
>>      Remaking foo
>>      arm...@blackfin:~/tmp$ make
>>      echo "Remaking foo"
>>      Remaking foo
>>
>> I doubt your patch avoids churn as advertized with such makes.
>
> Indeed, see how it's done for config-*.h.
>
> # Uses generic rule in rules.mak
> trace.h: trace.h-timestamp
> trace.h-timestamp: $(SRC_PATH)/trace-events config-host.mak
>        $(call quiet-command,sh $(SRC_PATH)/tracetool --$(TRACE_BACKEND) -h < 
> $< > $@,"  GEN  trace.h)
>       �...@cmp $@ trace.h >/dev/null 2>&1 || cp $@ trace.h
>
> (untested).

I just copied the rule from %/config-devices.mak. Is also that rule
then incorrect?

Perhaps there could be a macro for this, not unlike move-if-change
script in various GNU packages?

[Qemu-devel] Tracing memory accesses via gdbstub and SPARC64

[Mark Cave-Ayland]

Hi all,

What is the best way of being able track accesses to a specific location 
via gdbstub? I'm trying to investigate a potential memory-clobbering bug 
in OpenBIOS on SPARC64 but using "watch" on a variable via gdbstub 
causes gdb to segfault, e.g.:



bu...@zeno:~/src/openbios/openbios-devel$ sparc64-linux-gdb
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-unknown-linux-gnu 
--target=sparc64-linux".

(gdb) file obj-sparc64/openbios-builtin.elf.nostrip
Reading symbols from 
/home/build/src/openbios/openbios-devel/obj-sparc64/openbios-builtin.elf.nostrip...done.

(gdb) watch foo
Watchpoint 1: foo
(gdb) target remote :1234
Remote debugging using :1234
[New Thread 1]
0x01fff020 in ?? ()
(gdb) cont
Continuing.
Segmentation fault


Basically I'm looking for a way of causing gdb to break when a 
particular memory location is written so I can execute a backtrace and 
figure out the culprit. I'd be quite happy to hardcode an address to 
force a break in gdb somewhere within the qemu source as workaround if 
someone could point me in the right direction?



Many thanks,

Mark.

--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs

[Qemu-devel] Re: [PATCH 2/2] trace: avoid unnecessary recompilation if nothing changed

[Paolo Bonzini]

On 09/27/2010 06:13 PM, Blue Swirl wrote:

Indeed, see how it's done for config-*.h.

# Uses generic rule in rules.mak
trace.h: trace.h-timestamp
trace.h-timestamp: $(SRC_PATH)/trace-events config-host.mak
$(call quiet-command,sh $(SRC_PATH)/tracetool --$(TRACE_BACKEND) -h<  $<  >  
$@,"  GEN  trace.h)
@cmp $@ trace.h>/dev/null 2>&1 || cp $@ trace.h

(untested).


I just copied the rule from %/config-devices.mak. Is also that rule
then incorrect?


config-devices.mak will cause the Makefile to be reread, but no 
recompilations, so it's fine not to use a timestamp file.  Headers are 
more complicated.



Perhaps there could be a macro for this, not unlike move-if-change
script in various GNU packages?


The problem is not really the move-if-change script, but rather the 
timestamping rules.  You can use $(eval) for that but it quickly becomes 
unmanageable.


Paolo

[Qemu-devel] Re: [PATCH 3/3] Add svm cpuid features

[Avi Kivity]

 On 09/27/2010 05:40 PM, Roedel, Joerg wrote:

On Mon, Sep 27, 2010 at 11:02:23AM -0400, Avi Kivity wrote:
>On 09/27/2010 04:58 PM, Avi Kivity wrote:
>  >   On 09/27/2010 03:16 PM, Joerg Roedel wrote:
>  >>  This patch adds the svm cpuid feature flags to the qemu
>  >>  intialization path. It also adds the svm features available
>  >>  on phenom to its cpu-definition and extends the host cpu
>  >>  type to support all svm features KVM can provide.
>  >>
>  >
>  >  This should really be "all svm features" since we'll later mask them
>  >  with kvm capabilities.  This way, if we later add more capabilities,
>  >  we automatically gain support in userspace.

Yes, that is what -cpu host does with these patches applied. The
svm_features variable is set to -1 in this case and masked out later
with the KVM capabilities.



Well, running current uq/master I get:

  has_svm: can't execute cpuid 0x800a
  kvm: no hardware support

?

--
error compiling committee.c: too many arguments to function

[Qemu-devel] [PATCH] virtio: invoke set_status callback on reset

[Michael S. Tsirkin]

As status is set to 0 on reset, invoke the
relevant callback. This makes for a cleaner
code in devices as they don't need to
duplicate the code in their reset routine,
as well as excercises this path a little more.

Signed-off-by: Michael S. Tsirkin 
---
 hw/virtio.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/hw/virtio.c b/hw/virtio.c
index 4475bb3..d7b5853 100644
--- a/hw/virtio.c
+++ b/hw/virtio.c
@@ -443,6 +443,8 @@ void virtio_reset(void *opaque)
 VirtIODevice *vdev = opaque;
 int i;
 
+virtio_set_status(vdev, 0);
+
 if (vdev->reset)
 vdev->reset(vdev);
 
-- 
1.7.3-rc1

[Qemu-devel] [PATCH] virtio-net: unify vhost-net start/stop

[Michael S. Tsirkin]

Move all of vhost-net start/stop logic to a single routine,
and call it from everywhere.

Additionally, start/stop vhost-net on link up/down:
we should not transmit anything if user asked us to
put the link down.

Signed-off-by: Michael S. Tsirkin 
---
 hw/virtio-net.c |   37 +
 1 files changed, 17 insertions(+), 20 deletions(-)

diff --git a/hw/virtio-net.c b/hw/virtio-net.c
index 075f72d..d3fc400 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -51,6 +51,7 @@ typedef struct VirtIONet
 uint8_t nouni;
 uint8_t nobcast;
 uint8_t vhost_started;
+bool vm_running;
 VMChangeStateEntry *vmstate;
 struct {
 int in_use;
@@ -107,6 +108,8 @@ static void virtio_net_set_link_status(VLANClientState *nc)
 
 if (n->status != old_status)
 virtio_notify_config(&n->vdev);
+
+virtio_net_set_status(n->vdev.status);
 }
 
 static void virtio_net_reset(VirtIODevice *vdev)
@@ -120,10 +123,6 @@ static void virtio_net_reset(VirtIODevice *vdev)
 n->nomulti = 0;
 n->nouni = 0;
 n->nobcast = 0;
-if (n->vhost_started) {
-vhost_net_stop(tap_get_vhost_net(n->nic->nc.peer), vdev);
-n->vhost_started = 0;
-}
 
 /* Flush any MAC and VLAN filter table state */
 n->mac_table.in_use = 0;
@@ -726,12 +725,9 @@ static void virtio_net_save(QEMUFile *f, void *opaque)
 {
 VirtIONet *n = opaque;
 
-if (n->vhost_started) {
-/* TODO: should we really stop the backend?
- * If we don't, it might keep writing to memory. */
-vhost_net_stop(tap_get_vhost_net(n->nic->nc.peer), &n->vdev);
-n->vhost_started = 0;
-}
+/* At this point, backend must be stopped, otherwise
+ * it might keep writing to memory. */
+assert(!n->vhost_started);
 virtio_save(&n->vdev, f);
 
 qemu_put_buffer(f, n->mac, ETH_ALEN);
@@ -876,11 +872,13 @@ static void virtio_net_set_status(struct VirtIODevice 
*vdev, uint8_t status)
 if (!tap_get_vhost_net(n->nic->nc.peer)) {
 return;
 }
-if (!!n->vhost_started == !!(status & VIRTIO_CONFIG_S_DRIVER_OK)) {
+if (!!n->vhost_started == (status & VIRTIO_CONFIG_S_DRIVER_OK) &&
+(n->status & VIRTIO_NET_S_LINK_UP) &&
+n->vm_running) {
 return;
 }
-if (status & VIRTIO_CONFIG_S_DRIVER_OK) {
-int r = vhost_net_start(tap_get_vhost_net(n->nic->nc.peer), vdev);
+if (!n->vhost_started) {
+int r = vhost_net_start(tap_get_vhost_net(n->nic->nc.peer), &n->vdev);
 if (r < 0) {
 fprintf(stderr, "unable to start vhost net: %d: "
 "falling back on userspace virtio\n", -r);
@@ -888,7 +886,7 @@ static void virtio_net_set_status(struct VirtIODevice 
*vdev, uint8_t status)
 n->vhost_started = 1;
 }
 } else {
-vhost_net_stop(tap_get_vhost_net(n->nic->nc.peer), vdev);
+vhost_net_stop(tap_get_vhost_net(n->nic->nc.peer), &n->vdev);
 n->vhost_started = 0;
 }
 }
@@ -896,11 +894,11 @@ static void virtio_net_set_status(struct VirtIODevice 
*vdev, uint8_t status)
 static void virtio_net_vmstate_change(void *opaque, int running, int reason)
 {
 VirtIONet *n = opaque;
-uint8_t status = running ? VIRTIO_CONFIG_S_DRIVER_OK : 0;
+n->vm_running = running;
 /* This is called when vm is started/stopped,
- * it will start/stop vhost backend if * appropriate
+ * it will start/stop vhost backend if appropriate
  * e.g. after migration. */
-virtio_net_set_status(&n->vdev, n->vdev.status & status);
+virtio_net_set_status(&n->vdev, n->vdev.status);
 }
 
 VirtIODevice *virtio_net_init(DeviceState *dev, NICConf *conf)
@@ -951,9 +949,8 @@ void virtio_net_exit(VirtIODevice *vdev)
 VirtIONet *n = DO_UPCAST(VirtIONet, vdev, vdev);
 qemu_del_vm_change_state_handler(n->vmstate);
 
-if (n->vhost_started) {
-vhost_net_stop(tap_get_vhost_net(n->nic->nc.peer), vdev);
-}
+/* This will stop vhost backend if appropriate. */
+virtio_net_set_status(vdev, 0);
 
 qemu_purge_queued_packets(&n->nic->nc);
 
-- 
1.7.3-rc1

[Qemu-devel] [PATCH] virtio-9p: Use GCC_FMT_ATTR and fix a format warning

[Stefan Weil]

With the new gcc format warnings, gcc detected this:

/qemu/hw/virtio-9p.c:1040: error: format ‘%u’ expects type ‘unsigned int’, but 
argument 4 has type ‘__nlink_t’

Cc: Blue Swirl 
Signed-off-by: Stefan Weil 
---
 hw/virtio-9p.c |   10 ++
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 32fa3bc..3b2d49c 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -333,7 +333,8 @@ static int number_to_string(void *arg, char type)
 return ret;
 }
 
-static int v9fs_string_alloc_printf(char **strp, const char *fmt, va_list ap)
+static int GCC_FMT_ATTR(2, 0)
+v9fs_string_alloc_printf(char **strp, const char *fmt, va_list ap)
 {
 va_list ap2;
 char *iter = (char *)fmt;
@@ -387,7 +388,8 @@ alloc_print:
 return vsprintf(*strp, fmt, ap);
 }
 
-static void v9fs_string_sprintf(V9fsString *str, const char *fmt, ...)
+static void GCC_FMT_ATTR(2, 3)
+v9fs_string_sprintf(V9fsString *str, const char *fmt, ...)
 {
 va_list ap;
 int err;
@@ -1034,8 +1036,8 @@ static int stat_to_v9stat(V9fsState *s, V9fsString *name,
 S_ISCHR(stbuf->st_mode) ? 'c' : 'b',
 major(stbuf->st_rdev), minor(stbuf->st_rdev));
 } else if (S_ISDIR(stbuf->st_mode) || S_ISREG(stbuf->st_mode)) {
-v9fs_string_sprintf(&v9stat->extension, "%s %u",
-"HARDLINKCOUNT", stbuf->st_nlink);
+v9fs_string_sprintf(&v9stat->extension, "%s %lu",
+"HARDLINKCOUNT", (unsigned long)stbuf->st_nlink);
 }
 
 str = strrchr(name->data, '/');
-- 
1.7.1

[Qemu-devel] [PATCHv2] virtio-net: unify vhost-net start/stop

[Michael S. Tsirkin]

Move all of vhost-net start/stop logic to a single routine,
and call it from everywhere.

Additionally, start/stop vhost-net on link up/down:
we should not transmit anything if user asked us to
put the link down.

Signed-off-by: Michael S. Tsirkin 
---

Sent a wrong version, sorry about the noise.

 hw/virtio-net.c |   89 ++
 1 files changed, 43 insertions(+), 46 deletions(-)

diff --git a/hw/virtio-net.c b/hw/virtio-net.c
index 075f72d..f87c219 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -51,6 +51,7 @@ typedef struct VirtIONet
 uint8_t nouni;
 uint8_t nobcast;
 uint8_t vhost_started;
+bool vm_running;
 VMChangeStateEntry *vmstate;
 struct {
 int in_use;
@@ -95,6 +96,38 @@ static void virtio_net_set_config(VirtIODevice *vdev, const 
uint8_t *config)
 }
 }
 
+static void virtio_net_set_status(struct VirtIODevice *vdev, uint8_t status)
+{
+VirtIONet *n = to_virtio_net(vdev);
+if (!n->nic->nc.peer) {
+return;
+}
+if (n->nic->nc.peer->info->type != NET_CLIENT_TYPE_TAP) {
+return;
+}
+
+if (!tap_get_vhost_net(n->nic->nc.peer)) {
+return;
+}
+if (!!n->vhost_started == (status & VIRTIO_CONFIG_S_DRIVER_OK) &&
+(n->status & VIRTIO_NET_S_LINK_UP) &&
+n->vm_running) {
+return;
+}
+if (!n->vhost_started) {
+int r = vhost_net_start(tap_get_vhost_net(n->nic->nc.peer), &n->vdev);
+if (r < 0) {
+fprintf(stderr, "unable to start vhost net: %d: "
+"falling back on userspace virtio\n", -r);
+} else {
+n->vhost_started = 1;
+}
+} else {
+vhost_net_stop(tap_get_vhost_net(n->nic->nc.peer), &n->vdev);
+n->vhost_started = 0;
+}
+}
+
 static void virtio_net_set_link_status(VLANClientState *nc)
 {
 VirtIONet *n = DO_UPCAST(NICState, nc, nc)->opaque;
@@ -107,6 +140,8 @@ static void virtio_net_set_link_status(VLANClientState *nc)
 
 if (n->status != old_status)
 virtio_notify_config(&n->vdev);
+
+virtio_net_set_status(&n->vdev, n->vdev.status);
 }
 
 static void virtio_net_reset(VirtIODevice *vdev)
@@ -120,10 +155,6 @@ static void virtio_net_reset(VirtIODevice *vdev)
 n->nomulti = 0;
 n->nouni = 0;
 n->nobcast = 0;
-if (n->vhost_started) {
-vhost_net_stop(tap_get_vhost_net(n->nic->nc.peer), vdev);
-n->vhost_started = 0;
-}
 
 /* Flush any MAC and VLAN filter table state */
 n->mac_table.in_use = 0;
@@ -726,12 +757,9 @@ static void virtio_net_save(QEMUFile *f, void *opaque)
 {
 VirtIONet *n = opaque;
 
-if (n->vhost_started) {
-/* TODO: should we really stop the backend?
- * If we don't, it might keep writing to memory. */
-vhost_net_stop(tap_get_vhost_net(n->nic->nc.peer), &n->vdev);
-n->vhost_started = 0;
-}
+/* At this point, backend must be stopped, otherwise
+ * it might keep writing to memory. */
+assert(!n->vhost_started);
 virtio_save(&n->vdev, f);
 
 qemu_put_buffer(f, n->mac, ETH_ALEN);
@@ -863,44 +891,14 @@ static NetClientInfo net_virtio_info = {
 .link_status_changed = virtio_net_set_link_status,
 };
 
-static void virtio_net_set_status(struct VirtIODevice *vdev, uint8_t status)
-{
-VirtIONet *n = to_virtio_net(vdev);
-if (!n->nic->nc.peer) {
-return;
-}
-if (n->nic->nc.peer->info->type != NET_CLIENT_TYPE_TAP) {
-return;
-}
-
-if (!tap_get_vhost_net(n->nic->nc.peer)) {
-return;
-}
-if (!!n->vhost_started == !!(status & VIRTIO_CONFIG_S_DRIVER_OK)) {
-return;
-}
-if (status & VIRTIO_CONFIG_S_DRIVER_OK) {
-int r = vhost_net_start(tap_get_vhost_net(n->nic->nc.peer), vdev);
-if (r < 0) {
-fprintf(stderr, "unable to start vhost net: %d: "
-"falling back on userspace virtio\n", -r);
-} else {
-n->vhost_started = 1;
-}
-} else {
-vhost_net_stop(tap_get_vhost_net(n->nic->nc.peer), vdev);
-n->vhost_started = 0;
-}
-}
-
 static void virtio_net_vmstate_change(void *opaque, int running, int reason)
 {
 VirtIONet *n = opaque;
-uint8_t status = running ? VIRTIO_CONFIG_S_DRIVER_OK : 0;
+n->vm_running = running;
 /* This is called when vm is started/stopped,
- * it will start/stop vhost backend if * appropriate
+ * it will start/stop vhost backend if appropriate
  * e.g. after migration. */
-virtio_net_set_status(&n->vdev, n->vdev.status & status);
+virtio_net_set_status(&n->vdev, n->vdev.status);
 }
 
 VirtIODevice *virtio_net_init(DeviceState *dev, NICConf *conf)
@@ -951,9 +949,8 @@ void virtio_net_exit(VirtIODevice *vdev)
 VirtIONet *n = DO_UPCAST(VirtIONet, vdev, vdev);
 qemu_del_vm_change_state_handler(n->vmstate);
 
-if (n->vhost_started) {
-vhost_net_

Re: [Qemu-devel] qemu: qemu_mutex_lock: Invalid argument

[Rick Vernam]

On Wednesday 15 September 2010 05:46:55 Yoshiaki Tamura wrote:
> Hi Rick,
> 
> 2010/9/15 Corentin Chary :
> > On Tue, Sep 14, 2010 at 10:00 PM, Rick Vernam  wrote:
> >> I don't have nearly enough info to file a proper bug report.
> >> 
> >> I am running qemu-kvm-0.13.0 rc1
> >> starting qemu like so:
> >> /root/qemu/bin/qemu-system-x86_64 -cpu host -enable-kvm -drive
> >> file=/root/qemu/w2k3_server.raw,if=virtio,aio=native -net
> >> nic,model=virtio,macaddr=52:54:00:12:34:56 -net tap,ifname=tap0
> >> -localtime - usb -usbdevice tablet -vga std -vnc :25581 -monitor stdio
> >> -m 512 -runas rick
> >> 
> >> Every now and again, qemu will up and quit leaving only the following
> >> message: qemu: qemu_mutex_lock: Invalid argument
> >> 
> >> At the moment I can't stop what I'm doing to go learn how to debug qemu,
> >> but I'd be happy if anybody is interested in suggesting something I
> >> could do to provide some info about this bug...
> >> Would it be helpful to build with -O0 -g and run in gdb, then get a bt
> >> when it dies?
> >> I haven't put this into production yet, so I can still afford downtime &
> >> re- compiles...etc.
> >> 
> >> thanks..
> >> 
> >> host machine is:
> >> 2.6.32-gentoo-r7 x86_64 Intel(R) Xeon(R) CPU E5450 @ 3.00GHz
> >> GenuineIntel GNU/Linux
> >> 
> >> guest os is Windows Server 2003, Standard Edition.  Service Pack 2.
> >> Red Het VirtIO Ethernet Adapter Driver Version: 5.1.209.605
> >> Red Hat VirtIO SCSI Controller Driver Version: 6.0.0.10
> >> 
> >> here is how I ran configure:
> >> ./configure --prefix=/root/qemu --target-list=x86_64-softmmu
> >> --extra-cflags="- march=native -O2 -pipe"
> >> --extra-ldflags="-march=native -O2 -pipe" --audio-drv- list=
> >> --audio-card-list= --disable-curses --disable-curl --enable-vnc-tls --
> >> enable-vnc-sasl --enable-vnc-jpeg --enable-vnc-png --enable-vnc-thread
> > 
> > There is two patch for that
> > http://patchwork.ozlabs.org/patch/62420/
> 
> Can you try the patch above?  If it works, I need to ask Anthony to
> pick it up for 0.13.
I have not encountered this problem since applying the patch.  So I sure would 
like to see it in 0.13.

Thanks,
-Rick

> 
> Thanks,
> 
> Yoshi
> 
> > http://patchwork.ozlabs.org/patch/62263/
> > 
> > On of these patch is already in master:
> > http://git.qemu.org/qemu.git/commit/?id=ac71103dc6b408775ae72067790ab3679
> > 12f75ec
> > 
> > --
> > Corentin Chary
> > http://xf.iksaif.net

[Qemu-devel] Re: [PATCHv2] virtio-net: unify vhost-net start/stop

[Alex Williamson]

On Mon, 2010-09-27 at 18:41 +0200, Michael S. Tsirkin wrote:
> Move all of vhost-net start/stop logic to a single routine,
> and call it from everywhere.
> 
> Additionally, start/stop vhost-net on link up/down:
> we should not transmit anything if user asked us to
> put the link down.
> 
> Signed-off-by: Michael S. Tsirkin 
> ---
> 
> Sent a wrong version, sorry about the noise.
> 
>  hw/virtio-net.c |   89 ++
>  1 files changed, 43 insertions(+), 46 deletions(-)
> 
> diff --git a/hw/virtio-net.c b/hw/virtio-net.c
> index 075f72d..f87c219 100644
> --- a/hw/virtio-net.c
> +++ b/hw/virtio-net.c
> @@ -51,6 +51,7 @@ typedef struct VirtIONet
>  uint8_t nouni;
>  uint8_t nobcast;
>  uint8_t vhost_started;
> +bool vm_running;
>  VMChangeStateEntry *vmstate;
>  struct {
>  int in_use;
> @@ -95,6 +96,38 @@ static void virtio_net_set_config(VirtIODevice *vdev, 
> const uint8_t *config)
>  }
>  }
>  
> +static void virtio_net_set_status(struct VirtIODevice *vdev, uint8_t status)
> +{
> +VirtIONet *n = to_virtio_net(vdev);
> +if (!n->nic->nc.peer) {
> +return;
> +}
> +if (n->nic->nc.peer->info->type != NET_CLIENT_TYPE_TAP) {
> +return;
> +}
> +
> +if (!tap_get_vhost_net(n->nic->nc.peer)) {
> +return;
> +}
> +if (!!n->vhost_started == (status & VIRTIO_CONFIG_S_DRIVER_OK) &&
> +(n->status & VIRTIO_NET_S_LINK_UP) &&
> +n->vm_running) {

I don't think this works...

#define VIRTIO_CONFIG_S_DRIVER_OK   4

!!(1) == (status & 4)?

> +return;
> +}
> +if (!n->vhost_started) {
> +int r = vhost_net_start(tap_get_vhost_net(n->nic->nc.peer), 
> &n->vdev);
> +if (r < 0) {
> +fprintf(stderr, "unable to start vhost net: %d: "
> +"falling back on userspace virtio\n", -r);

Definitely worth noting if not using vhost, but aren't we potentially
going to see this in the log a lot in that case?  Thanks,

Alex

> +} else {
> +n->vhost_started = 1;
> +}
> +} else {
> +vhost_net_stop(tap_get_vhost_net(n->nic->nc.peer), &n->vdev);
> +n->vhost_started = 0;
> +}
> +}
> +
>  static void virtio_net_set_link_status(VLANClientState *nc)
>  {
>  VirtIONet *n = DO_UPCAST(NICState, nc, nc)->opaque;
> @@ -107,6 +140,8 @@ static void virtio_net_set_link_status(VLANClientState 
> *nc)
>  
>  if (n->status != old_status)
>  virtio_notify_config(&n->vdev);
> +
> +virtio_net_set_status(&n->vdev, n->vdev.status);
>  }
>  
>  static void virtio_net_reset(VirtIODevice *vdev)
> @@ -120,10 +155,6 @@ static void virtio_net_reset(VirtIODevice *vdev)
>  n->nomulti = 0;
>  n->nouni = 0;
>  n->nobcast = 0;
> -if (n->vhost_started) {
> -vhost_net_stop(tap_get_vhost_net(n->nic->nc.peer), vdev);
> -n->vhost_started = 0;
> -}
>  
>  /* Flush any MAC and VLAN filter table state */
>  n->mac_table.in_use = 0;
> @@ -726,12 +757,9 @@ static void virtio_net_save(QEMUFile *f, void *opaque)
>  {
>  VirtIONet *n = opaque;
>  
> -if (n->vhost_started) {
> -/* TODO: should we really stop the backend?
> - * If we don't, it might keep writing to memory. */
> -vhost_net_stop(tap_get_vhost_net(n->nic->nc.peer), &n->vdev);
> -n->vhost_started = 0;
> -}
> +/* At this point, backend must be stopped, otherwise
> + * it might keep writing to memory. */
> +assert(!n->vhost_started);
>  virtio_save(&n->vdev, f);
>  
>  qemu_put_buffer(f, n->mac, ETH_ALEN);
> @@ -863,44 +891,14 @@ static NetClientInfo net_virtio_info = {
>  .link_status_changed = virtio_net_set_link_status,
>  };
>  
> -static void virtio_net_set_status(struct VirtIODevice *vdev, uint8_t status)
> -{
> -VirtIONet *n = to_virtio_net(vdev);
> -if (!n->nic->nc.peer) {
> -return;
> -}
> -if (n->nic->nc.peer->info->type != NET_CLIENT_TYPE_TAP) {
> -return;
> -}
> -
> -if (!tap_get_vhost_net(n->nic->nc.peer)) {
> -return;
> -}
> -if (!!n->vhost_started == !!(status & VIRTIO_CONFIG_S_DRIVER_OK)) {
> -return;
> -}
> -if (status & VIRTIO_CONFIG_S_DRIVER_OK) {
> -int r = vhost_net_start(tap_get_vhost_net(n->nic->nc.peer), vdev);
> -if (r < 0) {
> -fprintf(stderr, "unable to start vhost net: %d: "
> -"falling back on userspace virtio\n", -r);
> -} else {
> -n->vhost_started = 1;
> -}
> -} else {
> -vhost_net_stop(tap_get_vhost_net(n->nic->nc.peer), vdev);
> -n->vhost_started = 0;
> -}
> -}
> -
>  static void virtio_net_vmstate_change(void *opaque, int running, int reason)
>  {
>  VirtIONet *n = opaque;
> -uint8_t status = running ? VIRTIO_CONFIG_S_DRIVER_OK : 0;
> +n->vm_running = running;
>  /* This i

[Qemu-devel] Re: [PATCH] net: delay freeing peer host device

[Alex Williamson]

On Mon, 2010-09-27 at 15:00 +0200, Michael S. Tsirkin wrote:
> With -netdev, virtio devices present offload
> features to guest, depending on the backend used.
> Thus, removing host netdev peer while guest is
> active leads to guest-visible inconsistency and/or crashes.
> 
> As a solution, while guest (NIC) peer device exists,
> we prevent the host peer from being deleted.
> This patch does this by adding peer_deleted flag in nic state:
> if host device is going away while guest device
> is around, set this flag and keep a shell of
> the host device around for as long as guest device exists.
> 
> The link is put down so all packets will get discarded.
> 
> At the moment, management can detect that device deletion
> is delayed by doing info net. As a next step, we shall add
> commands that control hotplug/unplug without
> removing the device, and an event to report that
> guest has responded to the hotplug event.
> 
> Signed-off-by: Michael S. Tsirkin 
> ---
>  net.c |   40 +---
>  net.h |1 +
>  2 files changed, 34 insertions(+), 7 deletions(-)
> 
> diff --git a/net.c b/net.c
> index 3d0fde7..edb87af 100644
> --- a/net.c
> +++ b/net.c
> @@ -281,29 +281,55 @@ NICState *qemu_new_nic(NetClientInfo *info,
>  return nic;
>  }
>  
> -void qemu_del_vlan_client(VLANClientState *vc)
> +static void qemu_free_vlan_client(VLANClientState *vc)
>  {
>  if (vc->vlan) {
>  QTAILQ_REMOVE(&vc->vlan->clients, vc, next);
>  } else {
> +QTAILQ_REMOVE(&non_vlan_clients, vc, next);
>  if (vc->send_queue) {
>  qemu_del_net_queue(vc->send_queue);
>  }
> -QTAILQ_REMOVE(&non_vlan_clients, vc, next);
>  if (vc->peer) {
>  vc->peer->peer = NULL;
>  }
>  }
> -
> -if (vc->info->cleanup) {
> -vc->info->cleanup(vc);
> -}
> -
>  qemu_free(vc->name);
>  qemu_free(vc->model);
>  qemu_free(vc);
>  }
>  
> +void qemu_del_vlan_client(VLANClientState *vc)
> +{
> +/* If there is a peer NIC, delete and cleanup client, but do not free. */
> +if (!vc->vlan && vc->peer && vc->peer->info->type == 
> NET_CLIENT_TYPE_NIC) {
> +NICState *nic = DO_UPCAST(NICState, nc, vc->peer);
> +if (nic->peer_deleted) {
> +return;
> +}
> +nic->peer_deleted = true;
> +/* Let NIC know peer is gone. */
> +vc->peer->link_down = true;
> +if (vc->peer->info->link_status_changed) {
> +vc->peer->info->link_status_changed(vc->peer);

Are we potentially introducing more races here?  Now we have the tap
trying to call link change on a peer device that's potentially in the
middle of going away.  Thanks,

Alex

> +}
> +if (vc->info->cleanup) {
> +vc->info->cleanup(vc);
> +}
> +return;
> +}
> +
> +/* If this is a peer NIC and peer has already been deleted, free it now. 
> */
> +if (!vc->vlan && vc->peer && vc->info->type == NET_CLIENT_TYPE_NIC) {
> +NICState *nic = DO_UPCAST(NICState, nc, vc);
> +if (nic->peer_deleted) {
> +qemu_free_vlan_client(vc->peer);
> +}
> +}
> +
> +qemu_free_vlan_client(vc);
> +}
> +
>  VLANClientState *
>  qemu_find_vlan_client_by_name(Monitor *mon, int vlan_id,
>const char *client_str)
> diff --git a/net.h b/net.h
> index 518cf9c..44c31a9 100644
> --- a/net.h
> +++ b/net.h
> @@ -72,6 +72,7 @@ typedef struct NICState {
>  VLANClientState nc;
>  NICConf *conf;
>  void *opaque;
> +bool peer_deleted;
>  } NICState;
>  
>  struct VLANState {

[Qemu-devel] "Bad ram offset"?

[Artyom Tarasenko]

In today's git master:

$ ./qemu-system-sparc64 -M sun4u -m 2048
Bad ram offset 8000
Aborted

$ ./qemu-system-sparc -M SS-20 -m 2048
Bad ram offset 8010
Aborted

Is there a way to give guest 2GiB+ RAM? The host seems to have enough:

$ free
 total   used   free sharedbuffers cached
Mem:   611766845083201609348  0   78763286208
-/+ buffers/cache:12142364903432
Swap:   6553440  0 6553440

$ uname -a
Linux host 2.6.32.21-166.fc12.x86_64 #1 SMP Fri Aug 27 06:07:37 UTC
2010 x86_64 x86_64 x86_64 GNU/Linux

The configure script seems to realize that the host is 64 bit:
...
QEMU_CFLAGS   -Werror -m64 -Wtype-limits -Wold-style-definition
-Wold-style-declaration -Wignored-qualifiers -Winit-self -Wformat-y2k
-Wformat-security -Wnested-externs -Wempty-body -fstack-protector-all
-I. -I$(SRC_PATH) -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes
-Wredundant-decls -Wall -Wundef -Wendif-labels -Wwrite-strings
-Wmissing-prototypes -fno-strict-aliasing
LDFLAGS   -Wl,--warn-common -m64 -g
make  make
install   install
host CPU  x86_64
host big endian   no
target list   sparc-softmmu sparc64-softmmu
...
$  gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap
--enable-shared --enable-threads=posix --enable-checking=release
--with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada
--enable-java-awt=gtk --disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic
--with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC)

-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/

[Qemu-devel] Re: BUG - qdev - partial loss of network connectivity

[Leszek Urbanski]

<20100926154324.gd21...@redhat.com>; from Michael S. Tsirkin on Sun, Sep 26, 
2010 at 17:43:24 +0200

> > > >It's vanilla 2.6.32.22, but I also reproduced this on Debian's 2.6.32-23
> > > >(based on 2.6.32.21).
> > > >
> > > >If offload is the only difference, I'll play with different offload
> > > >options and check which one causes it.
> > > >   
> > > 
> > > It's not technically the only difference but it's the most likely 
> > > culprit IMHO.
> > 
> > udp fragmentation offload is definitely the culprit.
> 
> I see. Most likely guest bug - won't be the first bug around UFO.
> If so pls copy netdev linux-nfs and virtualization.
> Do you see anything in dmesg? Can try 2.6.36-rc5?

(for reference: first post is at:
http://lists.nongnu.org/archive/html/qemu-devel/2010-09/msg01685.html )

I can't reproduce it on 2.6.36-rc5. Do you have an idea which patch may have
fixed it, or should I dissect?

2.6.32.x - there's nothing interesting in dmesg, apart from traces related
to tasks in D state waiting on the NFS mounts:

[   84.396127] nfs: server 10.0.0.1 not responding, still trying
[  240.568162] INFO: task cp:1838 blocked for more than 120 seconds.
[  240.569715] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  240.571486] cpD 0002 0  1838   1831 0x
[  240.573340]  88011fa5b880 0082  
88011e45bb44
[  240.575508]  88011e45bcc8 8102cdac f9e0 
88011e45bfd8
[  240.578827]  00015780 00015780 88011c7ce2e0 
88011c7ce5d8
[  240.580502] Call Trace:
[  240.581132]  [] ? pvclock_clocksource_read+0x3a/0x8b
[  240.582427]  [] ? pvclock_clocksource_read+0x3a/0x8b
[  240.583869]  [] ? sync_page+0x0/0x46
[  240.585034]  [] ? sync_page+0x0/0x46
[  240.586087]  [] ? io_schedule+0x73/0xb7
[  240.587287]  [] ? sync_page+0x41/0x46
[  240.588202]  [] ? __wait_on_bit+0x41/0x70
[  240.589314]  [] ? wait_on_page_bit+0x6b/0x71
[  240.590630]  [] ? wake_bit_function+0x0/0x23
[  240.591906]  [] ? pagevec_lookup_tag+0x1a/0x21
[  240.592954]  [] ? wait_on_page_writeback_range+0x69/0x11b
[  240.594403]  [] ? filemap_write_and_wait+0x26/0x32
[  240.595563]  [] ? nfs_setattr+0xb9/0x117 [nfs]
[  240.596670]  [] ? find_get_page+0x1a/0x77
[  240.598012]  [] ? lock_page+0x9/0x1f
[  240.598878]  [] ? filemap_fault+0xb9/0x2f6
[  240.599839]  [] ? __do_fault+0x38c/0x3c3
[  240.601003]  [] ? do_sync_write+0xce/0x113
[  240.602082]  [] ? current_fs_time+0x1e/0x24
[  240.602968]  [] ? notify_change+0x180/0x2c5
[  240.604245]  [] ? utimes_common+0x12d/0x14d
[  240.605355]  [] ? do_utimes+0x81/0xca
[  240.606558]  [] ? sys_utimensat+0x5b/0x6a
[  240.607817]  [] ? system_call_fastpath+0x16/0x1b
[  240.609124] INFO: task find:1866 blocked for more than 120 seconds.
[  240.610409] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  240.612066] find  D  0  1866   1863 0x
[  240.613490]  8145d1f0 0086  
88011e2d2350
[  240.615188]  0022b63d07c7 88011c55e000 f9e0 
8800c78a5fd8
[  240.616576]  00015780 00015780 88011e2d2350 
88011e2d2648
[  240.618297] Call Trace:
[  240.618777]  [] ? virt_to_head_page+0x9/0x2a
[  240.619906]  [] ? __mutex_lock_common+0x122/0x192
[  240.621324]  [] ? mutex_lock+0x1a/0x31
[  240.622543]  [] ? mntput_no_expire+0x23/0xee
[  240.623860]  [] ? nfs_getattr+0x3b/0xda [nfs]
[  240.625219]  [] ? vfs_fstatat+0x43/0x57
[  240.626290]  [] ? sys_newfstatat+0x11/0x30
[  240.627594]  [] ? mntput_no_expire+0x23/0xee
[  240.628768]  [] ? device_not_available+0x1b/0x20
[  240.629644]  [] ? system_call_fastpath+0x16/0x1b


-- 
Leszek "Tygrys" Urbanski, SCSA, SCNA
 "Unix-to-Unix Copy Program;" said PDP-1. "You will never find a more
  wretched hive of bugs and flamers. We must be cautious." -- DECWARS
 http://cygnus.moo.pl/ -- Cygnus High Altitude Balloon

[Qemu-devel] [Bug 646427] Re: VirtFS mapped symlinks resolved wrong

[Moshroum]

Fixed by the mentioned documentation

** Changed in: qemu
   Status: New => Invalid

-- 
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: Invalid

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

[Qemu-devel] [Bug 648128] Re: VirtFS: Cannot mount 9p during boot

[Moshroum]

Fixed for me by http://article.gmane.org/gmane.linux.utilities.util-
linux-ng/3500/raw and
http://article.gmane.org/gmane.linux.kernel/1041020/raw

** Changed in: qemu
   Status: New => In Progress

-- 
VirtFS: Cannot mount 9p during boot
https://bugs.launchpad.net/bugs/648128
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: In Progress

Bug description:
I use as client Debian squeeze i386 with a custom kernel:
Linux (none) 2.6.35.5 #3 Thu Sep 23 18:36:02 UTC 2010 i686 GNU/Linux

And as host Debian squeeze amd64
Linux asd 2.6.32-5-amd64 #1 SMP Fri Sep 17 21:50:19 UTC 2010 x86_64 GNU/Linux

kvm version is:
kvm-88-5908-gdd67374

Started the client using:
sudo /usr/local/kvm/bin/qemu-system-x86_64 -m 1024 -kernel linux-2.6.35.5.qemu 
-drive file=root.img,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=/host,security_model=passthrough,mount_tag=host -nographic

I noticed 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 /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

The stuff in /etc/fstab is:
host/mnt   9p  trans=virtio 0 0



I intercepted the boot by adding `set -v; set +e; mount -t 9p -o trans=virtio 
host_share /mnt; /bin/sh` on top of my /etc/rc.local:
... but than it works quite well... well that is not what I expected. So I 
changed it to `set -v; mount /mnt || true; /bin/sh`.. and then it doesn't work 
anymore... mysterios but hey, did you notice that the share is actually called 
host and not host_share as I wrote inside the rc.local. So why does it work at 
all? Let me change it to `set -v; set +e; mount -t 9p -o trans=virtio host 
/mnt; /bin/sh` and reboot again.

What should i say: it says:
[8.004754] device: '9p-1': device_add
[8.006446] 9p: no channels available
[8.007156] device: '9p-1': device_unregister
[8.008650] device: '9p-1': device_create_release
mount: No such file or directory

But i have a shell now and can type the mount stuff inside it:
$ mount -v -t 9p -o trans=virtio host /mnt
mount -v -t 9p -o trans=virtio host /mnt
[   70.982688] device: '9p-2': device_add
[   70.986508] 9p: no channels available
[   70.987969] device: '9p-2': device_unregister
[   70.992937] device: '9p-2': device_create_release
mount: No such file or directory
$ ls -l /sys/bus/virtio/drivers/9pnet_virtio
total 0
--w--- 1 root root 4096 Sep 26 12:58 bind
--w--- 1 root root 4096 Sep 26 12:58 uevent
--w--- 1 root root 4096 Sep 26 12:58 unbind
lrwxrwxrwx 1 root root0 Sep 26 12:58 virtio1 -> 
../../../../devices/virtio-pci/virtio1
$ ls -l /sys/devices/virtio-pci/virtio1
total 0
lrwxrwxrwx 1 root root0 Sep 26 13:00 bus -> ../../../bus/virtio
-r--r--r-- 1 root root 4096 Sep 26 13:00 device
lrwxrwxrwx 1 root root0 Sep 26 13:00 driver -> 
../../../bus/virtio/drivers/9pnet_virtio
-r--r--r-- 1 root root 4096 Sep 26 13:00 features
-r--r--r-- 1 root root 4096 Sep 26 13:00 modalias
-r--r--r-- 1 root root 4096 Sep 26 13:00 mount_tag
drwxr-xr-x 2 root root0 Sep 26 12:58 power
-r--r--r-- 1 root root 4096 Sep 26 13:00 status
lrwxrwxrwx 1 root root0 Sep 26 13:00 subsystem -> ../../../bus/virtio
-rw-r--r-- 1 root root 4096 Sep 26 13:00 uevent
-r--r--r-- 1 root root 4096 Sep 26 13:00 vendor
$ cat /sys/devices/virtio-pci/virtio1/mount_tag
host$ mount -v -t 9p -o trans=virtio host /mnt
[  340.559853] device: '9p-3': device_add
[  340.563699] 9p: no channels available
[  340.565602] device: '9p-3': device_unregister
[  340.569201] device: '9p-3': device_create_release
mount: No such file or director
$ mount  -v -t 9p -o trans=virtio hostA /mnt
[  406.218462] device: '9p-4': device_add
hostA on /mnt type 9p (rw,trans=virtio)
$ env
CONSOLE=/dev/console
HOME=/
runlevel=2
INIT_VERSION=sysvinit-2.88
COLUMNS=80
TERM=linux
PATH=/sbin:/usr/sbin:/bin:/usr/bin
RUNLEVEL=2
PREVLEVEL=N
SHELL=/bin/sh
PWD=/
previous=N
LINES=24
VERBOSE=no
$ id
uid=0(root) gid=0(root) groups=0(root)
$ hexdump asd
000 6f68 7473      
010    
014

I rebooted again and now just ctrl+d in my rc.local shell to get to my real 
root login with zsh:
$ cat /sys/devices/virtio-pci/virtio1/mount_tag > asd
$ hexdump asd
000 6f68 7473      
010    
014
$ id
uid=0(root) gid=0(root) groups=0(root)
$ env
TERM=linux
HOME=/root
SHELL=/bin/zsh
USER=root
LOGNAME=root
PATH=/host/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
MAIL=/var/mail/root
HUSHLOGIN=F

[Qemu-devel] Re: [PATCHv2] virtio-net: unify vhost-net start/stop

[Michael S. Tsirkin]

On Mon, Sep 27, 2010 at 01:43:11PM -0600, Alex Williamson wrote:
> On Mon, 2010-09-27 at 18:41 +0200, Michael S. Tsirkin wrote:
> > Move all of vhost-net start/stop logic to a single routine,
> > and call it from everywhere.
> > 
> > Additionally, start/stop vhost-net on link up/down:
> > we should not transmit anything if user asked us to
> > put the link down.
> > 
> > Signed-off-by: Michael S. Tsirkin 
> > ---
> > 
> > Sent a wrong version, sorry about the noise.
> > 
> >  hw/virtio-net.c |   89 
> > ++
> >  1 files changed, 43 insertions(+), 46 deletions(-)
> > 
> > diff --git a/hw/virtio-net.c b/hw/virtio-net.c
> > index 075f72d..f87c219 100644
> > --- a/hw/virtio-net.c
> > +++ b/hw/virtio-net.c
> > @@ -51,6 +51,7 @@ typedef struct VirtIONet
> >  uint8_t nouni;
> >  uint8_t nobcast;
> >  uint8_t vhost_started;
> > +bool vm_running;
> >  VMChangeStateEntry *vmstate;
> >  struct {
> >  int in_use;
> > @@ -95,6 +96,38 @@ static void virtio_net_set_config(VirtIODevice *vdev, 
> > const uint8_t *config)
> >  }
> >  }
> >  
> > +static void virtio_net_set_status(struct VirtIODevice *vdev, uint8_t 
> > status)
> > +{
> > +VirtIONet *n = to_virtio_net(vdev);
> > +if (!n->nic->nc.peer) {
> > +return;
> > +}
> > +if (n->nic->nc.peer->info->type != NET_CLIENT_TYPE_TAP) {
> > +return;
> > +}
> > +
> > +if (!tap_get_vhost_net(n->nic->nc.peer)) {
> > +return;
> > +}
> > +if (!!n->vhost_started == (status & VIRTIO_CONFIG_S_DRIVER_OK) &&
> > +(n->status & VIRTIO_NET_S_LINK_UP) &&
> > +n->vm_running) {
> 
> I don't think this works...
> 
> #define VIRTIO_CONFIG_S_DRIVER_OK   4
> 
> !!(1) == (status & 4)?

The && converts it to a boolean.

> > +return;
> > +}
> > +if (!n->vhost_started) {
> > +int r = vhost_net_start(tap_get_vhost_net(n->nic->nc.peer), 
> > &n->vdev);
> > +if (r < 0) {
> > +fprintf(stderr, "unable to start vhost net: %d: "
> > +"falling back on userspace virtio\n", -r);
> 
> Definitely worth noting if not using vhost, but aren't we potentially
> going to see this in the log a lot in that case?  Thanks,
> 
> Alex

Not really, we detect failure at start normally, and do
not proceed.
This means that somehow the device went dead: should not
happen really, but since it's easy to recover we do.

> > +} else {
> > +n->vhost_started = 1;
> > +}
> > +} else {
> > +vhost_net_stop(tap_get_vhost_net(n->nic->nc.peer), &n->vdev);
> > +n->vhost_started = 0;
> > +}
> > +}
> > +
> >  static void virtio_net_set_link_status(VLANClientState *nc)
> >  {
> >  VirtIONet *n = DO_UPCAST(NICState, nc, nc)->opaque;
> > @@ -107,6 +140,8 @@ static void virtio_net_set_link_status(VLANClientState 
> > *nc)
> >  
> >  if (n->status != old_status)
> >  virtio_notify_config(&n->vdev);
> > +
> > +virtio_net_set_status(&n->vdev, n->vdev.status);
> >  }
> >  
> >  static void virtio_net_reset(VirtIODevice *vdev)
> > @@ -120,10 +155,6 @@ static void virtio_net_reset(VirtIODevice *vdev)
> >  n->nomulti = 0;
> >  n->nouni = 0;
> >  n->nobcast = 0;
> > -if (n->vhost_started) {
> > -vhost_net_stop(tap_get_vhost_net(n->nic->nc.peer), vdev);
> > -n->vhost_started = 0;
> > -}
> >  
> >  /* Flush any MAC and VLAN filter table state */
> >  n->mac_table.in_use = 0;
> > @@ -726,12 +757,9 @@ static void virtio_net_save(QEMUFile *f, void *opaque)
> >  {
> >  VirtIONet *n = opaque;
> >  
> > -if (n->vhost_started) {
> > -/* TODO: should we really stop the backend?
> > - * If we don't, it might keep writing to memory. */
> > -vhost_net_stop(tap_get_vhost_net(n->nic->nc.peer), &n->vdev);
> > -n->vhost_started = 0;
> > -}
> > +/* At this point, backend must be stopped, otherwise
> > + * it might keep writing to memory. */
> > +assert(!n->vhost_started);
> >  virtio_save(&n->vdev, f);
> >  
> >  qemu_put_buffer(f, n->mac, ETH_ALEN);
> > @@ -863,44 +891,14 @@ static NetClientInfo net_virtio_info = {
> >  .link_status_changed = virtio_net_set_link_status,
> >  };
> >  
> > -static void virtio_net_set_status(struct VirtIODevice *vdev, uint8_t 
> > status)
> > -{
> > -VirtIONet *n = to_virtio_net(vdev);
> > -if (!n->nic->nc.peer) {
> > -return;
> > -}
> > -if (n->nic->nc.peer->info->type != NET_CLIENT_TYPE_TAP) {
> > -return;
> > -}
> > -
> > -if (!tap_get_vhost_net(n->nic->nc.peer)) {
> > -return;
> > -}
> > -if (!!n->vhost_started == !!(status & VIRTIO_CONFIG_S_DRIVER_OK)) {
> > -return;
> > -}
> > -if (status & VIRTIO_CONFIG_S_DRIVER_OK) {
> > -int r = vhost_net_start(tap_get_vhost_net(n->nic->nc.peer), vdev);
> > -if (

[Qemu-devel] Re: [PATCH] net: delay freeing peer host device

[Michael S. Tsirkin]

On Mon, Sep 27, 2010 at 02:18:37PM -0600, Alex Williamson wrote:
> On Mon, 2010-09-27 at 15:00 +0200, Michael S. Tsirkin wrote:
> > With -netdev, virtio devices present offload
> > features to guest, depending on the backend used.
> > Thus, removing host netdev peer while guest is
> > active leads to guest-visible inconsistency and/or crashes.
> > 
> > As a solution, while guest (NIC) peer device exists,
> > we prevent the host peer from being deleted.
> > This patch does this by adding peer_deleted flag in nic state:
> > if host device is going away while guest device
> > is around, set this flag and keep a shell of
> > the host device around for as long as guest device exists.
> > 
> > The link is put down so all packets will get discarded.
> > 
> > At the moment, management can detect that device deletion
> > is delayed by doing info net. As a next step, we shall add
> > commands that control hotplug/unplug without
> > removing the device, and an event to report that
> > guest has responded to the hotplug event.
> > 
> > Signed-off-by: Michael S. Tsirkin 
> > ---
> >  net.c |   40 +---
> >  net.h |1 +
> >  2 files changed, 34 insertions(+), 7 deletions(-)
> > 
> > diff --git a/net.c b/net.c
> > index 3d0fde7..edb87af 100644
> > --- a/net.c
> > +++ b/net.c
> > @@ -281,29 +281,55 @@ NICState *qemu_new_nic(NetClientInfo *info,
> >  return nic;
> >  }
> >  
> > -void qemu_del_vlan_client(VLANClientState *vc)
> > +static void qemu_free_vlan_client(VLANClientState *vc)
> >  {
> >  if (vc->vlan) {
> >  QTAILQ_REMOVE(&vc->vlan->clients, vc, next);
> >  } else {
> > +QTAILQ_REMOVE(&non_vlan_clients, vc, next);
> >  if (vc->send_queue) {
> >  qemu_del_net_queue(vc->send_queue);
> >  }
> > -QTAILQ_REMOVE(&non_vlan_clients, vc, next);
> >  if (vc->peer) {
> >  vc->peer->peer = NULL;
> >  }
> >  }
> > -
> > -if (vc->info->cleanup) {
> > -vc->info->cleanup(vc);
> > -}
> > -
> >  qemu_free(vc->name);
> >  qemu_free(vc->model);
> >  qemu_free(vc);
> >  }
> >  
> > +void qemu_del_vlan_client(VLANClientState *vc)
> > +{
> > +/* If there is a peer NIC, delete and cleanup client, but do not free. 
> > */
> > +if (!vc->vlan && vc->peer && vc->peer->info->type == 
> > NET_CLIENT_TYPE_NIC) {
> > +NICState *nic = DO_UPCAST(NICState, nc, vc->peer);
> > +if (nic->peer_deleted) {
> > +return;
> > +}
> > +nic->peer_deleted = true;
> > +/* Let NIC know peer is gone. */
> > +vc->peer->link_down = true;
> > +if (vc->peer->info->link_status_changed) {
> > +vc->peer->info->link_status_changed(vc->peer);
> 
> Are we potentially introducing more races here?  Now we have the tap
> trying to call link change on a peer device that's potentially in the
> middle of going away.  Thanks,
> 
> Alex

You mean in guest?
This could always happen anyway: user can call link state change
command. So drivers must be ready for this.
There's no race in qemu because everything is singlethreaded.

> > +}
> > +if (vc->info->cleanup) {
> > +vc->info->cleanup(vc);
> > +}
> > +return;
> > +}
> > +
> > +/* If this is a peer NIC and peer has already been deleted, free it 
> > now. */
> > +if (!vc->vlan && vc->peer && vc->info->type == NET_CLIENT_TYPE_NIC) {
> > +NICState *nic = DO_UPCAST(NICState, nc, vc);
> > +if (nic->peer_deleted) {
> > +qemu_free_vlan_client(vc->peer);
> > +}
> > +}
> > +
> > +qemu_free_vlan_client(vc);
> > +}
> > +
> >  VLANClientState *
> >  qemu_find_vlan_client_by_name(Monitor *mon, int vlan_id,
> >const char *client_str)
> > diff --git a/net.h b/net.h
> > index 518cf9c..44c31a9 100644
> > --- a/net.h
> > +++ b/net.h
> > @@ -72,6 +72,7 @@ typedef struct NICState {
> >  VLANClientState nc;
> >  NICConf *conf;
> >  void *opaque;
> > +bool peer_deleted;
> >  } NICState;
> >  
> >  struct VLANState {
> 
> 

[Qemu-devel] KVM call agenda for Sept 28

[Chris Wright]

Please send in any agenda items you are interested in covering.

thanks,
-chris

[Qemu-devel] [Bug 648356] Re: VirtFS possible memory leak in 9p virtio mapped

[Moshroum]

** Description changed:

  I use as client Debian squeeze i386 with a custom kernel:
  Linux (none) 2.6.35.5 #3 Thu Sep 23 18:36:02 UTC 2010 i686 GNU/Linux
  
  And as host Debian squeeze amd64
  Linux asd 2.6.32-5-amd64 #1 SMP Fri Sep 17 21:50:19 UTC 2010 x86_64 GNU/Linux
  
  kvm version is:
  kvm-88-5908-gdd67374
  
  Started the client using:
  sudo /usr/local/kvm/bin/qemu-system-x86_64 -m 1024 -kernel 
linux-2.6.35.5.qemu -drive file=root.img,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=/host,security_model=mapped,mount_tag=host -nographic
  
- 
  I've done following inside the guest:
  
  $  mount -t 9p -o trans=virtio host /mnt
  $ rm -f /mnt/test
  $ touch /mnt/test
  $ ls -l /mnt/test
- $ while true ;do ls -l /host/test > /dev/null; done
+ $ while true ;do ls -l /mnt/test > /dev/null; done
  
  Now I can see on my host system that the memory consumption starts at
  90MB and after a minute it raises to 130MB.  The extra memory
  consumption stops when I stop the while-loop.
  
  $ while true ;do ls -l /tmp > /dev/null; done
  
  Doesn't show that behaviour.

-- 
VirtFS possible memory leak in 9p virtio mapped
https://bugs.launchpad.net/bugs/648356
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 use as client Debian squeeze i386 with a custom kernel:
Linux (none) 2.6.35.5 #3 Thu Sep 23 18:36:02 UTC 2010 i686 GNU/Linux

And as host Debian squeeze amd64
Linux asd 2.6.32-5-amd64 #1 SMP Fri Sep 17 21:50:19 UTC 2010 x86_64 GNU/Linux

kvm version is:
kvm-88-5908-gdd67374

Started the client using:
sudo /usr/local/kvm/bin/qemu-system-x86_64 -m 1024 -kernel linux-2.6.35.5.qemu 
-drive file=root.img,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=/host,security_model=mapped,mount_tag=host -nographic

I've done following inside the guest:

$  mount -t 9p -o trans=virtio host /mnt
$ rm -f /mnt/test
$ touch /mnt/test
$ ls -l /mnt/test
$ while true ;do ls -l /mnt/test > /dev/null; done

Now I can see on my host system that the memory consumption starts at 90MB and 
after a minute it raises to 130MB.  The extra memory consumption stops when I 
stop the while-loop.

$ while true ;do ls -l /tmp > /dev/null; done

Doesn't show that behaviour.

[Qemu-devel] [Bug 648356] Re: VirtFS possible memory leak in 9p virtio mapped

[Moshroum]

Updated to v2.6.36.6 with https://patchwork.kernel.org/patch/127401/ and
it still has the problem. It increases the memory usage not as fast, but
it still quite a lot.

I also tried to mount it using -oversion=9p2000.L

/sys/kernel/debug/kmemleak says on unmount:


unreferenced object 0xf791a870 (size 192):
  comm "swapper", pid 1, jiffies 4294892433 (age 784.692s)
  hex dump (first 32 bytes):
00 00 00 e0 00 00 00 00 ff ff bf fe 00 00 00 00  
00 b9 9d f7 00 02 00 00 6b 6b 6b 6b 6b 6b 6b 6b  
  backtrace:
[] kmemleak_alloc+0x70/0x160
[] __kmalloc+0x254/0x440
[] pci_acpi_scan_root+0x260/0x3b3
[] acpi_pci_root_add+0x295/0x4b7
[] acpi_device_probe+0x72/0x277
[] driver_probe_device+0x135/0x410
[] __driver_attach+0x11f/0x130
[] bus_for_each_dev+0x92/0x110
[] driver_attach+0x27/0x40
[] bus_add_driver+0x1bd/0x4e0
[] driver_register+0xcb/0x290
[] acpi_bus_register_driver+0x55/0x65
[] acpi_pci_root_init+0x47/0x72
[] do_one_initcall+0x3e/0x2c0
[] kernel_init+0x1a6/0x305
[] kernel_thread_helper+0x6/0x14
unreferenced object 0xf79db900 (size 16):
  comm "swapper", pid 1, jiffies 4294892433 (age 784.692s)
  hex dump (first 16 bytes):
50 43 49 20 42 75 73 20 30 30 30 30 3a 30 30 00  PCI Bus :00.
  backtrace:
[] kmemleak_alloc+0x70/0x160
[] __kmalloc+0x254/0x440
[] kvasprintf+0x68/0xd0
[] kasprintf+0x2d/0x50
[] pci_acpi_scan_root+0x2a6/0x3b3
[] acpi_pci_root_add+0x295/0x4b7
[] acpi_device_probe+0x72/0x277
[] driver_probe_device+0x135/0x410
[] __driver_attach+0x11f/0x130
[] bus_for_each_dev+0x92/0x110
[] driver_attach+0x27/0x40
[] bus_add_driver+0x1bd/0x4e0
[] driver_register+0xcb/0x290
[] acpi_bus_register_driver+0x55/0x65
[] acpi_pci_root_init+0x47/0x72
[] do_one_initcall+0x3e/0x2c0
unreferenced object 0xf6a12c60 (size 96):
  comm "mount", pid 1191, jiffies 4294893979 (age 778.536s)
  hex dump (first 32 bytes):
01 00 00 00 ad 4e ad de ff ff ff ff ff ff ff ff  .N..
28 65 11 c2 80 e8 b8 c1 8d 2c 78 c1 00 00 00 00  (e...,x.
  backtrace:
[] kmemleak_alloc+0x70/0x160
[] kmem_cache_alloc+0x21b/0x340
[] p9_idpool_create+0x59/0xf0
[] p9_client_create+0xe2/0x650
[] v9fs_session_init+0x35f/0x890
[] v9fs_get_sb+0xb1/0x440
[] vfs_kern_mount+0xaa/0x240
[] do_kern_mount+0x53/0x1c0
[] do_mount+0x88a/0x10f0
[] sys_mount+0xe2/0x170
[] sysenter_do_call+0x12/0x38
[] 0x
unreferenced object 0xf6bb6cc0 (size 148):
  comm "mount", pid 1191, jiffies 4294893979 (age 778.536s)
  hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  backtrace:
[] kmemleak_alloc+0x70/0x160
[] kmem_cache_alloc+0x21b/0x340
[] idr_pre_get+0x8f/0xd0
[] p9_idpool_get+0x35/0xf0
[] p9_client_create+0x106/0x650
[] v9fs_session_init+0x35f/0x890
[] v9fs_get_sb+0xb1/0x440
[] vfs_kern_mount+0xaa/0x240
[] do_kern_mount+0x53/0x1c0
[] do_mount+0x88a/0x10f0
[] sys_mount+0xe2/0x170
[] sysenter_do_call+0x12/0x38
[] 0x
unreferenced object 0xf6bb6d80 (size 148):
  comm "mount", pid 1191, jiffies 4294893979 (age 778.616s)
  hex dump (first 32 bytes):
00 00 00 00 c0 6c bb f6 00 00 00 00 00 00 00 00  .l..
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  backtrace:
[] kmemleak_alloc+0x70/0x160
[] kmem_cache_alloc+0x21b/0x340
[] idr_pre_get+0x8f/0xd0
[] p9_idpool_get+0x35/0xf0
[] p9_client_create+0x106/0x650
[] v9fs_session_init+0x35f/0x890
[] v9fs_get_sb+0xb1/0x440
[] vfs_kern_mount+0xaa/0x240
[] do_kern_mount+0x53/0x1c0
[] do_mount+0x88a/0x10f0
[] sys_mount+0xe2/0x170
[] sysenter_do_call+0x12/0x38
[] 0x
unreferenced object 0xf6bb6b40 (size 148):
  comm "mount", pid 1191, jiffies 4294893979 (age 778.616s)
  hex dump (first 32 bytes):
00 00 00 00 80 6d bb f6 00 00 00 00 00 00 00 00  .m..
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  backtrace:
[] kmemleak_alloc+0x70/0x160
[] kmem_cache_alloc+0x21b/0x340
[] idr_pre_get+0x8f/0xd0
[] p9_idpool_get+0x35/0xf0
[] p9_client_create+0x106/0x650
[] v9fs_session_init+0x35f/0x890
[] v9fs_get_sb+0xb1/0x440
[] vfs_kern_mount+0xaa/0x240
[] do_kern_mount+0x53/0x1c0
[] do_mount+0x88a/0x10f0
[] sys_mount+0xe2/0x170
[] sysenter_do_call+0x12/0x38
[] 0x
unreferenced object 0xf6bb6e40 (size 148):
  comm "mount", pid 1191, jiffies 4294893979 (age 778.616s)
  hex dump (first 32 bytes):
00 00 00 00 40 6b bb f6 00 00 00 00 00 00 00 00  @k..
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  backtrace:
[] kmemleak_alloc+0x70/0x160
[] kmem_cache_alloc+0x21b/0x340
[] idr_pre_get+0x8f/0xd0
[] p

[Qemu-devel] Re: [PATCH v3 08/13] pcie root port: implement pcie root port.

[Isaku Yamahata]

On Mon, Sep 27, 2010 at 12:40:12PM +0200, Michael S. Tsirkin wrote:
> On Mon, Sep 27, 2010 at 03:22:43PM +0900, Isaku Yamahata wrote:
> > On Sun, Sep 26, 2010 at 02:50:42PM +0200, Michael S. Tsirkin wrote:
> > > On Fri, Sep 24, 2010 at 02:38:09PM +0900, Isaku Yamahata wrote:
> > > > On Wed, Sep 22, 2010 at 01:25:59PM +0200, Michael S. Tsirkin wrote:
> > > > 
> > > > > > +PCIESlot *pcie_root_init(PCIBus *bus, int devfn, bool 
> > > > > > multifunction,
> > > > > > + const char *bus_name, pci_map_irq_fn 
> > > > > > map_irq,
> > > > > > + uint8_t port, uint8_t chassis, uint16_t 
> > > > > > slot);
> > > > > > +
> > > > > 
> > > > > I am a bit unhappy about all these _init functions.
> > > > > Can devices be created with qdev? If they were
> > > > > it would be possible to configure the system completely
> > > > > from qemu command line.
> > > > 
> > > > That's very reasonable question.
> > > > Once machine configuration file is supported, those initialization
> > > > functions will go away.
> > > > I.e. when the initialization code like pc_init1() in pc_piix.c 
> > > > disappears,
> > > > those functions will also go away.
> > > > 
> > > > Until that, those initialization glues will stay like pci_create family
> > > > or other many initialization glues unfortunately.
> > > > This is the result of qdev missing a feature, not the cause.
> > > > It would be a long-term issue to add machine configuration file support.
> > > 
> > > Just to clarify, if I wanted to have a flag to make virtio-net
> > > a pci express device, how would I do this?
> > 
> > the following preparation is needed.
> > - register PCIDeviceInfo with name like "virtio-net-pci-xen"
> >   with PCIDeviceInfo::is_express = true.
> > - in initialization function, initialize express capability.
> > - in write config function, call related function.
> > 
> > And then,
> > if (express)
> >create "virtio-net-pci-xen"
> > else
> >create "virtio-net-pci"
> 
> Sounds pretty bad: we can't double the number of devices
> with each capability we add.
> Can we make it so setting is_express on command line
> will convert the device to PCI express?

I don't see your point. Capability isn't something that should be
genericly customizable.
If any, it would not be a generic option, but one specific to device.
There is no generic way to automatically convert pci device into
express device. It means designing a new express device.

Maybe what you want is
- set is_express = true
  This result in always allocating 4k-sized configuration space.
  (Possibly we need more fine-grained parameter in PCIDeviceInfo
   than is_express.)
- introduce device specific property that a user can turn on/off
- In initialization function/config write function and where necessary,
  check the property.
-- 
yamahata

Re: [Qemu-devel] snapshots

[edison]

QCOW2 snapshots are stored inside the disk image, which is the kind of
internal snapshot.
I had send out a patch
(http://lists.nongnu.org/archive/html/qemu-devel/2010-09/msg01662.html)
last weeks, that can copy the snapshot out of the disk. FYI.

On Sun, Sep 26, 2010 at 10:47 PM, chandra shekar
 wrote:
> hi,everyone i want to change the default location of qemu to store
> snapshots.
> I have searched savem.c file completely and i am unable to find where does
> qemu stores snapshots
> and the relevant code for it plz help anyone,thanks
>
>

Re: [Qemu-devel] [Snapshot Mode]

[edison]

savevm will take disk snapshot also, then you can copy the snapshot
out of disk image to another storage.
I had posted two patches about it:
http://lists.nongnu.org/archive/html/qemu-devel/2010-09/msg01662.html
and http://lists.nongnu.org/archive/html/qemu-devel/2010-09/msg00655.html.
FYI.
BTW, if you just want to try taking online snapshot or bakcup snapshot
on QCOW2, our CloudStack may fit your requirement
(http://git.cloud.com/cloudstack-oss)

On Thu, Sep 23, 2010 at 1:31 PM, Benjamin Kormann  wrote:
> Hi there,
>
> we've been using qemu for quite a while on different platforms and we'd like
> to perform snapshots on running qemu machines and tar them onto a backup
> server.
> The qemu-img snapshot can only be applied to inactive qemu machines
> (images), hence this is not applicable. The savevm command within the qemu
> monitor saves the current cpu state, ram, device state and content of all
> writable disks. After this command has ended the qemu machine is still
> running and a backup (copy or tar of file) can potentially be initiated.
> Since the machine is still up and running changes occur to the qemu image
> and the final backup file might become corrupted if no snapshot
> functionality is supported by the underlying filesystem.
> Finally my question is:
> How can I perform a backup of a system at runtime (at best without the need
> of any filesystem snapshot)?
>
> Thank you very much in advance.
>
> Cheers,
>
>
>    - Benny
>
>
>
>

[Qemu-devel] roby zhou wants to stay in touch on LinkedIn

[roby zhou]

LinkedIn


   
I'd like to add you to my professional network on LinkedIn.

- roby zhou

roby zhou
Solution Engineer at Myriad Group AG 
China

Confirm that you know roby zhou
https://www.linkedin.com/e/-kkb1ec-gem4zced-1/isd/1717720215/2nPlrZr3/


 
-- 
(c) 2010, LinkedIn Corporation

[Qemu-devel] how to add patches

[chandra shekar]

hi everyone i like to add a patch to my qemu but unable to understand
the format that is how do i proceed in adding this patch to my qemu  the
patch is
http://lists.nongnu.org/archive/html/qemu-devel/2010-09/msg01662.html,thanks

[Qemu-devel] Re: x86: PMTIMER calibration sometimes fails

[Thomas De Schampheleire]

Hi,

Can anyone help me with this?

Thanks,  Thomas

On Tue, Sep 21, 2010 at 8:58 AM, Thomas De Schampheleire
 wrote:
> Hi,
>
> I am running an x86 based Linux system under qemu. Linux boots up
> correctly in most cases, however sometimes the PMTIMER fails to
> calibrate correctly:
>
> [    0.00] Fast TSC calibration failed
> [    0.00] TSC: Unable to calibrate against PIT
> [    0.00] TSC: HPET/PMTIMER calibration failed.
> [    0.00] Marking TSC unstable due to could not calculate TSC khz
> [    0.010998] Calibrating delay loop... 1011.71 BogoMIPS (lpj=505856)
>
> while the following messages appears in a good situation:
>
> [    0.00] Fast TSC calibration failed
> [    0.00] TSC: Unable to calibrate against PIT
> [    0.00] TSC: using PMTIMER reference calibration
> [    0.00] Detected 2258.151 MHz processor.
> [    0.009099] Calibrating delay loop (skipped), value calculated
> using timer frequency.. 4516.30 BogoMIPS (lpj=2258151)
>
> HPET is deliberately disabled.
>
> Both situations occur with the same Linux kernel configuration, so I
> am assuming this is a qemu problem.
> I have the impression that in a bad situation, the boot messages
> scroll by slower, indicating a slower emulation than in the good case
> (as the timings seen by the kernel are approximately the same).
>
> Please find in attachment the full boot log of a good and bad
> situation, plus the kernel configuration.
>
> Have you seen this problem before? Do you have any idea how to fix it?
>
> Thanks,
> Thomas
>