[Qemu-devel] [PATCH] configure: fix libcacard check

[Alon Levy]

SRC_PATH is undefined during configure run time, it is only defined in
makefiles generated by it. Replace with source_path which is defined.

Signed-off-by: Alon Levy 
---
 configure |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index 5fcd315..227c7d4 100755
--- a/configure
+++ b/configure
@@ -2653,7 +2653,7 @@ if test "$smartcard" != "no" ; then
 #include 
 int main(void) { PK11_FreeSlot(0); return 0; }
 EOF
-smartcard_cflags="-I\$(SRC_PATH)/libcacard"
+smartcard_cflags="-I$source_path/libcacard"
 libcacard_libs="$($pkg_config --libs nss 2>/dev/null) $glib_libs"
 libcacard_cflags="$($pkg_config --cflags nss 2>/dev/null) $glib_cflags"
 if $pkg_config --atleast-version=3.12.8 nss >/dev/null 2>&1 && \
-- 
1.7.10.1

Re: [Qemu-devel] [PATCH] configure: fix libcacard check

[Peter Maydell]

On 22 July 2012 12:00, Alon Levy  wrote:
> SRC_PATH is undefined during configure run time, it is only defined in
> makefiles generated by it. Replace with source_path which is defined.

There's a (slightly different) patch to address this issue in my
configure series I posted earlier this week:
http://patchwork.ozlabs.org/patch/171698/

-- PMM

Re: [Qemu-devel] [PATCH v7.5] kvm: notify host when the guest is panicked

[Sasha Levin]

On 07/21/2012 10:44 AM, Wen Congyang wrote:
> We can know the guest is panicked when the guest runs on xen.
> But we do not have such feature on kvm.
> 
> Another purpose of this feature is: management app(for example:
> libvirt) can do auto dump when the guest is panicked. If management
> app does not do auto dump, the guest's user can do dump by hand if
> he sees the guest is panicked.
> 
> We have three solutions to implement this feature:
> 1. use vmcall
> 2. use I/O port
> 3. use virtio-serial.
> 
> We have decided to avoid touching hypervisor. The reason why I choose
> choose the I/O port is:
> 1. it is easier to implememt
> 2. it does not depend any virtual device
> 3. it can work when starting the kernel

Was the option of implementing a virtio-watchdog driver considered?

You're basically re-implementing a watchdog, a guest-host interface and a set 
of protocols for guest-host communications.

Why can't we re-use everything we have now, push a virtio watchdog driver into 
drivers/watchdog/, and gain a more complete solution to detecting hangs inside 
the guest.

Re: [Qemu-devel] [PATCH] configure: fix libcacard check

[Alon Levy]

On Sun, Jul 22, 2012 at 12:30:27PM +0100, Peter Maydell wrote:
> On 22 July 2012 12:00, Alon Levy  wrote:
> > SRC_PATH is undefined during configure run time, it is only defined in
> > makefiles generated by it. Replace with source_path which is defined.
> 
> There's a (slightly different) patch to address this issue in my
> configure series I posted earlier this week:
> http://patchwork.ozlabs.org/patch/171698/
> 

Your fix looks fine. I appologize for not checking - wasn't sure if this
happens when not requesting libcacard compilation (via
--enable-smartcard-nss), so didn't think it was already addressed on the
list, my bad.

> -- PMM
> 

Re: [Qemu-devel] [RFC PATCH 0/2] GlusterFS support in QEMU - v2

[Stefan Hajnoczi]

On Sat, Jul 21, 2012 at 9:29 AM, Bharata B Rao
 wrote:
> -drive file=gluster:server@port:volname:image
>
> - Here 'gluster' is the protocol.
> - 'server@port' specifies the server where the volume file specification for
>   the given volume resides. 'port' is the port number on which gluster
>   management daemon (glusterd) is listening. This is optional and if not
>   specified, QEMU will send 0 which will make libgfapi to use the default
>   port.

'server@port' is weird notation.  Normally it is 'server:port' (e.g.
URLs).  Can you change it?

What about the other transports supported by libgfapi: UNIX domain
sockets and RDMA?  My reading of glfs.h is that there are 3 connection
options:
1. 'transport': 'socket' (default), 'unix', 'rdma'
2. 'host': server hostname for 'socket', path to UNIX domain socket
for 'unix', or something else for 'rdma'
3. 'port': TCP port when 'socket' is used.  Ignored otherwise.

Unfortunately QEMU block drivers cannot take custom options yet.  That
would make it possible to cleanly map these connection options and
save you from inventing syntax which doesn't expose all options.

In the meantime it would be nice if the syntax exposed all options.

> Note that we are no longer using volfiles directly and use volume names
> instead. For this to work, gluster management daemon (glusterd) needs to
> be running on the QEMU node. This limits the QEMU user to access the volumes 
> by
> the default volfiles that are generated by gluster CLI. This should be
> fine as long as gluster CLI provides the capability to generate or regenerate
> volume files for a given volume with the xlator set that QEMU user is
> interested in. GlusterFS developers tell me that this can be provided with
> some enhancements to Gluster CLI/glusterd. Note that the custom volume files
> is typically needed when GlusterFS server is co-located with QEMU in
> which case it would  be beneficial to get rid of client-server overhead and
> RPC communication overhead.

My knowledge of GlusterFS is limited.  Here is what I am thinking:

1. The user cannot specify a local configuration file, you require
that there is a glusterd running which provides configuration
information.
2. It is currently not possible to bypass RPC because the glusterd
managed configuration file doesn't support that.

I'm not sure if these statements are true?

Would you support local volfiles in the future again?  Why force users
to run glusterd?

> - As mentioned above, the VM image on gluster volume can be specified like
>   this:
> -drive file=gluster:localhost:testvol:/F17,format=gluster
>
>   Note that format=gluster is not needed ideally and its a work around I have
>   until libgfapi provides a working connection cleanup routine (glfs_fini()).
>   When the format isn't specified, QEMU figures out the format by doing
>   find_image_format that results in one open and close before opening the
>   image file long term for standard read and write. Gluster connection
>   initialization is done from open and connection termination is done from
>   close. But since glfs_fini() isn't working yet, I am bypassing
>   find_image_format by specifying format=gluster directly which results in
>   just one open and hence I am not limited by glfs_fini().

Has libgfapi been released yet?  Does it have versioning which will
allow the QEMU GlusterFS block driver to build against different
versions?  I'm just wondering how the pieces will fit together once
distros start shipping them.

Stefan

Re: [Qemu-devel] question about qemu migrate.

[Sheldon]

On 07/22/2012 12:49 PM, Amos Kong wrote:
On Sun, Jul 22, 2012 at 12:30 PM, Sheldon > wrote:


I find there are four kinds of uri for qmp_migrate
"tcp:", "exec:", "unix:", and "fd:"


now I want to migrate the vm to a local file with "exec:" uri by
hmp-command.

How should I do the migration?


(qemu) migrate -d exec:cat>/tmp/vm.out
 -incoming fd:

thank you. it can work now.
there are still some questions.
1. the migration file vm.out  is  a QEMU suspend to disk image.
How can I reboot vm.out by QEMU?

2. I execute "migrate" with -b option, seems that the "migrate" runs at 
background.
I cat get the "migrate" information by qmp , there is a { "execute": 
"query-migrate" } command in qmp-command.
But I can not get the the "migrate" information by hmp,  there is not a 
"query-migrate" command in hmp-command.

Re: [Qemu-devel] [RFC PATCH 2/2] block: gluster as block backend

[Stefan Hajnoczi]

On Sat, Jul 21, 2012 at 9:31 AM, Bharata B Rao
 wrote:
> +typedef struct GlusterAIOCB {
> +BlockDriverAIOCB common;
> +QEMUIOVector *qiov;

The qiov field is unused.

> +char *bounce;

Unused.

> +struct BDRVGlusterState *s;

You can get this through common.bs->opaque, but if you like having a
shortcut, that's fine.

> +int cancelled;

bool

> +} GlusterAIOCB;
> +
> +typedef struct GlusterCBKData {
> +GlusterAIOCB *acb;
> +struct BDRVGlusterState *s;
> +int64_t size;
> +int ret;
> +} GlusterCBKData;

I think GlusterCBKData could just be part of GlusterAIOCB.  That would
simplify the code a little and avoid some malloc/free.

> +
> +typedef struct BDRVGlusterState {
> +struct glfs *glfs;
> +int fds[2];
> +int open_flags;
> +struct glfs_fd *fd;
> +int qemu_aio_count;
> +int event_reader_pos;
> +GlusterCBKData *event_gcbk;
> +} BDRVGlusterState;
> +
> +#define GLUSTER_FD_READ 0
> +#define GLUSTER_FD_WRITE 1
> +
> +static void qemu_gluster_complete_aio(GlusterCBKData *gcbk)
> +{
> +GlusterAIOCB *acb = gcbk->acb;
> +int ret;
> +
> +if (acb->cancelled) {

Where does cancelled get set?

> +qemu_aio_release(acb);
> +goto done;
> +}
> +
> +if (gcbk->ret == gcbk->size) {
> +ret = 0; /* Success */
> +} else if (gcbk->ret < 0) {
> +ret = gcbk->ret; /* Read/Write failed */
> +} else {
> +ret = -EINVAL; /* Partial read/write - fail it */

EINVAL is for invalid arguments.  EIO would be better.

> +/*
> + * file=protocol:server@port:volname:image
> + */
> +static int qemu_gluster_parsename(GlusterConf *c, const char *filename)
> +{
> +char *file = g_strdup(filename);
> +char *token, *next_token, *saveptr;
> +char *token_s, *next_token_s, *saveptr_s;
> +int ret = -EINVAL;
> +
> +/* Discard the protocol */
> +token = strtok_r(file, ":", &saveptr);
> +if (!token) {
> +goto out;
> +}
> +
> +/* server@port */
> +next_token = strtok_r(NULL, ":", &saveptr);
> +if (!next_token) {
> +goto out;
> +}
> +if (strchr(next_token, '@')) {
> +token_s = strtok_r(next_token, "@", &saveptr_s);
> +if (!token_s) {
> +goto out;
> +}
> +strncpy(c->server, token_s, HOST_NAME_MAX);

strncpy(3) will not NUL-terminate when token_s is HOST_NAME_MAX
characters long.  QEMU has cutils.c:pstrcpy().

When the argument is too long we should probably report an error
instead of truncating.

Same below.

> +next_token_s = strtok_r(NULL, "@", &saveptr_s);
> +if (!next_token_s) {
> +goto out;
> +}
> +c->port = atoi(next_token_s);

No error checking.  If the input is invalid an error message would
help the user here.

> +static struct glfs *qemu_gluster_init(GlusterConf *c, const char *filename)
> +{
> +struct glfs *glfs = NULL;
> +int ret;
> +
> +ret = qemu_gluster_parsename(c, filename);
> +if (ret < 0) {
> +errno = -ret;
> +goto out;
> +}
> +
> +glfs = glfs_new(c->volname);
> +if (!glfs) {
> +goto out;
> +}
> +
> +ret = glfs_set_volfile_server(glfs, "socket", c->server, c->port);
> +if (ret < 0) {
> +goto out;
> +}
> +
> +/*
> + * TODO: Logging is not necessary but instead nice to have.
> + * Can QEMU optionally log into a standard place ?

QEMU prints to stderr, can you do that here too?  The global log file
is not okay, especially when multiple QEMU instances are running.

> + * Need to use defines like gf_loglevel_t:GF_LOG_INFO instead of
> + * hard coded values like 7 here.
> + */
> +ret = glfs_set_logging(glfs, "/tmp/qemu-gluster.log", 7);
> +if (ret < 0) {
> +goto out;
> +}
> +
> +ret = glfs_init(glfs);
> +if (ret < 0) {
> +goto out;
> +}
> +return glfs;
> +
> +out:
> +if (glfs) {
> +(void)glfs_fini(glfs);
> +}
> +return NULL;
> +}
> +
> +static int qemu_gluster_open(BlockDriverState *bs, const char *filename,
> +int bdrv_flags)
> +{
> +BDRVGlusterState *s = bs->opaque;
> +GlusterConf *c = g_malloc(sizeof(GlusterConf));

Can this be allocated on the stack?

> +int ret;
> +
> +s->glfs = qemu_gluster_init(c, filename);
> +if (!s->glfs) {
> +ret = -errno;
> +goto out;
> +}
> +
> +s->open_flags |=  O_BINARY;

Can open_flags be a local variable?

> +static int qemu_gluster_create(const char *filename,
> +QEMUOptionParameter *options)
> +{
> +struct glfs *glfs;
> +struct glfs_fd *fd;
> +GlusterConf *c = g_malloc(sizeof(GlusterConf));
> +int ret = 0;
> +int64_t total_size = 0;
> +
> +glfs = qemu_gluster_init(c, filename);
> +if (!glfs) {
> +ret = -errno;
> +goto out;
> +}
> +
> +/* Read out options */
> +while (options && options->name) {
> +if (!strcmp(options->name, BLOCK_OPT_SIZE)) {
> + 

Re: [Qemu-devel] Qemu-devel Digest, Vol 112, Issue 513

[Paulo Arcinas]

 needed ideally and its a work around
I have
> >   until libgfapi provides a working connection cleanup routine
(glfs_fini()).
> >   When the format isn't specified, QEMU figures out the format by doing
> >   find_image_format that results in one open and close before opening
the
> >   image file long term for standard read and write. Gluster connection
> >   initialization is done from open and connection termination is done
from
> >   close. But since glfs_fini() isn't working yet, I am bypassing
> >   find_image_format by specifying format=gluster directly which results
in
> >   just one open and hence I am not limited by glfs_fini().
>
> Has libgfapi been released yet?  Does it have versioning which will
> allow the QEMU GlusterFS block driver to build against different
> versions?  I'm just wondering how the pieces will fit together once
> distros start shipping them.
>
> Stefan
>
>
>
> --
>
> Message: 6
> Date: Sun, 22 Jul 2012 22:59:43 +0800
> From: Sheldon 
> To: Amos Kong 
> Cc: qemu-devel@nongnu.org, Stefan Hajnoczi
> 
> Subject: Re: [Qemu-devel] question about qemu migrate.
> Message-ID: <500c155f.3020...@linux.vnet.ibm.com>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
> On 07/22/2012 12:49 PM, Amos Kong wrote:
> > On Sun, Jul 22, 2012 at 12:30 PM, Sheldon  > <mailto:shao...@linux.vnet.ibm.com>> wrote:
> >
> > I find there are four kinds of uri for qmp_migrate
> > "tcp:", "exec:", "unix:", and "fd:"
> >
> >
> > now I want to migrate the vm to a local file with "exec:" uri by
> > hmp-command.
> >
> > How should I do the migration?
> >
> >
> > (qemu) migrate -d exec:cat>/tmp/vm.out
> >  -incoming fd:
> thank you. it can work now.
> there are still some questions.
> 1. the migration file vm.out  is  a QEMU suspend to disk image.
> How can I reboot vm.out by QEMU?
>
> 2. I execute "migrate" with -b option, seems that the "migrate" runs at
> background.
> I cat get the "migrate" information by qmp , there is a { "execute":
> "query-migrate" } command in qmp-command.
> But I can not get the the "migrate" information by hmp,  there is not a
> "query-migrate" command in hmp-command.
>
>
>
>
>
>
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
http://lists.nongnu.org/archive/html/qemu-devel/attachments/20120722/bb1ee297/attachment.html
>
>
> --
>
> Message: 7
> Date: Sun, 22 Jul 2012 16:38:00 +0100
> From: Stefan Hajnoczi 
> To: bhar...@linux.vnet.ibm.com
> Cc: Amar Tumballi , Anand Avati
> ,qemu-devel@nongnu.org, Vijay Bellur
> 
> Subject: Re: [Qemu-devel] [RFC PATCH 2/2] block: gluster as block
> backend
> Message-ID:
> 
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Sat, Jul 21, 2012 at 9:31 AM, Bharata B Rao
>  wrote:
> > +typedef struct GlusterAIOCB {
> > +BlockDriverAIOCB common;
> > +QEMUIOVector *qiov;
>
> The qiov field is unused.
>
> > +char *bounce;
>
> Unused.
>
> > +struct BDRVGlusterState *s;
>
> You can get this through common.bs->opaque, but if you like having a
> shortcut, that's fine.
>
> > +int cancelled;
>
> bool
>
> > +} GlusterAIOCB;
> > +
> > +typedef struct GlusterCBKData {
> > +GlusterAIOCB *acb;
> > +struct BDRVGlusterState *s;
> > +int64_t size;
> > +int ret;
> > +} GlusterCBKData;
>
> I think GlusterCBKData could just be part of GlusterAIOCB.  That would
> simplify the code a little and avoid some malloc/free.
>
> > +
> > +typedef struct BDRVGlusterState {
> > +struct glfs *glfs;
> > +int fds[2];
> > +int open_flags;
> > +struct glfs_fd *fd;
> > +int qemu_aio_count;
> > +int event_reader_pos;
> > +GlusterCBKData *event_gcbk;
> > +} BDRVGlusterState;
> > +
> > +#define GLUSTER_FD_READ 0
> > +#define GLUSTER_FD_WRITE 1
> > +
> > +static void qemu_gluster_complete_aio(GlusterCBKData *gcbk)
> > +{
> > +GlusterAIOCB *acb = gcbk->acb;
> > +int ret;
> > +
> > +if (acb->cancelled) {
>
> Where does cancelled get set?
>
> > +qemu_aio_release(acb);
> > +goto done;
> > +}
> > +
> > +if (gcbk->ret

Re: [Qemu-devel] [PATCH v7.5] kvm: notify host when the guest is panicked

[Anthony Liguori]

Sasha Levin  writes:

> On 07/21/2012 10:44 AM, Wen Congyang wrote:
>> We can know the guest is panicked when the guest runs on xen.
>> But we do not have such feature on kvm.
>> 
>> Another purpose of this feature is: management app(for example:
>> libvirt) can do auto dump when the guest is panicked. If management
>> app does not do auto dump, the guest's user can do dump by hand if
>> he sees the guest is panicked.
>> 
>> We have three solutions to implement this feature:
>> 1. use vmcall
>> 2. use I/O port
>> 3. use virtio-serial.
>> 
>> We have decided to avoid touching hypervisor. The reason why I choose
>> choose the I/O port is:
>> 1. it is easier to implememt
>> 2. it does not depend any virtual device
>> 3. it can work when starting the kernel
>
> Was the option of implementing a virtio-watchdog driver considered?
>
> You're basically re-implementing a watchdog, a guest-host interface and a set 
> of protocols for guest-host communications.
>
> Why can't we re-use everything we have now, push a virtio watchdog
> driver into drivers/watchdog/, and gain a more complete solution to
> detecting hangs inside the guest.

The purpose of virtio is not to reinvent every possible type of device.
There are plenty of hardware watchdogs that are very suitable to be used
for this purpose.  QEMU implements quite a few already.

Watchdogs are not performance sensitive so there's no point in using
virtio.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH v7] kvm: notify host when the guest is panicked

[Anthony Liguori]

Sasha Levin  writes:

> On 07/21/2012 09:12 AM, Wen Congyang wrote:
>> +#define KVM_PV_PORT (0x505UL)
>> +
>>  #ifdef __KERNEL__
>>  #include 
>>  
>> @@ -221,6 +223,11 @@ static inline void kvm_disable_steal_time(void)
>>  }
>>  #endif
>>  
>> +static inline unsigned int kvm_arch_pv_features(void)
>> +{
>> +return inl(KVM_PV_PORT);
>> +}
>> +
>
> Why is this safe?
>
> I'm not sure you can just pick any ioport you'd like and use it.

There are three ways I/O ports get used on a PC:

1) Platform devices
 - This is well defined since the vast majority of platform devices are
   implemented within a single chip.  If you're emulating an i440fx
   chipset, the PIIX4 spec has an exhaustive list.

2) PCI devices
 - Typically, PCI only allocates ports starting at 0x0d00 to avoid
   conflicts with ISA devices.

3) ISA devices
 - ISA uses subtractive decoding so any ISA device can access.  In
   theory, an ISA device could attempt to use port 0x0505 but it's
   unlikely.  In a modern guest, there aren't really any ISA devices being
   added either.

So yes, picking port 0x0505 is safe for something like this (as long as
you check to make sure that you really are under KVM).

Regards,

Anthony Liguori

> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Qemu-devel] [PATCH v7.5] kvm: notify host when the guest is panicked

[Sasha Levin]

On 07/22/2012 09:14 PM, Anthony Liguori wrote:
> Sasha Levin  writes:
> 
>> On 07/21/2012 10:44 AM, Wen Congyang wrote:
>>> We can know the guest is panicked when the guest runs on xen.
>>> But we do not have such feature on kvm.
>>>
>>> Another purpose of this feature is: management app(for example:
>>> libvirt) can do auto dump when the guest is panicked. If management
>>> app does not do auto dump, the guest's user can do dump by hand if
>>> he sees the guest is panicked.
>>>
>>> We have three solutions to implement this feature:
>>> 1. use vmcall
>>> 2. use I/O port
>>> 3. use virtio-serial.
>>>
>>> We have decided to avoid touching hypervisor. The reason why I choose
>>> choose the I/O port is:
>>> 1. it is easier to implememt
>>> 2. it does not depend any virtual device
>>> 3. it can work when starting the kernel
>>
>> Was the option of implementing a virtio-watchdog driver considered?
>>
>> You're basically re-implementing a watchdog, a guest-host interface and a 
>> set of protocols for guest-host communications.
>>
>> Why can't we re-use everything we have now, push a virtio watchdog
>> driver into drivers/watchdog/, and gain a more complete solution to
>> detecting hangs inside the guest.
> 
> The purpose of virtio is not to reinvent every possible type of device.
> There are plenty of hardware watchdogs that are very suitable to be used
> for this purpose.  QEMU implements quite a few already.
> 
> Watchdogs are not performance sensitive so there's no point in using
> virtio.

The issue here is not performance, but the adding of a brand new guest-host 
interface.

virtio-rng isn't performance sensitive either, yet it was implemented using 
virtio so there wouldn't be yet another interface to communicate between guest 
and host.

This patch goes ahead to add a "arch pv features" interface using ioports, 
without any idea what it might be used for beyond this watchdog.

Re: [Qemu-devel] [PATCH v7] kvm: notify host when the guest is panicked

[Sasha Levin]

On 07/22/2012 09:22 PM, Anthony Liguori wrote:
> Sasha Levin  writes:
> 
>> On 07/21/2012 09:12 AM, Wen Congyang wrote:
>>> +#define KVM_PV_PORT(0x505UL)
>>> +
>>>  #ifdef __KERNEL__
>>>  #include 
>>>  
>>> @@ -221,6 +223,11 @@ static inline void kvm_disable_steal_time(void)
>>>  }
>>>  #endif
>>>  
>>> +static inline unsigned int kvm_arch_pv_features(void)
>>> +{
>>> +   return inl(KVM_PV_PORT);
>>> +}
>>> +
>>
>> Why is this safe?
>>
>> I'm not sure you can just pick any ioport you'd like and use it.
> 
> There are three ways I/O ports get used on a PC:
> 
> 1) Platform devices
>  - This is well defined since the vast majority of platform devices are
>implemented within a single chip.  If you're emulating an i440fx
>chipset, the PIIX4 spec has an exhaustive list.
> 
> 2) PCI devices
>  - Typically, PCI only allocates ports starting at 0x0d00 to avoid
>conflicts with ISA devices.
> 
> 3) ISA devices
>  - ISA uses subtractive decoding so any ISA device can access.  In
>theory, an ISA device could attempt to use port 0x0505 but it's
>unlikely.  In a modern guest, there aren't really any ISA devices being
>added either.
> 
> So yes, picking port 0x0505 is safe for something like this (as long as
> you check to make sure that you really are under KVM).

Is there anything that actually prevents me from using PCI ports lower than 
0x0d00? As you said in (3), ISA isn't really used anymore (nor is implemented 
by lkvm for example), so placing PCI below 0x0d00 might even make sense in that 
case.

Furthermore, I can place one of these brand new virtio-mmio devices which got 
introduced recently wherever I want right now - Having a device that uses 0x505 
would cause a pretty non-obvious failure mode.

Either way, If we are going to grab an ioport, then:

 - It should be documented well somewhere in Documentation/virt/kvm
 - It should go through request_region() to actually claim those ioports.
 - It should fail gracefully if that port is taken for some reason, instead of 
not even checking it.

Re: [Qemu-devel] [PATCH v7] kvm: notify host when the guest is panicked

[Sasha Levin]

On 07/22/2012 10:19 PM, Sasha Levin wrote:
> On 07/22/2012 09:22 PM, Anthony Liguori wrote:
>> Sasha Levin  writes:
>>
>>> On 07/21/2012 09:12 AM, Wen Congyang wrote:
 +#define KVM_PV_PORT   (0x505UL)
 +
  #ifdef __KERNEL__
  #include 
  
 @@ -221,6 +223,11 @@ static inline void kvm_disable_steal_time(void)
  }
  #endif
  
 +static inline unsigned int kvm_arch_pv_features(void)
 +{
 +  return inl(KVM_PV_PORT);
 +}
 +
>>>
>>> Why is this safe?
>>>
>>> I'm not sure you can just pick any ioport you'd like and use it.
>>
>> There are three ways I/O ports get used on a PC:
>>
>> 1) Platform devices
>>  - This is well defined since the vast majority of platform devices are
>>implemented within a single chip.  If you're emulating an i440fx
>>chipset, the PIIX4 spec has an exhaustive list.
>>
>> 2) PCI devices
>>  - Typically, PCI only allocates ports starting at 0x0d00 to avoid
>>conflicts with ISA devices.
>>
>> 3) ISA devices
>>  - ISA uses subtractive decoding so any ISA device can access.  In
>>theory, an ISA device could attempt to use port 0x0505 but it's
>>unlikely.  In a modern guest, there aren't really any ISA devices being
>>added either.
>>
>> So yes, picking port 0x0505 is safe for something like this (as long as
>> you check to make sure that you really are under KVM).
> 
> Is there anything that actually prevents me from using PCI ports lower than 
> 0x0d00? As you said in (3), ISA isn't really used anymore (nor is implemented 
> by lkvm for example), so placing PCI below 0x0d00 might even make sense in 
> that case.
> 
> Furthermore, I can place one of these brand new virtio-mmio devices which got 
> introduced recently wherever I want right now - Having a device that uses 
> 0x505 would cause a pretty non-obvious failure mode.
> 
> Either way, If we are going to grab an ioport, then:
> 
>  - It should be documented well somewhere in Documentation/virt/kvm
>  - It should go through request_region() to actually claim those ioports.
>  - It should fail gracefully if that port is taken for some reason, instead 
> of not even checking it.
> 

Out of curiosity I tested that, and apparently lkvm has no problem allocating 
virtio-pci devices in that range:

sh-4.2# pwd
/sys/devices/pci:00/:00:01.0
sh-4.2# cat resource | head -n1
0x0500 0x05ff 0x00040101

This was with the commit in question applied.

Re: [Qemu-devel] [PATCH v7] kvm: notify host when the guest is panicked

[Anthony Liguori]

Sasha Levin  writes:

> On 07/22/2012 09:22 PM, Anthony Liguori wrote:
>> Sasha Levin  writes:
>> 
>>> On 07/21/2012 09:12 AM, Wen Congyang wrote:
 +#define KVM_PV_PORT   (0x505UL)
 +
  #ifdef __KERNEL__
  #include 
  
 @@ -221,6 +223,11 @@ static inline void kvm_disable_steal_time(void)
  }
  #endif
  
 +static inline unsigned int kvm_arch_pv_features(void)
 +{
 +  return inl(KVM_PV_PORT);
 +}
 +
>>>
>>> Why is this safe?
>>>
>>> I'm not sure you can just pick any ioport you'd like and use it.
>> 
>> There are three ways I/O ports get used on a PC:
>> 
>> 1) Platform devices
>>  - This is well defined since the vast majority of platform devices are
>>implemented within a single chip.  If you're emulating an i440fx
>>chipset, the PIIX4 spec has an exhaustive list.
>> 
>> 2) PCI devices
>>  - Typically, PCI only allocates ports starting at 0x0d00 to avoid
>>conflicts with ISA devices.
>> 
>> 3) ISA devices
>>  - ISA uses subtractive decoding so any ISA device can access.  In
>>theory, an ISA device could attempt to use port 0x0505 but it's
>>unlikely.  In a modern guest, there aren't really any ISA devices being
>>added either.
>> 
>> So yes, picking port 0x0505 is safe for something like this (as long as
>> you check to make sure that you really are under KVM).
>
> Is there anything that actually prevents me from using PCI ports lower
> than 0x0d00? As you said in (3), ISA isn't really used anymore (nor is
> implemented by lkvm for example), so placing PCI below 0x0d00 might
> even make sense in that case.

On modern systems, the OS goes by whatever is in the ACPI table
describing the PCI bus.  In QEMU, we have:

WordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange,
  0x, // Address Space Granularity
  0x0D00, // Address Range Minimum
  0x, // Address Range Maximum
  0x, // Address Translation Offset
  0xF300, // Address Length
  ,, , TypeStatic)

So Linux will always use 0x0D00 -> 0x for the valid
range. Practically speaking, you can't use anything below 0x0D00 because
the PCI bus configuration registers live at 0xCF8-0xCFF.  If you tried
to create the region starting at 0x0500 you'd have to limit it to 0xCF8
to avoid conflicting with the PCI host controller.

That's not a useful amount of space for I/O ports so that would be a
pretty dumb thing to do.

> Furthermore, I can place one of these brand new virtio-mmio devices
> which got introduced recently wherever I want right now - Having a
> device that uses 0x505 would cause a pretty non-obvious failure mode.

I think you're confusing PIO with MMIO.  They are separate address
spaces.

You could certainly argue that relying on PIO is way too architecture
specific since that's only available on x86.  That's a good argument but
the counter is that other architectures have their own interfaces for
this sort of thing.

> Either way, If we are going to grab an ioport, then:
>
>  - It should be documented well somewhere in Documentation/virt/kvm
>  - It should go through request_region() to actually claim those ioports.
>  - It should fail gracefully if that port is taken for some reason,
>  instead of not even checking it.

I agree with the above.

Regards,

Anthony Liguori

Re: [Qemu-devel] question about qemu migrate.

[Amos Kong]

On Sun, Jul 22, 2012 at 10:59 PM, Sheldon  wrote:
>
>
> (qemu) migrate -d exec:cat>/tmp/vm.out
>  -incoming fd:
> thank you. it can work now.
> there are still some questions.
> 1. the migration file vm.out is a QEMU suspend to disk image.
> How can I reboot vm.out by QEMU?


Load the suspend vm.out by  # qemu-kvm  incoming fd/tmp/vm.out2

Is it satisfied for you?


> 2. I execute "migrate" with -b option, seems that the "migrate" runs
> at background.
> I cat get the "migrate" information by qmp , there is a { "execute":
> "query-migrate" } command in qmp-command.


> But I can not get the the "migrate" information by hmp, there is not
> a "query-migrate" command in hmp-command.

(qemu) info migrate

info commands(for hmp) always correspond with query commands(for qmp),
some query-cmds are not implemented right now (eg. query-network)


hmpqmp
------
info status -> query-status
info block  -> query-block
info pci-> query-pci

Re: [Qemu-devel] [PATCH v7] kvm: notify host when the guest is panicked

[Anthony Liguori]

Sasha Levin  writes:

> On 07/22/2012 10:19 PM, Sasha Levin wrote:
>> On 07/22/2012 09:22 PM, Anthony Liguori wrote:
>>> Sasha Levin  writes:
>>>
 On 07/21/2012 09:12 AM, Wen Congyang wrote:
> +#define KVM_PV_PORT  (0x505UL)
> +
>  #ifdef __KERNEL__
>  #include 
>  
> @@ -221,6 +223,11 @@ static inline void kvm_disable_steal_time(void)
>  }
>  #endif
>  
> +static inline unsigned int kvm_arch_pv_features(void)
> +{
> + return inl(KVM_PV_PORT);
> +}
> +

 Why is this safe?

 I'm not sure you can just pick any ioport you'd like and use it.
>>>
>>> There are three ways I/O ports get used on a PC:
>>>
>>> 1) Platform devices
>>>  - This is well defined since the vast majority of platform devices are
>>>implemented within a single chip.  If you're emulating an i440fx
>>>chipset, the PIIX4 spec has an exhaustive list.
>>>
>>> 2) PCI devices
>>>  - Typically, PCI only allocates ports starting at 0x0d00 to avoid
>>>conflicts with ISA devices.
>>>
>>> 3) ISA devices
>>>  - ISA uses subtractive decoding so any ISA device can access.  In
>>>theory, an ISA device could attempt to use port 0x0505 but it's
>>>unlikely.  In a modern guest, there aren't really any ISA devices being
>>>added either.
>>>
>>> So yes, picking port 0x0505 is safe for something like this (as long as
>>> you check to make sure that you really are under KVM).
>> 
>> Is there anything that actually prevents me from using PCI ports lower than 
>> 0x0d00? As you said in (3), ISA isn't really used anymore (nor is 
>> implemented by lkvm for example), so placing PCI below 0x0d00 might even 
>> make sense in that case.
>> 
>> Furthermore, I can place one of these brand new virtio-mmio devices which 
>> got introduced recently wherever I want right now - Having a device that 
>> uses 0x505 would cause a pretty non-obvious failure mode.
>> 
>> Either way, If we are going to grab an ioport, then:
>> 
>>  - It should be documented well somewhere in Documentation/virt/kvm
>>  - It should go through request_region() to actually claim those ioports.
>>  - It should fail gracefully if that port is taken for some reason, instead 
>> of not even checking it.
>> 
>
> Out of curiosity I tested that, and apparently lkvm has no problem allocating 
> virtio-pci devices in that range:
>
> sh-4.2# pwd
> /sys/devices/pci:00/:00:01.0
> sh-4.2# cat resource | head -n1
> 0x0500 0x05ff 0x00040101
>
> This was with the commit in question applied.

With all due respect, lkvm has a half-baked implementation of PCI.  This
is why you have to pass kernel parameters to disable ACPI and disable
PCI BIOS probing.

So yeah, you can do funky things in lkvm but that doesn't mean a system
that emulated actual hardware would ever do that.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH v7.5] kvm: notify host when the guest is panicked

[Anthony Liguori]

Sasha Levin  writes:

> On 07/22/2012 09:14 PM, Anthony Liguori wrote:
>> Sasha Levin  writes:
>> 
>>> On 07/21/2012 10:44 AM, Wen Congyang wrote:
 We can know the guest is panicked when the guest runs on xen.
 But we do not have such feature on kvm.

 Another purpose of this feature is: management app(for example:
 libvirt) can do auto dump when the guest is panicked. If management
 app does not do auto dump, the guest's user can do dump by hand if
 he sees the guest is panicked.

 We have three solutions to implement this feature:
 1. use vmcall
 2. use I/O port
 3. use virtio-serial.

 We have decided to avoid touching hypervisor. The reason why I choose
 choose the I/O port is:
 1. it is easier to implememt
 2. it does not depend any virtual device
 3. it can work when starting the kernel
>>>
>>> Was the option of implementing a virtio-watchdog driver considered?
>>>
>>> You're basically re-implementing a watchdog, a guest-host interface and a 
>>> set of protocols for guest-host communications.
>>>
>>> Why can't we re-use everything we have now, push a virtio watchdog
>>> driver into drivers/watchdog/, and gain a more complete solution to
>>> detecting hangs inside the guest.
>> 
>> The purpose of virtio is not to reinvent every possible type of device.
>> There are plenty of hardware watchdogs that are very suitable to be used
>> for this purpose.  QEMU implements quite a few already.
>> 
>> Watchdogs are not performance sensitive so there's no point in using
>> virtio.
>
> The issue here is not performance, but the adding of a brand new
> guest-host interface.

We have:

1) Virtio--this is our preferred PV interface.  It needs PCI to be fully
initialized and probably will live as a module.

2) Hypercalls--this a secondary PV interface but is available very
early.  It's terminated in kvm.ko which means it can only operate on
things that are logically part of the CPU and/or APIC complex.

This patch introduces a third interface which is available early like
hypercalls but not necessarily terminated in kvm.ko.  That means it can
have a broader scope in functionality than (2).

We could just as well use a hypercall and have multiple commands issued
to that hypercall as a convention and add a new exit type to KVM that
sent that specific hypercall to userspace for processing.

But a PIO operation already has this behavior and requires no changes to kvm.ko.

> virtio-rng isn't performance sensitive either, yet it was implemented
> using virtio so there wouldn't be yet another interface to communicate
> between guest and host.

There isn't really an obvious discrete RNG that is widely supported.

> This patch goes ahead to add a "arch pv features" interface using
> ioports, without any idea what it might be used for beyond this
> watchdog.

It's not a watchdog--it's the opposite of a watchdog.

You know such a thing already exists in the kernel, right?  S390 has had
a hypercall like this for years.

Regards,

Anthony Liguori

[Qemu-devel] Closing an opened telnet monitor?

[Erik Rull]

Hi all,

how can I close an open telnet session to my qemu monitor? I didn't find 
any possiblity beside killing my telnet client on my remote connected system.


Is there a "nicer" way of doing that? "quit" is definitively the wrong 
command :-)


Thanks.

Best regards,

Erik

Re: [Qemu-devel] Disabling Console Switch using Ctrl + Alt + 2

[Erik Rull]

Paolo Bonzini wrote:

Il 16/07/2012 08:47, Erik Rull ha scritto:



how can I disable a switch to the "parallel0" console when accidentially
pressing Ctrl + Alt + 2?

I don't need such a feature and it confuses some users of the running guest
system (some language layouts have the @ placed on the 2 where you need to
access either with AltGr or Ctrl + Alt).


You can just disable the parallel port with "-parallel none".

Paolo



Thanks - and this seems to be included when using -nodefaults, which does 
even more for me :-)


Best regards,

Erik

Re: [Qemu-devel] [PATCH v7] kvm: notify host when the guest is panicked

[Sasha Levin]

On 07/23/2012 12:29 AM, Anthony Liguori wrote:
> Sasha Levin  writes:
> 
>> On 07/22/2012 10:19 PM, Sasha Levin wrote:
>>> On 07/22/2012 09:22 PM, Anthony Liguori wrote:
 Sasha Levin  writes:

> On 07/21/2012 09:12 AM, Wen Congyang wrote:
>> +#define KVM_PV_PORT (0x505UL)
>> +
>>  #ifdef __KERNEL__
>>  #include 
>>  
>> @@ -221,6 +223,11 @@ static inline void kvm_disable_steal_time(void)
>>  }
>>  #endif
>>  
>> +static inline unsigned int kvm_arch_pv_features(void)
>> +{
>> +return inl(KVM_PV_PORT);
>> +}
>> +
>
> Why is this safe?
>
> I'm not sure you can just pick any ioport you'd like and use it.

 There are three ways I/O ports get used on a PC:

 1) Platform devices
  - This is well defined since the vast majority of platform devices are
implemented within a single chip.  If you're emulating an i440fx
chipset, the PIIX4 spec has an exhaustive list.

 2) PCI devices
  - Typically, PCI only allocates ports starting at 0x0d00 to avoid
conflicts with ISA devices.

 3) ISA devices
  - ISA uses subtractive decoding so any ISA device can access.  In
theory, an ISA device could attempt to use port 0x0505 but it's
unlikely.  In a modern guest, there aren't really any ISA devices being
added either.

 So yes, picking port 0x0505 is safe for something like this (as long as
 you check to make sure that you really are under KVM).
>>>
>>> Is there anything that actually prevents me from using PCI ports lower than 
>>> 0x0d00? As you said in (3), ISA isn't really used anymore (nor is 
>>> implemented by lkvm for example), so placing PCI below 0x0d00 might even 
>>> make sense in that case.
>>>
>>> Furthermore, I can place one of these brand new virtio-mmio devices which 
>>> got introduced recently wherever I want right now - Having a device that 
>>> uses 0x505 would cause a pretty non-obvious failure mode.
>>>
>>> Either way, If we are going to grab an ioport, then:
>>>
>>>  - It should be documented well somewhere in Documentation/virt/kvm
>>>  - It should go through request_region() to actually claim those ioports.
>>>  - It should fail gracefully if that port is taken for some reason, instead 
>>> of not even checking it.
>>>
>>
>> Out of curiosity I tested that, and apparently lkvm has no problem 
>> allocating virtio-pci devices in that range:
>>
>> sh-4.2# pwd
>> /sys/devices/pci:00/:00:01.0
>> sh-4.2# cat resource | head -n1
>> 0x0500 0x05ff 0x00040101
>>
>> This was with the commit in question applied.
> 
> With all due respect, lkvm has a half-baked implementation of PCI.  This
> is why you have to pass kernel parameters to disable ACPI and disable
> PCI BIOS probing.
> 
> So yeah, you can do funky things in lkvm but that doesn't mean a system
> that emulated actual hardware would ever do that.

We disable ACPI simply because we don't support it. MPtable is a perfectly 
valid mechanism to do everything we need so far, so implementing ACPI didn't 
interest either of us too much. What's more - why implement a "complete design 
disaster in every way" ;)

Regarding PCI probing, while we do force the use of direct memory probing this 
is because we lack anything which reassembles a BIOS. Like the above, this 
wasn't too interesting in a virtualized environment, and the kernel is pretty 
happy running without it. PCI probing does happen in a standard way.

I think that the interesting part in that test was not that you could actually 
put a PCI device in the 0x500 range, but that nothing failed and no one yelled 
at me (with the panic commit applied).

I'm not worried about port 0x505 being taken, I'm worried that it'll silently 
break a (although not very common/reasonable/typical) perfectly valid use case.

Re: [Qemu-devel] [PATCH v7.5] kvm: notify host when the guest is panicked

[Sasha Levin]

On 07/23/2012 12:36 AM, Anthony Liguori wrote:
> Sasha Levin  writes:
> 
>> On 07/22/2012 09:14 PM, Anthony Liguori wrote:
>>> Sasha Levin  writes:
>>>
 On 07/21/2012 10:44 AM, Wen Congyang wrote:
> We can know the guest is panicked when the guest runs on xen.
> But we do not have such feature on kvm.
>
> Another purpose of this feature is: management app(for example:
> libvirt) can do auto dump when the guest is panicked. If management
> app does not do auto dump, the guest's user can do dump by hand if
> he sees the guest is panicked.
>
> We have three solutions to implement this feature:
> 1. use vmcall
> 2. use I/O port
> 3. use virtio-serial.
>
> We have decided to avoid touching hypervisor. The reason why I choose
> choose the I/O port is:
> 1. it is easier to implememt
> 2. it does not depend any virtual device
> 3. it can work when starting the kernel

 Was the option of implementing a virtio-watchdog driver considered?

 You're basically re-implementing a watchdog, a guest-host interface and a 
 set of protocols for guest-host communications.

 Why can't we re-use everything we have now, push a virtio watchdog
 driver into drivers/watchdog/, and gain a more complete solution to
 detecting hangs inside the guest.
>>>
>>> The purpose of virtio is not to reinvent every possible type of device.
>>> There are plenty of hardware watchdogs that are very suitable to be used
>>> for this purpose.  QEMU implements quite a few already.
>>>
>>> Watchdogs are not performance sensitive so there's no point in using
>>> virtio.
>>
>> The issue here is not performance, but the adding of a brand new
>> guest-host interface.
> 
> We have:
> 
> 1) Virtio--this is our preferred PV interface.  It needs PCI to be fully
> initialized and probably will live as a module.
> 
> 2) Hypercalls--this a secondary PV interface but is available very
> early.  It's terminated in kvm.ko which means it can only operate on
> things that are logically part of the CPU and/or APIC complex.
> 
> This patch introduces a third interface which is available early like
> hypercalls but not necessarily terminated in kvm.ko.  That means it can
> have a broader scope in functionality than (2).
> 
> We could just as well use a hypercall and have multiple commands issued
> to that hypercall as a convention and add a new exit type to KVM that
> sent that specific hypercall to userspace for processing.
> 
> But a PIO operation already has this behavior and requires no changes to 
> kvm.ko.

I don't dispute that there may be a need for another guest-host interface, but 
this patch can basically be called "kvm: notify host when the guest is 
panicked, oh, btw, and add a brand new undocumented interface"

The new interface should at least come in it's own patch, with documentation.

Re: [Qemu-devel] [PATCH 2/2] vexpress: Add NOR1 Flash support

[Peter Crosthwaite]

On Sat, Jul 21, 2012 at 12:56 AM, jagan <402ja...@gmail.com> wrote:
> Thanks for your info, In fact I was thinking about to use
> drive_get(IF_PFLASH, 0, 0) for first and drive_get(IF_PFLASH, 0, 1)  also.
>
> But the point I was still uncover is even I was using  drive_get(IF_PFLASH,
> 0, 0)   on both the flashes, If I tested through u-boot
> I was able to detect two flashes and able to write, read and erase
>

Yes that right. It will work, but not across boots.

> here are my test procedure:
> ---
> $ qemu-system-arm -M vexpress-a9 -net nic -net tap,ifname=tap0 -kernel

Here, you have no -pflash argument, so there in no bdrv storage file
for your pflash. It will work but any data you write will be lost when
you close QEMU.

> u-boot -nographic
>
> /* writing kernel on to flash0, with 0x4004 offset */
> VExpress# tftp 0x60008000 uImage-vexp
> VExpress# erase all
> VExpress# cp.b 0x60008000 0x4004 ${filesize}
>
> /* writing ramdisk on to flash1, with 0x4544 offset */
> VExpress# tftp 0x6010 ramdisk16M.img.gz
> VExpress# cp.b 0x6010 0x4544 ${filesize}
>
> /* Reading from flash0, flash1 and boot */
> VExpress# cp 0x4004 0x6100 ${filesize}
> VExpress# cp 0x4544 0x6080 ${filesize}
> VExpress# bootm 0x6100
>
> Please let me know for any issue on my testing.let me know you want the boot
> logs.

This is fine, just make the suggested drive_get_next() change, as that
will allow you to keep your flash data from one qemu run to the next.

Heres a test sequence to illustrate what we are getting at:

1. make some binary files, nor1.bin, nor2.bin, with random/zero/one data
2. qemu-system-arm -M vexpress-a9 -net nic -net tap,ifname=tap0
-kernel -pflash ./nor0.bin -pflash ./nor1.bin ...
3. Get u-boot to write two different things to the two different flashes.
4. Close QEMU.
5. run QEMU again, same cmd line as step 2
6. get u-boot (or whatever) to read back contents both flashes.
7. verify data is the same as written in step 3.

Regards,
Peter

>
> Regards,
> Jagan.
>
>
> On Fri, Jul 20, 2012 at 7:49 PM, Igor Mitsyanko 
> wrote:
>>
>> On 07/20/2012 05:30 PM, jagan wrote:
>>
>> I think I understand the situation, like when I called
>> pflash_cfi01_register, it verifies BlockDriverState is < 0.
>> Was my understanding correct?
>>
>> If ie so. I think I need to change  drive_get(IF_PFLASH, 0, 0)  to
>> drive_get_next(IF_PFLASH) on second flash access by keeping
>> drive_get(IF_PFLASH, 0, 0
>> on first flash, correct?
>>
>> But I am wondering why it's still detecting 2 Flashes with 128MB when I
>> tested through u-boot.
>> Even I was written Linux and Ramdisk on to flashes again read back and
>> able to boot it, Fine.
>>
>> Please find the attachment for u-boot log.
>>
>> I haven't tested -pflash argument through ./qemu-system-arm because it
>> again asking about kernel argument, do I need to test this also?
>>
>>
>> Now I understand why QEMU didn't abort during your test, If you do not
>> specify a -pflash argument then there is no backing drive for any of flash
>> banks and they just behave as read-only RAM regions, and in that case it
>> doesn't matter whether you used drive_get(IF_PFLASH, 0, 0) or
>> drive_get_next(IF_PFLASH) or nothing at all. U-boot should detect both banks
>> without any problem, but he wouldn't be able to write anything to them.
>> As Peter already said, you need to use drive_get_next(IF_PFLASH) for both
>> flash banks initialization, or use drive_get(IF_PFLASH, 0, 0) for first and
>> drive_get(IF_PFLASH, 0, 1) for second bank.
>>
>>
>>
>> Regards,
>> Jagan.
>>
>> On Fri, Jul 20, 2012 at 6:58 AM, Peter Crosthwaite
>>  wrote:
>>>
>>> On Thu, Jul 19, 2012 at 7:16 PM, jagan <402ja...@gmail.com> wrote:
>>> > Yes, I have used same  drive_get(IF_PFLASH, 0, 0) with two flashes.
>>> > As these flashes are two different banks with individual bases address,
>>> > I
>>> > used the same.
>>> >
>>> > Was there any block allocation problem with this..will you please
>>> > elaborate.
>>> > I couldn't understand about drive_get_next(),
>>>
>>> s/drive_get(IF_PFLASH, 0, 0) /drive_get_next(IF_PFLASH)/
>>>
>>> This will mean you have two -fplash arguments on qemu cmd line your two
>>> flashes.
>>>
>>> qemu-system-arm ... -pflash nor0.bin -pflash nor1.bin
>>>
>>> Currently you back (or attempt to back) both flashes to the same bdrv
>>> which means they share storage. The two flashes will corrupt each
>>> others data.
>>>
>>> Regards,
>>> Peter
>>>
>>>  I think function can be useful
>>> > single drive devices SD/MTD.
>>> >
>>> > Please suggest your comments.
>>> >
>>> > Regards,
>>> > Jagan.
>>> >
>>> > On Thu, Jul 19, 2012 at 5:27 AM, Peter Crosthwaite
>>> >  wrote:
>>> >>
>>> >> On Thu, Jul 19, 2012 at 5:03 AM,  <402ja...@gmail.com> wrote:
>>> >> > From: Jagan <402ja...@gmail.com>
>>> >> >
>>> >> > This patch adds support for NOR1 flash (Bank #2) on
>>> >> > vexpress-a9 platform. It is 64MB CFI01 compliant flash.
>>> >> >
>>> >> > Tested

Re: [Qemu-devel] [PATCH v7.5] kvm: notify host when the guest is panicked

[Wen Congyang]

At 07/22/2012 07:39 PM, Sasha Levin Wrote:
> On 07/21/2012 10:44 AM, Wen Congyang wrote:
>> We can know the guest is panicked when the guest runs on xen.
>> But we do not have such feature on kvm.
>>
>> Another purpose of this feature is: management app(for example:
>> libvirt) can do auto dump when the guest is panicked. If management
>> app does not do auto dump, the guest's user can do dump by hand if
>> he sees the guest is panicked.
>>
>> We have three solutions to implement this feature:
>> 1. use vmcall
>> 2. use I/O port
>> 3. use virtio-serial.
>>
>> We have decided to avoid touching hypervisor. The reason why I choose
>> choose the I/O port is:
>> 1. it is easier to implememt
>> 2. it does not depend any virtual device
>> 3. it can work when starting the kernel
> 
> Was the option of implementing a virtio-watchdog driver considered?

virtio-watchdog? What is this? I don't find it in qemu. Do I miss something?

Another reason why we don't use this:
If the watchdog timeouts, we cannot say the kernel is panicked. For
example, the kernel is hung, or the kernel is deadlock, or ...
the watchdog daemon can not have chance to touch watchdog device.

Thanks
Wen Congyang

> 
> You're basically re-implementing a watchdog, a guest-host interface and a set 
> of protocols for guest-host communications.
> 
> Why can't we re-use everything we have now, push a virtio watchdog driver 
> into drivers/watchdog/, and gain a more complete solution to detecting hangs 
> inside the guest.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [Qemu-devel] [PATCH v7.5] kvm: notify host when the guest is panicked

[Wen Congyang]

At 07/23/2012 07:50 AM, Sasha Levin Wrote:
> On 07/23/2012 12:36 AM, Anthony Liguori wrote:
>> Sasha Levin  writes:
>>
>>> On 07/22/2012 09:14 PM, Anthony Liguori wrote:
 Sasha Levin  writes:

> On 07/21/2012 10:44 AM, Wen Congyang wrote:
>> We can know the guest is panicked when the guest runs on xen.
>> But we do not have such feature on kvm.
>>
>> Another purpose of this feature is: management app(for example:
>> libvirt) can do auto dump when the guest is panicked. If management
>> app does not do auto dump, the guest's user can do dump by hand if
>> he sees the guest is panicked.
>>
>> We have three solutions to implement this feature:
>> 1. use vmcall
>> 2. use I/O port
>> 3. use virtio-serial.
>>
>> We have decided to avoid touching hypervisor. The reason why I choose
>> choose the I/O port is:
>> 1. it is easier to implememt
>> 2. it does not depend any virtual device
>> 3. it can work when starting the kernel
>
> Was the option of implementing a virtio-watchdog driver considered?
>
> You're basically re-implementing a watchdog, a guest-host interface and a 
> set of protocols for guest-host communications.
>
> Why can't we re-use everything we have now, push a virtio watchdog
> driver into drivers/watchdog/, and gain a more complete solution to
> detecting hangs inside the guest.

 The purpose of virtio is not to reinvent every possible type of device.
 There are plenty of hardware watchdogs that are very suitable to be used
 for this purpose.  QEMU implements quite a few already.

 Watchdogs are not performance sensitive so there's no point in using
 virtio.
>>>
>>> The issue here is not performance, but the adding of a brand new
>>> guest-host interface.
>>
>> We have:
>>
>> 1) Virtio--this is our preferred PV interface.  It needs PCI to be fully
>> initialized and probably will live as a module.
>>
>> 2) Hypercalls--this a secondary PV interface but is available very
>> early.  It's terminated in kvm.ko which means it can only operate on
>> things that are logically part of the CPU and/or APIC complex.
>>
>> This patch introduces a third interface which is available early like
>> hypercalls but not necessarily terminated in kvm.ko.  That means it can
>> have a broader scope in functionality than (2).
>>
>> We could just as well use a hypercall and have multiple commands issued
>> to that hypercall as a convention and add a new exit type to KVM that
>> sent that specific hypercall to userspace for processing.
>>
>> But a PIO operation already has this behavior and requires no changes to 
>> kvm.ko.
> 
> I don't dispute that there may be a need for another guest-host interface, 
> but this patch can basically be called "kvm: notify host when the guest is 
> panicked, oh, btw, and add a brand new undocumented interface"

I forgot to document this interface. I will add it.

Thanks
Wen Congyang

> 
> The new interface should at least come in it's own patch, with documentation.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

[Qemu-devel] [PULL] UniCore32 PUV3 machine support

[gxt]

are available in the git repository at:

  git://github.com/gxt/QEMU.git unicore32

Andreas Färber (1):
  target-unicore32: Drop UC32_CPUID macros

Guan Xuetao (13):
  unicore32-softmmu: Add unicore32-softmmu build support
  unicore32-softmmu: Add coprocessor 0(sysctrl) and 1(ocd) instruction 
support
  unicore32-softmmu: Make UniCore32 cpuid & exceptions correct and runable
  unicore32-softmmu: Implement softmmu specific functions
  unicore32-softmmu: Make sure that kernel can access user space
  unicore32-softmmu: Add puv3 soc/board support
  unicore32-softmmu: Add puv3 interrupt support
  unicore32-softmmu: Add puv3 ostimer support
  unicore32-softmmu: Add puv3 gpio support
  unicore32-softmmu: Add puv3 pm support
  unicore32-softmmu: Add puv3 dma support
  unicore32-softmmu: Add ps2 support
  unicore32-softmmu: Add maintainer information for UniCore32 machine

 MAINTAINERS   |8 +
 arch_init.c   |2 +
 arch_init.h   |1 +
 configure |1 +
 cpu-exec.c|1 +
 default-configs/unicore32-softmmu.mak |4 +
 hw/Makefile.objs  |7 +
 hw/puv3.c |  130 
 hw/puv3.h |   49 ++
 hw/puv3_dma.c |  109 +
 hw/puv3_gpio.c|  141 +
 hw/puv3_intc.c|  135 +
 hw/puv3_ost.c |  151 +++
 hw/puv3_pm.c  |  149 ++
 hw/unicore32/Makefile.objs|6 +
 linux-user/main.c |3 +-
 target-unicore32/Makefile.objs|2 +-
 target-unicore32/cpu.c|   19 ++-
 target-unicore32/cpu.h|   18 +--
 target-unicore32/helper.c |  180 ++
 target-unicore32/helper.h |   17 +--
 target-unicore32/machine.c|   23 +++
 target-unicore32/op_helper.c  |   44 ++-
 target-unicore32/softmmu.c|  267 +
 target-unicore32/translate.c  |  116 +--
 25 files changed, 1509 insertions(+), 74 deletions(-)
 create mode 100644 default-configs/unicore32-softmmu.mak
 create mode 100644 hw/puv3.c
 create mode 100644 hw/puv3.h
 create mode 100644 hw/puv3_dma.c
 create mode 100644 hw/puv3_gpio.c
 create mode 100644 hw/puv3_intc.c
 create mode 100644 hw/puv3_ost.c
 create mode 100644 hw/puv3_pm.c
 create mode 100644 hw/unicore32/Makefile.objs
 create mode 100644 target-unicore32/machine.c
 create mode 100644 target-unicore32/softmmu.c

Re: [Qemu-devel] [PATCH 7/7] RTC: Allow to migrate from old QEMU

[Juan Quintela]

Paolo Bonzini  wrote:
> From: "Zhang, Yang Z" 
>
> The new logic is compatible with old, and it should not block migration
> from old QEMU.  However, the new version cannot migrate to the old one.
>
> Cc: Juan Quintela 

I guess that you removed the tm structs.

This are the current fields.

.fields  = (VMStateField []) {
VMSTATE_BUFFER(cmos_data, RTCState),
VMSTATE_UINT8(cmos_index, RTCState),
VMSTATE_INT32(current_tm.tm_sec, RTCState),
VMSTATE_INT32(current_tm.tm_min, RTCState),
VMSTATE_INT32(current_tm.tm_hour, RTCState),
VMSTATE_INT32(current_tm.tm_wday, RTCState),
VMSTATE_INT32(current_tm.tm_mday, RTCState),
VMSTATE_INT32(current_tm.tm_mon, RTCState),
VMSTATE_INT32(current_tm.tm_year, RTCState),

you can change this to:

VMSTATE_UNUSED(7*4);

Some for the others.

VMSTATE_TIMER(periodic_timer, RTCState),
VMSTATE_INT64(next_periodic_time, RTCState),
VMSTATE_INT64(next_second_time, RTCState),
VMSTATE_TIMER(second_timer, RTCState),
VMSTATE_TIMER(second_timer2, RTCState),
VMSTATE_UINT32_V(irq_coalesced, RTCState, 2),
VMSTATE_UINT32_V(period, RTCState, 2),
VMSTATE_END_OF_LIST()
}


>  static const VMStateDescription vmstate_rtc = {
>  .name = "mc146818rtc",
> -.version_id = 2,
> -.minimum_version_id = 1,
> +.version_id = 3,
> +.minimum_version_id = 3,
>  .minimum_version_id_old = 1,
> +.load_state_old = rtc_load_old,
>  .post_load = rtc_post_load,
>  .fields  = (VMStateField []) {
>  VMSTATE_BUFFER(cmos_data, RTCState),
> @@ -837,7 +873,7 @@ static int rtc_initfn(ISADevice *dev)

no changes in the other part of vmstate?  that is at least strange?  I
guess they are on the other patches on the series.  Will take a look.


>  memory_region_init_io(&s->io, &cmos_ops, s, "rtc", 2);
>  isa_register_ioport(dev, &s->io, base);
>  
> -qdev_set_legacy_instance_id(&dev->qdev, base, 2);
> +qdev_set_legacy_instance_id(&dev->qdev, base, 3);
>  qemu_register_reset(rtc_reset, s);
>  
>  object_property_add(OBJECT(s), "date", "struct tm",

Re: [Qemu-devel] [PATCH 4/7] RTC: Update the RTC clock only when reading it

[Juan Quintela]

Paolo Bonzini  wrote:
> From: "Zhang, Yang Z" 
>
> Calculate guest RTC based on the time of the last update, instead of
> using timers.  The formula is
>
> (base_rtc + guest_time_now - guest_time_last_update + offset)
>
> Base_rtc is the RTC value when the RTC was last updated.
> Guest_time_now is the guest time when the access happens.
> Guest_time_last_update was the guest time when the RTC was last updated.
> Offset is used when divider reset happens or the set bit is toggled.
>
> The timer is kept in order to signal interrupts, but it only needs to
> run when either UF or AF is cleared.  When the bits are both set, the
> timer does not run.
>
> UIP is now synthesized when reading register A.  If the timer is not set,
> or if there is more than one second before it (as is the case at the
> end of this series), the leading edge of UIP is computed and the rising
> edge occurs 220us later.  If the update timer occurs within one second,
> however, the rising edge of the AF and UF bits should coincide withe
> the falling edge of UIP.  We do not know exactly when this will happen
> because there could be delays in the servicing of the timer.  Hence, in
> this case reading register A only computes for the rising edge of UIP,
> and latches the bit until the timer is fired and clears it.
>
> Signed-off-by: Yang Zhang 
> Signed-off-by: Paolo Bonzini 
> @@ -540,11 +593,12 @@ static const VMStateDescription vmstate_rtc = {
>  VMSTATE_INT32(current_tm.tm_mday, RTCState),
>  VMSTATE_INT32(current_tm.tm_mon, RTCState),
>  VMSTATE_INT32(current_tm.tm_year, RTCState),
> +VMSTATE_UINT64(base_rtc, RTCState),
> +VMSTATE_UINT64(last_update, RTCState),
> +VMSTATE_INT64(offset, RTCState),
   VMSTATE_UINT64_V(base_rtc, RTCState, 3)
same ofr the others.

Normally, new fields are added at the end of the structure.


>  VMSTATE_TIMER(periodic_timer, RTCState),
>  VMSTATE_INT64(next_periodic_time, RTCState),
> -VMSTATE_INT64(next_second_time, RTCState),
> -VMSTATE_TIMER(second_timer, RTCState),
> -VMSTATE_TIMER(second_timer2, RTCState),
> +VMSTATE_TIMER(update_timer, RTCState),

I have to read the rest of the patch to know what is the relation of
this 4 fields, to see if there is any way to create this in any sane
way that is compatible.

The new fields can go in a different subsection.  The three ones that
are removed, I don't know if that values can be calculated.


>  VMSTATE_UINT32_V(irq_coalesced, RTCState, 2),
>  VMSTATE_UINT32_V(period, RTCState, 2),
>  VMSTATE_END_OF_LIST()

Later, Juan.

[Qemu-devel] [PATCH 0/3] vfio-pci: reworking end-of-interrupt

[Alexey Kardashevskiy]

Here is a small patchset just to keep moving.

The main problem here is how we implement add_eoi_notifier()
which is supposed to be a callback of a global interrupt controller
which does not exists on QEMUMachine level.

Alexey Kardashevskiy (3):
  xics: added end-of-interrupt (EOI) handlers
  ioapic: removed obsolete ioapic_remove_gsi_eoi_notifier
  vfio-pci: rework of EOI

 hw/ioapic.c   |   19 ++-
 hw/ioapic.h   |1 -
 hw/vfio_pci.c |   24 
 hw/vfio_pci.h |1 -
 hw/xics.c |   13 +
 hw/xics.h |4 
 6 files changed, 35 insertions(+), 27 deletions(-)

-- 
1.7.10.4

[Qemu-devel] [PATCH 1/3] xics: added end-of-interrupt (EOI) handlers

[Alexey Kardashevskiy]

The patch adds EOI handler to process h_eoi RTAS call correctly
for PCI legacy interrupts.

This functionality is going to be used in VFIO later.

Signed-off-by: Alexey Kardashevskiy 
---
 hw/xics.c |   13 +
 hw/xics.h |4 
 2 files changed, 17 insertions(+)

diff --git a/hw/xics.c b/hw/xics.c
index 668a0d6..d36d62c 100644
--- a/hw/xics.c
+++ b/hw/xics.c
@@ -170,6 +170,7 @@ struct ics_irq_state {
 int sent:1;
 int rejected:1;
 int masked_pending:1;
+NotifierList eoi_notifier;
 };
 
 struct ics_state {
@@ -309,6 +310,8 @@ static void ics_eoi(struct ics_state *ics, int nr)
 if (irq->type == XICS_LSI) {
 irq->sent = 0;
 }
+
+notifier_list_notify(&irq->eoi_notifier, NULL);
 }
 
 /*
@@ -536,6 +539,7 @@ struct icp_state *xics_system_init(int nr_irqs)
 for (i = 0; i < nr_irqs; i++) {
 ics->irqs[i].priority = 0xff;
 ics->irqs[i].saved_priority = 0xff;
+notifier_list_init(&ics->irqs[i].eoi_notifier);
 }
 
 ics->qirqs = qemu_allocate_irqs(ics_set_irq, ics, nr_irqs);
@@ -552,3 +556,12 @@ struct icp_state *xics_system_init(int nr_irqs)
 
 return icp;
 }
+
+void xics_add_eoi_notifier(Notifier *notify, uint32_t srcno)
+{
+struct ics_state *ics = spapr->icp->ics;
+struct ics_irq_state *irq = &ics->irqs[srcno - ics->offset];
+
+notifier_list_add(&irq->eoi_notifier, notify);
+}
+
diff --git a/hw/xics.h b/hw/xics.h
index 2080159..ca75fac 100644
--- a/hw/xics.h
+++ b/hw/xics.h
@@ -27,6 +27,8 @@
 #if !defined(__XICS_H__)
 #define __XICS_H__
 
+#include "notify.h"
+
 #define XICS_IPI0x2
 
 struct icp_state;
@@ -41,4 +43,6 @@ qemu_irq xics_assign_irq(struct icp_state *icp, int irq,
 
 struct icp_state *xics_system_init(int nr_irqs);
 
+void xics_add_eoi_notifier(Notifier *notify, uint32_t srcno);
+
 #endif /* __XICS_H__ */
-- 
1.7.10.4

[Qemu-devel] [PATCH 2/3] ioapic: removed obsolete ioapic_remove_gsi_eoi_notifier

[Alexey Kardashevskiy]

As the Notifier struct contains everything it needs to get removed
from the notifiers list, there is no need in ioapic_remove_gsi_eoi_notifier().
This patch removes it.

Signed-off-by: Alexey Kardashevskiy 
---
 hw/ioapic.c |   19 ++-
 hw/ioapic.h |1 -
 2 files changed, 2 insertions(+), 18 deletions(-)

diff --git a/hw/ioapic.c b/hw/ioapic.c
index a6e0387..ead1b5f 100644
--- a/hw/ioapic.c
+++ b/hw/ioapic.c
@@ -139,8 +139,7 @@ void ioapic_eoi_broadcast(int vector)
 }
 }
 
-static void ioapic_update_gsi_eoi_notifier(Notifier *notify, uint32_t gsi,
-   bool add)
+void ioapic_add_gsi_eoi_notifier(Notifier *notify, uint32_t gsi)
 {
 IOAPICCommonState *s;
 int i;
@@ -159,25 +158,11 @@ static void ioapic_update_gsi_eoi_notifier(Notifier 
*notify, uint32_t gsi,
 continue;
 }
 
-if (add) {
-notifier_list_add(&s->eoi_notifiers[pin], notify);
-} else {
-notifier_remove(notify);
-}
+notifier_list_add(&s->eoi_notifiers[pin], notify);
 return;
 }
 }
 
-void ioapic_add_gsi_eoi_notifier(Notifier *notify, uint32_t gsi)
-{
-ioapic_update_gsi_eoi_notifier(notify, gsi, true);
-}
-
-void ioapic_remove_gsi_eoi_notifier(Notifier *notify, uint32_t gsi)
-{
-ioapic_update_gsi_eoi_notifier(notify, gsi, false);
-}
-
 static uint64_t
 ioapic_mem_read(void *opaque, target_phys_addr_t addr, unsigned int size)
 {
diff --git a/hw/ioapic.h b/hw/ioapic.h
index a28fada..2d7d6a2 100644
--- a/hw/ioapic.h
+++ b/hw/ioapic.h
@@ -27,6 +27,5 @@
 
 void ioapic_eoi_broadcast(int vector);
 void ioapic_add_gsi_eoi_notifier(Notifier *notify, uint32_t gsi);
-void ioapic_remove_gsi_eoi_notifier(Notifier *notify, uint32_t gsi);
 
 #endif /* !HW_IOAPIC_H */
-- 
1.7.10.4

[Qemu-devel] [PATCH 3/3] vfio-pci: rework of EOI

[Alexey Kardashevskiy]

Originally VFIO is coded to support IOAPIC only (i.e. x86).
The patch adds XICS (POWERPC interrupt controller) and replaces
ioapic_add_gsi_eoi_notifier with unified macro to have as little
#ifdef TARGET_PPC64 as possible.

Still needs some rework to get rid of #ifdef TARGET_PPC64.

Signed-off-by: Alexey Kardashevskiy 
---
 hw/vfio_pci.c |   24 
 hw/vfio_pci.h |1 -
 2 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/hw/vfio_pci.c b/hw/vfio_pci.c
index fd65731..cd68fe0 100644
--- a/hw/vfio_pci.c
+++ b/hw/vfio_pci.c
@@ -21,7 +21,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -44,6 +43,15 @@
 #include "range.h"
 #include "vfio_pci.h"
 
+#ifndef TARGET_PPC64
+#include 
+#include "ioapic.h"
+#define vfio_irq_add_eoi_notifier   ioapic_add_gsi_eoi_notifier
+#else
+#include "xics.h"
+#define vfio_irq_add_eoi_notifier   xics_add_eoi_notifier
+#endif
+
 //#define DEBUG_VFIO
 #ifdef DEBUG_VFIO
 #define DPRINTF(fmt, ...) \
@@ -258,7 +266,7 @@ static void vfio_enable_intx_kvm(VFIODevice *vdev)
 irqfd.fd = event_notifier_get_fd(&vdev->intx.interrupt);
 
 qemu_set_fd_handler(irqfd.fd, NULL, NULL, vdev);
-ioapic_remove_gsi_eoi_notifier(&vdev->intx.eoi, vdev->intx.irq);
+notifier_remove(&vdev->intx.eoi);
 vfio_mask_intx(vdev);
 vdev->intx.pending = false;
 qemu_set_irq(vdev->pdev.irq[vdev->intx.pin], 0);
@@ -294,7 +302,7 @@ static void vfio_enable_intx_kvm(VFIODevice *vdev)
 return;
 
 fail:
-ioapic_add_gsi_eoi_notifier(&vdev->intx.eoi, vdev->intx.irq);
+vfio_irq_add_eoi_notifier(&vdev->intx.eoi, vdev->intx.irq);
 qemu_set_fd_handler(irqfd.fd, vfio_intx_interrupt, NULL, vdev);
 vfio_unmask_intx(vdev);
 #endif
@@ -341,7 +349,7 @@ static void vfio_disable_intx_kvm(VFIODevice *vdev)
 
 event_notifier_cleanup(&vdev->intx.unmask);
 
-ioapic_add_gsi_eoi_notifier(&vdev->intx.eoi, vdev->intx.irq);
+vfio_irq_add_eoi_notifier(&vdev->intx.eoi, vdev->intx.irq);
 qemu_set_fd_handler(irqfd.fd, vfio_intx_interrupt, NULL, vdev);
 vfio_unmask_intx(vdev);
 
@@ -366,7 +374,7 @@ static void vfio_update_irq(Notifier *notify, void *data)
 vdev->host.func, vdev->intx.irq, irq);
 
 vfio_disable_intx_kvm(vdev);
-ioapic_remove_gsi_eoi_notifier(&vdev->intx.eoi, vdev->intx.irq);
+notifier_remove(&vdev->intx.eoi);
 
 vdev->intx.irq = irq;
 
@@ -375,7 +383,7 @@ static void vfio_update_irq(Notifier *notify, void *data)
 return;
 }
 
-ioapic_add_gsi_eoi_notifier(&vdev->intx.eoi, vdev->intx.irq);
+vfio_irq_add_eoi_notifier(&vdev->intx.eoi, vdev->intx.irq);
 vfio_enable_intx_kvm(vdev);
 
 /* Re-enable the interrupt in cased we missed an EOI */
@@ -404,7 +412,7 @@ static int vfio_enable_intx(VFIODevice *vdev)
 vdev->intx.pin = pin - 1; /* Pin A (1) -> irq[0] */
 vdev->intx.irq = pci_get_irq(&vdev->pdev, vdev->intx.pin);
 vdev->intx.eoi.notify = vfio_eoi;
-ioapic_add_gsi_eoi_notifier(&vdev->intx.eoi, vdev->intx.irq);
+vfio_irq_add_eoi_notifier(&vdev->intx.eoi, vdev->intx.irq);
 
 vdev->intx.update_irq.notify = vfio_update_irq;
 pci_add_irq_update_notifier(&vdev->pdev, &vdev->intx.update_irq);
@@ -441,7 +449,7 @@ static void vfio_disable_intx(VFIODevice *vdev)
 vfio_disable_irqindex(vdev, VFIO_PCI_INTX_IRQ_INDEX);
 
 pci_remove_irq_update_notifier(&vdev->intx.update_irq);
-ioapic_remove_gsi_eoi_notifier(&vdev->intx.eoi, vdev->intx.irq);
+notifier_remove(&vdev->intx.eoi);
 
 fd = event_notifier_get_fd(&vdev->intx.interrupt);
 qemu_set_fd_handler(fd, NULL, NULL, vdev);
diff --git a/hw/vfio_pci.h b/hw/vfio_pci.h
index 00bb3dd..d1a7434 100644
--- a/hw/vfio_pci.h
+++ b/hw/vfio_pci.h
@@ -4,7 +4,6 @@
 #include "qemu-common.h"
 #include "qemu-queue.h"
 #include "pci.h"
-#include "ioapic.h"
 #include "event_notifier.h"
 
 typedef struct VFIOPCIHostDevice {
-- 
1.7.10.4

Re: [Qemu-devel] Closing an opened telnet monitor?

[Michael Tokarev]

On 23.07.2012 02:37, Erik Rull wrote:
> Hi all,
> 
> how can I close an open telnet session to my qemu monitor? I didn't find any 
> possiblity beside killing my telnet client on my remote connected system.
> 
> Is there a "nicer" way of doing that? "quit" is definitively the wrong 
> command :-)

I guess every telnet client supports Ctrl+[ escape sequence.
So the answer to this is --- Ctrl+[, q.  man telnet.

/mjt

Re: [Qemu-devel] [PATCH v7] kvm: notify host when the guest is panicked

[Wen Congyang]

At 07/23/2012 04:19 AM, Sasha Levin Wrote:
> On 07/22/2012 09:22 PM, Anthony Liguori wrote:
>> Sasha Levin  writes:
>>
>>> On 07/21/2012 09:12 AM, Wen Congyang wrote:
 +#define KVM_PV_PORT   (0x505UL)
 +
  #ifdef __KERNEL__
  #include 
  
 @@ -221,6 +223,11 @@ static inline void kvm_disable_steal_time(void)
  }
  #endif
  
 +static inline unsigned int kvm_arch_pv_features(void)
 +{
 +  return inl(KVM_PV_PORT);
 +}
 +
>>>
>>> Why is this safe?
>>>
>>> I'm not sure you can just pick any ioport you'd like and use it.
>>
>> There are three ways I/O ports get used on a PC:
>>
>> 1) Platform devices
>>  - This is well defined since the vast majority of platform devices are
>>implemented within a single chip.  If you're emulating an i440fx
>>chipset, the PIIX4 spec has an exhaustive list.
>>
>> 2) PCI devices
>>  - Typically, PCI only allocates ports starting at 0x0d00 to avoid
>>conflicts with ISA devices.
>>
>> 3) ISA devices
>>  - ISA uses subtractive decoding so any ISA device can access.  In
>>theory, an ISA device could attempt to use port 0x0505 but it's
>>unlikely.  In a modern guest, there aren't really any ISA devices being
>>added either.
>>
>> So yes, picking port 0x0505 is safe for something like this (as long as
>> you check to make sure that you really are under KVM).
> 
> Is there anything that actually prevents me from using PCI ports lower than 
> 0x0d00? As you said in (3), ISA isn't really used anymore (nor is implemented 
> by lkvm for example), so placing PCI below 0x0d00 might even make sense in 
> that case.
> 
> Furthermore, I can place one of these brand new virtio-mmio devices which got 
> introduced recently wherever I want right now - Having a device that uses 
> 0x505 would cause a pretty non-obvious failure mode.
> 
> Either way, If we are going to grab an ioport, then:
> 
>  - It should be documented well somewhere in Documentation/virt/kvm
>  - It should go through request_region() to actually claim those ioports.

Good idea.

>  - It should fail gracefully if that port is taken for some reason, instead 
> of not even checking it.

Yes, I agree it.

I will update it.

Thanks
Wen Congyang

> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [Qemu-devel] [PATCH v2 4/4] ARM: exynos4210_pmu: Add software reset support

[Maksim Kozlov]

20.07.2012 18:32, Peter Maydell пишет:

On 12 July 2012 17:54, Maksim Kozlov  wrote:

Signed-off-by: Maksim Kozlov
---
  hw/exynos4210_pmu.c |   40 +---
  1 files changed, 33 insertions(+), 7 deletions(-)

diff --git a/hw/exynos4210_pmu.c b/hw/exynos4210_pmu.c
index 7f09c79..96588d9 100644
--- a/hw/exynos4210_pmu.c
+++ b/hw/exynos4210_pmu.c
@@ -18,13 +18,8 @@
   *  with this program; if not, see.
   */

-/*
- * This model implements PMU registers just as a bulk of memory. Currently,
- * the only reason this device exists is that secondary CPU boot loader
- * uses PMU INFORM5 register as a holding pen.
- */
-
  #include "sysbus.h"
+#include "sysemu.h"

  #ifndef DEBUG_PMU
  #define DEBUG_PMU   0
@@ -230,6 +225,8 @@

  #define EXYNOS4210_PMU_REGS_MEM_SIZE 0x3d0c

+#define SWRESET_SYSTEM_MASK 0x0001
+
  typedef struct Exynos4210PmuReg {
  const char  *name; /* for debug only */
  uint32_t offset;
@@ -458,7 +455,17 @@ static void exynos4210_pmu_write(void *opaque, 
target_phys_addr_t offset,
  PRINT_DEBUG_EXTEND("%s [0x%04x]<- 0x%04x\n",
   exynos4210_pmu_regs[index].name, (uint32_t)offset, 
(uint32_t)val);

-s->reg[index] = val;
+switch (offset) {
+case SWRESET:
+if (val&  SWRESET_SYSTEM_MASK) {
+s->reg[index] = val;
+qemu_system_reset_request();
+}
+break;
+default:
+s->reg[index] = val;
+break;
+}
  }

  static const MemoryRegionOps exynos4210_pmu_ops = {
@@ -477,9 +484,28 @@ static void exynos4210_pmu_reset(DeviceState *dev)
  Exynos4210PmuState *s =
  container_of(dev, Exynos4210PmuState, busdev.qdev);
  unsigned i;
+uint32_t index = exynos4210_pmu_get_register_index(s, SWRESET);
+uint32_t swreset = s->reg[index];

  /* Set default values for registers */
  for (i = 0; i<  PMU_NUM_OF_REGISTERS; i++) {
+if (swreset) {
+switch (exynos4210_pmu_regs[i].offset) {
+case INFORM0:
+case INFORM1:
+case INFORM2:
+case INFORM3:
+case INFORM4:
+case INFORM5:
+case INFORM6:
+case INFORM7:
+case PS_HOLD_CONTROL:
+/* keep these registers during SW reset */
+continue;
+default:
+break;
+}
+}
  s->reg[i] = exynos4210_pmu_regs[i].reset_value;
  }
  }


This patch seems to be trying to make a distinction that QEMU doesn't
support, ie between system wide "software reset" and system wide
"hard reset". I'm not convinced about the wisdom of trying to paper
over this lack with a single-device workaround.


Ok. Thank for review

And I found out that this patch contains a mistake, therefore it should 
be rejected in any case




-- PMM

Re: [Qemu-devel] [Qemu-ppc] [PATCH 2/2] spapr: Add support for -vga option

[Benjamin Herrenschmidt]

On Wed, 2012-06-27 at 17:25 -0500, Anthony Liguori wrote:

> If a user asks for something and we can't make it work, we should fail.

Note that QEMU's cirrus works fine with the new kernel cirrusdrmfb, so
I say we should allow it (needs to be able to the powerpc device .mak
as well tho.

It shouldn't be primary because old RHEL's iirc used to have cirrusfb
enabled and that would blow due to guest kernel bugs among others.

I haven't had a chance to try whatever userspace DDX the Xorg folks have
come up with to use on top of cirrusdrmfb, so that might need a bit of
fixing but there's no reason not to allow -vga cirrus at this point.

Note to Matthew: cirrusdrmfb is a LOT SLOWER than offb for a similar
SW only dumb framebuffer, probably has to do with the way it does the
"dirty" stuff, not sure ...

Why not draw directly into the emulated vram ?

Cheers,
Ben.