Re: [Qemu-devel] snabbswitch integration with QEMU for userspace ethernet I/O

[Michael S. Tsirkin]

On Thu, May 30, 2013 at 08:46:42AM +0200, Stefan Hajnoczi wrote:
> On Wed, May 29, 2013 at 6:02 PM, Julian Stecklina
>  wrote:
> > On 05/29/2013 04:21 PM, Stefan Hajnoczi wrote:
> >> The fact that a single switch process has shared memory access to all
> >> guests' RAM is critical.  If the switch process is exploited, then that
> >> exposes other guests' data!  (Think of a multi-tenant host with guests
> >> belonging to different users.)
> >
> > True. But people don't mind having instruction decoding and half of
> > virtio in the kernel these days, so it can't be that security critical...
> 
> No, it's still security critical.  If there were equivalent solutions
> with better security then I'm sure people would accept them.  It's
> just that there isn't an equivalent solution yet :).
> 
> Stefan

Some people would accept them.
Others run with selinux off ...

-- 
MST

Re: [Qemu-devel] snabbswitch integration with QEMU for userspace ethernet I/O

[Stefan Hajnoczi]

On Wed, May 29, 2013 at 6:02 PM, Julian Stecklina
 wrote:
> On 05/29/2013 04:21 PM, Stefan Hajnoczi wrote:
>> The fact that a single switch process has shared memory access to all
>> guests' RAM is critical.  If the switch process is exploited, then that
>> exposes other guests' data!  (Think of a multi-tenant host with guests
>> belonging to different users.)
>
> True. But people don't mind having instruction decoding and half of
> virtio in the kernel these days, so it can't be that security critical...

No, it's still security critical.  If there were equivalent solutions
with better security then I'm sure people would accept them.  It's
just that there isn't an equivalent solution yet :).

Stefan

Re: [Qemu-devel] KVM call agenda for 2013-05-28

[Gerd Hoffmann]

  Hi,

> Why should this be true?  Shouldn't we be allowed to increase the amount
> of memory the guest has across reboots?  That's equivalent to adding
> another DIMM after power off.

poweroff is equivalent to exiting qemu, not to guest reset.

> Not generating tables on reset does limit what we can do in a pretty
> fundamental way.  Even if you can argue it in the short term, I don't
> think it's viable in the long term.

I don't think so.  The procedure for adding/removing non-hotpluggable
hardware is:  poweroff, plugin/-out hardware (change config in qemu),
boot.  Hotpluggable hardware doesn't need acpi table updates.

cheers,
  Gerd

Re: [Qemu-devel] updated: kvm networking todo wiki

[Stefan Hajnoczi]

On Thu, May 30, 2013 at 7:23 AM, Rusty Russell  wrote:
> Anthony Liguori  writes:
>> Rusty Russell  writes:
>>> On Fri, May 24, 2013 at 08:47:58AM -0500, Anthony Liguori wrote:
 FWIW, I think what's more interesting is using vhost-net as a networking
 backend with virtio-net in QEMU being what's guest facing.

 In theory, this gives you the best of both worlds: QEMU acts as a first
 line of defense against a malicious guest while still getting the
 performance advantages of vhost-net (zero-copy).

>>> It would be an interesting idea if we didn't already have the vhost
>>> model where we don't need the userspace bounce.
>>
>> The model is very interesting for QEMU because then we can use vhost as
>> a backend for other types of network adapters (like vmxnet3 or even
>> e1000).
>>
>> It also helps for things like fault tolerance where we need to be able
>> to control packet flow within QEMU.
>
> (CC's reduced, context added, Dmitry Fleytman added for vmxnet3 thoughts).
>
> Then I'm really confused as to what this would look like.  A zero copy
> sendmsg?  We should be able to implement that today.
>
> On the receive side, what can we do better than readv?  If we need to
> return to userspace to tell the guest that we've got a new packet, we
> don't win on latency.  We might reduce syscall overhead with a
> multi-dimensional readv to read multiple packets at once?

Sounds like recvmmsg(2).

Stefan

Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28

[Gerd Hoffmann]

  Hi,

>>> Raised
>>> that QOM interface should be sufficient.
>>
>> Agree on this one.  Ideally the acpi table generation code should be
>> able to gather all information it needs from the qom tree, so it can be
>> a standalone C file instead of being scattered over all qemu.
> 
> Ack.  So my basic argument is why not expose the QOM interfaces to
> firmware and move the generation code there?  Seems like it would be
> more or less a copy/paste once we had a proper implementation in QEMU.

Well, no.  Firmware is a quite simple environment without standard libc
etc, so moving code from qemu to firmware certainly isn't as easy as
copying over a file.

>>> There were discussions on potentially introducing a middle component
>>> to generate the tables.  Coreboot was raised as a possibility, and
>>> David thought it would be okay to use coreboot for both OVMF and
>>> SeaBIOS.
>>
>> Certainly an option, but that is a long-term project.
> 
> Out of curiousity, are there other benefits to using coreboot as a core
> firmware in QEMU?

Short-term it's alot of work as we have to bring coreboot's qemu support
to feature parity with seabios.  I suspect most of this is acpi related
though, so when qemu provides the tables and coreboot uses them we could
be pretty close already.

Long-term it should simplify firmware maintainance as we have only *one*
place which handles the hardware bringup, and seabios/ovmf have less
work to do.

> Is there a payload we would ever plausibly use besides OVMF and SeaBIOS?

I wouldn't be surprised if people start using other coreboot payloads
and/or features such as direct linux kernel boot once it works well on qemu.

We might even run qemu test suites as coreboot payload.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH] pci: change typename of q35 to pci-q35

[Michael S. Tsirkin]

On Thu, May 30, 2013 at 10:47:48AM +0800, Amos Kong wrote:
> In QEMU, we set the firmware name of pc-i440fx is 'pci', and set the
> firmware name of q35 is 'q35-pcihost'.
> 
> The seabios pattern matching code isn't sophisticated, and we want to
> match those two devices with exact pattern.
> 
> This patch changes the typename of q35 to 'pci-q35', all pci devices
> use same prefix 'pci' in fireware name. And I will change pattern in
> seabios to "/pci*@i0cf8".
> 
> Signed-off-by: Amos Kong 

Let's just not leak name to the guest - there's no reason to.

Won't the following address the issue without bios changes?
Maybe we should find some way to set fw_name in hw/pci/pci_host.c,
worth looking into.

Signed-off-by: Michael S. Tsirkin 

---


diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
index 8467f86..24df6b5 100644
--- a/hw/pci-host/q35.c
+++ b/hw/pci-host/q35.c
@@ -76,6 +76,7 @@ static void q35_host_class_init(ObjectClass *klass, void 
*data)
 
 k->init = q35_host_init;
 dc->props = mch_props;
+dc->fw_name = "pci";
 }
 
 static void q35_host_initfn(Object *obj)

Re: [Qemu-devel] updated: kvm networking todo wiki

[Rusty Russell]

Anthony Liguori  writes:
> Rusty Russell  writes:
>> On Fri, May 24, 2013 at 08:47:58AM -0500, Anthony Liguori wrote:
>>> FWIW, I think what's more interesting is using vhost-net as a networking
>>> backend with virtio-net in QEMU being what's guest facing.
>>> 
>>> In theory, this gives you the best of both worlds: QEMU acts as a first
>>> line of defense against a malicious guest while still getting the
>>> performance advantages of vhost-net (zero-copy).
>>>
>> It would be an interesting idea if we didn't already have the vhost
>> model where we don't need the userspace bounce.
>
> The model is very interesting for QEMU because then we can use vhost as
> a backend for other types of network adapters (like vmxnet3 or even
> e1000).
>
> It also helps for things like fault tolerance where we need to be able
> to control packet flow within QEMU.

(CC's reduced, context added, Dmitry Fleytman added for vmxnet3 thoughts).

Then I'm really confused as to what this would look like.  A zero copy
sendmsg?  We should be able to implement that today.

On the receive side, what can we do better than readv?  If we need to
return to userspace to tell the guest that we've got a new packet, we
don't win on latency.  We might reduce syscall overhead with a
multi-dimensional readv to read multiple packets at once?

Confused,
Rusty.

Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

[Nicholas A. Bellinger]

On Wed, 2013-05-29 at 21:29 -0700, Nicholas A. Bellinger wrote:
> On Thu, 2013-05-30 at 06:17 +0800, Asias He wrote:
> > On Wed, May 29, 2013 at 08:10:44AM -0700, Badari Pulavarty wrote:
> > > On 05/29/2013 02:05 AM, Wenchao Xia wrote:
> > > >于 2013-5-28 17:00, Wenchao Xia 写道:
> 
> 
> 
> > > >  I have done a basic test of vhost-scsi, following is the result I'd
> > > >like to post, generally it seems fine:
> > > >
> > > >Result:
> > > >  fdisk/mkfs: fdisk can find it, mke2fs works fine.
> > > >  mount: can mount it.
> > > >  file I/O: dd 90M zero to a file in that disk succeed.
> > > 
> > > 
> > > 
> > > I tried without nested kvm.
> > > 
> > > >
> > > >Issues:
> > > >  1) in fdisk -l, sometime timeout with dmesg "end_request: I/O error,
> > > >dev  fd0, sector 0", I guess it is caused by nested KVM that failed
> > > >to kick host kernel?
> > > 
> > > 
> > > I don't see this issue. Are you sure "fd0" is actually the scsi device ?
> > > what is "fd0" ?
> > > 
> > > >  2) in fdisk -l, it shows 512 bytes larger than the parameter I
> > > >specified in fd_dev_size parameter in configfs on host.(shows
> > > >104858112 bytes, see the invocation script below)
> > > >
> > > 
> > > I see the same. For some reason "fdisk -l" in the VM shows
> > > 512-bytes more than the actual size for the file (on the host).
> > 
> > Hmm, interesting. Will look into it.
> > 
> > Nick, Any ideas here?
> > 
> 
> Mmm, fd_get_blocks() is not returning the expected minus one logical
> blocks with a !S_ISBLK() setup.
> 
> This is happening for every other backend ->get_blocks() call already,
> and should be happening for the fd_dev_size case as well.
> 
> Applying the following to target-pending.git now.
> 

Actually sorry, that last patch is not correct..

Here's a better one to properly set fd_dev->fd_block_size at configure
time, and use dev_attrib.block_size in fd_get_blocks() to allow for user
defined block_sizes.

Thanks,

--nab

commit 9e309f9307fe644dee8718980bfcb77de91ce38e
Author: Nicholas Bellinger 
Date:   Wed May 29 21:35:23 2013 -0700

target/file: Fix off-by-one READ_CAPACITY bug for !S_ISBLK export

This patch fixes a bug where FILEIO was incorrectly reporting the number
of logical blocks (+ 1) when using non struct block_device export mode.

It changes fd_get_blocks() to follow all other backend ->get_blocks() cases,
and reduces the calculated dev_size by one dev->dev_attrib.block_size
number of bytes, and fixes the initial block_size assignment within
fd_configure_device()

Reported-by: Wenchao Xia 
Reported-by: Badari Pulavarty 
Signed-off-by: Nicholas Bellinger 

diff --git a/drivers/target/target_core_file.c 
b/drivers/target/target_core_file.c
index 1b1d544..b11890d 100644
--- a/drivers/target/target_core_file.c
+++ b/drivers/target/target_core_file.c
@@ -153,6 +153,7 @@ static int fd_configure_device(struct se_device *dev)
struct request_queue *q = bdev_get_queue(inode->i_bdev);
unsigned long long dev_size;
 
+   fd_dev->fd_block_size = bdev_logical_block_size(inode->i_bdev);
/*
 * Determine the number of bytes from i_size_read() minus
 * one (1) logical sector from underlying struct block_device
@@ -199,6 +200,7 @@ static int fd_configure_device(struct se_device *dev)
goto fail;
}
 
+   fd_dev->fd_block_size = FD_BLOCKSIZE;
/*
 * Limit UNMAP emulation to 8k Number of LBAs (NoLB)
 */
@@ -217,9 +219,7 @@ static int fd_configure_device(struct se_device *dev)
dev->dev_attrib.max_write_same_len = 0x1000;
}
 
-   fd_dev->fd_block_size = dev->dev_attrib.hw_block_size;
-
-   dev->dev_attrib.hw_block_size = FD_BLOCKSIZE;
+   dev->dev_attrib.hw_block_size = fd_dev->fd_block_size;
dev->dev_attrib.hw_max_sectors = FD_MAX_SECTORS;
dev->dev_attrib.hw_queue_depth = FD_MAX_DEVICE_QUEUE_DEPTH;
 
@@ -694,11 +694,12 @@ static sector_t fd_get_blocks(struct se_device *dev)
 * to handle underlying block_device resize operations.
 */
if (S_ISBLK(i->i_mode))
-   dev_size = (i_size_read(i) - fd_dev->fd_block_size);
+   dev_size = i_size_read(i);
else
dev_size = fd_dev->fd_dev_size;
 
-   return div_u64(dev_size, dev->dev_attrib.block_size);
+   return div_u64(dev_size - dev->dev_attrib.block_size,
+  dev->dev_attrib.block_size);
 }
 
 static struct sbc_ops fd_sbc_ops = {

Re: [Qemu-devel] [PATCH 6/8] pci: Simpler implementation of primary PCI bus

[Michael S. Tsirkin]

On Thu, May 30, 2013 at 01:34:41PM +1000, David Gibson wrote:
> On Wed, May 29, 2013 at 03:22:29PM +0300, Michael S. Tsirkin wrote:
> > On Wed, May 29, 2013 at 09:04:00PM +1000, David Gibson wrote:
> > > On Wed, May 29, 2013 at 01:17:13PM +0300, Michael S. Tsirkin wrote:
> > > > On Wed, May 29, 2013 at 08:06:42PM +1000, David Gibson wrote:
> > > > > On Wed, May 29, 2013 at 12:55:53PM +0300, Michael S. Tsirkin wrote:
> > > > > > On Wed, May 29, 2013 at 07:43:41PM +1000, David Gibson wrote:
> > > > > > > On Thu, May 23, 2013 at 10:16:27PM +1000, David Gibson wrote:
> > > > > > > > On Thu, May 23, 2013 at 02:22:30PM +0300, Michael S. Tsirkin 
> > > > > > > > wrote:
> > > > > > > > > On Thu, May 09, 2013 at 10:31:10AM +1000, David Gibson wrote:
> > > > > > > > > > Currently pci_get_primary_bus() searches the list of root 
> > > > > > > > > > buses for one
> > > > > > > > > > with domain 0.  But since host buses are always registered 
> > > > > > > > > > with domain 0,
> > > > > > > > > > this just amounts to finding the only PCI host bus.
> > > > > > > > > > 
> > > > > > > > > > This simplifies the implementation by defining the primary 
> > > > > > > > > > PCI bus to
> > > > > > > > > > be the first one registered, using a global variable to 
> > > > > > > > > > track it.
> > > > > > > > > > 
> > > > > > > > > > Signed-off-by: David Gibson 
> > > > > > > > > 
> > > > > > > > > Or better: can we just fail if there is more than
> > > > > > > > > one root?
> > > > > > > > 
> > > > > > > > That might work, I'll look into doing that.
> > > > > > > 
> > > > > > > So, the difficulty with this is that then any machine with 
> > > > > > > multiple
> > > > > > > PCI bridges could not use pci_nic_init(), since it calls
> > > > > > > pci_get_bus_devfn() which calls pci_find_primary_bus() which would
> > > > > > > always fail.  And using pci_nic_init() is more or less mandatory 
> > > > > > > in
> > > > > > > the machine_init function to support old-style nic configuration.
> > > > > > > 
> > > > > > > Suggestions?
> > > > > > 
> > > > > > You mean multiple PCI roots?
> > > > > > Well, there are no legacy machines with multiple roots to support, 
> > > > > > are
> > > > > > there?  So why do we need to support legacy flags for these new
> > > > > > configurations?
> > > > > 
> > > > > Because people expect them.
> > > > 
> > > > People can learn, somehow they will learn to add a new root, so they can
> > > > learn to use -device too.
> > > 
> > > Hrm.  I'd kind of like a second (third?) opinion on that.  Anthony?
> > > 
> > > > So let's make it fail on multiple roots, and output a message along the
> > > > lines of "please use -device virtio-net-pci instead".
> > > 
> > > How to produce a meaningful error like that isn't totally obvious,
> > > since the test for multiple roots is down in find_primary_pci_bus()
> > > (or whatever), and once we get back up to pci_nic_init() we just know
> > > that pci_get_bus_devfn() failed for some reason.
> > 
> > What other possible reason for it to fail?
> 
> Unparseable address (it can be user specified) or internal failure to
> initialize the device are the first two that spring to mind..

Well, let's change the API in some way. How about we
pass root to pci_get_bus_devfn?

> > > > > Plus on spapr we already support the
> > > > > legacy nic options; it would be very strange for them to suddenly
> > > > > break when we add a second host bridge.
> > > > 
> > > > Not sure who "we" is here. IMHO user should ask for a new
> > > > machine type with two roots explicitly.
> > > 
> > > You seem to be thinking of the number of host bridges as a fixed
> > > property of the platform, which it isn't on spapr.  PCI host bridges
> > > are just another device.  Large scale real hardware can easily have
> > > dozens of them.
> > 
> > Absolutely. I'm not thinking of it as fixed.
> > I'm thinking of the *default* number of pci host bridges
> > as fixed. If a user is smart enough to use -device to create
> > a host bridge, said user can learn about -device for creating
> > a nic.
> 
> Hm, I guess.  I'm still uncomfortable with breaking a documented
> option, even if its not the preferred method these days.

Let's add 

> > > In qemu we create one always as a convenience, but
> > > users can (and will have to, for vfio) create additional ones
> > > trivially with -device.
> > 
> > So they know about -device then.
> > 
> > > [Which raises another complication as a tangent.  People (and libvirt)
> > > don't generally expect -nodefaults to remove the PCI bridge, but
> > > arguably it should on spapr, since a PAPR guest with no PCI is
> > > perfectly viable but there's currently no way to specify such a
> > > thing.]
> > 
> > I guess the problem is not what they expect generally,
> > but specifically that some users might rely on spapr with
> > -nodefaults having PCI?
> 
> I'm pretty sure libvirt will rely on that, if nothing else.
> 
> > I don't have any ideas besides introducing a new machine type
> > that 

Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

[Nicholas A. Bellinger]

On Thu, 2013-05-30 at 06:17 +0800, Asias He wrote:
> On Wed, May 29, 2013 at 08:10:44AM -0700, Badari Pulavarty wrote:
> > On 05/29/2013 02:05 AM, Wenchao Xia wrote:
> > >于 2013-5-28 17:00, Wenchao Xia 写道:



> > >  I have done a basic test of vhost-scsi, following is the result I'd
> > >like to post, generally it seems fine:
> > >
> > >Result:
> > >  fdisk/mkfs: fdisk can find it, mke2fs works fine.
> > >  mount: can mount it.
> > >  file I/O: dd 90M zero to a file in that disk succeed.
> > 
> > 
> > 
> > I tried without nested kvm.
> > 
> > >
> > >Issues:
> > >  1) in fdisk -l, sometime timeout with dmesg "end_request: I/O error,
> > >dev  fd0, sector 0", I guess it is caused by nested KVM that failed
> > >to kick host kernel?
> > 
> > 
> > I don't see this issue. Are you sure "fd0" is actually the scsi device ?
> > what is "fd0" ?
> > 
> > >  2) in fdisk -l, it shows 512 bytes larger than the parameter I
> > >specified in fd_dev_size parameter in configfs on host.(shows
> > >104858112 bytes, see the invocation script below)
> > >
> > 
> > I see the same. For some reason "fdisk -l" in the VM shows
> > 512-bytes more than the actual size for the file (on the host).
> 
> Hmm, interesting. Will look into it.
> 
> Nick, Any ideas here?
> 

Mmm, fd_get_blocks() is not returning the expected minus one logical
blocks with a !S_ISBLK() setup.

This is happening for every other backend ->get_blocks() call already,
and should be happening for the fd_dev_size case as well.

Applying the following to target-pending.git now.

diff --git a/drivers/target/target_core_file.c 
b/drivers/target/target_core_file.c
index 1b1d544..8a2ac90 100644
--- a/drivers/target/target_core_file.c
+++ b/drivers/target/target_core_file.c
@@ -694,11 +694,12 @@ static sector_t fd_get_blocks(struct se_device *dev)
 * to handle underlying block_device resize operations.
 */
if (S_ISBLK(i->i_mode))
-   dev_size = (i_size_read(i) - fd_dev->fd_block_size);
+   dev_size = i_size_read(i);
else
dev_size = fd_dev->fd_dev_size;
 
-   return div_u64(dev_size, dev->dev_attrib.block_size);
+   return div_u64(dev_size - fd_dev->fd_block_size,
+  dev->dev_attrib.block_size);
 }
 
 static struct sbc_ops fd_sbc_ops = {

Re: [Qemu-devel] [PATCH v2 1/3] block: add basic backup support to block driver

[Fam Zheng]

On Mon, 04/29 09:42, Stefan Hajnoczi wrote:
> +
> +static void coroutine_fn backup_run(void *opaque)
> +{
> +BackupBlockJob *job = opaque;
> +BlockDriverState *bs = job->common.bs;
> +assert(bs);
> +
> +int64_t start, end;
> +
> +start = 0;
> +end = DIV_ROUND_UP(bdrv_getlength(bs) / BDRV_SECTOR_SIZE,
> +   BACKUP_BLOCKS_PER_CLUSTER);
> +
> +job->bitmap = hbitmap_alloc(end, 0);
> +
> +DPRINTF("backup_run start %s %" PRId64 " %" PRId64 "\n",
> +bdrv_get_device_name(bs), start, end);
> +
> +int ret = 0;
> +
> +for (; start < end; start++) {
> +if (block_job_is_cancelled(&job->common)) {
> +ret = -1;
> +break;
> +}
> +
> +/* we need to yield so that qemu_aio_flush() returns.
> + * (without, VM does not reboot)
> + */
> +if (job->common.speed) {
> +uint64_t delay_ns = ratelimit_calculate_delay(
> +&job->limit, job->sectors_read);
> +job->sectors_read = 0;
> +block_job_sleep_ns(&job->common, rt_clock, delay_ns);
> +} else {
> +block_job_sleep_ns(&job->common, rt_clock, 0);
> +}
> +
> +if (block_job_is_cancelled(&job->common)) {
> +ret = -1;
> +break;
> +}
> +
> +if (hbitmap_get(job->bitmap, start)) {
> +continue; /* already copied */
> +}
> +
> +DPRINTF("backup_run loop C%" PRId64 "\n", start);
> +
> +/**
> + * This triggers a cluster copy
> + * Note: avoid direct call to brdv_co_backup_cow, because
> + * this does not call tracked_request_begin()
> + */
> +ret = bdrv_co_backup(bs, start*BACKUP_BLOCKS_PER_CLUSTER, 1);
> +if (ret < 0) {
> +break;
> +}
> +/* Publish progress */
> +job->common.offset += BACKUP_CLUSTER_SIZE;
> +}
> +
> +/* wait until pending backup_do_cow()calls have completed */
> +qemu_co_rwlock_wrlock(&job->rwlock);
> +qemu_co_rwlock_unlock(&job->rwlock);
> +
> +hbitmap_free(job->bitmap);
> +
> +bdrv_delete(job->target);
> +
> +DPRINTF("backup_run complete %d\n", ret);
> +block_job_completed(&job->common, ret);
> +}

What will ret value be when the source block is not aligned to cluster
size?

Fam

Re: [Qemu-devel] [PATCH 6/8] pci: Simpler implementation of primary PCI bus

[David Gibson]

On Wed, May 29, 2013 at 03:22:29PM +0300, Michael S. Tsirkin wrote:
> On Wed, May 29, 2013 at 09:04:00PM +1000, David Gibson wrote:
> > On Wed, May 29, 2013 at 01:17:13PM +0300, Michael S. Tsirkin wrote:
> > > On Wed, May 29, 2013 at 08:06:42PM +1000, David Gibson wrote:
> > > > On Wed, May 29, 2013 at 12:55:53PM +0300, Michael S. Tsirkin wrote:
> > > > > On Wed, May 29, 2013 at 07:43:41PM +1000, David Gibson wrote:
> > > > > > On Thu, May 23, 2013 at 10:16:27PM +1000, David Gibson wrote:
> > > > > > > On Thu, May 23, 2013 at 02:22:30PM +0300, Michael S. Tsirkin 
> > > > > > > wrote:
> > > > > > > > On Thu, May 09, 2013 at 10:31:10AM +1000, David Gibson wrote:
> > > > > > > > > Currently pci_get_primary_bus() searches the list of root 
> > > > > > > > > buses for one
> > > > > > > > > with domain 0.  But since host buses are always registered 
> > > > > > > > > with domain 0,
> > > > > > > > > this just amounts to finding the only PCI host bus.
> > > > > > > > > 
> > > > > > > > > This simplifies the implementation by defining the primary 
> > > > > > > > > PCI bus to
> > > > > > > > > be the first one registered, using a global variable to track 
> > > > > > > > > it.
> > > > > > > > > 
> > > > > > > > > Signed-off-by: David Gibson 
> > > > > > > > 
> > > > > > > > Or better: can we just fail if there is more than
> > > > > > > > one root?
> > > > > > > 
> > > > > > > That might work, I'll look into doing that.
> > > > > > 
> > > > > > So, the difficulty with this is that then any machine with multiple
> > > > > > PCI bridges could not use pci_nic_init(), since it calls
> > > > > > pci_get_bus_devfn() which calls pci_find_primary_bus() which would
> > > > > > always fail.  And using pci_nic_init() is more or less mandatory in
> > > > > > the machine_init function to support old-style nic configuration.
> > > > > > 
> > > > > > Suggestions?
> > > > > 
> > > > > You mean multiple PCI roots?
> > > > > Well, there are no legacy machines with multiple roots to support, are
> > > > > there?  So why do we need to support legacy flags for these new
> > > > > configurations?
> > > > 
> > > > Because people expect them.
> > > 
> > > People can learn, somehow they will learn to add a new root, so they can
> > > learn to use -device too.
> > 
> > Hrm.  I'd kind of like a second (third?) opinion on that.  Anthony?
> > 
> > > So let's make it fail on multiple roots, and output a message along the
> > > lines of "please use -device virtio-net-pci instead".
> > 
> > How to produce a meaningful error like that isn't totally obvious,
> > since the test for multiple roots is down in find_primary_pci_bus()
> > (or whatever), and once we get back up to pci_nic_init() we just know
> > that pci_get_bus_devfn() failed for some reason.
> 
> What other possible reason for it to fail?

Unparseable address (it can be user specified) or internal failure to
initialize the device are the first two that spring to mind..

> > > > Plus on spapr we already support the
> > > > legacy nic options; it would be very strange for them to suddenly
> > > > break when we add a second host bridge.
> > > 
> > > Not sure who "we" is here. IMHO user should ask for a new
> > > machine type with two roots explicitly.
> > 
> > You seem to be thinking of the number of host bridges as a fixed
> > property of the platform, which it isn't on spapr.  PCI host bridges
> > are just another device.  Large scale real hardware can easily have
> > dozens of them.
> 
> Absolutely. I'm not thinking of it as fixed.
> I'm thinking of the *default* number of pci host bridges
> as fixed. If a user is smart enough to use -device to create
> a host bridge, said user can learn about -device for creating
> a nic.

Hm, I guess.  I'm still uncomfortable with breaking a documented
option, even if its not the preferred method these days.

> > In qemu we create one always as a convenience, but
> > users can (and will have to, for vfio) create additional ones
> > trivially with -device.
> 
> So they know about -device then.
> 
> > [Which raises another complication as a tangent.  People (and libvirt)
> > don't generally expect -nodefaults to remove the PCI bridge, but
> > arguably it should on spapr, since a PAPR guest with no PCI is
> > perfectly viable but there's currently no way to specify such a
> > thing.]
> 
> I guess the problem is not what they expect generally,
> but specifically that some users might rely on spapr with
> -nodefaults having PCI?

I'm pretty sure libvirt will rely on that, if nothing else.

> I don't have any ideas besides introducing a new machine type
> that is same as spapr but without the default PCI host bridge.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: Digital signature

Re: [Qemu-devel] [PATCH v2 2/2] i.MX: unify all function and variale name convention in GPT

[Peter Chubb]

>  
> -static char const *imx_timerg_reg_name(uint32_t reg)
> +static char const *imx_timer_gpt_reg_name(uint32_t reg)

You could just use imc_gpt_xxx in line with the imx_epit_xxx naming
from your other patch series.


Otherwise this looks good.

--
Dr Peter Chubb  peter.chubb AT nicta.com.au
http://www.ssrg.nicta.com.au  Software Systems Research Group/NICTA

[Qemu-devel] EC space vs SystemIO for cpu hotplug

[li guang]

Hi, Igor and all

based on the patches "pass cpu online/offline event bewteen QEMU",
http://lists.nongnu.org/archive/html/qemu-devel/2013-05/msg04135.html

I'd like to go further, IMHO, too many specific operation regions of
SystemIO have been created for specific usage, like pci-hotplug,
cpu-hotplug, pvpanic, debugcon, and so on, are not so good thing,
in real world, obviously none of them, and more worse, they themselves
and operations are scattered in several code snippets.

but via EC's ACPI space, the *created* SystemIOs can be totally removed,
and we got a centrally controlled and rational and flexible approach for
OS and platform communication, because EC is standard and it really
exists in real world(hardware platform).

may you think of it, if we can use EC space instead of specific SystemIO
for cpu hotplug case, I append a simple patch for seabios.


diff --git a/src/acpi-dsdt-cpu-hotplug.dsl
b/src/acpi-dsdt-cpu-hotplug.dsl
index 0f3e83b..869373b 100644
--- a/src/acpi-dsdt-cpu-hotplug.dsl
+++ b/src/acpi-dsdt-cpu-hotplug.dsl
@@ -6,6 +6,7 @@ Scope(\_SB) {
 /* Objects filled in by run-time generated SSDT */
 External(NTFY, MethodObj)
 External(CPON, PkgObj)
+External(PRS, BuffObj)
 
 /* Methods called by run-time generated SSDT Processor objects */
 Method(CPMA, 1, NotSerialized) {
@@ -38,10 +39,10 @@ Scope(\_SB) {
 }
 
 /* CPU hotplug notify method */
-OperationRegion(PRST, SystemIO, 0xaf00, 32)
-Field(PRST, ByteAcc, NoLock, Preserve) {
-PRS, 256
-}
+//   OperationRegion(PRST, SystemIO, 0xaf00, 32)
+//Field(PRST, ByteAcc, NoLock, Preserve) {
+//  PRS, 256
+//  }
 Method(PRSC, 0) {
 // Local5 = active cpu bitmap
 Store(PRS, Local5)
diff --git a/src/acpi-dsdt-isa.dsl b/src/acpi-dsdt-isa.dsl
index 2b9c3a0..4567edb 100644
--- a/src/acpi-dsdt-isa.dsl
+++ b/src/acpi-dsdt-isa.dsl
@@ -117,6 +117,7 @@ Scope(\_SB.PCI0.ISA) {
Offset(1),
CPUS,   8,  // 1, CPU plug/unplug status map
CPUN,   8,  // 2, CPU index
+   PRS,256,// 3. CPU status map
}
 
Name(_GPE, 3)

[Qemu-devel] [SeaBIOS PATCH v2] boot: fix fw_dev_path pattern to match q35

[Amos Kong]

We match pci domain by "/pci@i0cf8" in SeaBIOS, but fw_dev_path prefix
of q35 is "/q35-pcihost@i0cf8". It causes boot priority of q35 devices
could not be changed by bootindex parameter in QEMU.

I have a patch to change typename of q35 to 'pci-q35', this patch fixes
the pattern to match both pc-i440fx and q35.

Signed-off-by: Amos Kong 
---
v2: use exact pattern
---
 src/boot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/boot.c b/src/boot.c
index c308602..300ecc3 100644
--- a/src/boot.c
+++ b/src/boot.c
@@ -97,7 +97,7 @@ find_prio(const char *glob)
 return -1;
 }
 
-#define FW_PCI_DOMAIN "/pci@i0cf8"
+#define FW_PCI_DOMAIN "/pci*@i0cf8"
 
 static char *
 build_pci_path(char *buf, int max, const char *devname, struct pci_device *pci)
-- 
1.8.1.4

[Qemu-devel] [PATCH] pci: change typename of q35 to pci-q35

[Amos Kong]

In QEMU, we set the firmware name of pc-i440fx is 'pci', and set the
firmware name of q35 is 'q35-pcihost'.

The seabios pattern matching code isn't sophisticated, and we want to
match those two devices with exact pattern.

This patch changes the typename of q35 to 'pci-q35', all pci devices
use same prefix 'pci' in fireware name. And I will change pattern in
seabios to "/pci*@i0cf8".

Signed-off-by: Amos Kong 
---
 include/hw/pci-host/q35.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/hw/pci-host/q35.h b/include/hw/pci-host/q35.h
index e182c82..3579fb0 100644
--- a/include/hw/pci-host/q35.h
+++ b/include/hw/pci-host/q35.h
@@ -34,7 +34,7 @@
 #include "hw/acpi/ich9.h"
 #include "hw/pci-host/pam.h"
 
-#define TYPE_Q35_HOST_DEVICE "q35-pcihost"
+#define TYPE_Q35_HOST_DEVICE "pci-q35"
 #define Q35_HOST_DEVICE(obj) \
  OBJECT_CHECK(Q35PCIHost, (obj), TYPE_Q35_HOST_DEVICE)
 
-- 
1.8.1.4

Re: [Qemu-devel] [PATCH V3 0/4] qapi and snapshot code clean up in block layer

[Wenchao Xia]

于 2013-5-27 23:41, Kevin Wolf 写道:

Am 25.05.2013 um 05:09 hat Wenchao Xia geschrieben:

These patches are the common part of my hmp/qmp block query series and Pavel's
qmp snapshot command converion series. It mainly does following things:
1 move snapshot related code to block/snapshot.c, qmp and info dumping code to
block/qapi.c.
2 better info dumping function to get rid of buffer, avoid string truncation.


Posted comments on patch 1 and 4.

Patches 2 and 3 are:
Reviewed-by: Kevin Wolf 


  It seems nothing need change, Kevin, do you think it can be merged?

--
Best Regards

Wenchao Xia

Re: [Qemu-devel] snabbswitch integration with QEMU for userspace ethernet I/O

[ronnie sahlberg]

Julian,

Stefan's concerns are valid.

(Hopefully, kernel is harder to exploit and more carefully audited.)




On Wed, May 29, 2013 at 9:02 AM, Julian Stecklina
 wrote:
> On 05/29/2013 04:21 PM, Stefan Hajnoczi wrote:
>> The fact that a single switch process has shared memory access to all
>> guests' RAM is critical.  If the switch process is exploited, then that
>> exposes other guests' data!  (Think of a multi-tenant host with guests
>> belonging to different users.)
>
> True. But people don't mind having instruction decoding and half of
> virtio in the kernel these days, so it can't be that security critical...
>
> Julian
>

Re: [Qemu-devel] [PATCH 11/16] qemu-io: Move functions for registering and running commands

[Eric Blake]

On 05/28/2013 09:27 AM, Kevin Wolf wrote:
> Signed-off-by: Kevin Wolf 
> ---
>  cmd.c  | 113 -
>  cmd.h  |  11 +---
>  qemu-io-cmds.c | 192 
> ++---
>  qemu-io.c  |  10 +--
>  4 files changed, 148 insertions(+), 178 deletions(-)

Reviewed-by: Eric Blake 

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

[Wenchao Xia]

于 2013-5-29 23:10, Badari Pulavarty 写道:
> On 05/29/2013 02:05 AM, Wenchao Xia wrote:
>> 于 2013-5-28 17:00, Wenchao Xia 写道:
>>> 于 2013-5-28 16:33, Asias He 写道:
 On Tue, May 28, 2013 at 10:01:14AM +0200, Paolo Bonzini wrote:
> Il 28/05/2013 09:13, Wenchao Xia ha scritto:
 From: Nicholas Bellinger 

 The WWPN specified in configfs is passed to "-device 
 vhost-scsi-pci".
 The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is
 not
 available from the QEMU command-line.  Instead, I hardcode it to
 zero.

>> Hi, Paolo
>>Any document about how to config it correctly in configfs, before
>> invoking qemu with the WWPN number?
>
> Unfortunately no, but vhost-scsi doesn't have many knobs (unlike
> iSCSI for example) so it's quite simple.  Here is an example:
>
> cd /sys/kernel/config/target
> mkdir -p core/fileio_0/fileio
> echo 'fd_dev_name=/home/pbonzini/test.img,fd_dev_size=5905580032' >
> core/fileio_0/fileio/control
> echo 1 > core/fileio_0/fileio/enable
> mkdir -p vhost/naa.600140554cf3a18e/tpgt_0/lun/lun_0
> cd vhost/naa.600140554cf3a18e/tpgt_0
> ln -sf ../../../../../core/fileio_0/fileio/ 
> lun/lun_0/virtual_scsi_port
> echo naa.60014053226f0388 > nexus
>
> The "nexus" value is the initiator WWN. naa.600140554cf3a18e is the
> target WWN that you have to pass to "-device vhost-scsi-pci".
>
> Paolo

 For me, I always use targetcli utils instead of the sysfs interface.
 targetcli in F18 has vhost support now.

>>>Thanks very much for above information, I'll try it for test.
>>>
>>   I have done a basic test of vhost-scsi, following is the result I'd
>> like to post, generally it seems fine:
>>
>> Result:
>>   fdisk/mkfs: fdisk can find it, mke2fs works fine.
>>   mount: can mount it.
>>   file I/O: dd 90M zero to a file in that disk succeed.
> 
> 
> 
> I tried without nested kvm.
> 
>>
>> Issues:
>>   1) in fdisk -l, sometime timeout with dmesg "end_request: I/O error,
>> dev  fd0, sector 0", I guess it is caused by nested KVM that failed
>> to kick host kernel?
> 
> 
> I don't see this issue. Are you sure "fd0" is actually the scsi device ?
> what is "fd0" ?
> 
  I am not sure, it just come out from dmesg when fdisk -l hung, and
following line is "sdb" which is the vhost-scsi device, and fdisk
printing stopped before "sdb" for a few seconds, so I think it's it.
it happened once after my partition operation.
  My instinct opinion is it happens only in nested KVM when host
missed a kick, since following I/O can succeed. Sadly I have no
bare-metal at hand to test as a comparation.

>>   2) in fdisk -l, it shows 512 bytes larger than the parameter I
>> specified in fd_dev_size parameter in configfs on host.(shows
>> 104858112 bytes, see the invocation script below)
>>
> 
> I see the same. For some reason "fdisk -l" in the VM shows
> 512-bytes more than the actual size for the file (on the host).
> 
> Thanks,
> Badari
> 


-- 
Best Regards

Wenchao Xia

Re: [Qemu-devel] [PATCH v3 4/5] xilinx_devcfg: Zynq devcfg device model

[Peter Crosthwaite]

Hi Anthony,

On Thu, May 30, 2013 at 3:57 AM, Anthony Liguori  wrote:
> peter.crosthwa...@xilinx.com writes:
>
>> From: "Peter A. G. Crosthwaite" 
>>
>> Minimal device model for devcfg module of Zynq. DMA capabilities and
>> interrupt generation supported.
>>
>> Signed-off-by: Peter A. G. Crosthwaite 
>> ---
>> Changed since v2:
>> Some QOM styling updates.
>> Re-implemented nw0 for lock register as pre_write
>> Changed since v1:
>> Rebased against new version of Register API.
>> Use action callbacks for side effects rather than switch.
>> Documented reasons for ge0, ge1 (Verbatim from TRM)
>> Added ui1 definitions for unimplemented major features
>> Removed dead lock code
>>
>>  default-configs/arm-softmmu.mak |   1 +
>>  hw/dma/Makefile.objs|   1 +
>>  hw/dma/xilinx_devcfg.c  | 495 
>> 
>>  3 files changed, 497 insertions(+)
>>  create mode 100644 hw/dma/xilinx_devcfg.c
>>
>> diff --git a/default-configs/arm-softmmu.mak 
>> b/default-configs/arm-softmmu.mak
>> index 27cbe3d..5a17f64 100644
>> --- a/default-configs/arm-softmmu.mak
>> +++ b/default-configs/arm-softmmu.mak
>> @@ -61,6 +61,7 @@ CONFIG_PXA2XX=y
>>  CONFIG_BITBANG_I2C=y
>>  CONFIG_FRAMEBUFFER=y
>>  CONFIG_XILINX_SPIPS=y
>> +CONFIG_ZYNQ_DEVCFG=y
>>
>>  CONFIG_A9SCU=y
>>  CONFIG_MARVELL_88W8618=y
>> diff --git a/hw/dma/Makefile.objs b/hw/dma/Makefile.objs
>> index 0e65ed0..96025cf 100644
>> --- a/hw/dma/Makefile.objs
>> +++ b/hw/dma/Makefile.objs
>> @@ -5,6 +5,7 @@ common-obj-$(CONFIG_PL330) += pl330.o
>>  common-obj-$(CONFIG_I82374) += i82374.o
>>  common-obj-$(CONFIG_I8257) += i8257.o
>>  common-obj-$(CONFIG_XILINX_AXI) += xilinx_axidma.o
>> +common-obj-$(CONFIG_ZYNQ_DEVCFG) += xilinx_devcfg.o
>>  common-obj-$(CONFIG_ETRAXFS) += etraxfs_dma.o
>>  common-obj-$(CONFIG_STP2000) += sparc32_dma.o
>>  common-obj-$(CONFIG_SUN4M) += sun4m_iommu.o
>> diff --git a/hw/dma/xilinx_devcfg.c b/hw/dma/xilinx_devcfg.c
>> new file mode 100644
>> index 000..b82b7cc
>> --- /dev/null
>> +++ b/hw/dma/xilinx_devcfg.c
>> @@ -0,0 +1,495 @@
>> +/*
>> + * QEMU model of the Xilinx Devcfg Interface
>> + *
>> + * Copyright (c) 2011 Peter A.G. Crosthwaite 
>> (peter.crosthwa...@petalogix.com)
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining a 
>> copy
>> + * of this software and associated documentation files (the "Software"), to 
>> deal
>> + * in the Software without restriction, including without limitation the 
>> rights
>> + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
>> + * copies of the Software, and to permit persons to whom the Software is
>> + * furnished to do so, subject to the following conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be included 
>> in
>> + * all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
>> OR
>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
>> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
>> OTHER
>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
>> FROM,
>> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
>> + * THE SOFTWARE.
>> + */
>> +
>> +#include "sysemu/sysemu.h"
>> +#include "sysemu/dma.h"
>> +#include "hw/sysbus.h"
>> +#include "hw/ptimer.h"
>> +#include "qemu/bitops.h"
>> +#include "hw/register.h"
>> +#include "qemu/bitops.h"
>> +
>> +#define TYPE_XILINX_DEVCFG "xlnx.ps7-dev-cfg"
>> +
>> +#define XILINX_DEVCFG(obj) \
>> +OBJECT_CHECK(XilinxDevcfg, (obj), TYPE_XILINX_DEVCFG)
>> +
>> +/* FIXME: get rid of hardcoded nastiness */
>> +
>> +#define FREQ_HZ 9
>> +
>> +#define BTT_MAX 0x400 /* bytes to transfer per delay inteval */
>> +#define CYCLES_BTT_MAX 1 /*approximate 10k cycles per delay interval */
>> +
>> +#ifndef XILINX_DEVCFG_ERR_DEBUG
>> +#define XILINX_DEVCFG_ERR_DEBUG 0
>> +#endif
>> +#define DB_PRINT(...) do { \
>> +if (XILINX_DEVCFG_ERR_DEBUG) { \
>> +fprintf(stderr,  ": %s: ", __func__); \
>> +fprintf(stderr, ## __VA_ARGS__); \
>> +} \
>> +} while (0);
>> +
>> +#define R_CTRL(0x00/4)
>> +#define FORCE_RST(1 << 31) /* Not supported, writes ignored 
>> */
>> +#define PCAP_PR  (1 << 27) /* Forced to 0 on bad unlock */
>> +#define PCAP_MODE(1 << 26)
>> +#define MULTIBOOT_EN (1 << 24)
>> +#define USER_MODE(1 << 15)
>> +#define PCFG_AES_FUSE(1 << 12) /* locked by AES_FUSE_LOCK */
>> +#define PCFG_AES_EN_SHIFT9 /* locked by AES_EN_LOCK */
>> +#define PCFG_AES_EN_LEN  3 /* locked by AES_EN_LOCK */
>> +#define PCFG_AES_EN_MASK (((1 << PCFG_AES_EN_LEN) - 1) \
>> +<< PCFG_AES_EN_SHIFT)
>> 

Re: [Qemu-devel] [coreboot] [SeaBIOS] SeaBIOS v1.7.2.2 stable release

[Kevin O'Connor]

On Wed, May 29, 2013 at 09:27:16AM +0200, Gerd Hoffmann wrote:
> While talking about releases:  There are quite some changes accumulated
> in master, time to cut a new release I think.  Given that sorting the
> acpi table issue seems to take more time than expected, how about freeze
> + call for patches _now_, release 1.7.3 some-when in June, then plan to
> merge the apci changes (however it works out) for 1.7.4?

Makes sense.

-Kevin

Re: [Qemu-devel] [SeaBIOS PATCH] boot: fix fw_dev_path pattern for q35-pcihost

[Kevin O'Connor]

On Wed, May 29, 2013 at 10:33:54AM +0800, Amos Kong wrote:
> On Tue, May 28, 2013 at 06:59:02PM -0400, Kevin O'Connor wrote:
> > On Tue, May 28, 2013 at 08:28:14PM +0800, Amos Kong wrote:
> > > -#define FW_PCI_DOMAIN "/pci@i0cf8"
> > > +#define FW_PCI_DOMAIN "/*pci*@i0cf8"
> > 
> > The seabios pattern matching code isn't that sophisticated - I think
> > this could end up doing something unexpected.  Why does it need to
> > change?
> 
> If we start a guest with default machine type (pc-i440fx), the prefix
> of bootindex string is "/pci@i0cf8", if we start guest with -M q35,
> the prefix will become "/q35-pcihost@i0cf8".
> 
> We only match "/pci@i0cf8" in seabios, it causes boot priority of q35
> devices could not be changed.
> 
> We could not change TYPE_Q35_HOST_DEVICE to 'pci' in qemu to adapt
> seabios, so fix the pattern.

It really can't be changed?

> I see glob_prefix() is not powerful, "/*pci*@i0cf8" & "/*@i0cf8" all
> work.
> 
> Or change TYPE_Q35_HOST_DEVICE to "pci-q35" in qemu, and use
> "/pci*@i0cf8" in seabios ?

That would be preferable.

-Kevin

Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28

[Kevin O'Connor]

On Wed, May 29, 2013 at 11:18:03AM -0500, Anthony Liguori wrote:
> Gerd Hoffmann  writes:
> > On 05/29/13 01:53, Kevin O'Connor wrote:
> >> Raised
> >> that QOM interface should be sufficient.
> >
> > Agree on this one.  Ideally the acpi table generation code should be
> > able to gather all information it needs from the qom tree, so it can be
> > a standalone C file instead of being scattered over all qemu.
> 
> Ack.  So my basic argument is why not expose the QOM interfaces to
> firmware and move the generation code there?

I remain doubtful that QOM has all the info needed to generate the
BIOS tables.  Does QOM describe how the 5th pci device uses global
interrupt 11 when using global interrupts, legacy interrupt 5 when not
using global interrupts, and that the legacy interrupt can be changed
by writing to the 0x60 address of the 1st pci device's config space?
Does QOM state that the machine supports S3 sleep mode?  Does QOM
indicate that an IPMI device supports the 3rd version of the IPMI
device specification?

I don't see how exporting QOM to the firmware will help.  I predict we
would continue to see most of the BIOS tables hardcoded in the
firmware and that all but the most minor changes to those tables would
require synchronizing code patches to both QEMU and the firmware.  I
also suspect we would end up adding fields to QOM that only the BIOS
tables cared about, and that ever increasing code would be needed in
both QEMU and the firmware to juggle to/from QOM so that the BIOS
tables could be created.

-Kevin

Re: [Qemu-devel] [PATCH v2] i.MX: Improve EPIT timer code.

[peter]

Jean-Christophe wrote:

This is fine by me ...

> * Unify function and type naming
> * use dynamic cast whenever possible
> * simplify Debug printf.
> * use new style device intialization.
> 
> Signed-off-by: Jean-Christophe DUBOIS 

Reviewed-by: Peter Chubb 


Peter C

Re: [Qemu-devel] [PATCH v2] monitor: work around delayed CHR_EVENT_OPENED events

[mdroth]

On Wed, May 29, 2013 at 01:27:33PM -0400, Luiz Capitulino wrote:
> On Mon, 27 May 2013 12:59:25 -0500
> mdroth  wrote:
> 
> > On Mon, May 27, 2013 at 11:16:01AM -0500, Anthony Liguori wrote:
> > > Luiz Capitulino  writes:
> > > 
> > > > On Sun, 26 May 2013 10:33:39 -0500
> > > > Michael Roth  wrote:
> > > >
> > > >> In the past, CHR_EVENT_OPENED events were emitted via a pre-expired
> > > >> QEMUTimer. Due to timers being processing at the tail end of each main
> > > >> loop iteration, this generally meant that such events would be emitted
> > > >> within the same main loop iteration, prior any client data being read
> > > >> by tcp/unix socket server backends.
> > > >> 
> > > >> With 9f939df955a4152aad69a19a77e0898631bb2c18, this was switched to
> > > >> a "bottom-half" that is registered via g_idle_add(). This makes it
> > > >> likely that the event won't be sent until a subsequent iteration, and
> > > >> also adds the possibility that such events will race with the
> > > >> processing of client data.
> > > >> 
> > > >> In cases where we rely on the CHR_EVENT_OPENED event being delivered
> > > >> prior to any client data being read, this may cause unexpected 
> > > >> behavior.
> > > >> 
> > > >> In the case of a QMP monitor session using a socket backend, the 
> > > >> delayed
> > > >> processing of the CHR_EVENT_OPENED event can lead to a situation where
> > > >> a previous session, where 'qmp_capabilities' has already processed, can
> > > >> cause the rejection of 'qmp_capabilities' for a subsequent session,
> > > >> since we reset capabilities in response to CHR_EVENT_OPENED, which may
> > > >> not yet have been delivered. This can be reproduced with the following
> > > >> command, generally within 50 or so iterations:
> > > >> 
> > > >>   mdroth@loki:~$ cat cmds
> > > >>   {'execute':'qmp_capabilities'}
> > > >>   {'execute':'query-cpus'}
> > > >>   mdroth@loki:~$ while true; do if socat stdio 
> > > >> unix-connect:/tmp/qmp.sock
> > > >>   /dev/null; then echo failed; break; 
> > > >> else
> > > >>   echo ok; fi; done;
> > > >>   ok
> > > >>   ok
> > > >>   failed
> > > >>   mdroth@loki:~$
> > > >> 
> > > >> As a work-around, we reset capabilities as part of the CHR_EVENT_CLOSED
> > > >> hook, which gets called as part of the GIOChannel cb associated with 
> > > >> the
> > > >> client rather than a bottom-half, and is thus guaranteed to be 
> > > >> delivered
> > > >> prior to accepting any subsequent client sessions.
> > > >> 
> > > >> This does not address the more general problem of whether or not there
> > > >> are chardev users that rely on CHR_EVENT_OPENED being delivered prior 
> > > >> to
> > > >> client data, and whether or not we should consider moving 
> > > >> CHR_EVENT_OPENED
> > > >> "in-band" with connection establishment as a general solution, but 
> > > >> fixes
> > > >> QMP for the time being.
> > > >> 
> > > >> Reported-by: Stefan Priebe 
> > > >> Cc: qemu-sta...@nongnu.org
> > > >> Signed-off-by: Michael Roth 
> > > >
> > > > Thanks for debugging this Michael. I'm going to apply your patch to the 
> > > > qmp
> > > > branch because we can't let this broken (esp. in -stable) but this is 
> > > > papering
> > > > over the real bug...
> > > 
> > > Do we really need OPENED to happen in a bottom half?  Shouldn't the open
> > > event handlers register the callback instead if they need it?
> > 
> > I think that's the more general fix, but wasn't sure if there were
> > historical reasons why we didn't do this in the first place.
> > 
> > Looking at it more closely it does seem like we need a general fix
> > sooner rather than later though, and I don't see any reason why we can't
> > move BH registration into the actual OPENED hooks as you suggest:
> > 
> > hw/usb/ccid-card-passthru.c
> >  - currently affected? no
> > debug hook only
> >  - needs OPENED BH? no
> > 
> > hw/usb/redirect.c
> >  - currently affected? yes
> > can_read handler checks for dev->parser != NULL, which may be
> > true if CLOSED BH has been executed yet. In the past, OPENED
> > quiesced outstanding CLOSED events prior to us reading client data.
> >  - need OPENED BH? possibly
> > seems to only be needed by CLOSED events, which can be issued by
> > USBDevice, so we do teardown/usb_detach in BH. For OPENED, this
> > may not apply. if we do issue a BH, we'd need to modify can_read
> > handler to avoid race.
> > 
> > hw/usb/dev-serial.c
> >  - currently affected? no
> > can_read checks for dev.attached != NULL. set to NULL
> > synchronously in CLOSED, will not accept reads until OPENED gets
> > called and sets dev.attached
> >  - need opened BH?  no
> > 
> > hw/char/sclpconsole.c
> >  - currently affected? no
> > guarded by can_read handler
> >  - need opened BH? no
> > 
> > hw/char/ipoctal232.c
> >  - currently affected? no
> > debug hook only
> >  - need opened BH? no
> > 
> > hw/char/virtio-console.c
> >  - currently affected? no
> > OPENED/CLOSED map to vq even

[Qemu-devel] [PATCH] qemu-char: don't issue CHR_EVENT_OPEN in a BH

[Michael Roth]

When CHR_EVENT_OPEN was initially added, it was CHR_EVENT_RESET, and
it was issued as a bottom-half:

86e94dea5b740dad65446c857f6959eae43e0ba6

AFAICT the only reason this was ever done in a BH was because it was
initially used to to issue a CHR_EVENT_RESET when we initialized the
monitor, and we would in some cases modify the chr_write handler for
a new chardev backend *after* the site where we issued the reset
(see: 86e94d:qemu_chr_open_stdio())

So we executed the reset in a BH to ensure the chardev was fully
initialized before we executed the CHR_EVENT_RESET handler (which
generally involved printing out a greeting/prompt for the monitor).

At some point this event was renamed to CHR_EVENT_OPEN, and we've
maintained the use of this BH ever since.

However, due to 9f939df955a4152aad69a19a77e0898631bb2c18, we schedule
the BH via g_idle_add(), which is causing events to sometimes be
delivered after we've already begun processing data from backends,
leading to:

 known bugs:

  QMP:
session negotation resets with OPEN event, in some cases this
is causing new sessions to get sporadically reset

 potential bugs:

  hw/usb/redirect.c:
can_read handler checks for dev->parser != NULL, which may be
true if CLOSED BH has not been executed yet. In the past, OPENED
quiesced outstanding CLOSED events prior to us reading client
data. If it's delayed, our check may allow reads to occur even
though we haven't processed the OPENED event yet, and when we
do finally get the OPENED event, our state may get reset.

  qtest.c:
can begin session before OPENED event is processed, leading to
a spurious reset of the system and irq_levels

  gdbstub.c:
may start a gdb session prior to the machine being paused

To fix these, let's just drop the BH.

Since the initial reasoning for using it still applies to an extent,
work around that be deferring the delivery of CHR_EVENT_OPENED until
after the chardevs have been fully initialized by setting a
'be_open_on_init' flag that gets checked toward the end of
qmp_chardev_add(). This defers delivery long enough that we can
be assured a CharDriverState is fully initialized before
CHR_EVENT_OPENED is sent.

Reported-by: Stefan Priebe 
Cc: qemu-sta...@nongnu.org
Signed-off-by: Michael Roth 
---
 backends/baum.c   |2 +-
 include/sysemu/char.h |2 +-
 qemu-char.c   |   29 ++---
 ui/console.c  |2 +-
 ui/gtk.c  |2 +-
 5 files changed, 14 insertions(+), 23 deletions(-)

diff --git a/backends/baum.c b/backends/baum.c
index 4cba79f..8384ef2 100644
--- a/backends/baum.c
+++ b/backends/baum.c
@@ -611,7 +611,7 @@ CharDriverState *chr_baum_init(void)
 
 qemu_set_fd_handler(baum->brlapi_fd, baum_chr_read, NULL, baum);
 
-qemu_chr_be_generic_open(chr);
+chr->be_open_on_init = true;
 
 return chr;
 
diff --git a/include/sysemu/char.h b/include/sysemu/char.h
index 5e42c90..dc7a0d8 100644
--- a/include/sysemu/char.h
+++ b/include/sysemu/char.h
@@ -70,13 +70,13 @@ struct CharDriverState {
 void (*chr_set_echo)(struct CharDriverState *chr, bool echo);
 void (*chr_set_fe_open)(struct CharDriverState *chr, int fe_open);
 void *opaque;
-int idle_tag;
 char *label;
 char *filename;
 int be_open;
 int fe_open;
 int explicit_fe_open;
 int avail_connections;
+bool be_open_on_init;
 QemuOpts *opts;
 QTAILQ_ENTRY(CharDriverState) next;
 };
diff --git a/qemu-char.c b/qemu-char.c
index 4f8382e..c553fbe 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -110,19 +110,9 @@ void qemu_chr_be_event(CharDriverState *s, int event)
 s->chr_event(s->handler_opaque, event);
 }
 
-static gboolean qemu_chr_be_generic_open_bh(gpointer opaque)
-{
-CharDriverState *s = opaque;
-qemu_chr_be_event(s, CHR_EVENT_OPENED);
-s->idle_tag = 0;
-return FALSE;
-}
-
 void qemu_chr_be_generic_open(CharDriverState *s)
 {
-if (s->idle_tag == 0) {
-s->idle_tag = g_idle_add(qemu_chr_be_generic_open_bh, s);
-}
+qemu_chr_be_event(s, CHR_EVENT_OPENED);
 }
 
 int qemu_chr_fe_write(CharDriverState *s, const uint8_t *buf, int len)
@@ -505,7 +495,7 @@ static CharDriverState *qemu_chr_open_mux(CharDriverState 
*drv)
 chr->chr_set_fe_open = NULL;
 
 /* Muxes are always open on creation */
-qemu_chr_be_generic_open(chr);
+chr->be_open_on_init = true;
 
 return chr;
 }
@@ -882,8 +872,7 @@ static CharDriverState *qemu_chr_open_fd(int fd_in, int 
fd_out)
 chr->chr_write = fd_chr_write;
 chr->chr_update_read_handler = fd_chr_update_read_handler;
 chr->chr_close = fd_chr_close;
-
-qemu_chr_be_generic_open(chr);
+chr->be_open_on_init = true;
 
 return chr;
 }
@@ -1594,8 +1583,7 @@ static CharDriverState *qemu_chr_open_pp_fd(int fd)
 chr->chr_ioctl = pp_ioctl;
 chr->chr_close = pp_close;
 chr->opaque = drv;
-
-qemu_chr_be_generic_open(chr);
+chr->be_open_on_init = true;
 
 return chr;
 }
@

[Qemu-devel] [PATCH 10/20] ipmi: Add a local BMC simulation

[minyard]

From: Corey Minyard 

This provides a minimal local BMC, basically enough to comply with the
spec and provide a complete watchdog timer (including a sensor, SDR,
and event).

Signed-off-by: Corey Minyard 
---
 default-configs/i386-softmmu.mak   |1 +
 default-configs/x86_64-softmmu.mak |1 +
 hw/ipmi/Makefile.objs  |1 +
 hw/ipmi/ipmi_sim.c | 1551 
 4 files changed, 1554 insertions(+)
 create mode 100644 hw/ipmi/ipmi_sim.c

diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index bcd19d0..491bc24 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -14,6 +14,7 @@ CONFIG_IPMI=y
 CONFIG_ISA_IPMI=y
 CONFIG_IPMI_KCS=y
 CONFIG_IPMI_BT=y
+CONFIG_IPMI_LOCAL=y
 CONFIG_SERIAL=y
 CONFIG_PARALLEL=y
 CONFIG_I8254=y
diff --git a/default-configs/x86_64-softmmu.mak 
b/default-configs/x86_64-softmmu.mak
index 3f2ca2f..7c0caeb 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -14,6 +14,7 @@ CONFIG_IPMI=y
 CONFIG_ISA_IPMI=y
 CONFIG_IPMI_KCS=y
 CONFIG_IPMI_BT=y
+CONFIG_IPMI_LOCAL=y
 CONFIG_SERIAL=y
 CONFIG_PARALLEL=y
 CONFIG_I8254=y
diff --git a/hw/ipmi/Makefile.objs b/hw/ipmi/Makefile.objs
index a8cd463..2366160 100644
--- a/hw/ipmi/Makefile.objs
+++ b/hw/ipmi/Makefile.objs
@@ -2,3 +2,4 @@ common-obj-$(CONFIG_IPMI) += ipmi.o
 common-obj-$(CONFIG_ISA_IPMI) += isa_ipmi.o
 common-obj-$(CONFIG_IPMI_KCS) += ipmi_kcs.o
 common-obj-$(CONFIG_IPMI_BT) += ipmi_bt.o
+common-obj-$(CONFIG_IPMI_LOCAL) += ipmi_sim.o
diff --git a/hw/ipmi/ipmi_sim.c b/hw/ipmi/ipmi_sim.c
new file mode 100644
index 000..20a2585
--- /dev/null
+++ b/hw/ipmi/ipmi_sim.c
@@ -0,0 +1,1551 @@
+/*
+ * IPMI BMC emulation
+ *
+ * Copyright (c) 2012 Corey Minyard, MontaVista Software, LLC
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include "qemu/timer.h"
+#include "ipmi.h"
+
+#define IPMI_NETFN_CHASSIS0x00
+#define IPMI_NETFN_CHASSIS_MAXCMD 0x03
+
+#define IPMI_CMD_GET_CHASSIS_CAPABILITIES 0x00
+#define IPMI_CMD_GET_CHASSIS_STATUS   0x01
+#define IPMI_CMD_CHASSIS_CONTROL  0x02
+
+#define IPMI_NETFN_SENSOR_EVENT   0x04
+#define IPMI_NETFN_SENSOR_EVENT_MAXCMD0x2e
+
+#define IPMI_CMD_SET_SENSOR_EVT_ENABLE0x28
+#define IPMI_CMD_GET_SENSOR_EVT_ENABLE0x29
+#define IPMI_CMD_REARM_SENSOR_EVTS0x2a
+#define IPMI_CMD_GET_SENSOR_EVT_STATUS0x2b
+#define IPMI_CMD_GET_SENSOR_READING   0x2d
+
+/* #define IPMI_NETFN_APP 0x06 In ipmi.h */
+#define IPMI_NETFN_APP_MAXCMD 0x36
+
+#define IPMI_CMD_GET_DEVICE_ID0x01
+#define IPMI_CMD_RESET_WATCHDOG_TIMER 0x22
+#define IPMI_CMD_SET_WATCHDOG_TIMER   0x24
+#define IPMI_CMD_GET_WATCHDOG_TIMER   0x25
+#define IPMI_CMD_SET_BMC_GLOBAL_ENABLES   0x2e
+#define IPMI_CMD_GET_BMC_GLOBAL_ENABLES   0x2f
+#define IPMI_CMD_CLR_MSG_FLAGS0x30
+#define IPMI_CMD_GET_MSG_FLAGS0x31
+#define IPMI_CMD_READ_EVT_MSG_BUF 0x35
+
+#define IPMI_NETFN_STORAGE0x0a
+#define IPMI_NETFN_STORAGE_MAXCMD 0x4a
+
+#define IPMI_CMD_GET_SDR_REP_INFO 0x20
+#define IPMI_CMD_GET_SDR_REP_ALLOC_INFO   0x21
+#define IPMI_CMD_RESERVE_SDR_REP  0x22
+#define IPMI_CMD_GET_SDR  0x23
+#define IPMI_CMD_ADD_SDR  0x24
+#define IPMI_CMD_PARTIAL_ADD_SDR  0x25
+#define IPMI_CMD_DELETE_SDR   0x26
+#define IPMI_CMD_CLEAR_SDR_REP0x27
+#define IPMI_CMD_GET_SDR_REP_TIME 0x28
+#define IPMI_CMD_SET_SDR_REP_TIME 0x29
+#define IPMI_CMD_ENTER_SDR_REP_UPD_MODE   0x2A
+#define IPMI_CMD_EXIT_SDR_REP_UPD_MODE0x2B
+#define IPMI_CMD_RUN_INIT_AGENT   0x2C
+#define IPMI_CMD_GET_SEL_INFO 0x40
+#define IPMI_CMD_GET_SEL_ALLOC_INFO   0x41
+#define IPMI_CMD_RESERVE_SEL  0x42
+#d

[Qemu-devel] [PATCH 12/20] ipmi: Add tests

[minyard]

From: Corey Minyard 

Test the KCS interface with a local BMC and a BT interface with an
external BMC.

Signed-off-by: Corey Minyard 
---
 tests/Makefile|4 +
 tests/ipmi-bt-test.c  |  444 +
 tests/ipmi-kcs-test.c |  294 
 3 files changed, 742 insertions(+)
 create mode 100644 tests/ipmi-bt-test.c
 create mode 100644 tests/ipmi-kcs-test.c

diff --git a/tests/Makefile b/tests/Makefile
index a307d5a..e05f191 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -55,6 +55,8 @@ check-qtest-i386-y += tests/ide-test$(EXESUF)
 check-qtest-i386-y += tests/hd-geo-test$(EXESUF)
 gcov-files-i386-y += hw/hd-geometry.c
 check-qtest-i386-y += tests/rtc-test$(EXESUF)
+check-qtest-i386-y += tests/ipmi-kcs-test$(EXESUF)
+check-qtest-i386-y += tests/ipmi-bt-test$(EXESUF)
 check-qtest-i386-y += tests/i440fx-test$(EXESUF)
 check-qtest-i386-y += tests/fw_cfg-test$(EXESUF)
 check-qtest-x86_64-y = $(check-qtest-i386-y)
@@ -129,6 +131,8 @@ tests/rtc-test$(EXESUF): tests/rtc-test.o
 tests/m48t59-test$(EXESUF): tests/m48t59-test.o
 tests/fdc-test$(EXESUF): tests/fdc-test.o
 tests/ide-test$(EXESUF): tests/ide-test.o $(libqos-pc-obj-y)
+tests/ipmi-kcs-test$(EXESUF): tests/ipmi-kcs-test.o
+tests/ipmi-bt-test$(EXESUF): tests/ipmi-bt-test.o
 tests/hd-geo-test$(EXESUF): tests/hd-geo-test.o
 tests/tmp105-test$(EXESUF): tests/tmp105-test.o $(libqos-omap-obj-y)
 tests/i440fx-test$(EXESUF): tests/i440fx-test.o $(libqos-pc-obj-y)
diff --git a/tests/ipmi-bt-test.c b/tests/ipmi-bt-test.c
new file mode 100644
index 000..889e15f
--- /dev/null
+++ b/tests/ipmi-bt-test.c
@@ -0,0 +1,444 @@
+/*
+ * IPMI BT test cases, using the external interface for checking
+ *
+ * Copyright (c) 2012 Corey Minyard 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "libqtest.h"
+#include "qemu-common.h"
+
+#define IPMI_IRQ5
+
+#define IPMI_BT_BASE0xe4
+
+#define IPMI_BT_CTLREG_CLR_WR_PTR  0
+#define IPMI_BT_CTLREG_CLR_RD_PTR  1
+#define IPMI_BT_CTLREG_H2B_ATN 2
+#define IPMI_BT_CTLREG_B2H_ATN 3
+#define IPMI_BT_CTLREG_SMS_ATN 4
+#define IPMI_BT_CTLREG_H_BUSY  6
+#define IPMI_BT_CTLREG_B_BUSY  7
+
+#define IPMI_BT_CTLREG_GET(b) ((bt_get_ctrlreg() >> (b)) & 1)
+#define IPMI_BT_CTLREG_GET_H2B_ATN() IPMI_BT_CTLREG_GET(IPMI_BT_CTLREG_H2B_ATN)
+#define IPMI_BT_CTLREG_GET_B2H_ATN() IPMI_BT_CTLREG_GET(IPMI_BT_CTLREG_B2H_ATN)
+#define IPMI_BT_CTLREG_GET_SMS_ATN() IPMI_BT_CTLREG_GET(IPMI_BT_CTLREG_SMS_ATN)
+#define IPMI_BT_CTLREG_GET_H_BUSY()  IPMI_BT_CTLREG_GET(IPMI_BT_CTLREG_H_BUSY)
+#define IPMI_BT_CTLREG_GET_B_BUSY()  IPMI_BT_CTLREG_GET(IPMI_BT_CTLREG_B_BUSY)
+
+#define IPMI_BT_CTLREG_SET(b) bt_write_ctrlreg(1 << (b))
+#define IPMI_BT_CTLREG_SET_CLR_WR_PTR() IPMI_BT_CTLREG_SET( \
+IPMI_BT_CTLREG_CLR_WR_PTR)
+#define IPMI_BT_CTLREG_SET_CLR_RD_PTR() IPMI_BT_CTLREG_SET( \
+IPMI_BT_CTLREG_CLR_RD_PTR)
+#define IPMI_BT_CTLREG_SET_H2B_ATN()  
IPMI_BT_CTLREG_SET(IPMI_BT_CTLREG_H2B_ATN)
+#define IPMI_BT_CTLREG_SET_B2H_ATN()  
IPMI_BT_CTLREG_SET(IPMI_BT_CTLREG_B2H_ATN)
+#define IPMI_BT_CTLREG_SET_SMS_ATN()  
IPMI_BT_CTLREG_SET(IPMI_BT_CTLREG_SMS_ATN)
+#define IPMI_BT_CTLREG_SET_H_BUSY()   IPMI_BT_CTLREG_SET(IPMI_BT_CTLREG_H_BUSY)
+
+static int bt_ints_enabled;
+
+static uint8_t bt_get_ctrlreg(void)
+{
+return inb(IPMI_BT_BASE);
+}
+
+static void bt_write_ctrlreg(uint8_t val)
+{
+outb(IPMI_BT_BASE, val);
+}
+
+static uint8_t bt_get_buf(void)
+{
+return inb(IPMI_BT_BASE + 1);
+}
+
+static void bt_write_buf(uint8_t val)
+{
+outb(IPMI_BT_BASE + 1, val);
+}
+
+static uint8_t bt_get_irqreg(void)
+{
+return inb(IPMI_BT_BASE + 2);
+}
+
+static void bt_write_irqreg(uint8_t val)
+{
+outb(IPMI_BT_BASE + 2, v

Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

[Asias He]

On Wed, May 29, 2013 at 08:10:44AM -0700, Badari Pulavarty wrote:
> On 05/29/2013 02:05 AM, Wenchao Xia wrote:
> >于 2013-5-28 17:00, Wenchao Xia 写道:
> >>于 2013-5-28 16:33, Asias He 写道:
> >>>On Tue, May 28, 2013 at 10:01:14AM +0200, Paolo Bonzini wrote:
> Il 28/05/2013 09:13, Wenchao Xia ha scritto:
> >>>From: Nicholas Bellinger 
> >>>
> >>>The WWPN specified in configfs is passed to "-device
> >>>vhost-scsi-pci".
> >>>The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is
> >>>not
> >>>available from the QEMU command-line.  Instead, I hardcode it to
> >>>zero.
> >>>
> >Hi, Paolo
> >   Any document about how to config it correctly in configfs, before
> >invoking qemu with the WWPN number?
> 
> Unfortunately no, but vhost-scsi doesn't have many knobs (unlike
> iSCSI for example) so it's quite simple.  Here is an example:
> 
> cd /sys/kernel/config/target
> mkdir -p core/fileio_0/fileio
> echo 'fd_dev_name=/home/pbonzini/test.img,fd_dev_size=5905580032' >
> core/fileio_0/fileio/control
> echo 1 > core/fileio_0/fileio/enable
> mkdir -p vhost/naa.600140554cf3a18e/tpgt_0/lun/lun_0
> cd vhost/naa.600140554cf3a18e/tpgt_0
> ln -sf ../../../../../core/fileio_0/fileio/
> lun/lun_0/virtual_scsi_port
> echo naa.60014053226f0388 > nexus
> 
> The "nexus" value is the initiator WWN. naa.600140554cf3a18e is the
> target WWN that you have to pass to "-device vhost-scsi-pci".
> 
> Paolo
> >>>
> >>>For me, I always use targetcli utils instead of the sysfs interface.
> >>>targetcli in F18 has vhost support now.
> >>>
> >>   Thanks very much for above information, I'll try it for test.
> >>
> >  I have done a basic test of vhost-scsi, following is the result I'd
> >like to post, generally it seems fine:
> >
> >Result:
> >  fdisk/mkfs: fdisk can find it, mke2fs works fine.
> >  mount: can mount it.
> >  file I/O: dd 90M zero to a file in that disk succeed.
> 
> 
> 
> I tried without nested kvm.
> 
> >
> >Issues:
> >  1) in fdisk -l, sometime timeout with dmesg "end_request: I/O error,
> >dev  fd0, sector 0", I guess it is caused by nested KVM that failed
> >to kick host kernel?
> 
> 
> I don't see this issue. Are you sure "fd0" is actually the scsi device ?
> what is "fd0" ?
> 
> >  2) in fdisk -l, it shows 512 bytes larger than the parameter I
> >specified in fd_dev_size parameter in configfs on host.(shows
> >104858112 bytes, see the invocation script below)
> >
> 
> I see the same. For some reason "fdisk -l" in the VM shows
> 512-bytes more than the actual size for the file (on the host).

Hmm, interesting. Will look into it.

Nick, Any ideas here?

> Thanks,
> Badari
> 

-- 
Asias

[Qemu-devel] [PATCH 11/20] ipmi: Add an external connection simulation interface

[minyard]

From: Corey Minyard 

This adds an interface for IPMI that connects to a remote
BMC over a chardev (generally a TCP socket).  The OpenIPMI
lanserv simulator describes this interface, see that for
interface details.

Signed-off-by: Corey Minyard 
---
 default-configs/i386-softmmu.mak   |1 +
 default-configs/x86_64-softmmu.mak |1 +
 hw/ipmi/Makefile.objs  |1 +
 hw/ipmi/ipmi_extern.c  |  475 
 4 files changed, 478 insertions(+)
 create mode 100644 hw/ipmi/ipmi_extern.c

diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 491bc24..496e221 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -15,6 +15,7 @@ CONFIG_ISA_IPMI=y
 CONFIG_IPMI_KCS=y
 CONFIG_IPMI_BT=y
 CONFIG_IPMI_LOCAL=y
+CONFIG_IPMI_EXTERN=y
 CONFIG_SERIAL=y
 CONFIG_PARALLEL=y
 CONFIG_I8254=y
diff --git a/default-configs/x86_64-softmmu.mak 
b/default-configs/x86_64-softmmu.mak
index 7c0caeb..0bf0851 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -15,6 +15,7 @@ CONFIG_ISA_IPMI=y
 CONFIG_IPMI_KCS=y
 CONFIG_IPMI_BT=y
 CONFIG_IPMI_LOCAL=y
+CONFIG_IPMI_EXTERN=y
 CONFIG_SERIAL=y
 CONFIG_PARALLEL=y
 CONFIG_I8254=y
diff --git a/hw/ipmi/Makefile.objs b/hw/ipmi/Makefile.objs
index 2366160..9dd05a8 100644
--- a/hw/ipmi/Makefile.objs
+++ b/hw/ipmi/Makefile.objs
@@ -3,3 +3,4 @@ common-obj-$(CONFIG_ISA_IPMI) += isa_ipmi.o
 common-obj-$(CONFIG_IPMI_KCS) += ipmi_kcs.o
 common-obj-$(CONFIG_IPMI_BT) += ipmi_bt.o
 common-obj-$(CONFIG_IPMI_LOCAL) += ipmi_sim.o
+common-obj-$(CONFIG_IPMI_EXTERN) += ipmi_extern.o
diff --git a/hw/ipmi/ipmi_extern.c b/hw/ipmi/ipmi_extern.c
new file mode 100644
index 000..0c5fcfb
--- /dev/null
+++ b/hw/ipmi/ipmi_extern.c
@@ -0,0 +1,475 @@
+/*
+ * IPMI BMC external connection
+ *
+ * Copyright (c) 2012 Corey Minyard, MontaVista Software, LLC
+ *
+ * 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.
+ */
+
+/*
+ * This is designed to connect with OpenIPMI's lanserv serial interface
+ * using the "VM" connection type.  See that for details.
+ */
+
+#include 
+#include "qemu/timer.h"
+#include "sysemu/char.h"
+#include "ipmi.h"
+
+#define VM_MSG_CHAR0xA0 /* Marks end of message */
+#define VM_CMD_CHAR0xA1 /* Marks end of a command */
+#define VM_ESCAPE_CHAR 0xAA /* Set bit 4 from the next byte to 0 */
+
+#define VM_PROTOCOL_VERSION1
+#define VM_CMD_VERSION 0xff /* A version number byte follows */
+#define VM_CMD_NOATTN  0x00
+#define VM_CMD_ATTN0x01
+#define VM_CMD_ATTN_IRQ0x02
+#define VM_CMD_POWEROFF0x03
+#define VM_CMD_RESET   0x04
+#define VM_CMD_ENABLE_IRQ  0x05 /* Enable/disable the messaging irq */
+#define VM_CMD_DISABLE_IRQ 0x06
+#define VM_CMD_SEND_NMI0x07
+#define VM_CMD_CAPABILITIES0x08
+#define   VM_CAPABILITIES_POWER0x01
+#define   VM_CAPABILITIES_RESET0x02
+#define   VM_CAPABILITIES_IRQ  0x04
+#define   VM_CAPABILITIES_NMI  0x08
+#define   VM_CAPABILITIES_ATTN 0x10
+
+#define IPMI_BMC_EXTERN(obj) OBJECT_CHECK(IPMIExternBmc, (obj), \
+TYPE_IPMI_BMC_EXTERN)
+typedef struct IPMIExternBmc {
+IPMIBmc parent;
+
+int connected;
+int is_listen;
+
+unsigned char inbuf[MAX_IPMI_MSG_SIZE + 2];
+unsigned int inpos;
+int in_escape;
+int in_too_many;
+int waiting_rsp;
+int sending_cmd;
+
+unsigned char outbuf[(MAX_IPMI_MSG_SIZE + 2) * 2 + 1];
+unsigned int outpos;
+unsigned int outlen;
+
+struct QEMUTimer *extern_timer;
+
+/* A reset event is pending to be sent upstream. */
+bool send_reset;
+} IPMIExternBmc;
+
+static int can_receive(void *opaque);
+static void receive(void *opaque, const uint8_t *buf, int size);
+static void chr_event(void *opaque, int event);
+
+static unsigned char

[Qemu-devel] [PATCH 14/20] ipmi: Add migration capability to the IPMI device.

[minyard]

From: Corey Minyard 

Signed-off-by: Corey Minyard io_length = 3;
 
 memory_region_init_io(&s->io, &ipmi_bt_io_ops, bt, "ipmi-bt", 3);
+vmstate_register(NULL, 0, &vmstate_ipmi_bt, bt);
 
 return 0;
 }
diff --git a/hw/ipmi/ipmi_extern.c b/hw/ipmi/ipmi_extern.c
index 0c5fcfb..39d3ebf 100644
--- a/hw/ipmi/ipmi_extern.c
+++ b/hw/ipmi/ipmi_extern.c
@@ -63,10 +63,10 @@ typedef struct IPMIExternBmc {
 
 unsigned char inbuf[MAX_IPMI_MSG_SIZE + 2];
 unsigned int inpos;
-int in_escape;
-int in_too_many;
-int waiting_rsp;
-int sending_cmd;
+bool in_escape;
+bool in_too_many;
+bool waiting_rsp;
+bool sending_cmd;
 
 unsigned char outbuf[(MAX_IPMI_MSG_SIZE + 2) * 2 + 1];
 unsigned int outpos;
@@ -442,12 +442,46 @@ static void ipmi_extern_handle_reset(IPMIBmc *b)
 ipmi_unlock(s);
 }
 
+static int ipmi_extern_post_migrate(void *opaque, int version_id)
+{
+IPMIExternBmc *es = opaque;
+
+/*
+ * We don't directly restore waiting_rsp, Instead, we return an
+ * error on the interface if a response was being waited for.
+ */
+if (es->waiting_rsp) {
+IPMIInterface *s = es->parent.intf;
+IPMIInterfaceClass *k = IPMI_INTERFACE_GET_CLASS(s);
+
+es->waiting_rsp = 0;
+es->inbuf[1] = es->outbuf[1] | 0x04;
+es->inbuf[2] = es->outbuf[2];
+es->inbuf[3] = IPMI_CC_BMC_INIT_IN_PROGRESS;
+k->handle_rsp(s, es->outbuf[0], es->inbuf + 1, 3);
+}
+return 0;
+}
+
+static const VMStateDescription vmstate_ipmi_extern = {
+.name = TYPE_IPMI_BMC_EXTERN,
+.version_id = 1,
+.minimum_version_id = 1,
+.post_load = ipmi_extern_post_migrate,
+.fields  = (VMStateField[]) {
+VMSTATE_BOOL(send_reset, IPMIExternBmc),
+VMSTATE_BOOL(waiting_rsp, IPMIExternBmc),
+VMSTATE_END_OF_LIST()
+}
+};
+
 static int ipmi_extern_init(IPMIBmc *b)
 {
 IPMIExternBmc *es = IPMI_BMC_EXTERN(b);
 
 es->extern_timer = qemu_new_timer_ns(vm_clock, extern_timeout, es);
 qemu_chr_add_handlers(es->parent.chr, can_receive, receive, chr_event, es);
+vmstate_register(NULL, 0, &vmstate_ipmi_extern, es);
 return 0;
 }
 
diff --git a/hw/ipmi/ipmi_kcs.c b/hw/ipmi/ipmi_kcs.c
index adbb640..22bbf24 100644
--- a/hw/ipmi/ipmi_kcs.c
+++ b/hw/ipmi/ipmi_kcs.c
@@ -302,6 +302,20 @@ static void ipmi_kcs_set_atn(IPMIInterface *s, int val, 
int irq)
 }
 }
 
+static const VMStateDescription vmstate_ipmi_kcs = {
+.name = TYPE_IPMI_INTERFACE_KCS,
+.version_id = 1,
+.minimum_version_id = 1,
+.fields  = (VMStateField[]) {
+VMSTATE_UINT8(status_reg, IPMIKcsInterface),
+VMSTATE_UINT8(data_out_reg, IPMIKcsInterface),
+VMSTATE_INT16(data_in_reg, IPMIKcsInterface),
+VMSTATE_INT16(cmd_reg, IPMIKcsInterface),
+VMSTATE_UINT8(waiting_rsp, IPMIKcsInterface),
+VMSTATE_END_OF_LIST()
+}
+};
+
 static int ipmi_kcs_init(IPMIInterface *s)
 {
 IPMIKcsInterface *kcs = IPMI_INTERFACE_KCS(s);
@@ -312,6 +326,7 @@ static int ipmi_kcs_init(IPMIInterface *s)
 s->io_length = 2;
 
 memory_region_init_io(&s->io, &ipmi_kcs_io_ops, kcs, "ipmi-kcs", 2);
+vmstate_register(NULL, 0, &vmstate_ipmi_kcs, kcs);
 
 return 0;
 }
diff --git a/hw/ipmi/ipmi_sim.c b/hw/ipmi/ipmi_sim.c
index 20a2585..fdf76b9 100644
--- a/hw/ipmi/ipmi_sim.c
+++ b/hw/ipmi/ipmi_sim.c
@@ -1481,6 +1481,34 @@ static const uint8_t init_sdrs[] = {
 0xff, 0xff, 0x00, 0x00, 0x00
 };
 
+static const VMStateDescription vmstate_ipmi_sim = {
+.name = TYPE_IPMI_BMC_SIMULATOR,
+.version_id = 1,
+.minimum_version_id = 1,
+.fields  = (VMStateField[]) {
+VMSTATE_UINT8(bmc_global_enables, IPMISimBmc),
+VMSTATE_UINT8(msg_flags, IPMISimBmc),
+VMSTATE_BOOL(watchdog_initialized, IPMISimBmc),
+VMSTATE_UINT8(watchdog_use, IPMISimBmc),
+VMSTATE_UINT8(watchdog_action, IPMISimBmc),
+VMSTATE_UINT8(watchdog_pretimeout, IPMISimBmc),
+VMSTATE_BOOL(watchdog_expired, IPMISimBmc),
+VMSTATE_UINT16(watchdog_timeout, IPMISimBmc),
+VMSTATE_BOOL(watchdog_running, IPMISimBmc),
+VMSTATE_BOOL(watchdog_preaction_ran, IPMISimBmc),
+VMSTATE_INT64(watchdog_expiry, IPMISimBmc),
+VMSTATE_UINT8_ARRAY(evtbuf, IPMISimBmc, 16),
+VMSTATE_UINT8(sensors[IPMI_WATCHDOG_SENSOR].status, IPMISimBmc),
+VMSTATE_UINT8(sensors[IPMI_WATCHDOG_SENSOR].reading, IPMISimBmc),
+VMSTATE_UINT16(sensors[IPMI_WATCHDOG_SENSOR].states, IPMISimBmc),
+VMSTATE_UINT16(sensors[IPMI_WATCHDOG_SENSOR].assert_states, 
IPMISimBmc),
+VMSTATE_UINT16(sensors[IPMI_WATCHDOG_SENSOR].deassert_states,
+   IPMISimBmc),
+VMSTATE_UINT16(sensors[IPMI_WATCHDOG_SENSOR].assert_enable, 
IPMISimBmc),
+VMSTATE_END_OF_LIST()
+}
+};
+
 static int ipmi_sim_init(IPMIBmc *b)
 {
 unsigned int i;
@@ -1525,6 +1553,9 @@ static int ipmi_sim_init(IPMIBmc *b)
 register_

[Qemu-devel] [PATCH 16/20] acpi: Add table construction tools

[minyard]

From: Corey Minyard 

Add a set of functions to allow construction of ACPI elements
dynamically.

Signed-off-by: Corey Minyard 
---
 hw/acpi/Makefile.objs   |2 +-
 hw/acpi/acpi-elements.c |  351 +++
 include/hw/acpi/acpi-elements.h |   77 +
 3 files changed, 429 insertions(+), 1 deletion(-)
 create mode 100644 hw/acpi/acpi-elements.c
 create mode 100644 include/hw/acpi/acpi-elements.h

diff --git a/hw/acpi/Makefile.objs b/hw/acpi/Makefile.objs
index a0b63b5..abfdc31 100644
--- a/hw/acpi/Makefile.objs
+++ b/hw/acpi/Makefile.objs
@@ -1,2 +1,2 @@
-common-obj-$(CONFIG_ACPI) += core.o piix4.o ich9.o
+common-obj-$(CONFIG_ACPI) += core.o piix4.o ich9.o acpi-elements.o
 
diff --git a/hw/acpi/acpi-elements.c b/hw/acpi/acpi-elements.c
new file mode 100644
index 000..08d3f40
--- /dev/null
+++ b/hw/acpi/acpi-elements.c
@@ -0,0 +1,351 @@
+/*
+ * Dynamically construct ACPI elements
+ *
+ * Copyright (C) 2012  Corey Minyard 
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License version 2 as published by the Free Software Foundation.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see 
+ *
+ * Contributions after 2012-01-13 are licensed under the terms of the
+ * GNU GPL, version 2 or (at your option) any later version.
+ */
+
+#include "hw/acpi/acpi-elements.h"
+#include 
+
+#define acpi_add_byte(data, val) do { **data = val; (*data)++; } while(0)
+
+static int
+acpi_add_Pkglen(char **data, int dlen, int length)
+{
+int pkglen;
+
+/*
+ * The funny length values following are because we include the length
+ * bytes in the full length.
+ */
+if (length <= 0x3e) {
+if (dlen > 0) {
+acpi_add_byte(data, length + 1);
+}
+return 1;
+} else if (length <= 0xffd) {
+pkglen = 2;
+} else if (length <= 0xc) {
+pkglen = 3;
+} else if (length <= 0xffb) {
+pkglen = 4;
+} else {
+return -1;
+}
+length += pkglen;
+if (pkglen <= dlen) {
+acpi_add_byte(data, ((pkglen - 1) << 6) | (length & 0xf));
+length >>= 4;
+pkglen--;
+while (pkglen > 0) {
+acpi_add_byte(data, length & 0xff);
+length >>= 8;
+pkglen--;
+}
+}
+return pkglen;
+}
+
+static int
+acpi_add_NameString(char **data, int dlen, const char *name)
+{
+int length = strlen(name);
+int i;
+
+if (dlen >= 4) {
+i = 0;
+while ((i < 4) && (i < length)) {
+acpi_add_byte(data, *name++);
+i++;
+}
+while (i < 4) {
+acpi_add_byte(data, '_');
+i++;
+}
+}
+return 4;
+}
+
+int
+acpi_add_Device(char **data, int dlen, const char *name,
+contained_acpi_elem e, void *opaque)
+{
+int length, plen, totlen;
+
+length = e(NULL, 0, opaque);
+if (length < 0)
+return length;
+
+plen = acpi_add_Pkglen(NULL, 0, length);
+if (plen < 0)
+return plen;
+totlen = length + plen + 6;
+if (dlen >= totlen) {
+acpi_add_byte(data, 0x5b);
+acpi_add_byte(data, 0x82);
+dlen -= 2;
+dlen -= acpi_add_Pkglen(data, dlen, length);
+dlen -= acpi_add_NameString(data, dlen, name);
+dlen -= e(data, dlen, opaque);
+}
+
+return totlen;
+}
+
+int
+acpi_add_Name(char **data, int dlen, const char *name,
+  contained_acpi_elem e, void *opaque)
+{
+int rv;
+
+if (dlen >= 5) {
+acpi_add_byte(data, 0x8);
+dlen -= 1;
+dlen -= acpi_add_NameString(data, dlen, name);
+}
+rv = e(data, dlen, opaque);
+if (rv < 0)
+return rv;
+return rv + 5;
+}
+
+int
+acpi_add_Method(char **data, int dlen, const char *name, uint8_t flags,
+contained_acpi_elem e, void *opaque)
+{
+int elen, plen;
+
+elen = e(NULL, 0, opaque);
+if (elen < 0)
+return elen;
+
+plen = acpi_add_Pkglen(NULL, 0, elen + 5);
+if (plen < 0)
+return plen;
+if (plen + elen + 6 <= dlen) {
+acpi_add_byte(data, 0x14);
+dlen -= 1;
+dlen -= acpi_add_Pkglen(data, dlen, elen + 5);
+dlen -= acpi_add_NameString(data, dlen, name);
+acpi_add_byte(data, flags);
+dlen -= 1;
+dlen -= e(data, dlen, opaque);
+}
+return plen + elen + 6;
+}
+
+int
+acpi_add_Integer(char **data, int dlen, void *vval)
+{
+uint64_t val = *((uint64_t *) vval);
+int length, i;
+unsigned char op;
+
+  

[Qemu-devel] [PATCH 17/20] pc: Postpone adding ACPI and SMBIOS to fw_cfg

[minyard]

From: Corey Minyard 

Postpone the addition of the ACPI and SMBIOS tables until after
device initialization.  This allows devices to add entries to these
tables.

Signed-off-by: Corey Minyard 
---
 hw/i386/pc.c |   38 ++
 1 file changed, 30 insertions(+), 8 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 197d218..d3143a4 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -598,8 +598,6 @@ static unsigned int pc_apic_id_limit(unsigned int max_cpus)
 static void *bochs_bios_init(void)
 {
 void *fw_cfg;
-uint8_t *smbios_table;
-size_t smbios_len;
 uint64_t *numa_fw_cfg;
 int i, j;
 unsigned int apic_id_limit = pc_apic_id_limit(max_cpus);
@@ -622,14 +620,8 @@ static void *bochs_bios_init(void)
 fw_cfg_add_i16(fw_cfg, FW_CFG_MAX_CPUS, (uint16_t)apic_id_limit);
 fw_cfg_add_i32(fw_cfg, FW_CFG_ID, 1);
 fw_cfg_add_i64(fw_cfg, FW_CFG_RAM_SIZE, (uint64_t)ram_size);
-fw_cfg_add_bytes(fw_cfg, FW_CFG_ACPI_TABLES,
- acpi_tables, acpi_tables_len);
 fw_cfg_add_i32(fw_cfg, FW_CFG_IRQ0_OVERRIDE, kvm_allows_irq0_override());
 
-smbios_table = smbios_get_table(&smbios_len);
-if (smbios_table)
-fw_cfg_add_bytes(fw_cfg, FW_CFG_SMBIOS_ENTRIES,
- smbios_table, smbios_len);
 fw_cfg_add_bytes(fw_cfg, FW_CFG_E820_TABLE,
  &e820_table, sizeof(e820_table));
 
@@ -1012,6 +1004,31 @@ void pc_acpi_init(const char *default_dsdt)
 }
 }
 
+struct pc_bios_post_init {
+Notifier post_init;
+void *fw_cfg;
+};
+
+/* Add the ACPI and SMBIOS tables after all the hardware has been initialized.
+ * This gives devices a chance to add to those tables.
+ */
+static void pc_bios_post_initfn(Notifier *n, void *opaque)
+{
+struct pc_bios_post_init *p = container_of(n, struct pc_bios_post_init,
+   post_init);
+uint8_t *smbios_table;
+size_t smbios_len;
+
+fw_cfg_add_bytes(p->fw_cfg, FW_CFG_ACPI_TABLES,
+ acpi_tables, acpi_tables_len);
+smbios_table = smbios_get_table(&smbios_len);
+if (smbios_table)
+fw_cfg_add_bytes(p->fw_cfg, FW_CFG_SMBIOS_ENTRIES,
+ smbios_table, smbios_len);
+}
+
+static struct pc_bios_post_init post_init;
+
 void *pc_memory_init(MemoryRegion *system_memory,
 const char *kernel_filename,
 const char *kernel_cmdline,
@@ -1071,6 +1088,11 @@ void *pc_memory_init(MemoryRegion *system_memory,
 for (i = 0; i < nb_option_roms; i++) {
 rom_add_option(option_rom[i].name, option_rom[i].bootindex);
 }
+
+post_init.fw_cfg = fw_cfg;
+post_init.post_init.notify = pc_bios_post_initfn;
+qemu_add_machine_init_done_notifier(&post_init.post_init);
+
 return fw_cfg;
 }
 
-- 
1.7.9.5

Re: [Qemu-devel] [PATCH 10/16] qemu-io: Move qemu_strsep() to cutils.c

[Eric Blake]

On 05/28/2013 09:27 AM, Kevin Wolf wrote:
> Signed-off-by: Kevin Wolf 
> ---
>  cmd.c | 21 -
>  include/qemu-common.h |  1 +
>  util/cutils.c | 21 +
>  3 files changed, 22 insertions(+), 21 deletions(-)

Reviewed-by: Eric Blake 

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [PATCH 01/20] qemu-char: Allocate CharDriverState in qemu_chr_new_from_opts

[minyard]

From: Corey Minyard 

This allocates the CharDriverState structure and passes it in to the
open routine.  This allows a coming option to automatically attempt to
reconnect a chardev if the connection fails.  The chardev has to be
kept around so a reconnect can be done on it.

Signed-off-by: Corey Minyard 
---
 backends/baum.c |6 +-
 backends/msmouse.c  |5 +-
 hw/misc/ivshmem.c   |   11 ++-
 include/sysemu/char.h   |9 +--
 include/ui/console.h|4 +-
 include/ui/qemu-spice.h |6 +-
 qemu-char.c |  180 +--
 spice-qemu-char.c   |   14 ++--
 ui/console.c|   10 +--
 9 files changed, 113 insertions(+), 132 deletions(-)

diff --git a/backends/baum.c b/backends/baum.c
index 4cba79f..292fd9f 100644
--- a/backends/baum.c
+++ b/backends/baum.c
@@ -561,10 +561,9 @@ static void baum_close(struct CharDriverState *chr)
 g_free(baum);
 }
 
-CharDriverState *chr_baum_init(void)
+CharDriverState *chr_baum_init(CharDriverState *chr)
 {
 BaumDriverState *baum;
-CharDriverState *chr;
 brlapi_handle_t *handle;
 #ifdef CONFIG_SDL
 SDL_SysWMinfo info;
@@ -572,7 +571,7 @@ CharDriverState *chr_baum_init(void)
 int tty;
 
 baum = g_malloc0(sizeof(BaumDriverState));
-baum->chr = chr = g_malloc0(sizeof(CharDriverState));
+baum->chr = chr;
 
 chr->opaque = baum;
 chr->chr_write = baum_write;
@@ -620,7 +619,6 @@ fail:
 brlapi__closeConnection(handle);
 fail_handle:
 g_free(handle);
-g_free(chr);
 g_free(baum);
 return NULL;
 }
diff --git a/backends/msmouse.c b/backends/msmouse.c
index 0ac05a0..5e5151a 100644
--- a/backends/msmouse.c
+++ b/backends/msmouse.c
@@ -63,11 +63,8 @@ static void msmouse_chr_close (struct CharDriverState *chr)
 g_free (chr);
 }
 
-CharDriverState *qemu_chr_open_msmouse(void)
+CharDriverState *qemu_chr_open_msmouse(CharDriverState *chr)
 {
-CharDriverState *chr;
-
-chr = g_malloc0(sizeof(CharDriverState));
 chr->chr_write = msmouse_chr_write;
 chr->chr_close = msmouse_chr_close;
 
diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
index a19a6d6..89cb295 100644
--- a/hw/misc/ivshmem.c
+++ b/hw/misc/ivshmem.c
@@ -283,12 +283,17 @@ static CharDriverState* create_eventfd_chr_device(void * 
opaque, EventNotifier *
 {
 /* create a event character device based on the passed eventfd */
 IVShmemState *s = opaque;
-CharDriverState * chr;
+CharDriverState *chr, *newchr;
 int eventfd = event_notifier_get_fd(n);
 
-chr = qemu_chr_open_eventfd(eventfd);
-
+newchr = g_malloc0(sizeof(*chr));
+if (newchr == NULL) {
+fprintf(stderr, "creating eventfd for eventfd %d failed\n", eventfd);
+exit(-1);
+}
+chr = qemu_chr_open_eventfd(newchr, eventfd);
 if (chr == NULL) {
+g_free(newchr);
 fprintf(stderr, "creating eventfd for eventfd %d failed\n", eventfd);
 exit(-1);
 }
diff --git a/include/sysemu/char.h b/include/sysemu/char.h
index 5e42c90..a8931c6 100644
--- a/include/sysemu/char.h
+++ b/include/sysemu/char.h
@@ -280,21 +280,22 @@ CharDriverState *qemu_chr_find(const char *name);
 
 QemuOpts *qemu_chr_parse_compat(const char *label, const char *filename);
 
-void register_char_driver(const char *name, CharDriverState *(*open)(QemuOpts 
*));
+void register_char_driver(const char *name,
+CharDriverState *(*open)(CharDriverState *, QemuOpts *));
 void register_char_driver_qapi(const char *name, int kind,
 void (*parse)(QemuOpts *opts, ChardevBackend *backend, Error **errp));
 
 /* add an eventfd to the qemu devices that are polled */
-CharDriverState *qemu_chr_open_eventfd(int eventfd);
+CharDriverState *qemu_chr_open_eventfd(CharDriverState *chr, int eventfd);
 
 extern int term_escape_char;
 
 CharDriverState *qemu_char_get_next_serial(void);
 
 /* msmouse */
-CharDriverState *qemu_chr_open_msmouse(void);
+CharDriverState *qemu_chr_open_msmouse(CharDriverState *chr);
 
 /* baum.c */
-CharDriverState *chr_baum_init(void);
+CharDriverState *chr_baum_init(CharDriverState *chr);
 
 #endif
diff --git a/include/ui/console.h b/include/ui/console.h
index 4307b5f..c86cf32 100644
--- a/include/ui/console.h
+++ b/include/ui/console.h
@@ -300,9 +300,9 @@ void qemu_console_copy(QemuConsole *con, int src_x, int 
src_y,
 DisplaySurface *qemu_console_surface(QemuConsole *con);
 DisplayState *qemu_console_displaystate(QemuConsole *console);
 
-typedef CharDriverState *(VcHandler)(ChardevVC *vc);
+typedef CharDriverState *(VcHandler)(CharDriverState *chr, ChardevVC *vc);
 
-CharDriverState *vc_init(ChardevVC *vc);
+CharDriverState *vc_init(CharDriverState *chr, ChardevVC *vc);
 void register_vc_handler(VcHandler *handler);
 
 /* sdl.c */
diff --git a/include/ui/qemu-spice.h b/include/ui/qemu-spice.h
index eba6d77..8d3099c 100644
--- a/include/ui/qemu-spice.h
+++ b/include/ui/qemu-spice.h
@@ -44,9 +44,11 @@ int qemu_spice_migrate_info(const char *hostname, int 

[Qemu-devel] [PATCH 08/20] ipmi: Add a KCS low-level interface

[minyard]

From: Corey Minyard 

This provides the simulation of the KCS hardware interface.

Signed-off-by: Corey Minyard 
---
 default-configs/i386-softmmu.mak   |1 +
 default-configs/x86_64-softmmu.mak |1 +
 hw/ipmi/Makefile.objs  |1 +
 hw/ipmi/ipmi_kcs.c |  342 
 4 files changed, 345 insertions(+)
 create mode 100644 hw/ipmi/ipmi_kcs.c

diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index b06317d..57503e9 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -12,6 +12,7 @@ CONFIG_VMWARE_VGA=y
 CONFIG_VMMOUSE=y
 CONFIG_IPMI=y
 CONFIG_ISA_IPMI=y
+CONFIG_IPMI_KCS=y
 CONFIG_SERIAL=y
 CONFIG_PARALLEL=y
 CONFIG_I8254=y
diff --git a/default-configs/x86_64-softmmu.mak 
b/default-configs/x86_64-softmmu.mak
index 9ef28e4..722fc37 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -12,6 +12,7 @@ CONFIG_VMWARE_VGA=y
 CONFIG_VMMOUSE=y
 CONFIG_IPMI=y
 CONFIG_ISA_IPMI=y
+CONFIG_IPMI_KCS=y
 CONFIG_SERIAL=y
 CONFIG_PARALLEL=y
 CONFIG_I8254=y
diff --git a/hw/ipmi/Makefile.objs b/hw/ipmi/Makefile.objs
index 3494b70..3c811ae 100644
--- a/hw/ipmi/Makefile.objs
+++ b/hw/ipmi/Makefile.objs
@@ -1,2 +1,3 @@
 common-obj-$(CONFIG_IPMI) += ipmi.o
 common-obj-$(CONFIG_ISA_IPMI) += isa_ipmi.o
+common-obj-$(CONFIG_IPMI_KCS) += ipmi_kcs.o
diff --git a/hw/ipmi/ipmi_kcs.c b/hw/ipmi/ipmi_kcs.c
new file mode 100644
index 000..adbb640
--- /dev/null
+++ b/hw/ipmi/ipmi_kcs.c
@@ -0,0 +1,342 @@
+/*
+ * QEMU IPMI KCS emulation
+ *
+ * Copyright (c) 2012 Corey Minyard, MontaVista Software, LLC
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+#include "hw/hw.h"
+#include "ipmi.h"
+
+#define TYPE_IPMI_INTERFACE_KCS TYPE_IPMI_INTERFACE_PREFIX "kcs"
+#define IPMI_INTERFACE_KCS(obj) OBJECT_CHECK(IPMIKcsInterface, (obj), \
+TYPE_IPMI_INTERFACE_KCS)
+
+#define IPMI_KCS_OBF_BIT0
+#define IPMI_KCS_IBF_BIT1
+#define IPMI_KCS_SMS_ATN_BIT2
+#define IPMI_KCS_CD_BIT 3
+
+#define IPMI_KCS_OBF_MASK  (1 << IPMI_KCS_OBF_BIT)
+#define IPMI_KCS_GET_OBF(d)(((d) >> IPMI_KCS_OBF_BIT) & 0x1)
+#define IPMI_KCS_SET_OBF(d, v) (d) = (((d) & ~IPMI_KCS_OBF_MASK) | \
+   (((v) & 1) << IPMI_KCS_OBF_BIT))
+#define IPMI_KCS_IBF_MASK  (1 << IPMI_KCS_IBF_BIT)
+#define IPMI_KCS_GET_IBF(d)(((d) >> IPMI_KCS_IBF_BIT) & 0x1)
+#define IPMI_KCS_SET_IBF(d, v) (d) = (((d) & ~IPMI_KCS_IBF_MASK) | \
+   (((v) & 1) << IPMI_KCS_IBF_BIT))
+#define IPMI_KCS_SMS_ATN_MASK  (1 << IPMI_KCS_SMS_ATN_BIT)
+#define IPMI_KCS_GET_SMS_ATN(d)(((d) >> IPMI_KCS_SMS_ATN_BIT) & 0x1)
+#define IPMI_KCS_SET_SMS_ATN(d, v) (d) = (((d) & ~IPMI_KCS_SMS_ATN_MASK) | \
+   (((v) & 1) << IPMI_KCS_SMS_ATN_BIT))
+#define IPMI_KCS_CD_MASK   (1 << IPMI_KCS_CD_BIT)
+#define IPMI_KCS_GET_CD(d) (((d) >> IPMI_KCS_CD_BIT) & 0x1)
+#define IPMI_KCS_SET_CD(d, v)  (d) = (((d) & ~IPMI_KCS_CD_MASK) | \
+   (((v) & 1) << IPMI_KCS_CD_BIT))
+
+#define IPMI_KCS_IDLE_STATE0
+#define IPMI_KCS_READ_STATE1
+#define IPMI_KCS_WRITE_STATE   2
+#define IPMI_KCS_ERROR_STATE   3
+
+#define IPMI_KCS_GET_STATE(d)(((d) >> 6) & 0x3)
+#define IPMI_KCS_SET_STATE(d, v) ((d) = ((d) & ~0xc0) | (((v) & 0x3) << 6))
+
+#define IPMI_KCS_ABORT_STATUS_CMD   0x60
+#define IPMI_KCS_WRITE_START_CMD0x61
+#define IPMI_KCS_WRITE_END_CMD  0x62
+#define IPMI_KCS_READ_CMD   0x68
+
+#define IPMI_KCS_STATUS_NO_ERR  0x00
+#define IPMI_KCS_STATUS_ABORTED_ERR 0x01
+#define IPMI_KCS_STATUS_BAD_CC_ERR  0x02
+#define IPMI_KCS_STATUS_LENGTH_ERR  0x06
+
+typedef struct IPMIKcsInterface {
+IPMIInterface intf;
+
+uint

[Qemu-devel] [PATCH 09/20] ipmi: Add a BT low-level interface

[minyard]

From: Corey Minyard 

This provides the simulation of the BT hardware interface for
IPMI.

Signed-off-by: Corey Minyard 
---
 default-configs/i386-softmmu.mak   |1 +
 default-configs/x86_64-softmmu.mak |1 +
 hw/ipmi/Makefile.objs  |1 +
 hw/ipmi/ipmi_bt.c  |  365 
 4 files changed, 368 insertions(+)
 create mode 100644 hw/ipmi/ipmi_bt.c

diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 57503e9..bcd19d0 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -13,6 +13,7 @@ CONFIG_VMMOUSE=y
 CONFIG_IPMI=y
 CONFIG_ISA_IPMI=y
 CONFIG_IPMI_KCS=y
+CONFIG_IPMI_BT=y
 CONFIG_SERIAL=y
 CONFIG_PARALLEL=y
 CONFIG_I8254=y
diff --git a/default-configs/x86_64-softmmu.mak 
b/default-configs/x86_64-softmmu.mak
index 722fc37..3f2ca2f 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -13,6 +13,7 @@ CONFIG_VMMOUSE=y
 CONFIG_IPMI=y
 CONFIG_ISA_IPMI=y
 CONFIG_IPMI_KCS=y
+CONFIG_IPMI_BT=y
 CONFIG_SERIAL=y
 CONFIG_PARALLEL=y
 CONFIG_I8254=y
diff --git a/hw/ipmi/Makefile.objs b/hw/ipmi/Makefile.objs
index 3c811ae..a8cd463 100644
--- a/hw/ipmi/Makefile.objs
+++ b/hw/ipmi/Makefile.objs
@@ -1,3 +1,4 @@
 common-obj-$(CONFIG_IPMI) += ipmi.o
 common-obj-$(CONFIG_ISA_IPMI) += isa_ipmi.o
 common-obj-$(CONFIG_IPMI_KCS) += ipmi_kcs.o
+common-obj-$(CONFIG_IPMI_BT) += ipmi_bt.o
diff --git a/hw/ipmi/ipmi_bt.c b/hw/ipmi/ipmi_bt.c
new file mode 100644
index 000..f5e014d
--- /dev/null
+++ b/hw/ipmi/ipmi_bt.c
@@ -0,0 +1,365 @@
+/*
+ * QEMU IPMI BT emulation
+ *
+ * Copyright (c) 2012 Corey Minyard, MontaVista Software, LLC
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+#include "hw/hw.h"
+#include "ipmi.h"
+
+#define TYPE_IPMI_INTERFACE_BT TYPE_IPMI_INTERFACE_PREFIX "bt"
+#define IPMI_INTERFACE_BT(obj) OBJECT_CHECK(IPMIBtInterface, (obj), \
+TYPE_IPMI_INTERFACE_BT)
+
+/* Control register */
+#define IPMI_BT_CLR_WR_BIT0
+#define IPMI_BT_CLR_RD_BIT1
+#define IPMI_BT_H2B_ATN_BIT2
+#define IPMI_BT_B2H_ATN_BIT3
+#define IPMI_BT_SMS_ATN_BIT4
+#define IPMI_BT_HBUSY_BIT6
+#define IPMI_BT_BBUSY_BIT7
+
+#define IPMI_BT_CLR_WR_MASK(1 << IPMI_BT_CLR_WR_BIT)
+#define IPMI_BT_GET_CLR_WR(d)  (((d) >> IPMI_BT_CLR_WR_BIT) & 0x1)
+#define IPMI_BT_SET_CLR_WR(d, v)   (d) = (((d) & ~IPMI_BT_CLR_WR_MASK) | \
+   (((v & 1) << IPMI_BT_CLR_WR_BIT)))
+
+#define IPMI_BT_CLR_RD_MASK(1 << IPMI_BT_CLR_RD_BIT)
+#define IPMI_BT_GET_CLR_RD(d)  (((d) >> IPMI_BT_CLR_RD_BIT) & 0x1)
+#define IPMI_BT_SET_CLR_RD(d, v)   (d) = (((d) & ~IPMI_BT_CLR_RD_MASK) | \
+   (((v & 1) << IPMI_BT_CLR_RD_BIT)))
+
+#define IPMI_BT_H2B_ATN_MASK   (1 << IPMI_BT_H2B_ATN_BIT)
+#define IPMI_BT_GET_H2B_ATN(d) (((d) >> IPMI_BT_H2B_ATN_BIT) & 0x1)
+#define IPMI_BT_SET_H2B_ATN(d, v)  (d) = (((d) & ~IPMI_BT_H2B_ATN_MASK) | \
+(((v & 1) << IPMI_BT_H2B_ATN_BIT)))
+
+#define IPMI_BT_B2H_ATN_MASK   (1 << IPMI_BT_B2H_ATN_BIT)
+#define IPMI_BT_GET_B2H_ATN(d) (((d) >> IPMI_BT_B2H_ATN_BIT) & 0x1)
+#define IPMI_BT_SET_B2H_ATN(d, v)  (d) = (((d) & ~IPMI_BT_B2H_ATN_MASK) | \
+(((v & 1) << IPMI_BT_B2H_ATN_BIT)))
+
+#define IPMI_BT_SMS_ATN_MASK   (1 << IPMI_BT_SMS_ATN_BIT)
+#define IPMI_BT_GET_SMS_ATN(d) (((d) >> IPMI_BT_SMS_ATN_BIT) & 0x1)
+#define IPMI_BT_SET_SMS_ATN(d, v)  (d) = (((d) & ~IPMI_BT_SMS_ATN_MASK) | \
+(((v & 1) << IPMI_BT_SMS_ATN_BIT)))
+
+#define IPMI_BT_HBUSY_MASK (1 << IPMI_BT_HBUSY_BIT)
+#define IPMI_BT_GET_HBUSY(d)   (((d) >> IPMI_BT_HBUSY_BIT) & 0x1)
+#define IPMI_BT_SET_HBUSY(d, v)(d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \
+  

[Qemu-devel] [PATCH 07/20] ipmi: Add a PC ISA type structure

[minyard]

From: Corey Minyard 

This provides the base infrastructure to tie IPMI low-level
interfaces into a PC ISA bus.

Signed-off-by: Corey Minyard 
---
 default-configs/i386-softmmu.mak   |1 +
 default-configs/x86_64-softmmu.mak |1 +
 hw/ipmi/Makefile.objs  |1 +
 hw/ipmi/isa_ipmi.c |  150 
 include/hw/nvram/fw_cfg.h  |   11 ++-
 5 files changed, 163 insertions(+), 1 deletion(-)
 create mode 100644 hw/ipmi/isa_ipmi.c

diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 84542ab..b06317d 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -11,6 +11,7 @@ CONFIG_VGA_CIRRUS=y
 CONFIG_VMWARE_VGA=y
 CONFIG_VMMOUSE=y
 CONFIG_IPMI=y
+CONFIG_ISA_IPMI=y
 CONFIG_SERIAL=y
 CONFIG_PARALLEL=y
 CONFIG_I8254=y
diff --git a/default-configs/x86_64-softmmu.mak 
b/default-configs/x86_64-softmmu.mak
index d580dc0..9ef28e4 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -11,6 +11,7 @@ CONFIG_VGA_CIRRUS=y
 CONFIG_VMWARE_VGA=y
 CONFIG_VMMOUSE=y
 CONFIG_IPMI=y
+CONFIG_ISA_IPMI=y
 CONFIG_SERIAL=y
 CONFIG_PARALLEL=y
 CONFIG_I8254=y
diff --git a/hw/ipmi/Makefile.objs b/hw/ipmi/Makefile.objs
index 65bde11..3494b70 100644
--- a/hw/ipmi/Makefile.objs
+++ b/hw/ipmi/Makefile.objs
@@ -1 +1,2 @@
 common-obj-$(CONFIG_IPMI) += ipmi.o
+common-obj-$(CONFIG_ISA_IPMI) += isa_ipmi.o
diff --git a/hw/ipmi/isa_ipmi.c b/hw/ipmi/isa_ipmi.c
new file mode 100644
index 000..616a357
--- /dev/null
+++ b/hw/ipmi/isa_ipmi.c
@@ -0,0 +1,150 @@
+/*
+ * QEMU ISA IPMI emulation
+ *
+ * Copyright (c) 2012 Corey Minyard, MontaVista Software, LLC
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+#include "hw/hw.h"
+#include "hw/isa/isa.h"
+#include "hw/i386/pc.h"
+#include "qemu/timer.h"
+#include "sysemu/char.h"
+#include "sysemu/sysemu.h"
+#include "ipmi.h"
+
+/* This is the type the user specifies on the -device command line */
+#define TYPE_ISA_IPMI   "isa-ipmi"
+#define ISA_IPMI(obj) OBJECT_CHECK(ISAIPMIDevice, (obj), \
+TYPE_ISA_IPMI)
+typedef struct ISAIPMIDevice {
+ISADevice dev;
+char *interface;
+uint32_t iobase;
+uint32_t isairq;
+uint8_t slave_addr;
+CharDriverState *chr;
+IPMIInterface *intf;
+} ISAIPMIDevice;
+
+static int ipmi_isa_initfn(ISADevice *dev)
+{
+ISAIPMIDevice *isa = ISA_IPMI(dev);
+char typename[20];
+Object *intfobj;
+IPMIInterface *intf;
+Object *bmcobj;
+IPMIBmc *bmc;
+int rc;
+Error *errp = NULL;
+
+if (!isa->interface) {
+isa->interface = g_strdup("kcs");
+}
+
+if (isa->chr) {
+bmcobj = object_new(TYPE_IPMI_BMC_EXTERN);
+} else {
+bmcobj = object_new(TYPE_IPMI_BMC_SIMULATOR);
+}
+bmc = IPMI_BMC(bmcobj);
+bmc->chr = isa->chr;
+snprintf(typename, sizeof(typename),
+ TYPE_IPMI_INTERFACE_PREFIX "%s", isa->interface);
+intfobj = object_new(typename);
+intf = IPMI_INTERFACE(intfobj);
+bmc->intf = intf;
+intf->bmc = bmc;
+intf->io_base = isa->iobase;
+intf->slave_addr = isa->slave_addr;
+rc = ipmi_interface_init(intf);
+if (rc) {
+return rc;
+}
+rc = ipmi_bmc_init(bmc);
+if (rc) {
+return rc;
+}
+
+/* These may be set by the interface. */
+isa->iobase = intf->io_base;
+isa->slave_addr = intf->slave_addr;
+
+if (isa->isairq != 0) {
+isa_init_irq(dev, &intf->irq, isa->isairq);
+intf->use_irq = 1;
+}
+
+isa->intf = intf;
+object_property_add_child(OBJECT(isa), "intf", OBJECT(intf), &errp);
+if (error_is_set(&errp)) {
+fprintf(stderr, "%s\n", error_get_pretty(errp));
+return 1;
+}
+object_property_add_child(OBJECT(isa), "bmc", OBJECT(bmc), &errp);
+if (error_is_set(&errp)) {
+fprintf(stderr, "%s\n", error_get_pret

[Qemu-devel] [PATCH 18/20] ipmi: Add ACPI table entries for BMCs

[minyard]

From: Corey Minyard 

Use the new ACPI table construction tools to create an ACPI
entry for IPMI.

Signed-off-by: Corey Minyard 
---
 hw/ipmi/isa_ipmi.c |  127 
 1 file changed, 127 insertions(+)

diff --git a/hw/ipmi/isa_ipmi.c b/hw/ipmi/isa_ipmi.c
index 7664b66..92afb88 100644
--- a/hw/ipmi/isa_ipmi.c
+++ b/hw/ipmi/isa_ipmi.c
@@ -23,6 +23,8 @@
  */
 #include "hw/hw.h"
 #include "hw/isa/isa.h"
+#include "hw/acpi/acpi-elements.h"
+#include "hw/acpi/acpi.h"
 #include "hw/i386/pc.h"
 #include "qemu/timer.h"
 #include "sysemu/char.h"
@@ -36,16 +38,134 @@
 typedef struct ISAIPMIDevice {
 ISADevice dev;
 char *interface;
+int intftype;
 uint32_t iobase;
+uint32_t endaddr;
 uint32_t isairq;
+uint8_t regspacing;
 uint8_t slave_addr;
+uint8_t version;
 CharDriverState *chr;
 IPMIInterface *intf;
 } ISAIPMIDevice;
 
+static int
+acpi_ipmi_crs_ops(char **data, int dlen, void *opaque)
+{
+ISAIPMIDevice *info = opaque;
+int len, rv;
+uint8_t regspacing = info->regspacing;
+
+if (regspacing == 1)
+regspacing = 0;
+/* IO(Decode16, x, y, z, c) */
+len = acpi_add_IO16(data, dlen, info->iobase, info->endaddr,
+regspacing, info->endaddr - info->iobase + 1);
+if (len < 0)
+return len;
+if (info->isairq) {
+/* Interrupt(ResourceConsumer,Level,ActiveHigh,Exclusive) {n} */
+rv = acpi_add_Interrupt(data, dlen, info->isairq,
+ACPI_RESOURCE_CONSUMER,
+ACPI_INTERRUPT_MODE_LEVEL,
+ACPI_INTERRUPT_POLARITY_ACTIVE_HIGH,
+ACPI_INTERRUPT_EXCLUSIVE);
+if (rv < 0)
+return rv;
+len += rv;
+}
+rv = acpi_add_EndResource(data, dlen);
+if (rv < 0)
+return rv;
+len += rv;
+return len;
+}
+
+static int
+acpi_ipmi_crs(char **data, int dlen, void *opaque)
+{
+ISAIPMIDevice *info = opaque;
+int len;
+
+len = acpi_add_BufferOp(NULL, 0, acpi_ipmi_crs_ops, info);
+if (len < 0)
+return len;
+if (len <= dlen) {
+acpi_add_BufferOp(data, dlen, acpi_ipmi_crs_ops, info);
+}
+return len;
+}
+
+static int
+acpi_ipmi_dev(char **data, int dlen, void *opaque)
+{
+ISAIPMIDevice *info = opaque;
+int len, rv;
+char *name;
+uint64_t val;
+
+name = g_strdup_printf("ipmi_%s", info->interface);
+
+/* Name(_HID, EISAID("IPI0001")) */
+len = acpi_add_Name(data, dlen, "_HID", acpi_add_EISAID,
+(void *) "IPI0001");
+if (len < 0)
+return len;
+/* Name(_STR, Unicode("ipmi_xxx")) */
+rv = acpi_add_Name(data, dlen, "_STR", acpi_add_Unicode, name);
+if (rv < 0)
+return rv;
+len += rv;
+val = 0;
+/* Name(_UID, 0) */
+rv = acpi_add_Name(data, dlen, "_UID", acpi_add_Integer, &val);
+if (rv < 0)
+return rv;
+len += rv;
+/* Name(_CRS, ResourceTemplate() { */
+rv = acpi_add_Name(data, dlen, "_CRS", acpi_ipmi_crs, info);
+if (rv < 0)
+return rv;
+len += rv;
+val = info->intftype;
+/* Method(_IFT) { Return(i) } */
+rv = acpi_add_Method(data, dlen, "_IFT", 0, acpi_add_Return, &val);
+if (rv < 0)
+return rv;
+len += rv;
+val = ((info->version & 0xf0) << 4) | (info->version & 0x0f);
+/* Method(_SRV) { Return(version) } */
+rv = acpi_add_Method(data, dlen, "_SRV", 0, acpi_add_Return, &val);
+if (rv < 0)
+return rv;
+len += rv;
+return len;
+}
+
+static void
+ipmi_encode_acpi(ISAIPMIDevice *info)
+{
+char ipmitable[200];
+char *tblptr = ipmitable;
+int rc;
+Error *err = NULL;
+
+/* Device(MI0) { */
+rc = acpi_add_Device(&tblptr, sizeof(ipmitable), "MI0",
+ acpi_ipmi_dev, info);
+/* } */
+if (rc < 0) {
+fprintf(stderr, "Unable to format IPMI ACPI table entry\n");
+return;
+}
+
+acpi_append_to_table("DSDT", ipmitable, rc, &err);
+}
+
 static int ipmi_isa_initfn(ISADevice *dev)
 {
 ISAIPMIDevice *isa = ISA_IPMI(dev);
+IPMIInterfaceClass *intfk;
 char typename[20];
 Object *intfobj;
 IPMIInterface *intf;
@@ -69,6 +189,7 @@ static int ipmi_isa_initfn(ISADevice *dev)
  TYPE_IPMI_INTERFACE_PREFIX "%s", isa->interface);
 intfobj = object_new(typename);
 intf = IPMI_INTERFACE(intfobj);
+intfk = IPMI_INTERFACE_GET_CLASS(intf);
 bmc->intf = intf;
 intf->bmc = bmc;
 intf->io_base = isa->iobase;
@@ -85,6 +206,10 @@ static int ipmi_isa_initfn(ISADevice *dev)
 /* These may be set by the interface. */
 isa->iobase = intf->io_base;
 isa->slave_addr = intf->slave_addr;
+isa->regspacing = 1;
+isa->endaddr = cpu_to_le64(intf->io_base + intf->io_length - 1);
+isa->intftype = intfk->smbios_type;
+isa->version = 0x20; /* Version 2.0 */
 
 if (isa->i

Re: [Qemu-devel] [PATCH 09/16] qemu-io: Move 'quit' function

[Eric Blake]

On 05/28/2013 09:27 AM, Kevin Wolf wrote:
> This one only makes sense in the context of the qemu-io tool, so move it
> to qemu-io.c. Adapt coding style and register it like other commands.
> 
> Signed-off-by: Kevin Wolf 
> ---
>  cmd.c | 29 -
>  cmd.h |  2 --
>  qemu-io.c | 17 -
>  3 files changed, 16 insertions(+), 32 deletions(-)
> 

Reviewed-by: Eric Blake 

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [PATCH 02/20] qemu-char: Allow a chardev to reconnect if disconnected

[minyard]

From: Corey Minyard 

Allow a socket that connects to reconnect on a periodic basis if it
fails to connect at startup or if the connection drops while in use.

Signed-off-by: Corey Minyard 
---
 include/sysemu/char.h |3 ++
 qemu-char.c   |   84 +++--
 qemu-options.hx   |   11 +--
 3 files changed, 85 insertions(+), 13 deletions(-)

diff --git a/include/sysemu/char.h b/include/sysemu/char.h
index a8931c6..122193b 100644
--- a/include/sysemu/char.h
+++ b/include/sysemu/char.h
@@ -79,6 +79,9 @@ struct CharDriverState {
 int avail_connections;
 QemuOpts *opts;
 QTAILQ_ENTRY(CharDriverState) next;
+GSList *backend;
+QEMUTimer *recon_timer;
+uint64_t recon_time;
 };
 
 /**
diff --git a/qemu-char.c b/qemu-char.c
index 8dc1e0d..2c34224 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -98,9 +98,22 @@ void qemu_chr_be_event(CharDriverState *s, int event)
 /* Keep track if the char device is open */
 switch (event) {
 case CHR_EVENT_OPENED:
+if (s->recon_timer) {
+qemu_del_timer(s->recon_timer);
+}
 s->be_open = 1;
 break;
 case CHR_EVENT_CLOSED:
+if (s->recon_timer) {
+void (*chr_close)(struct CharDriverState *chr) = s->chr_close;
+if (chr_close) {
+s->chr_close = NULL;
+chr_close(s);
+}
+qemu_mod_timer(s->recon_timer,
+   (qemu_get_clock_ns(vm_clock) +
+(s->recon_time * 10ULL)));
+}
 s->be_open = 0;
 break;
 }
@@ -2649,6 +2662,7 @@ static void tcp_chr_close(CharDriverState *chr)
 closesocket(s->listen_fd);
 }
 g_free(s);
+chr->opaque = NULL;
 qemu_chr_be_event(chr, CHR_EVENT_CLOSED);
 }
 
@@ -2788,8 +2802,9 @@ static CharDriverState 
*qemu_chr_open_socket(CharDriverState *chr,
 if (fd >= 0) {
 closesocket(fd);
 }
-if (chr) {
+if (chr && chr->opaque) {
 g_free(chr->opaque);
+chr->opaque = NULL;
 }
 return NULL;
 }
@@ -3214,6 +3229,21 @@ void register_char_driver_qapi(const char *name, int 
kind,
 backends = g_slist_append(backends, s);
 }
 
+static void recon_timeout(void *opaque)
+{
+CharDriverState *chr = opaque;
+CharDriver *cd = chr->backend->data;
+
+if (chr->be_open) {
+return;
+}
+
+qemu_mod_timer(chr->recon_timer,
+   (qemu_get_clock_ns(vm_clock) +
+(chr->recon_time * 10ULL)));
+cd->open(chr, chr->opts);
+}
+
 CharDriverState *qemu_chr_new_from_opts(QemuOpts *opts,
 void (*init)(struct CharDriverState *s),
 Error **errp)
@@ -3293,11 +3323,36 @@ CharDriverState *qemu_chr_new_from_opts(QemuOpts *opts,
 }
 
 chr = g_malloc0(sizeof(CharDriverState));
-chr = cd->open(chr, opts);
-if (!chr) {
-error_setg(errp, "chardev: opening backend \"%s\" failed",
-   qemu_opt_get(opts, "backend"));
-goto err;
+
+chr->backend = i;
+chr->recon_time = qemu_opt_get_number(opts, "reconnect", 0);
+if (chr->recon_time) {
+if (strcmp(qemu_opt_get(opts, "backend"), "socket") != 0) {
+g_free(chr);
+fprintf(stderr, "chardev: reconnect only supported on sockets\n");
+return NULL;
+}
+if (qemu_opt_get_bool(opts, "server", 0)) {
+g_free(chr);
+fprintf(stderr, "chardev: server device cannot reconnect\n");
+return NULL;
+}
+chr->opts = opts;
+chr->recon_timer = qemu_new_timer_ns(vm_clock, recon_timeout, chr);
+
+/* Make sure it connects in time. */
+qemu_mod_timer(chr->recon_timer,
+   (qemu_get_clock_ns(vm_clock) +
+(chr->recon_time * 10ULL)));
+}
+
+if (!cd->open(chr, opts)) {
+if (!chr->recon_time) {
+/* Reconnect is not enabled, give up */
+fprintf(stderr, "chardev: opening backend \"%s\" failed\n",
+qemu_opt_get(opts, "backend"));
+return NULL;
+}
 }
 
 if (!chr->filename)
@@ -3310,7 +3365,8 @@ CharDriverState *qemu_chr_new_from_opts(QemuOpts *opts,
 int len = strlen(qemu_opts_id(opts)) + 6;
 base->label = g_malloc(len);
 snprintf(base->label, len, "%s-base", qemu_opts_id(opts));
-chr = qemu_chr_open_mux(chr, base);
+chr = g_malloc0(sizeof(CharDriverState));
+qemu_chr_open_mux(chr, base);
 chr->filename = base->filename;
 chr->avail_connections = MAX_MUX;
 QTAILQ_INSERT_TAIL(&chardevs, chr, next);
@@ -3318,7 +3374,6 @@ CharDriverState *qemu_chr_new_from_opts(QemuOpts *opts,
 chr->avail_connections = 1;
 }
 chr->

[Qemu-devel] [PATCH 19/20] smbios: Add a function to directly add an entry

[minyard]

From: Corey Minyard 

There was no way to directly add a table entry to the SMBIOS table,
even though the BIOS supports this.  So add a function to do this.
This is in preparation for the IPMI handler adding it's SMBIOS table
entry.

Signed-off-by: Corey Minyard 
---
 hw/i386/smbios.c |   27 +++
 include/hw/i386/smbios.h |2 ++
 2 files changed, 29 insertions(+)

diff --git a/hw/i386/smbios.c b/hw/i386/smbios.c
index c00bb2f..c268f2a 100644
--- a/hw/i386/smbios.c
+++ b/hw/i386/smbios.c
@@ -178,6 +178,33 @@ static void smbios_build_type_1_fields(const char *t)
  strlen(buf) + 1, buf);
 }
 
+int smbios_table_entry_add(struct smbios_structure_header *entry)
+{
+struct smbios_table *table;
+struct smbios_structure_header *header;
+unsigned int size = entry->length;
+
+if (!smbios_entries) {
+smbios_entries_len = sizeof(uint16_t);
+smbios_entries = g_malloc0(smbios_entries_len);
+}
+smbios_entries = g_realloc(smbios_entries, smbios_entries_len +
+  sizeof(*table) + size);
+table = (struct smbios_table *)(smbios_entries + smbios_entries_len);
+table->header.type = SMBIOS_TABLE_ENTRY;
+table->header.length = cpu_to_le16(sizeof(*table) + size);
+
+header = (struct smbios_structure_header *)(table->data);
+memcpy(header, entry, size);
+
+smbios_check_collision(header->type, SMBIOS_TABLE_ENTRY);
+
+smbios_entries_len += sizeof(*table) + size;
+(*(uint16_t *)smbios_entries) =
+   cpu_to_le16(le16_to_cpu(*(uint16_t *)smbios_entries) + 1);
+return 0;
+}
+
 int smbios_entry_add(const char *t)
 {
 char buf[1024];
diff --git a/include/hw/i386/smbios.h b/include/hw/i386/smbios.h
index 94e3641..d92fa88 100644
--- a/include/hw/i386/smbios.h
+++ b/include/hw/i386/smbios.h
@@ -28,6 +28,8 @@ struct smbios_structure_header {
 uint16_t handle;
 } QEMU_PACKED;
 
+int smbios_table_entry_add(struct smbios_structure_header *entry);
+
 /* SMBIOS type 0 - BIOS Information */
 struct smbios_type_0 {
 struct smbios_structure_header header;
-- 
1.7.9.5

[Qemu-devel] [PATCH 20/20] ipmi: Add SMBIOS table entry

[minyard]

From: Corey Minyard 

Add an IPMI table entry to the SMBIOS.

Signed-off-by: Corey Minyard 
---
 hw/ipmi/isa_ipmi.c   |   23 +++
 include/hw/i386/smbios.h |   12 
 2 files changed, 35 insertions(+)

diff --git a/hw/ipmi/isa_ipmi.c b/hw/ipmi/isa_ipmi.c
index 92afb88..706cc2c 100644
--- a/hw/ipmi/isa_ipmi.c
+++ b/hw/ipmi/isa_ipmi.c
@@ -29,6 +29,7 @@
 #include "qemu/timer.h"
 #include "sysemu/char.h"
 #include "sysemu/sysemu.h"
+#include "hw/i386/smbios.h"
 #include "ipmi.h"
 
 /* This is the type the user specifies on the -device command line */
@@ -162,6 +163,27 @@ ipmi_encode_acpi(ISAIPMIDevice *info)
 acpi_append_to_table("DSDT", ipmitable, rc, &err);
 }
 
+static void ipmi_encode_smbios(ISAIPMIDevice *info)
+{
+struct smbios_type_38 smb38;
+
+smb38.header.type = 38;
+smb38.header.length = sizeof(smb38);
+smb38.header.handle = cpu_to_le16(0x3000);
+smb38.interface_type = info->intftype;
+smb38.ipmi_spec_revision = 0x20;
+smb38.i2c_slave_address = info->slave_addr;
+smb38.nv_storage_device_address = 0;
+
+/* or 1 to set it to I/O space */
+smb38.base_address = cpu_to_le64(info->iobase | 1);
+
+ /* 1-byte boundaries, addr bit0=0, level triggered irq */
+smb38.base_address_modifier = 1;
+smb38.interrupt_number = info->isairq;
+smbios_table_entry_add((struct smbios_structure_header *) &smb38);
+}
+
 static int ipmi_isa_initfn(ISADevice *dev)
 {
 ISAIPMIDevice *isa = ISA_IPMI(dev);
@@ -233,6 +255,7 @@ static int ipmi_isa_initfn(ISADevice *dev)
 isa_register_ioport(dev, &intf->io, intf->io_base);
 
 ipmi_encode_acpi(isa);
+ipmi_encode_smbios(isa);
 
 return 0;
 }
diff --git a/include/hw/i386/smbios.h b/include/hw/i386/smbios.h
index d92fa88..fb79d5a 100644
--- a/include/hw/i386/smbios.h
+++ b/include/hw/i386/smbios.h
@@ -156,6 +156,18 @@ struct smbios_type_32 {
 uint8_t boot_status;
 } QEMU_PACKED;
 
+/* SMBIOS type 38 - IPMI */
+struct smbios_type_38 {
+struct smbios_structure_header header;
+uint8_t interface_type;
+uint8_t ipmi_spec_revision;
+uint8_t i2c_slave_address;
+uint8_t nv_storage_device_address;
+uint64_t base_address;
+uint8_t base_address_modifier;
+uint8_t interrupt_number;
+} QEMU_PACKED;
+
 /* SMBIOS type 127 -- End-of-table */
 struct smbios_type_127 {
 struct smbios_structure_header header;
-- 
1.7.9.5

[Qemu-devel] [PATCH 15/20] acpi: Add a way to extend tables

[minyard]

From: Corey Minyard 

Add a function that can extend the contents of a given
ACPI table to add on new entries.  This way devices that
have ACPI entries can add them.

Signed-off-by: Corey Minyard 
---
 hw/acpi/core.c |   47 +++
 include/hw/acpi/acpi.h |2 ++
 2 files changed, 49 insertions(+)

diff --git a/hw/acpi/core.c b/hw/acpi/core.c
index 42eeace..4bd006c 100644
--- a/hw/acpi/core.c
+++ b/hw/acpi/core.c
@@ -229,6 +229,53 @@ static void acpi_table_install(const char unsigned *blob, 
size_t bloblen,
   ACPI_TABLE_PFX_SIZE, acpi_payload_size);
 }
 
+void acpi_append_to_table(const char *sig, void *blob, size_t bloblen,
+  Error **errp)
+{
+struct acpi_table_header *ext_hdr;
+unsigned int ntables, i;
+size_t acpi_payload_size;
+size_t pos, pos2;
+
+if (!acpi_tables)
+return;
+
+ntables = le16_to_cpupu((uint16_t *)acpi_tables);
+pos = sizeof(uint16_t);
+for (i = 0; i < ntables; i++) {
+ext_hdr = (void *) (((char *) acpi_tables) + pos);
+if (memcmp(sig, ext_hdr->sig, 4) == 0)
+break;
+pos += le16_to_cpupu(&ext_hdr->_length) + ACPI_TABLE_PFX_SIZE;
+}
+if (i == ntables)
+return;
+
+acpi_payload_size = le16_to_cpupu(&ext_hdr->_length);
+if (acpi_payload_size + bloblen > UINT16_MAX) {
+error_setg(errp, "ACPI table overflow adding field");
+return;
+}
+
+acpi_tables = g_realloc(acpi_tables, acpi_tables_len + bloblen);
+
+pos2 = pos + acpi_payload_size + ACPI_TABLE_PFX_SIZE;
+memcpy(acpi_tables + pos2 + bloblen, acpi_tables + pos2,
+   acpi_tables_len - pos2);
+memcpy(acpi_tables + pos2, blob, bloblen);
+
+acpi_payload_size += bloblen;
+
+ext_hdr = (void *) (((char *) acpi_tables) + pos);
+ext_hdr->_length = cpu_to_le16(acpi_payload_size);
+ext_hdr->length = cpu_to_le32(acpi_payload_size);
+
+ext_hdr->checksum = 0;
+ext_hdr->checksum = acpi_checksum((const char unsigned *)ext_hdr +
+  ACPI_TABLE_PFX_SIZE, acpi_payload_size);
+acpi_tables_len += bloblen;
+}
+
 void acpi_table_add(const QemuOpts *opts, Error **errp)
 {
 AcpiTableOptions *hdrs = NULL;
diff --git a/include/hw/acpi/acpi.h b/include/hw/acpi/acpi.h
index 635be7b..01d3a1b 100644
--- a/include/hw/acpi/acpi.h
+++ b/include/hw/acpi/acpi.h
@@ -166,5 +166,7 @@ extern char unsigned *acpi_tables;
 extern size_t acpi_tables_len;
 
 void acpi_table_add(const QemuOpts *opts, Error **errp);
+void acpi_append_to_table(const char *sig, void *blob, size_t bloblen,
+  Error **errp);
 
 #endif /* !QEMU_HW_ACPI_H */
-- 
1.7.9.5

[Qemu-devel] [PATCH 06/20] Add a base IPMI interface

[minyard]

From: Corey Minyard 

Add the basic IPMI types and infrastructure to QEMU.  Low-level
interfaces and simulation interfaces will register with this; it's
kind of the go-between to tie them together.

Signed-off-by: Corey Minyard 
---
 default-configs/i386-softmmu.mak   |1 +
 default-configs/x86_64-softmmu.mak |1 +
 hw/Makefile.objs   |1 +
 hw/ipmi/Makefile.objs  |1 +
 hw/ipmi/ipmi.c |  167 +
 hw/ipmi/ipmi.h |  241 
 qemu-doc.texi  |2 +
 7 files changed, 414 insertions(+)
 create mode 100644 hw/ipmi/Makefile.objs
 create mode 100644 hw/ipmi/ipmi.c
 create mode 100644 hw/ipmi/ipmi.h

diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 03deca2..84542ab 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -10,6 +10,7 @@ CONFIG_VGA_ISA=y
 CONFIG_VGA_CIRRUS=y
 CONFIG_VMWARE_VGA=y
 CONFIG_VMMOUSE=y
+CONFIG_IPMI=y
 CONFIG_SERIAL=y
 CONFIG_PARALLEL=y
 CONFIG_I8254=y
diff --git a/default-configs/x86_64-softmmu.mak 
b/default-configs/x86_64-softmmu.mak
index 599b630..d580dc0 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -10,6 +10,7 @@ CONFIG_VGA_ISA=y
 CONFIG_VGA_CIRRUS=y
 CONFIG_VMWARE_VGA=y
 CONFIG_VMMOUSE=y
+CONFIG_IPMI=y
 CONFIG_SERIAL=y
 CONFIG_PARALLEL=y
 CONFIG_I8254=y
diff --git a/hw/Makefile.objs b/hw/Makefile.objs
index 0243d6a..eeeb3bd 100644
--- a/hw/Makefile.objs
+++ b/hw/Makefile.objs
@@ -12,6 +12,7 @@ devices-dirs-$(CONFIG_SOFTMMU) += i2c/
 devices-dirs-$(CONFIG_SOFTMMU) += ide/
 devices-dirs-$(CONFIG_SOFTMMU) += input/
 devices-dirs-$(CONFIG_SOFTMMU) += intc/
+devices-dirs-$(CONFIG_SOFTMMU) += ipmi/
 devices-dirs-$(CONFIG_SOFTMMU) += isa/
 devices-dirs-$(CONFIG_SOFTMMU) += misc/
 devices-dirs-$(CONFIG_SOFTMMU) += net/
diff --git a/hw/ipmi/Makefile.objs b/hw/ipmi/Makefile.objs
new file mode 100644
index 000..65bde11
--- /dev/null
+++ b/hw/ipmi/Makefile.objs
@@ -0,0 +1 @@
+common-obj-$(CONFIG_IPMI) += ipmi.o
diff --git a/hw/ipmi/ipmi.c b/hw/ipmi/ipmi.c
new file mode 100644
index 000..21560a9
--- /dev/null
+++ b/hw/ipmi/ipmi.c
@@ -0,0 +1,167 @@
+/*
+ * QEMU IPMI emulation
+ *
+ * Copyright (c) 2012 Corey Minyard, MontaVista Software, LLC
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "hw/hw.h"
+#include "ipmi.h"
+#include "sysemu/sysemu.h"
+#include "qmp-commands.h"
+
+#ifdef DO_IPMI_THREAD
+static void *ipmi_thread(void *opaque)
+{
+IPMIInterface *s = opaque;
+int64_t wait_until;
+
+ipmi_lock(s);
+for (;;) {
+qemu_cond_wait(&s->waker, &s->lock);
+wait_until = 0;
+while (s->do_wake) {
+s->do_wake = 0;
+s->handle_if_event(s);
+}
+}
+ipmi_unlock(s);
+return NULL;
+}
+#endif
+
+static int ipmi_do_hw_op(IPMIInterface *s, enum ipmi_op op, int checkonly)
+{
+switch (op) {
+case IPMI_RESET_CHASSIS:
+if (checkonly) {
+return 0;
+}
+qemu_system_reset_request();
+return 0;
+
+case IPMI_POWEROFF_CHASSIS:
+if (checkonly) {
+return 0;
+}
+qemu_system_powerdown_request();
+return 0;
+
+case IPMI_SEND_NMI:
+if (checkonly) {
+return 0;
+}
+qemu_mutex_lock_iothread();
+qmp_inject_nmi(NULL);
+qemu_mutex_unlock_iothread();
+return 0;
+
+case IPMI_POWERCYCLE_CHASSIS:
+case IPMI_PULSE_DIAG_IRQ:
+case IPMI_SHUTDOWN_VIA_ACPI_OVERTEMP:
+case IPMI_POWERON_CHASSIS:
+default:
+return IPMI_CC_COMMAND_NOT_SUPPORTED;
+}
+}
+
+static void ipmi_set_irq_enable(IPMIInterface *s, int val)
+{
+s->irqs_enabled = val;
+}
+
+void ipmi_interface_reset(IPMIInterface *s)
+{
+IPMIBmcClass *bk = IPMI_BMC_GET_CLASS(s->bmc);
+
+if (b

[Qemu-devel] [PATCH 03/20] qemu-char: Fix a race reporting opens and closes

[minyard]

From: Corey Minyard 

When an open event is reported, it is done through a bh.  But close
events are reported immediately.  So if an open event is in the bh
and a close occurs, an extraneous open happens, which can confuse a
user.

To fix this, this patch sets the "opened" flag immediately instead
of in the bh handler and checks to make sure the opened flag is
set before reporting an open event.

This also modifies the spice code to call qemu_chr_generic_open
to report an open, to keep things consistent.

Signed-off-by: Corey Minyard 
---
 qemu-char.c   |   18 --
 spice-qemu-char.c |7 +--
 2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/qemu-char.c b/qemu-char.c
index 2c34224..76cddd9 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -98,10 +98,13 @@ void qemu_chr_be_event(CharDriverState *s, int event)
 /* Keep track if the char device is open */
 switch (event) {
 case CHR_EVENT_OPENED:
+/*
+ * See the comment in qemu_chr_generic_open_bh() for why
+ * 's->opened = 1' is not here.
+ */
 if (s->recon_timer) {
 qemu_del_timer(s->recon_timer);
 }
-s->be_open = 1;
 break;
 case CHR_EVENT_CLOSED:
 if (s->recon_timer) {
@@ -126,13 +129,24 @@ void qemu_chr_be_event(CharDriverState *s, int event)
 static gboolean qemu_chr_be_generic_open_bh(gpointer opaque)
 {
 CharDriverState *s = opaque;
-qemu_chr_be_event(s, CHR_EVENT_OPENED);
+/*
+ * Since the "close" event doesn't go through a bh, there is a
+ * possible race condition if a close comes in after an open, but
+ * the open is in the bh queue.  So we double-check here, and we
+ * set opened in qemu_chr_generic_open() instead of
+ * qemu_chr_be_event().
+ */
+if (s->be_open) {
+qemu_chr_be_event(s, CHR_EVENT_OPENED);
+}
 s->idle_tag = 0;
 return FALSE;
 }
 
 void qemu_chr_be_generic_open(CharDriverState *s)
 {
+/* See the comment in qemu_chr_generic_open_bh() for why this is here */
+s->be_open = 1;
 if (s->idle_tag == 0) {
 s->idle_tag = g_idle_add(qemu_chr_be_generic_open_bh, s);
 }
diff --git a/spice-qemu-char.c b/spice-qemu-char.c
index 69c5938..436ab21 100644
--- a/spice-qemu-char.c
+++ b/spice-qemu-char.c
@@ -97,8 +97,11 @@ static void vmc_state(SpiceCharDeviceInstance *sin, int 
connected)
 return;
 }
 
-qemu_chr_be_event(scd->chr,
-  connected ? CHR_EVENT_OPENED : CHR_EVENT_CLOSED);
+if (connected) {
+qemu_chr_generic_open(scd->chr);
+} else {
+qemu_chr_be_event(scd->chr, CHR_EVENT_CLOSED);
+}
 }
 
 static SpiceCharDeviceInterface vmc_interface = {
-- 
1.7.9.5

[Qemu-devel] [PATCH 00/20] Add an IPMI device to QEMU

[minyard]

I have finally gotten some time to work on this, this series of
patches adds an IPMI interface to qemu.  The changes are roughly:

patches 01-05 - Add the capability to have a chardev reconnect if
the connections fails.  This way, if using an external BMC, qemu
will detect the failure and periodically attempt to reconnect.
This also adds ways for the device code to get an event on a
disconnect and connect so it can handle it properly.  This is
probably useful for things besides IPMI.  There are also a few
small bugfixes in this.

patches 06-14 - Add the IPMI device itself, with an ISA interface
for now (PCI and others can also be added easily).

patches 15-18 - Add a way to dynamically add content to the ACPI
tables, and add the capability to add the IPMI information to the
table.

Patches 19-20 - Add a way to dynamically add content to the SMBIOS
tables, and add an IPMI entry to the table.

[Qemu-devel] [PATCH 05/20] qemu-char: Close fd at end of file

[minyard]

From: Corey Minyard 

The chardev backends that used qemu_chr_open_fd did not get their
file descriptors closed at end of file or when the chardev was closed.
This could result in a file descriptor leak.

Signed-off-by: Corey Minyard 
---
 qemu-char.c |   35 +--
 1 file changed, 29 insertions(+), 6 deletions(-)

diff --git a/qemu-char.c b/qemu-char.c
index 1270a65..e959ccf 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -796,6 +796,8 @@ typedef struct FDCharDriver {
 guint fd_in_tag;
 int max_size;
 QTAILQ_ENTRY(FDCharDriver) node;
+int close_fdin;
+int close_fdout;
 } FDCharDriver;
 
 static int fd_chr_write(CharDriverState *chr, const uint8_t *buf, int len)
@@ -805,6 +807,18 @@ static int fd_chr_write(CharDriverState *chr, const 
uint8_t *buf, int len)
 return io_channel_send(s->fd_out, buf, len);
 }
 
+static void fd_close_fds(FDCharDriver *s)
+{
+if ((s->close_fdin != s->close_fdout) && (s->close_fdout != -1)) {
+close(s->close_fdout);
+}
+s->close_fdout = -1;
+if (s->close_fdin != -1) {
+close(s->close_fdin);
+}
+s->close_fdin = -1;
+}
+
 static gboolean fd_chr_read(GIOChannel *chan, GIOCondition cond, void *opaque)
 {
 CharDriverState *chr = opaque;
@@ -829,6 +843,7 @@ static gboolean fd_chr_read(GIOChannel *chan, GIOCondition 
cond, void *opaque)
 io_remove_watch_poll(s->fd_in_tag);
 s->fd_in_tag = 0;
 }
+fd_close_fds(s);
 qemu_chr_be_event(chr, CHR_EVENT_CLOSED);
 return FALSE;
 }
@@ -884,19 +899,27 @@ static void fd_chr_close(struct CharDriverState *chr)
 g_io_channel_unref(s->fd_out);
 }
 
+fd_close_fds(s);
 g_free(s);
 qemu_chr_be_event(chr, CHR_EVENT_CLOSED);
 }
 
 /* open a character device to a unix fd */
 static CharDriverState *qemu_chr_open_fd(CharDriverState *chr,
- int fd_in, int fd_out)
+ int fd_in, int fd_out,
+ int close_fds_on_close)
 {
 FDCharDriver *s;
 
 s = g_malloc0(sizeof(FDCharDriver));
 s->fd_in = io_channel_from_fd(fd_in);
 s->fd_out = io_channel_from_fd(fd_out);
+if (close_fds_on_close) {
+s->close_fdin = fd_in;
+s->close_fdout = fd_out;
+} else {
+s->close_fdin = s->close_fdout = -1;
+}
 fcntl(fd_out, F_SETFL, O_NONBLOCK);
 s->chr = chr;
 chr->opaque = s;
@@ -936,7 +959,7 @@ static CharDriverState *qemu_chr_open_pipe(CharDriverState 
*chr,
 return NULL;
 }
 }
-return qemu_chr_open_fd(chr, fd_in, fd_out);
+return qemu_chr_open_fd(chr, fd_in, fd_out, TRUE);
 }
 
 /* init terminal so that we can grab keys */
@@ -990,7 +1013,7 @@ static CharDriverState 
*qemu_chr_open_stdio(CharDriverState *chr,
 fcntl(0, F_SETFL, O_NONBLOCK);
 atexit(term_exit);
 
-qemu_chr_open_fd(chr, 0, 1);
+qemu_chr_open_fd(chr, 0, 1, FALSE);
 chr->chr_close = qemu_chr_close_stdio;
 chr->chr_set_echo = qemu_chr_set_echo_stdio;
 stdio_allow_signal = display_type != DT_NOGRAPHIC;
@@ -1473,7 +1496,7 @@ static void qemu_chr_close_tty(CharDriverState *chr)
 static CharDriverState *qemu_chr_open_tty_fd(CharDriverState *chr, int fd)
 {
 tty_serial_init(fd, 115200, 'N', 8, 1);
-qemu_chr_open_fd(chr, fd, fd);
+qemu_chr_open_fd(chr, fd, fd, TRUE);
 chr->chr_ioctl = tty_serial_ioctl;
 chr->chr_close = qemu_chr_close_tty;
 return chr;
@@ -2561,7 +2584,7 @@ static gboolean tcp_chr_read(GIOChannel *chan, 
GIOCondition cond, void *opaque)
 #ifndef _WIN32
 CharDriverState *qemu_chr_open_eventfd(CharDriverState *chr, int eventfd)
 {
-return qemu_chr_open_fd(chr, eventfd, eventfd);
+return qemu_chr_open_fd(chr, eventfd, eventfd, FALSE);
 }
 #endif
 
@@ -3692,7 +3715,7 @@ static CharDriverState 
*qmp_chardev_open_file(CharDriverState *chr,
 }
 }
 
-return qemu_chr_open_fd(chr, in, out);
+return qemu_chr_open_fd(chr, in, out, TRUE);
 }
 
 static CharDriverState *qmp_chardev_open_serial(CharDriverState *chr,
-- 
1.7.9.5

[Qemu-devel] [PATCH 04/20] qemu-char: remove free of chr from win_stdio_close

[minyard]

From: Corey Minyard 

This will result in a double free on close, because it's freed
in qemu_chr_delete() right after calling the close function.

Signed-off-by: Corey Minyard 
---
 qemu-char.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/qemu-char.c b/qemu-char.c
index 76cddd9..1270a65 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -2145,7 +2145,6 @@ static void win_stdio_close(CharDriverState *chr)
 }
 
 g_free(chr->opaque);
-g_free(chr);
 }
 
 static CharDriverState *qemu_chr_open_stdio(CharDriverState *chr,
-- 
1.7.9.5

[Qemu-devel] [PATCH 13/20] ipmi: Add documentation

[minyard]

From: Corey Minyard 

Add some basic documentation for the IPMI device.

Signed-off-by: Corey Minyard 
---
 qemu-options.hx |   35 +++
 1 file changed, 35 insertions(+)

diff --git a/qemu-options.hx b/qemu-options.hx
index df5488f..538572d 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -327,6 +327,41 @@ Add device @var{driver}.  @var{prop}=@var{value} sets 
driver
 properties.  Valid properties depend on the driver.  To get help on
 possible drivers and properties, use @code{-device help} and
 @code{-device @var{driver},help}.
+
+Some drivers are:
+@item -device 
isa-ipmi[,interface=kcs|bt][,iobase=@var{val}][,irq=@var{val}][,slave_addr=@var{val}][,chardev=name]
+
+Add an IPMI device.  This also adds a corresponding SMBIOS entry to the
+SMBIOS tables for x86.  The following options are handled:
+@table @option
+@item interface=kcs|bt
+Define the interface type to use.  Currently the IPMI-defined KCS and
+BT interfaces are handled.  The default is KCS.
+@item iobase=@var{val}
+Define the I/O address of the interface.  The default is 0xca0 for KCS
+and 0xe4 for BT.
+@item irq=@var{val}
+Define the interrupt to use.  The default is 5.  To disable interrupts,
+set this to 0.
+@item slave_addr=@var{val}
+The IPMI slave address to use for the BMC.  The default is 0x20.
+@item chardev=name
+If a chardev is not specified, the IPMI driver uses a built-in baseboard
+management controller (BMC) simulator.  It provides a basic BMC with a
+watchdog timer and associated sensor.
+
+If a chardev is specified, A connection is made to an external BMC
+simulator.  If you do this, it is strongly recommended that you use
+the "reconnect=" chardev option to reconnect to the simulator if the
+connection is lost.  Note that if this is not used carefully, it can
+be a security issue, as the interface has the ability to send resets,
+NMIs, and power off the VM.  It's best if QEMU makes a connection to
+an external simulator running on a secure port on localhost, so
+neither the simulator nor QEMU is exposed to any outside network.
+
+See the "lanserv/README.vm" file in the OpenIPMI library for more
+details on the external interface.
+@end table
 ETEXI
 
 DEF("name", HAS_ARG, QEMU_OPTION_name,
-- 
1.7.9.5

Re: [Qemu-devel] [PATCH 08/16] qemu-io: Move 'help' function

[Eric Blake]

On 05/28/2013 09:27 AM, Kevin Wolf wrote:
> No reason to treat it different from other commands. Move it to
> qemu-io-cmds.c, adapt the coding style and register it like any other
> command.
> 
> Signed-off-by: Kevin Wolf 
> ---
>  cmd.c  | 79 
> --
>  cmd.h  |  1 -
>  qemu-io-cmds.c | 67 -
>  3 files changed, 66 insertions(+), 81 deletions(-)

> -void
> -help_init(void)
> -{
> - help_cmd.name = _("help");
> - help_cmd.altname = _("?");
> - help_cmd.cfunc = help_f;
> - help_cmd.argmin = 0;
> - help_cmd.argmax = 1;
> - help_cmd.flags = CMD_FLAG_GLOBAL;
> - help_cmd.args = _("[command]");
> - help_cmd.oneline = _("help for one or all commands");

The old code marked strings for translation with _(), ...

> +static const cmdinfo_t help_cmd = {
> +.name   = "help",
> +.altname= "?",
> +.cfunc  = help_f,
> +.argmin = 0,
> +.argmax = 1,
> +.flags  = CMD_FLAG_GLOBAL,
> +.args   = "[command]",
> +.oneline= "help for one or all commands",

...whereas the new code uses fixed literals.  Then again, po/messages.po
doesn't contain any mention of cmd.c, so it's not like we were actually
translating the strings, even if they were marked for translation.  So
no real change.

Reviewed-by: Eric Blake 

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH] seccomp: add the asynchronous I/O syscalls to the whitelist

[Corey Bryant]

On 05/29/2013 04:30 PM, Paul Moore wrote:

In order to enable the asynchronous I/O functionality when using the
seccomp sandbox we need to add the associated syscalls to the
whitelist.

Signed-off-by: Paul Moore 
---
  qemu-seccomp.c |5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/qemu-seccomp.c b/qemu-seccomp.c
index 031da1d..ca123bf 100644
--- a/qemu-seccomp.c
+++ b/qemu-seccomp.c
@@ -87,6 +87,7 @@ static const struct QemuSeccompSyscall seccomp_whitelist[] = {
  { SCMP_SYS(stat), 245 },
  { SCMP_SYS(uname), 245 },
  { SCMP_SYS(eventfd2), 245 },
+{ SCMP_SYS(io_getevents), 245 },
  { SCMP_SYS(dup), 245 },
  { SCMP_SYS(dup2), 245 },
  { SCMP_SYS(dup3), 245 },
@@ -229,7 +230,9 @@ static const struct QemuSeccompSyscall seccomp_whitelist[] 
= {
  { SCMP_SYS(sendmmsg), 241 },
  { SCMP_SYS(recvmmsg), 241 },
  { SCMP_SYS(prlimit64), 241 },
-{ SCMP_SYS(waitid), 241 }
+{ SCMP_SYS(waitid), 241 },
+{ SCMP_SYS(io_setup), 241 },
+{ SCMP_SYS(io_destroy), 241 }
  };

  int seccomp_start(void)





Thanks for the patch.  It looks good to me and I see these are used by 
the block aio code.


Reviewed-by: Corey Bryant 

--
Regards,
Corey Bryant

Re: [Qemu-devel] [PATCH 07/16] qemu-io: Factor out qemuio_command

[Eric Blake]

On 05/28/2013 09:27 AM, Kevin Wolf wrote:
> It's duplicated code. Move it to qemu-io-cmds.c because it's not
> dependent on any static data of the qemu-io tool.
> 
> Signed-off-by: Kevin Wolf 
> ---
>  cmd.c  | 43 +--
>  cmd.h  |  3 ++-
>  qemu-io-cmds.c | 24 
>  3 files changed, 31 insertions(+), 39 deletions(-)
> 

Reviewed-by: Eric Blake 

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2] monitor: work around delayed CHR_EVENT_OPENED events

[mdroth]

On Wed, May 29, 2013 at 01:27:33PM -0400, Luiz Capitulino wrote:
> On Mon, 27 May 2013 12:59:25 -0500
> mdroth  wrote:
> 
> > On Mon, May 27, 2013 at 11:16:01AM -0500, Anthony Liguori wrote:
> > > Luiz Capitulino  writes:
> > > 
> > > > On Sun, 26 May 2013 10:33:39 -0500
> > > > Michael Roth  wrote:
> > > >
> > > >> In the past, CHR_EVENT_OPENED events were emitted via a pre-expired
> > > >> QEMUTimer. Due to timers being processing at the tail end of each main
> > > >> loop iteration, this generally meant that such events would be emitted
> > > >> within the same main loop iteration, prior any client data being read
> > > >> by tcp/unix socket server backends.
> > > >> 
> > > >> With 9f939df955a4152aad69a19a77e0898631bb2c18, this was switched to
> > > >> a "bottom-half" that is registered via g_idle_add(). This makes it
> > > >> likely that the event won't be sent until a subsequent iteration, and
> > > >> also adds the possibility that such events will race with the
> > > >> processing of client data.
> > > >> 
> > > >> In cases where we rely on the CHR_EVENT_OPENED event being delivered
> > > >> prior to any client data being read, this may cause unexpected 
> > > >> behavior.
> > > >> 
> > > >> In the case of a QMP monitor session using a socket backend, the 
> > > >> delayed
> > > >> processing of the CHR_EVENT_OPENED event can lead to a situation where
> > > >> a previous session, where 'qmp_capabilities' has already processed, can
> > > >> cause the rejection of 'qmp_capabilities' for a subsequent session,
> > > >> since we reset capabilities in response to CHR_EVENT_OPENED, which may
> > > >> not yet have been delivered. This can be reproduced with the following
> > > >> command, generally within 50 or so iterations:
> > > >> 
> > > >>   mdroth@loki:~$ cat cmds
> > > >>   {'execute':'qmp_capabilities'}
> > > >>   {'execute':'query-cpus'}
> > > >>   mdroth@loki:~$ while true; do if socat stdio 
> > > >> unix-connect:/tmp/qmp.sock
> > > >>   /dev/null; then echo failed; break; 
> > > >> else
> > > >>   echo ok; fi; done;
> > > >>   ok
> > > >>   ok
> > > >>   failed
> > > >>   mdroth@loki:~$
> > > >> 
> > > >> As a work-around, we reset capabilities as part of the CHR_EVENT_CLOSED
> > > >> hook, which gets called as part of the GIOChannel cb associated with 
> > > >> the
> > > >> client rather than a bottom-half, and is thus guaranteed to be 
> > > >> delivered
> > > >> prior to accepting any subsequent client sessions.
> > > >> 
> > > >> This does not address the more general problem of whether or not there
> > > >> are chardev users that rely on CHR_EVENT_OPENED being delivered prior 
> > > >> to
> > > >> client data, and whether or not we should consider moving 
> > > >> CHR_EVENT_OPENED
> > > >> "in-band" with connection establishment as a general solution, but 
> > > >> fixes
> > > >> QMP for the time being.
> > > >> 
> > > >> Reported-by: Stefan Priebe 
> > > >> Cc: qemu-sta...@nongnu.org
> > > >> Signed-off-by: Michael Roth 
> > > >
> > > > Thanks for debugging this Michael. I'm going to apply your patch to the 
> > > > qmp
> > > > branch because we can't let this broken (esp. in -stable) but this is 
> > > > papering
> > > > over the real bug...
> > > 
> > > Do we really need OPENED to happen in a bottom half?  Shouldn't the open
> > > event handlers register the callback instead if they need it?
> > 
> > I think that's the more general fix, but wasn't sure if there were
> > historical reasons why we didn't do this in the first place.
> > 
> > Looking at it more closely it does seem like we need a general fix
> > sooner rather than later though, and I don't see any reason why we can't
> > move BH registration into the actual OPENED hooks as you suggest:
> > 
> > hw/usb/ccid-card-passthru.c
> >  - currently affected? no
> > debug hook only
> >  - needs OPENED BH? no
> > 
> > hw/usb/redirect.c
> >  - currently affected? yes
> > can_read handler checks for dev->parser != NULL, which may be
> > true if CLOSED BH has been executed yet. In the past, OPENED
> > quiesced outstanding CLOSED events prior to us reading client data.
> >  - need OPENED BH? possibly
> > seems to only be needed by CLOSED events, which can be issued by
> > USBDevice, so we do teardown/usb_detach in BH. For OPENED, this
> > may not apply. if we do issue a BH, we'd need to modify can_read
> > handler to avoid race.
> > 
> > hw/usb/dev-serial.c
> >  - currently affected? no
> > can_read checks for dev.attached != NULL. set to NULL
> > synchronously in CLOSED, will not accept reads until OPENED gets
> > called and sets dev.attached
> >  - need opened BH?  no
> > 
> > hw/char/sclpconsole.c
> >  - currently affected? no
> > guarded by can_read handler
> >  - need opened BH? no
> > 
> > hw/char/ipoctal232.c
> >  - currently affected? no
> > debug hook only
> >  - need opened BH? no
> > 
> > hw/char/virtio-console.c
> >  - currently affected? no
> > OPENED/CLOSED map to vq even

[Qemu-devel] [PATCH] seccomp: add the asynchronous I/O syscalls to the whitelist

[Paul Moore]

In order to enable the asynchronous I/O functionality when using the
seccomp sandbox we need to add the associated syscalls to the
whitelist.

Signed-off-by: Paul Moore 
---
 qemu-seccomp.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/qemu-seccomp.c b/qemu-seccomp.c
index 031da1d..ca123bf 100644
--- a/qemu-seccomp.c
+++ b/qemu-seccomp.c
@@ -87,6 +87,7 @@ static const struct QemuSeccompSyscall seccomp_whitelist[] = {
 { SCMP_SYS(stat), 245 },
 { SCMP_SYS(uname), 245 },
 { SCMP_SYS(eventfd2), 245 },
+{ SCMP_SYS(io_getevents), 245 },
 { SCMP_SYS(dup), 245 },
 { SCMP_SYS(dup2), 245 },
 { SCMP_SYS(dup3), 245 },
@@ -229,7 +230,9 @@ static const struct QemuSeccompSyscall seccomp_whitelist[] 
= {
 { SCMP_SYS(sendmmsg), 241 },
 { SCMP_SYS(recvmmsg), 241 },
 { SCMP_SYS(prlimit64), 241 },
-{ SCMP_SYS(waitid), 241 }
+{ SCMP_SYS(waitid), 241 },
+{ SCMP_SYS(io_setup), 241 },
+{ SCMP_SYS(io_destroy), 241 }
 };
 
 int seccomp_start(void)

Re: [Qemu-devel] [PATCH 06/16] qemu-io: Split off commands to qemu-io-cmds.c

[Eric Blake]

On 05/28/2013 09:27 AM, Kevin Wolf wrote:
> This is the implementation of all qemu-io commands that make sense to be
> called from the qemu monitor, i.e. everything except open, close and
> quit.
> 
> Signed-off-by: Kevin Wolf 
> ---
>  Makefile   |2 +-
>  qemu-io-cmds.c | 1835 
> 
>  qemu-io.c  | 1817 +--
>  3 files changed, 1838 insertions(+), 1816 deletions(-)
>  create mode 100644 qemu-io-cmds.c

I checked the bulk of this patch via:

$ diff -u <(sed -n '/^-/ s///p' file) <(sed -n '/^\+/ s///p' file)

The bulk of the patch is blind code motion plus a bit of touchup; I did
however spot one case where you were too eager in your search-and-replace:

  * Memory allocation helpers.
  *
- * Make sure memory is aligned by default, or purposefully misaligned if
+ * Make sure memory is aligned by default, or purposefully
qemuio_misaligned if
  * that is specified on the command line.

> +
> +int qemuio_misalign;

Should this variable be typed 'bool'?

Other than that,

Reviewed-by: Eric Blake 

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [PATCH 1/4] util/envlist: Properly forward a callback's error in envlist_parse.

[Thomas Schwinge]

Signed-off-by: Thomas Schwinge 
---
 util/envlist.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git util/envlist.c util/envlist.c
index ebc06cf..cbbf7e5 100644
--- util/envlist.c
+++ util/envlist.c
@@ -109,9 +109,10 @@ envlist_parse(envlist_t *envlist, const char *env,
 
envvar = strtok_r(tmpenv, ",", &envsave);
while (envvar != NULL) {
-   if ((*callback)(envlist, envvar) != 0) {
+   int err;
+   if ((err = (*callback)(envlist, envvar)) != 0) {
free(tmpenv);
-   return (errno);
+   return (err);
}
envvar = strtok_r(NULL, ",", &envsave);
}
-- 
1.7.10.4

[Qemu-devel] [Bug 1180970] Re: qemu: fatal: Trying to execute code outside RAM or ROM; worked in 1.4.0, fails in 1.4.92

[Duane Voth]

I just tried Richard's fix against HEAD (6a4e17711) and it works for me.
I also like that his fix clearly constrains aflag to the values 1 and 2
for 64bit mode - a concept which matches the intent of the 0x67 prefix.

$ git diff target-i386/translate.c 
diff --git a/target-i386/translate.c b/target-i386/translate.c
index 0aeccdb..cb7fe0b 100644
--- a/target-i386/translate.c
+++ b/target-i386/translate.c
@@ -4816,6 +4816,8 @@ static target_ulong disas_insn(CPUX86State *env, DisasCont
 if (!(prefixes & PREFIX_ADR)) {
 aflag = 2;
 }
+/* 0x67 toggles between 64-bit and 32-bit addressing */
+aflag = (prefixes & PREFIX_ADR ? 1 : 2);
 }
 #endif

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1180970

Title:
  qemu: fatal: Trying to execute code outside RAM or ROM; worked in
  1.4.0, fails in 1.4.92

Status in QEMU:
  In Progress

Bug description:
  I'm using qemu to run and debug the EDK2 uEFI environment. OVMF is
  being built out of the EDK2 tree I've checked out (r14367).
  (Reproducing all this could be tedious so I am available for
  debugging/testing.)

  qemu 1.4.0 was able to execute this guest environment with no trouble,
  qemu 1.4.92 however issues an error message and aborts.  The command
  line I use to start qemu is:

  $ /usr/local/bin/qemu-system-x86_64 -m 1024 -bios OVMF.fd -monitor
  stdio

  1.4.92 gives the following register dump:

  QEMU 1.4.92 monitor - type 'help' for more information
  (qemu) qemu: fatal: Trying to execute code outside RAM or ROM at 
0x0001

  RAX=3e084da8 RBX=3e084868 RCX= 
RDX=3e084f00
  RSI=0001 RDI=3e085000 RBP=3e084708 
RSP=3fac8510
  R8 = R9 =3e14c3e3 R10=0033 
R11=00d3
  R12=3e0848a0 R13= R14= 
R15=
  RIP=ffe4 RFL=0046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
  ES =0008   00cf9300 DPL=0 DS   [-WA]
  CS =0028   00af9b00 DPL=0 CS64 [-RA]
  SS =0008   00cf9300 DPL=0 DS   [-WA]
  DS =0008   00cf9300 DPL=0 DS   [-WA]
  FS =0008   00cf9300 DPL=0 DS   [-WA]
  GS =0008   00cf9300 DPL=0 DS   [-WA]
  LDT=   8200 DPL=0 LDT
  TR =   8b00 DPL=0 TSS64-busy
  GDT= 3fa50e98 003f
  IDT= 3f9d6e20 0fff
  CR0=8033 CR2= CR3=3fa67000 CR4=0668
  ...

  
  Questions:
  1) Is this problem relevant?  (is full backward compatability to be 
supported?)
  2) Are there new guest execution controls in 1.4.9x that might cause this?
  3) If #2, can they be disabled by a qemu command line switch?
  4) If not #2, in what qemu source file specifically can I find the logic 
causing the abort? (help me help you :)
  5) If guest memory is corrupted or improperly mapped, how can I keep qemu 
alive to examime/dump guest memory?

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1180970/+subscriptions

Re: [Qemu-devel] [PATCH] qapi: pad GenericList value fields to 64 bits

[Luiz Capitulino]

On Wed, 29 May 2013 13:12:18 -0500
mdroth  wrote:

> On Wed, May 29, 2013 at 01:32:52PM -0400, Luiz Capitulino wrote:
> > On Sun, 26 May 2013 22:20:58 -0500
> > Michael Roth  wrote:
> > 
> > > With the introduction of native list types, we now have types such as
> > > int64List where the 'value' field is not a pointer, but the actual
> > > 64-bit value.
> > > 
> > > On 32-bit architectures, this can lead to situations where 'next' field
> > > offset in GenericList does not correspond to the 'next' field in the
> > > types that we cast to GenericList when using the visit_next_list()
> > > interface, causing issues when we attempt to traverse linked list
> > > structures of these types.
> > > 
> > > To fix this, pad the 'value' field of GenericList and other
> > > schema-defined/native *List types out to 64-bits.
> > > 
> > > This is less memory-efficient for 32-bit architectures, but allows us to
> > > continue to rely on list-handling interfaces that target GenericList to
> > > simply visitor implementations.
> > > 
> > > In the future we can improve efficiency by defaulting to using native C
> > > array backends to handle list of non-pointer types, which would be more
> > > memory efficient in itself and allow us to roll back this change.
> > 
> > I'm also concerned with the small complexity this change is adding.
> > How hard would it be to do the proper solution with arrays instead?
> 
> It's not *too* bad, we'd need patches 9-11 from here:
> 
> http://lists.gnu.org/archive/html/qemu-devel/2012-10/threads.html#05755
> 
> Along with code generation bits, and then all the unit test stuff.
> 
> I think we should be able to get it in for 1.6, but I'd rather not leave
> 32-bit busted in the meantime.

Ok, I've applied this patch to the QMP branch.

> 
> > 
> > > 
> > > Signed-off-by: Michael Roth 
> > > ---
> > >  include/qapi/visitor.h  |5 -
> > >  scripts/qapi-types.py   |   10 --
> > >  tests/test-qmp-output-visitor.c |5 -
> > >  3 files changed, 16 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/include/qapi/visitor.h b/include/qapi/visitor.h
> > > index 1fef18c..28c21d8 100644
> > > --- a/include/qapi/visitor.h
> > > +++ b/include/qapi/visitor.h
> > > @@ -18,7 +18,10 @@
> > >  
> > >  typedef struct GenericList
> > >  {
> > > -void *value;
> > > +union {
> > > +void *value;
> > > +uint64_t padding;
> > > +};
> > >  struct GenericList *next;
> > >  } GenericList;
> > >  
> > > diff --git a/scripts/qapi-types.py b/scripts/qapi-types.py
> > > index fd42d71..ddcfed9 100644
> > > --- a/scripts/qapi-types.py
> > > +++ b/scripts/qapi-types.py
> > > @@ -22,7 +22,10 @@ def generate_fwd_struct(name, members, 
> > > builtin_type=False):
> > >  
> > >  typedef struct %(name)sList
> > >  {
> > > -%(type)s value;
> > > +union {
> > > +%(type)s value;
> > > +uint64_t padding;
> > > +};
> > >  struct %(name)sList *next;
> > >  } %(name)sList;
> > >  ''',
> > > @@ -35,7 +38,10 @@ typedef struct %(name)s %(name)s;
> > >  
> > >  typedef struct %(name)sList
> > >  {
> > > -%(name)s *value;
> > > +union {
> > > +%(name)s *value;
> > > +uint64_t padding;
> > > +};
> > >  struct %(name)sList *next;
> > >  } %(name)sList;
> > >  ''',
> > > diff --git a/tests/test-qmp-output-visitor.c 
> > > b/tests/test-qmp-output-visitor.c
> > > index 0942a41..b2fa9a7 100644
> > > --- a/tests/test-qmp-output-visitor.c
> > > +++ b/tests/test-qmp-output-visitor.c
> > > @@ -295,7 +295,10 @@ static void 
> > > test_visitor_out_struct_errors(TestOutputVisitorData *data,
> > >  
> > >  typedef struct TestStructList
> > >  {
> > > -TestStruct *value;
> > > +union {
> > > +TestStruct *value;
> > > +uint64_t padding;
> > > +};
> > >  struct TestStructList *next;
> > >  } TestStructList;
> > >  
> > 
> > 
> 

[Qemu-devel] [PATCH 4/4] linux-user: Restore original behavior of the -E and -U command-line options.

[Thomas Schwinge]

Revert the change in behavior that had been introducecd in commit
fc9c54124d134dbd76338a92a91804dab2df8166 for the -E and -U command-line
options, but keep the comma-splitting for the QEMU_SET_ENV and QEMU_UNSET_ENV
environment variables.

Signed-off-by: Thomas Schwinge 
---
 linux-user/main.c |   51 +++
 1 file changed, 35 insertions(+), 16 deletions(-)

diff --git linux-user/main.c linux-user/main.c
index b7d49f4..874791b 100644
--- linux-user/main.c
+++ linux-user/main.c
@@ -3209,15 +3209,37 @@ static void handle_arg_log_filename(arg_origin whence, 
const char *arg)
 
 static void handle_arg_set_env(arg_origin whence, const char *arg)
 {
-if (envlist_parse_set(envlist, arg) != 0) {
-usage();
+switch (whence) {
+case ARG_ORIGIN_ENV:
+if (envlist_parse_set(envlist, arg) != 0) {
+usage();
+}
+break;
+case ARG_ORIGIN_CMDLINE:
+if (envlist_setenv(envlist, arg) != 0) {
+usage();
+}
+break;
+default:
+abort();
 }
 }
 
 static void handle_arg_unset_env(arg_origin whence, const char *arg)
 {
-if (envlist_parse_unset(envlist, arg) != 0) {
-usage();
+switch (whence) {
+case ARG_ORIGIN_ENV:
+if (envlist_parse_unset(envlist, arg) != 0) {
+usage();
+}
+break;
+case ARG_ORIGIN_CMDLINE:
+if (envlist_unsetenv(envlist, arg) != 0) {
+usage();
+}
+break;
+default:
+abort();
 }
 }
 
@@ -3443,18 +3465,15 @@ static void usage(void)
guest_stack_size);
 
 printf("\n"
-   "You can use -E and -U options or the QEMU_SET_ENV and\n"
-   "QEMU_UNSET_ENV environment variables to set and unset\n"
-   "environment variables for the target process.\n"
-   "It is possible to provide several variables by separating them\n"
-   "by commas in getsubopt(3) style. Additionally it is possible to\n"
-   "provide the -E and -U options multiple times.\n"
-   "The following lines are equivalent:\n"
-   "-E var1=val2 -E var2=val2 -U LD_PRELOAD -U LD_DEBUG\n"
-   "-E var1=val2,var2=val2 -U LD_PRELOAD,LD_DEBUG\n"
-   "QEMU_SET_ENV=var1=val2,var2=val2 
QEMU_UNSET_ENV=LD_PRELOAD,LD_DEBUG\n"
-   "Note that if you provide several changes to a single variable\n"
-   "the last change will stay in effect.\n");
+"The -E and -U command-line options can be provided multiple times to set\n"
+"and unset environment variables for the target process, and -E can be used\n"
+"to specify values containing commas.  When using the QEMU_SET_ENV and\n"
+"QEMU_UNSET_ENV environment variables, a comma is used in getsubopt(3) style\n"
+"to set or unset several variables.  The following lines are equivalent:\n"
+"-E var1=val2 -E var2=val2 -U LD_PRELOAD -U LD_DEBUG\n"
+"QEMU_SET_ENV=var1=val2,var2=val2 QEMU_UNSET_ENV=LD_PRELOAD,LD_DEBUG\n"
+"Note that if you provide several changes to a single variable, the last\n"
+"change will stay in effect.\n");
 
 exit(1);
 }
-- 
1.7.10.4

[Qemu-devel] [PATCH, resend] linux-user: environment variables

[Thomas Schwinge]

Hi!

I'm resending here the patches previously posted and described in the thread
starting at
.
In short, fix a bug in util/envlist, code simplification, and then restore the
original behavior of the -E and -U command-line options.


Grüße,
 Thomas

[Qemu-devel] [PATCH 2/4] linux-user: Use existing envlist_parse_set/envlist_parse_unset interface.

[Thomas Schwinge]

Signed-off-by: Thomas Schwinge 
---
 linux-user/main.c |   18 --
 util/envlist.c|4 ++--
 2 files changed, 6 insertions(+), 16 deletions(-)

diff --git linux-user/main.c linux-user/main.c
index b97b8cf..a0ea161 100644
--- linux-user/main.c
+++ linux-user/main.c
@@ -3204,26 +3204,16 @@ static void handle_arg_log_filename(const char *arg)
 
 static void handle_arg_set_env(const char *arg)
 {
-char *r, *p, *token;
-r = p = strdup(arg);
-while ((token = strsep(&p, ",")) != NULL) {
-if (envlist_setenv(envlist, token) != 0) {
-usage();
-}
+if (envlist_parse_set(envlist, arg) != 0) {
+usage();
 }
-free(r);
 }
 
 static void handle_arg_unset_env(const char *arg)
 {
-char *r, *p, *token;
-r = p = strdup(arg);
-while ((token = strsep(&p, ",")) != NULL) {
-if (envlist_unsetenv(envlist, token) != 0) {
-usage();
-}
+if (envlist_parse_unset(envlist, arg) != 0) {
+usage();
 }
-free(r);
 }
 
 static void handle_arg_argv0(const char *arg)
diff --git util/envlist.c util/envlist.c
index cbbf7e5..8027bbf 100644
--- util/envlist.c
+++ util/envlist.c
@@ -55,10 +55,10 @@ envlist_free(envlist_t *envlist)
 
 /*
  * Parses comma separated list of set/modify environment
- * variable entries and updates given enlist accordingly.
+ * variable entries and updates given envlist accordingly.
  *
  * For example:
- * envlist_parse(el, "HOME=foo,SHELL=/bin/sh");
+ * envlist_parse_set(el, "HOME=foo,SHELL=/bin/sh");
  *
  * inserts/sets environment variables HOME and SHELL.
  *
-- 
1.7.10.4

[Qemu-devel] [PATCH 3/4] linux-user: Tell handler_arg_* which context they're invoked from.

[Thomas Schwinge]

Signed-off-by: Thomas Schwinge 
---
 linux-user/main.c |   47 ++-
 1 file changed, 26 insertions(+), 21 deletions(-)

diff --git linux-user/main.c linux-user/main.c
index a0ea161..b7d49f4 100644
--- linux-user/main.c
+++ linux-user/main.c
@@ -3180,12 +3180,17 @@ void init_task_state(TaskState *ts)
 ts->sigqueue_table[i].next = NULL;
 }
 
-static void handle_arg_help(const char *arg)
+typedef enum {
+ARG_ORIGIN_ENV,
+ARG_ORIGIN_CMDLINE
+} arg_origin;
+
+static void handle_arg_help(arg_origin whence, const char *arg)
 {
 usage();
 }
 
-static void handle_arg_log(const char *arg)
+static void handle_arg_log(arg_origin whence, const char *arg)
 {
 int mask;
 
@@ -3197,31 +3202,31 @@ static void handle_arg_log(const char *arg)
 qemu_set_log(mask);
 }
 
-static void handle_arg_log_filename(const char *arg)
+static void handle_arg_log_filename(arg_origin whence, const char *arg)
 {
 qemu_set_log_filename(arg);
 }
 
-static void handle_arg_set_env(const char *arg)
+static void handle_arg_set_env(arg_origin whence, const char *arg)
 {
 if (envlist_parse_set(envlist, arg) != 0) {
 usage();
 }
 }
 
-static void handle_arg_unset_env(const char *arg)
+static void handle_arg_unset_env(arg_origin whence, const char *arg)
 {
 if (envlist_parse_unset(envlist, arg) != 0) {
 usage();
 }
 }
 
-static void handle_arg_argv0(const char *arg)
+static void handle_arg_argv0(arg_origin whence, const char *arg)
 {
 argv0 = strdup(arg);
 }
 
-static void handle_arg_stack_size(const char *arg)
+static void handle_arg_stack_size(arg_origin whence, const char *arg)
 {
 char *p;
 guest_stack_size = strtoul(arg, &p, 0);
@@ -3236,12 +3241,12 @@ static void handle_arg_stack_size(const char *arg)
 }
 }
 
-static void handle_arg_ld_prefix(const char *arg)
+static void handle_arg_ld_prefix(arg_origin whence, const char *arg)
 {
 interp_prefix = strdup(arg);
 }
 
-static void handle_arg_pagesize(const char *arg)
+static void handle_arg_pagesize(arg_origin whence, const char *arg)
 {
 qemu_host_page_size = atoi(arg);
 if (qemu_host_page_size == 0 ||
@@ -3251,17 +3256,17 @@ static void handle_arg_pagesize(const char *arg)
 }
 }
 
-static void handle_arg_gdb(const char *arg)
+static void handle_arg_gdb(arg_origin whence, const char *arg)
 {
 gdbstub_port = atoi(arg);
 }
 
-static void handle_arg_uname(const char *arg)
+static void handle_arg_uname(arg_origin whence, const char *arg)
 {
 qemu_uname_release = strdup(arg);
 }
 
-static void handle_arg_cpu(const char *arg)
+static void handle_arg_cpu(arg_origin whence, const char *arg)
 {
 cpu_model = strdup(arg);
 if (cpu_model == NULL || is_help_option(cpu_model)) {
@@ -3274,13 +3279,13 @@ static void handle_arg_cpu(const char *arg)
 }
 
 #if defined(CONFIG_USE_GUEST_BASE)
-static void handle_arg_guest_base(const char *arg)
+static void handle_arg_guest_base(arg_origin whence, const char *arg)
 {
 guest_base = strtol(arg, NULL, 0);
 have_guest_base = 1;
 }
 
-static void handle_arg_reserved_va(const char *arg)
+static void handle_arg_reserved_va(arg_origin whence, const char *arg)
 {
 char *p;
 int shift = 0;
@@ -3317,17 +3322,17 @@ static void handle_arg_reserved_va(const char *arg)
 }
 #endif
 
-static void handle_arg_singlestep(const char *arg)
+static void handle_arg_singlestep(arg_origin whence, const char *arg)
 {
 singlestep = 1;
 }
 
-static void handle_arg_strace(const char *arg)
+static void handle_arg_strace(arg_origin whence, const char *arg)
 {
 do_strace = 1;
 }
 
-static void handle_arg_version(const char *arg)
+static void handle_arg_version(arg_origin whence, const char *arg)
 {
 printf("qemu-" TARGET_ARCH " version " QEMU_VERSION QEMU_PKGVERSION
", Copyright (c) 2003-2008 Fabrice Bellard\n");
@@ -3338,7 +3343,7 @@ struct qemu_argument {
 const char *argv;
 const char *env;
 bool has_arg;
-void (*handle_opt)(const char *arg);
+void (*handle_opt)(arg_origin whence, const char *arg);
 const char *example;
 const char *help;
 };
@@ -3467,7 +3472,7 @@ static int parse_args(int argc, char **argv)
 
 r = getenv(arginfo->env);
 if (r != NULL) {
-arginfo->handle_opt(r);
+arginfo->handle_opt(ARG_ORIGIN_ENV, r);
 }
 }
 
@@ -3492,10 +3497,10 @@ static int parse_args(int argc, char **argv)
 if (optind >= argc) {
 usage();
 }
-arginfo->handle_opt(argv[optind]);
+arginfo->handle_opt(ARG_ORIGIN_CMDLINE, argv[optind]);
 optind++;
 } else {
-arginfo->handle_opt(NULL);
+arginfo->handle_opt(ARG_ORIGIN_CMDLINE, NULL);
 }
 break;
 }
-- 
1.7.10.4

[Qemu-devel] [PATCH] target-i386: Fix aflag logic for CODE64 and the 0x67 prefix

[Richard Henderson]

The code reorganization in commit 4a6fd938 broke handling of PREFIX_ADR.
While fixing this, tidy and comment the code so that it's more obvious
what's going on in setting both aflag and dflag.

The TARGET_X86_64 ifdef can be eliminated because CODE64 expands to the
constant zero when TARGET_X86_64 is undefined.

Cc: Paolo Bonzini 
Reported-by: Laszlo Ersek 
Signed-off-by: Richard Henderson 
---
 target-i386/translate.c | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/target-i386/translate.c b/target-i386/translate.c
index 0aeccdb..14b0298 100644
--- a/target-i386/translate.c
+++ b/target-i386/translate.c
@@ -4677,8 +4677,6 @@ static target_ulong disas_insn(CPUX86State *env, 
DisasContext *s,
 }
 s->pc = pc_start;
 prefixes = 0;
-aflag = s->code32;
-dflag = s->code32;
 s->override = -1;
 rex_w = -1;
 rex_r = 0;
@@ -4801,23 +4799,25 @@ static target_ulong disas_insn(CPUX86State *env, 
DisasContext *s,
 }
 
 /* Post-process prefixes.  */
-if (prefixes & PREFIX_DATA) {
-dflag ^= 1;
-}
-if (prefixes & PREFIX_ADR) {
-aflag ^= 1;
-}
-#ifdef TARGET_X86_64
 if (CODE64(s)) {
-if (rex_w == 1) {
-/* 0x66 is ignored if rex.w is set */
-dflag = 2;
+/* In 64-bit mode, the default data size is 32-bit.  Select 64-bit
+   data with rex_w, and 16-bit data with 0x66; rex_w takes precedence
+   over 0x66 if both are present.  */
+dflag = (rex_w > 0 ? 2 : prefixes & PREFIX_DATA ? 0 : 1);
+/* In 64-bit mode, 0x67 selects 32-bit addressing.  */
+aflag = (prefixes & PREFIX_ADR ? 1 : 2);
+} else {
+/* In 16/32-bit mode, 0x66 selects the opposite data size.  */
+dflag = s->code32;
+if (prefixes & PREFIX_DATA) {
+dflag ^= 1;
 }
-if (!(prefixes & PREFIX_ADR)) {
-aflag = 2;
+/* In 16/32-bit mode, 0x67 selects the opposite addressing.  */
+aflag = s->code32;
+if (prefixes & PREFIX_ADR) {
+aflag ^= 1;
 }
 }
-#endif
 
 s->prefix = prefixes;
 s->aflag = aflag;
-- 
1.8.1.4

Re: [Qemu-devel] [PATCH v3 4/5] xilinx_devcfg: Zynq devcfg device model

[Anthony Liguori]

Anthony Liguori  writes:

> peter.crosthwa...@xilinx.com writes:
>
>> From: "Peter A. G. Crosthwaite" 
>>
>> Minimal device model for devcfg module of Zynq. DMA capabilities and
>> interrupt generation supported.
>>
>> Signed-off-by: Peter A. G. Crosthwaite 
>> ---
>> Changed since v2:
>> Some QOM styling updates.
>> Re-implemented nw0 for lock register as pre_write
>> Changed since v1:
>> Rebased against new version of Register API.
>> Use action callbacks for side effects rather than switch.
>> Documented reasons for ge0, ge1 (Verbatim from TRM)
>> Added ui1 definitions for unimplemented major features
>> Removed dead lock code
>>
>>  default-configs/arm-softmmu.mak |   1 +
>>  hw/dma/Makefile.objs|   1 +
>>  hw/dma/xilinx_devcfg.c  | 495 
>> 
>>  3 files changed, 497 insertions(+)
>>  create mode 100644 hw/dma/xilinx_devcfg.c
>>
>> diff --git a/default-configs/arm-softmmu.mak 
>> b/default-configs/arm-softmmu.mak
>> index 27cbe3d..5a17f64 100644
>> --- a/default-configs/arm-softmmu.mak
>> +++ b/default-configs/arm-softmmu.mak
>> @@ -61,6 +61,7 @@ CONFIG_PXA2XX=y
>>  CONFIG_BITBANG_I2C=y
>>  CONFIG_FRAMEBUFFER=y
>>  CONFIG_XILINX_SPIPS=y
>> +CONFIG_ZYNQ_DEVCFG=y
>>  
>>  CONFIG_A9SCU=y
>>  CONFIG_MARVELL_88W8618=y
>> diff --git a/hw/dma/Makefile.objs b/hw/dma/Makefile.objs
>> index 0e65ed0..96025cf 100644
>> --- a/hw/dma/Makefile.objs
>> +++ b/hw/dma/Makefile.objs
>> @@ -5,6 +5,7 @@ common-obj-$(CONFIG_PL330) += pl330.o
>>  common-obj-$(CONFIG_I82374) += i82374.o
>>  common-obj-$(CONFIG_I8257) += i8257.o
>>  common-obj-$(CONFIG_XILINX_AXI) += xilinx_axidma.o
>> +common-obj-$(CONFIG_ZYNQ_DEVCFG) += xilinx_devcfg.o
>>  common-obj-$(CONFIG_ETRAXFS) += etraxfs_dma.o
>>  common-obj-$(CONFIG_STP2000) += sparc32_dma.o
>>  common-obj-$(CONFIG_SUN4M) += sun4m_iommu.o
>> diff --git a/hw/dma/xilinx_devcfg.c b/hw/dma/xilinx_devcfg.c
>> new file mode 100644
>> index 000..b82b7cc
>> --- /dev/null
>> +++ b/hw/dma/xilinx_devcfg.c
>> @@ -0,0 +1,495 @@
>> +/*
>> + * QEMU model of the Xilinx Devcfg Interface
>> + *
>> + * Copyright (c) 2011 Peter A.G. Crosthwaite 
>> (peter.crosthwa...@petalogix.com)
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining a 
>> copy
>> + * of this software and associated documentation files (the "Software"), to 
>> deal
>> + * in the Software without restriction, including without limitation the 
>> rights
>> + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
>> + * copies of the Software, and to permit persons to whom the Software is
>> + * furnished to do so, subject to the following conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be included 
>> in
>> + * all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
>> OR
>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
>> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
>> OTHER
>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
>> FROM,
>> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
>> + * THE SOFTWARE.
>> + */
>> +
>> +#include "sysemu/sysemu.h"
>> +#include "sysemu/dma.h"
>> +#include "hw/sysbus.h"
>> +#include "hw/ptimer.h"
>> +#include "qemu/bitops.h"
>> +#include "hw/register.h"
>> +#include "qemu/bitops.h"
>> +
>> +#define TYPE_XILINX_DEVCFG "xlnx.ps7-dev-cfg"
>> +
>> +#define XILINX_DEVCFG(obj) \
>> +OBJECT_CHECK(XilinxDevcfg, (obj), TYPE_XILINX_DEVCFG)
>> +
>> +/* FIXME: get rid of hardcoded nastiness */
>> +
>> +#define FREQ_HZ 9
>> +
>> +#define BTT_MAX 0x400 /* bytes to transfer per delay inteval */
>> +#define CYCLES_BTT_MAX 1 /*approximate 10k cycles per delay interval */
>> +
>> +#ifndef XILINX_DEVCFG_ERR_DEBUG
>> +#define XILINX_DEVCFG_ERR_DEBUG 0
>> +#endif
>> +#define DB_PRINT(...) do { \
>> +if (XILINX_DEVCFG_ERR_DEBUG) { \
>> +fprintf(stderr,  ": %s: ", __func__); \
>> +fprintf(stderr, ## __VA_ARGS__); \
>> +} \
>> +} while (0);
>> +
>> +#define R_CTRL(0x00/4)
>> +#define FORCE_RST(1 << 31) /* Not supported, writes ignored 
>> */
>> +#define PCAP_PR  (1 << 27) /* Forced to 0 on bad unlock */
>> +#define PCAP_MODE(1 << 26)
>> +#define MULTIBOOT_EN (1 << 24)
>> +#define USER_MODE(1 << 15)
>> +#define PCFG_AES_FUSE(1 << 12) /* locked by AES_FUSE_LOCK */
>> +#define PCFG_AES_EN_SHIFT9 /* locked by AES_EN_LOCK */
>> +#define PCFG_AES_EN_LEN  3 /* locked by AES_EN_LOCK */
>> +#define PCFG_AES_EN_MASK (((1 << PCFG_AES_EN_LEN) - 1) \
>> +<< PCFG_AES_EN_SHIFT)
>> +#define SEU_EN   (1 << 8)

Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28

[Michael S. Tsirkin]

On Wed, May 29, 2013 at 07:28:05PM +0300, Michael S. Tsirkin wrote:
> Because that's just insanely rick interface

s/rick/rich/. Sorry about the typo.

Re: [Qemu-devel] [PATCH] qapi: pad GenericList value fields to 64 bits

[mdroth]

On Wed, May 29, 2013 at 01:32:52PM -0400, Luiz Capitulino wrote:
> On Sun, 26 May 2013 22:20:58 -0500
> Michael Roth  wrote:
> 
> > With the introduction of native list types, we now have types such as
> > int64List where the 'value' field is not a pointer, but the actual
> > 64-bit value.
> > 
> > On 32-bit architectures, this can lead to situations where 'next' field
> > offset in GenericList does not correspond to the 'next' field in the
> > types that we cast to GenericList when using the visit_next_list()
> > interface, causing issues when we attempt to traverse linked list
> > structures of these types.
> > 
> > To fix this, pad the 'value' field of GenericList and other
> > schema-defined/native *List types out to 64-bits.
> > 
> > This is less memory-efficient for 32-bit architectures, but allows us to
> > continue to rely on list-handling interfaces that target GenericList to
> > simply visitor implementations.
> > 
> > In the future we can improve efficiency by defaulting to using native C
> > array backends to handle list of non-pointer types, which would be more
> > memory efficient in itself and allow us to roll back this change.
> 
> I'm also concerned with the small complexity this change is adding.
> How hard would it be to do the proper solution with arrays instead?

It's not *too* bad, we'd need patches 9-11 from here:

http://lists.gnu.org/archive/html/qemu-devel/2012-10/threads.html#05755

Along with code generation bits, and then all the unit test stuff.

I think we should be able to get it in for 1.6, but I'd rather not leave
32-bit busted in the meantime.

> 
> > 
> > Signed-off-by: Michael Roth 
> > ---
> >  include/qapi/visitor.h  |5 -
> >  scripts/qapi-types.py   |   10 --
> >  tests/test-qmp-output-visitor.c |5 -
> >  3 files changed, 16 insertions(+), 4 deletions(-)
> > 
> > diff --git a/include/qapi/visitor.h b/include/qapi/visitor.h
> > index 1fef18c..28c21d8 100644
> > --- a/include/qapi/visitor.h
> > +++ b/include/qapi/visitor.h
> > @@ -18,7 +18,10 @@
> >  
> >  typedef struct GenericList
> >  {
> > -void *value;
> > +union {
> > +void *value;
> > +uint64_t padding;
> > +};
> >  struct GenericList *next;
> >  } GenericList;
> >  
> > diff --git a/scripts/qapi-types.py b/scripts/qapi-types.py
> > index fd42d71..ddcfed9 100644
> > --- a/scripts/qapi-types.py
> > +++ b/scripts/qapi-types.py
> > @@ -22,7 +22,10 @@ def generate_fwd_struct(name, members, 
> > builtin_type=False):
> >  
> >  typedef struct %(name)sList
> >  {
> > -%(type)s value;
> > +union {
> > +%(type)s value;
> > +uint64_t padding;
> > +};
> >  struct %(name)sList *next;
> >  } %(name)sList;
> >  ''',
> > @@ -35,7 +38,10 @@ typedef struct %(name)s %(name)s;
> >  
> >  typedef struct %(name)sList
> >  {
> > -%(name)s *value;
> > +union {
> > +%(name)s *value;
> > +uint64_t padding;
> > +};
> >  struct %(name)sList *next;
> >  } %(name)sList;
> >  ''',
> > diff --git a/tests/test-qmp-output-visitor.c 
> > b/tests/test-qmp-output-visitor.c
> > index 0942a41..b2fa9a7 100644
> > --- a/tests/test-qmp-output-visitor.c
> > +++ b/tests/test-qmp-output-visitor.c
> > @@ -295,7 +295,10 @@ static void 
> > test_visitor_out_struct_errors(TestOutputVisitorData *data,
> >  
> >  typedef struct TestStructList
> >  {
> > -TestStruct *value;
> > +union {
> > +TestStruct *value;
> > +uint64_t padding;
> > +};
> >  struct TestStructList *next;
> >  } TestStructList;
> >  
> 
> 

Re: [Qemu-devel] [PATCH 16/16] Make qemu-io commands available in the monitor

[Luiz Capitulino]

On Wed, 29 May 2013 10:13:42 +0200
Kevin Wolf  wrote:

> Am 28.05.2013 um 18:07 hat Eric Blake geschrieben:
> > On 05/28/2013 09:27 AM, Kevin Wolf wrote:
> > > The QMP version is flagged with a __org.qemu.debug- prefix in order to
> > > reinforce the statement that qemu-io is for testing and debugging only,
> > > with no API guarantees.
> > 
> > Correct use of naming conventions.
> > 
> > Hmm, I wonder if the recent addition of an 'abort' action to
> > 'transaction' should be renamed __org.qemu.debug-abort, to make it
> > obvious that it is another case of a QMP command useful mainly for
> > testing, and not real-life use.
> 
> Makes sense to me.
> 
> But first I'd like to get Luiz's ack for this, because I think I'm the
> first one to use an __org.qemu prefix, and I'm the first one trying to
> introduce a QMP command without API stability.

I think that should be fine. However, it's not a perfect match for QMP
as you don't expect mngt to use it anytime soon and that the command's
syntax is not QMP friendly:

> { "execute": "__org.qemu.debug-qemu-io-command", "arguments":
> { "device": "ide0-hd0", "command": "write -P 0x12 4M 512k" } }

What about adding a HMP-only command (the good old way) and use it
through human-monitor-command?

IMO, this matches better your current use-case and the API instability
of the command.

Re: [Qemu-devel] [PATCH v3 4/5] xilinx_devcfg: Zynq devcfg device model

[Anthony Liguori]

peter.crosthwa...@xilinx.com writes:

> From: "Peter A. G. Crosthwaite" 
>
> Minimal device model for devcfg module of Zynq. DMA capabilities and
> interrupt generation supported.
>
> Signed-off-by: Peter A. G. Crosthwaite 
> ---
> Changed since v2:
> Some QOM styling updates.
> Re-implemented nw0 for lock register as pre_write
> Changed since v1:
> Rebased against new version of Register API.
> Use action callbacks for side effects rather than switch.
> Documented reasons for ge0, ge1 (Verbatim from TRM)
> Added ui1 definitions for unimplemented major features
> Removed dead lock code
>
>  default-configs/arm-softmmu.mak |   1 +
>  hw/dma/Makefile.objs|   1 +
>  hw/dma/xilinx_devcfg.c  | 495 
> 
>  3 files changed, 497 insertions(+)
>  create mode 100644 hw/dma/xilinx_devcfg.c
>
> diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
> index 27cbe3d..5a17f64 100644
> --- a/default-configs/arm-softmmu.mak
> +++ b/default-configs/arm-softmmu.mak
> @@ -61,6 +61,7 @@ CONFIG_PXA2XX=y
>  CONFIG_BITBANG_I2C=y
>  CONFIG_FRAMEBUFFER=y
>  CONFIG_XILINX_SPIPS=y
> +CONFIG_ZYNQ_DEVCFG=y
>  
>  CONFIG_A9SCU=y
>  CONFIG_MARVELL_88W8618=y
> diff --git a/hw/dma/Makefile.objs b/hw/dma/Makefile.objs
> index 0e65ed0..96025cf 100644
> --- a/hw/dma/Makefile.objs
> +++ b/hw/dma/Makefile.objs
> @@ -5,6 +5,7 @@ common-obj-$(CONFIG_PL330) += pl330.o
>  common-obj-$(CONFIG_I82374) += i82374.o
>  common-obj-$(CONFIG_I8257) += i8257.o
>  common-obj-$(CONFIG_XILINX_AXI) += xilinx_axidma.o
> +common-obj-$(CONFIG_ZYNQ_DEVCFG) += xilinx_devcfg.o
>  common-obj-$(CONFIG_ETRAXFS) += etraxfs_dma.o
>  common-obj-$(CONFIG_STP2000) += sparc32_dma.o
>  common-obj-$(CONFIG_SUN4M) += sun4m_iommu.o
> diff --git a/hw/dma/xilinx_devcfg.c b/hw/dma/xilinx_devcfg.c
> new file mode 100644
> index 000..b82b7cc
> --- /dev/null
> +++ b/hw/dma/xilinx_devcfg.c
> @@ -0,0 +1,495 @@
> +/*
> + * QEMU model of the Xilinx Devcfg Interface
> + *
> + * Copyright (c) 2011 Peter A.G. Crosthwaite 
> (peter.crosthwa...@petalogix.com)
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a 
> copy
> + * of this software and associated documentation files (the "Software"), to 
> deal
> + * in the Software without restriction, including without limitation the 
> rights
> + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> + * copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
> FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> + * THE SOFTWARE.
> + */
> +
> +#include "sysemu/sysemu.h"
> +#include "sysemu/dma.h"
> +#include "hw/sysbus.h"
> +#include "hw/ptimer.h"
> +#include "qemu/bitops.h"
> +#include "hw/register.h"
> +#include "qemu/bitops.h"
> +
> +#define TYPE_XILINX_DEVCFG "xlnx.ps7-dev-cfg"
> +
> +#define XILINX_DEVCFG(obj) \
> +OBJECT_CHECK(XilinxDevcfg, (obj), TYPE_XILINX_DEVCFG)
> +
> +/* FIXME: get rid of hardcoded nastiness */
> +
> +#define FREQ_HZ 9
> +
> +#define BTT_MAX 0x400 /* bytes to transfer per delay inteval */
> +#define CYCLES_BTT_MAX 1 /*approximate 10k cycles per delay interval */
> +
> +#ifndef XILINX_DEVCFG_ERR_DEBUG
> +#define XILINX_DEVCFG_ERR_DEBUG 0
> +#endif
> +#define DB_PRINT(...) do { \
> +if (XILINX_DEVCFG_ERR_DEBUG) { \
> +fprintf(stderr,  ": %s: ", __func__); \
> +fprintf(stderr, ## __VA_ARGS__); \
> +} \
> +} while (0);
> +
> +#define R_CTRL(0x00/4)
> +#define FORCE_RST(1 << 31) /* Not supported, writes ignored 
> */
> +#define PCAP_PR  (1 << 27) /* Forced to 0 on bad unlock */
> +#define PCAP_MODE(1 << 26)
> +#define MULTIBOOT_EN (1 << 24)
> +#define USER_MODE(1 << 15)
> +#define PCFG_AES_FUSE(1 << 12) /* locked by AES_FUSE_LOCK */
> +#define PCFG_AES_EN_SHIFT9 /* locked by AES_EN_LOCK */
> +#define PCFG_AES_EN_LEN  3 /* locked by AES_EN_LOCK */
> +#define PCFG_AES_EN_MASK (((1 << PCFG_AES_EN_LEN) - 1) \
> +<< PCFG_AES_EN_SHIFT)
> +#define SEU_EN   (1 << 8) /* locked by SEU_LOCK */
> +#define SEC_EN   (1 << 7) /* locked by SEC_LOCK */
> +#define SPNIDEN  (1 << 6) /* locked by DBG_LOCK */
> +  

Re: [Qemu-devel] [PATCH v3 2/5] register: Add Register API

[Edgar E. Iglesias]

On Fri, May 24, 2013 at 03:47:33PM +1000, peter.crosthwa...@xilinx.com wrote:
> From: Peter Crosthwaite 
> 
> This API provides some encapsulation of registers and factors our some
> common functionality to common code. Bits of device state (usually MMIO
> registers), often have all sorts of access restrictions and semantics
> associated with them. This API allow you to define what those
> restrictions are on a bit-by-bit basis.
> 
> Helper functions are then used to access the register which observe the
> semantics defined by the RegisterAccessInfo struct.
> 
> Some features:
> Bits can be marked as read_only (ro field)
> Bits can be marked as write-1-clear (w1c field)
> Reset values can be defined (reset)
> Bits can throw guest errors when written certain values (ge0, ge1)
> Bits can throw unimp errors when written certain values (ui0, ui1)
> Bits can be marked clear on read (cor)
> Pre and post action callbacks can be added to read and write ops
> Verbose debugging info can be enabled/disabled
> 
> Useful for defining device register spaces in a data driven way. Cuts
> down on a lot of the verbosity and repetition in the switch-case blocks
> in the standard foo_mmio_read/write functions.
> 
> Signed-off-by: Peter Crosthwaite 


Reviewed-by: Edgar E. Iglesias 


> ---
> changed from v2:
> Simplified! Removed pre-read, nwx, wo
> Removed byte loops (Gerd Review)
> Made data pointer optional
> Added fast paths for simple registers
> Moved into hw/core and include/hw (Paolo Review)
> changed from v1:
> Rebranded as the "Register API" - I think thats probably what it is.
> Near total rewrite of implementation.
> De-arrayified reset (this is client/Memory APIs job).
> Moved out of bitops into its own file (Blue review)
> Added debug, the register pointer, and prefix to a struct (Blue Review)
> Made 64-bit to play friendlier with memory API (Blue review)
> Made backend storage uint8_t (MST review)
> Added read/write callbacks (Blue review)
> Added ui0, ui1 (Blue review)
> Moved re-purposed width (now byte width defining actual storage size)
> Arrayified ge0, ge1 (ui0, ui1 too) and added .reason
> Added wo field (not an April fools joke - this has genuine meaning here)
> Added we mask to write accessor
> 
>  hw/core/Makefile.objs |   1 +
>  hw/core/register.c| 190 
> ++
>  include/hw/register.h | 129 ++
>  3 files changed, 320 insertions(+)
>  create mode 100644 hw/core/register.c
>  create mode 100644 include/hw/register.h
> 
> diff --git a/hw/core/Makefile.objs b/hw/core/Makefile.objs
> index 950146c..210cb1a 100644
> --- a/hw/core/Makefile.objs
> +++ b/hw/core/Makefile.objs
> @@ -2,6 +2,7 @@
>  common-obj-y += qdev.o qdev-properties.o
>  # irq.o needed for qdev GPIO handling:
>  common-obj-y += irq.o
> +common-obj-y += register.o
>  
>  common-obj-$(CONFIG_EMPTY_SLOT) += empty_slot.o
>  common-obj-$(CONFIG_XILINX_AXI) += stream.o
> diff --git a/hw/core/register.c b/hw/core/register.c
> new file mode 100644
> index 000..b10212e
> --- /dev/null
> +++ b/hw/core/register.c
> @@ -0,0 +1,190 @@
> +/*
> + * Register Definition API
> + *
> + * Copyright (c) 2013 Xilinx Inc.
> + * Copyright (c) 2013 Peter Crosthwaite 
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2.  See
> + * the COPYING file in the top-level directory.
> + */
> +
> +#include "hw/register.h"
> +#include "qemu/log.h"
> +
> +static inline void register_write_log(RegisterInfo *reg, int dir, uint64_t 
> val,
> +  int mask, const char *msg,
> +  const char *reason)
> +{
> +qemu_log_mask(mask, "%s:%s bits %#" PRIx64 " %s write of %d%s%s\n",
> +  reg->prefix, reg->access->name, val, msg, dir,
> +  reason ? ": " : "", reason ? reason : "");
> +}
> +
> +static inline void register_write_val(RegisterInfo *reg, uint64_t val)
> +{
> +if (!reg->data) {
> +return;
> +}
> +switch (reg->data_size) {
> +case 1:
> +*(uint8_t *)reg->data = val;
> +break;
> +case 2:
> +*(uint16_t *)reg->data = val;
> +break;
> +case 4:
> +*(uint32_t *)reg->data = val;
> +break;
> +case 8:
> +*(uint64_t *)reg->data = val;
> +break;
> +default:
> +abort();
> +}
> +}
> +
> +static inline uint64_t register_read_val(RegisterInfo *reg)
> +{
> +switch (reg->data_size) {
> +case 1:
> +return *(uint8_t *)reg->data;
> +case 2:
> +return *(uint16_t *)reg->data;
> +case 4:
> +return *(uint32_t *)reg->data;
> +case 8:
> +return *(uint64_t *)reg->data;
> +default:
> +abort();
> +}
> +return 0; /* unreachable */
> +}
> +
> +void register_write(RegisterInfo *reg, uint64_t val, uint64_t we)
> +{
> +uint64_t old_val, new_val, test, no_w_mask;
> +const RegisterAccessInfo *ac;
> +const Regi

Re: [Qemu-devel] [PATCH 7/7] monitor: QMP/HMP support for retrieving VNVRAM details

[Corey Bryant]

On 05/29/2013 01:15 PM, Luiz Capitulino wrote:

On Thu, 23 May 2013 13:44:47 -0400
Corey Bryant  wrote:


Signed-off-by: Corey Bryant 


Looks good to me, only one small nit below.



It looks like this series is going to get dropped, but thanks for the 
review!


--
Regards,
Corey Bryant


---
  hmp.c|   32 
  hmp.h|1 +
  monitor.c|7 +
  qapi-schema.json |   47 +++
  qmp-commands.hx  |   41 +++
  vnvram.c |   71 ++
  6 files changed, 199 insertions(+), 0 deletions(-)

diff --git a/hmp.c b/hmp.c
index 4fb76ec..a144f73 100644
--- a/hmp.c
+++ b/hmp.c
@@ -653,6 +653,38 @@ void hmp_info_tpm(Monitor *mon, const QDict *qdict)
  qapi_free_TPMInfoList(info_list);
  }

+void hmp_info_vnvram(Monitor *mon, const QDict *dict)
+{
+VNVRAMInfoList *info_list, *info;
+Error *err = NULL;
+unsigned int c = 0;
+
+info_list = qmp_query_vnvram(&err);
+if (err) {
+monitor_printf(mon, "VNVRAM not found\n");
+error_free(err);
+return;
+}
+
+for (info = info_list; info; info = info->next) {
+VNVRAMInfo *ni = info->value;
+VNVRAMEntryInfoList *einfo_list = ni->entries, *einfo;
+unsigned int d = 0;
+monitor_printf(mon, "vnvram%u: drive-id=%s "
+   "virtual-disk-size=%"PRId64" vnvram-size=%"PRIu64"\n",
+   c++, ni->drive_id, ni->virtual_disk_size,
+   ni->vnvram_size);
+
+for (einfo = einfo_list; einfo; einfo = einfo->next) {
+VNVRAMEntryInfo *nei = einfo->value;
+monitor_printf(mon, "  entry%u: name=%s cur-size=%"PRIu64" "
+   "max-size=%"PRIu64"\n",
+   d++, nei->name, nei->cur_size, nei->max_size);
+}
+}
+qapi_free_VNVRAMInfoList(info_list);
+}
+
  void hmp_quit(Monitor *mon, const QDict *qdict)
  {
  monitor_suspend(mon);
diff --git a/hmp.h b/hmp.h
index 95fe76e..e26daf2 100644
--- a/hmp.h
+++ b/hmp.h
@@ -37,6 +37,7 @@ void hmp_info_balloon(Monitor *mon, const QDict *qdict);
  void hmp_info_pci(Monitor *mon, const QDict *qdict);
  void hmp_info_block_jobs(Monitor *mon, const QDict *qdict);
  void hmp_info_tpm(Monitor *mon, const QDict *qdict);
+void hmp_info_vnvram(Monitor *mon, const QDict *dict);
  void hmp_quit(Monitor *mon, const QDict *qdict);
  void hmp_stop(Monitor *mon, const QDict *qdict);
  void hmp_system_reset(Monitor *mon, const QDict *qdict);
diff --git a/monitor.c b/monitor.c
index 62aaebe..c10fe15 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2764,6 +2764,13 @@ static mon_cmd_t info_cmds[] = {
  .mhandler.cmd = hmp_info_tpm,
  },
  {
+.name   = "vnvram",
+.args_type  = "",
+.params = "",
+.help   = "show VNVRAM information",
+.mhandler.cmd = hmp_info_vnvram,
+},
+{
  .name   = NULL,
  },
  };
diff --git a/qapi-schema.json b/qapi-schema.json
index 9302e7d..73d42d6 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -3619,3 +3619,50 @@
  '*cpuid-input-ecx': 'int',
  'cpuid-register': 'X86CPURegister32',
  'features': 'int' } }
+
+# @VNVRAMEntryInfo:
+#
+# Information about an entry in the VNVRAM.
+#
+# @name: name of the entry
+#
+# @cur-size: current size of the entry's blob in bytes


It's preferable not to abbreviate, you can have current-size.


+#
+# @max-size: max size of the entry's blob in bytes
+#
+# Since: 1.6
+#
+##
+{ 'type': 'VNVRAMEntryInfo',
+  'data': {'name': 'str', 'cur-size': 'int', 'max-size': 'int', } }
+
+##
+# @VNVRAMInfo:
+#
+# Information about the VNVRAM device.
+#
+# @drive-id: ID of the VNVRAM (and associated drive)
+#
+# @virtual-disk-size: Virtual size of the associated disk drive in bytes
+#
+# @vnvram-size: Size of the VNVRAM in bytes
+#
+# @entries: Array of @VNVRAMEntryInfo
+#
+# Since: 1.6
+#
+##
+{ 'type': 'VNVRAMInfo',
+  'data': {'drive-id': 'str', 'virtual-disk-size': 'int',
+   'vnvram-size': 'int', 'entries' : ['VNVRAMEntryInfo']} }
+
+##
+# @query-vnvram:
+#
+# Return information about the VNVRAM devices.
+#
+# Returns: @VNVRAMInfo on success
+#
+# Since: 1.6
+##
+{ 'command': 'query-vnvram', 'returns': ['VNVRAMInfo'] }
diff --git a/qmp-commands.hx b/qmp-commands.hx
index ffd130e..56a57b7 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -2932,3 +2932,44 @@ Example:
  <- { "return": {} }

  EQMP
+
+{
+.name   = "query-vnvram",
+.args_type  = "",
+.mhandler.cmd_new = qmp_marshal_input_query_vnvram,
+},
+
+SQMP
+query-vnvram
+
+
+Show VNVRAM info.
+
+Return a json-array of json-objects representing VNVRAMs.  Each VNVRAM
+is described by a json-object with the following:
+
+- "drive-id": ID of the VNVRAM (json-string)
+- "vitual-disk-size": Virtual size of assoc

Re: [Qemu-devel] [PATCH] qapi: pad GenericList value fields to 64 bits

[Luiz Capitulino]

On Sun, 26 May 2013 22:20:58 -0500
Michael Roth  wrote:

> With the introduction of native list types, we now have types such as
> int64List where the 'value' field is not a pointer, but the actual
> 64-bit value.
> 
> On 32-bit architectures, this can lead to situations where 'next' field
> offset in GenericList does not correspond to the 'next' field in the
> types that we cast to GenericList when using the visit_next_list()
> interface, causing issues when we attempt to traverse linked list
> structures of these types.
> 
> To fix this, pad the 'value' field of GenericList and other
> schema-defined/native *List types out to 64-bits.
> 
> This is less memory-efficient for 32-bit architectures, but allows us to
> continue to rely on list-handling interfaces that target GenericList to
> simply visitor implementations.
> 
> In the future we can improve efficiency by defaulting to using native C
> array backends to handle list of non-pointer types, which would be more
> memory efficient in itself and allow us to roll back this change.

I'm also concerned with the small complexity this change is adding.
How hard would it be to do the proper solution with arrays instead?

> 
> Signed-off-by: Michael Roth 
> ---
>  include/qapi/visitor.h  |5 -
>  scripts/qapi-types.py   |   10 --
>  tests/test-qmp-output-visitor.c |5 -
>  3 files changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/include/qapi/visitor.h b/include/qapi/visitor.h
> index 1fef18c..28c21d8 100644
> --- a/include/qapi/visitor.h
> +++ b/include/qapi/visitor.h
> @@ -18,7 +18,10 @@
>  
>  typedef struct GenericList
>  {
> -void *value;
> +union {
> +void *value;
> +uint64_t padding;
> +};
>  struct GenericList *next;
>  } GenericList;
>  
> diff --git a/scripts/qapi-types.py b/scripts/qapi-types.py
> index fd42d71..ddcfed9 100644
> --- a/scripts/qapi-types.py
> +++ b/scripts/qapi-types.py
> @@ -22,7 +22,10 @@ def generate_fwd_struct(name, members, builtin_type=False):
>  
>  typedef struct %(name)sList
>  {
> -%(type)s value;
> +union {
> +%(type)s value;
> +uint64_t padding;
> +};
>  struct %(name)sList *next;
>  } %(name)sList;
>  ''',
> @@ -35,7 +38,10 @@ typedef struct %(name)s %(name)s;
>  
>  typedef struct %(name)sList
>  {
> -%(name)s *value;
> +union {
> +%(name)s *value;
> +uint64_t padding;
> +};
>  struct %(name)sList *next;
>  } %(name)sList;
>  ''',
> diff --git a/tests/test-qmp-output-visitor.c b/tests/test-qmp-output-visitor.c
> index 0942a41..b2fa9a7 100644
> --- a/tests/test-qmp-output-visitor.c
> +++ b/tests/test-qmp-output-visitor.c
> @@ -295,7 +295,10 @@ static void 
> test_visitor_out_struct_errors(TestOutputVisitorData *data,
>  
>  typedef struct TestStructList
>  {
> -TestStruct *value;
> +union {
> +TestStruct *value;
> +uint64_t padding;
> +};
>  struct TestStructList *next;
>  } TestStructList;
>  

Re: [Qemu-devel] [PATCH v2] monitor: work around delayed CHR_EVENT_OPENED events

[Luiz Capitulino]

On Mon, 27 May 2013 12:59:25 -0500
mdroth  wrote:

> On Mon, May 27, 2013 at 11:16:01AM -0500, Anthony Liguori wrote:
> > Luiz Capitulino  writes:
> > 
> > > On Sun, 26 May 2013 10:33:39 -0500
> > > Michael Roth  wrote:
> > >
> > >> In the past, CHR_EVENT_OPENED events were emitted via a pre-expired
> > >> QEMUTimer. Due to timers being processing at the tail end of each main
> > >> loop iteration, this generally meant that such events would be emitted
> > >> within the same main loop iteration, prior any client data being read
> > >> by tcp/unix socket server backends.
> > >> 
> > >> With 9f939df955a4152aad69a19a77e0898631bb2c18, this was switched to
> > >> a "bottom-half" that is registered via g_idle_add(). This makes it
> > >> likely that the event won't be sent until a subsequent iteration, and
> > >> also adds the possibility that such events will race with the
> > >> processing of client data.
> > >> 
> > >> In cases where we rely on the CHR_EVENT_OPENED event being delivered
> > >> prior to any client data being read, this may cause unexpected behavior.
> > >> 
> > >> In the case of a QMP monitor session using a socket backend, the delayed
> > >> processing of the CHR_EVENT_OPENED event can lead to a situation where
> > >> a previous session, where 'qmp_capabilities' has already processed, can
> > >> cause the rejection of 'qmp_capabilities' for a subsequent session,
> > >> since we reset capabilities in response to CHR_EVENT_OPENED, which may
> > >> not yet have been delivered. This can be reproduced with the following
> > >> command, generally within 50 or so iterations:
> > >> 
> > >>   mdroth@loki:~$ cat cmds
> > >>   {'execute':'qmp_capabilities'}
> > >>   {'execute':'query-cpus'}
> > >>   mdroth@loki:~$ while true; do if socat stdio unix-connect:/tmp/qmp.sock
> > >>   /dev/null; then echo failed; break; else
> > >>   echo ok; fi; done;
> > >>   ok
> > >>   ok
> > >>   failed
> > >>   mdroth@loki:~$
> > >> 
> > >> As a work-around, we reset capabilities as part of the CHR_EVENT_CLOSED
> > >> hook, which gets called as part of the GIOChannel cb associated with the
> > >> client rather than a bottom-half, and is thus guaranteed to be delivered
> > >> prior to accepting any subsequent client sessions.
> > >> 
> > >> This does not address the more general problem of whether or not there
> > >> are chardev users that rely on CHR_EVENT_OPENED being delivered prior to
> > >> client data, and whether or not we should consider moving 
> > >> CHR_EVENT_OPENED
> > >> "in-band" with connection establishment as a general solution, but fixes
> > >> QMP for the time being.
> > >> 
> > >> Reported-by: Stefan Priebe 
> > >> Cc: qemu-sta...@nongnu.org
> > >> Signed-off-by: Michael Roth 
> > >
> > > Thanks for debugging this Michael. I'm going to apply your patch to the 
> > > qmp
> > > branch because we can't let this broken (esp. in -stable) but this is 
> > > papering
> > > over the real bug...
> > 
> > Do we really need OPENED to happen in a bottom half?  Shouldn't the open
> > event handlers register the callback instead if they need it?
> 
> I think that's the more general fix, but wasn't sure if there were
> historical reasons why we didn't do this in the first place.
> 
> Looking at it more closely it does seem like we need a general fix
> sooner rather than later though, and I don't see any reason why we can't
> move BH registration into the actual OPENED hooks as you suggest:
> 
> hw/usb/ccid-card-passthru.c
>  - currently affected? no
> debug hook only
>  - needs OPENED BH? no
> 
> hw/usb/redirect.c
>  - currently affected? yes
> can_read handler checks for dev->parser != NULL, which may be
> true if CLOSED BH has been executed yet. In the past, OPENED
> quiesced outstanding CLOSED events prior to us reading client data.
>  - need OPENED BH? possibly
> seems to only be needed by CLOSED events, which can be issued by
> USBDevice, so we do teardown/usb_detach in BH. For OPENED, this
> may not apply. if we do issue a BH, we'd need to modify can_read
> handler to avoid race.
> 
> hw/usb/dev-serial.c
>  - currently affected? no
> can_read checks for dev.attached != NULL. set to NULL
> synchronously in CLOSED, will not accept reads until OPENED gets
> called and sets dev.attached
>  - need opened BH?  no
> 
> hw/char/sclpconsole.c
>  - currently affected? no
> guarded by can_read handler
>  - need opened BH? no
> 
> hw/char/ipoctal232.c
>  - currently affected? no
> debug hook only
>  - need opened BH? no
> 
> hw/char/virtio-console.c
>  - currently affected? no
> OPENED/CLOSED map to vq events handled asynchronously. can_read
> checks for guest_connected state rather than anything set by OPENED
>  - need opened BH? no
> 
> qtest.c
>  - currently affected? yes
> can_read handler doesn't check for qtest_opened == true, can read
> data before OPENED event is processed
>  - need opened BH? no
> 
> monitor.c
>  - current affected? yes
> neg

Re: [Qemu-devel] [PATCH 7/7] monitor: QMP/HMP support for retrieving VNVRAM details

[Luiz Capitulino]

On Thu, 23 May 2013 13:44:47 -0400
Corey Bryant  wrote:

> Signed-off-by: Corey Bryant 

Looks good to me, only one small nit below.

> ---
>  hmp.c|   32 
>  hmp.h|1 +
>  monitor.c|7 +
>  qapi-schema.json |   47 +++
>  qmp-commands.hx  |   41 +++
>  vnvram.c |   71 
> ++
>  6 files changed, 199 insertions(+), 0 deletions(-)
> 
> diff --git a/hmp.c b/hmp.c
> index 4fb76ec..a144f73 100644
> --- a/hmp.c
> +++ b/hmp.c
> @@ -653,6 +653,38 @@ void hmp_info_tpm(Monitor *mon, const QDict *qdict)
>  qapi_free_TPMInfoList(info_list);
>  }
>  
> +void hmp_info_vnvram(Monitor *mon, const QDict *dict)
> +{
> +VNVRAMInfoList *info_list, *info;
> +Error *err = NULL;
> +unsigned int c = 0;
> +
> +info_list = qmp_query_vnvram(&err);
> +if (err) {
> +monitor_printf(mon, "VNVRAM not found\n");
> +error_free(err);
> +return;
> +}
> +
> +for (info = info_list; info; info = info->next) {
> +VNVRAMInfo *ni = info->value;
> +VNVRAMEntryInfoList *einfo_list = ni->entries, *einfo;
> +unsigned int d = 0;
> +monitor_printf(mon, "vnvram%u: drive-id=%s "
> +   "virtual-disk-size=%"PRId64" vnvram-size=%"PRIu64"\n",
> +   c++, ni->drive_id, ni->virtual_disk_size,
> +   ni->vnvram_size);
> +
> +for (einfo = einfo_list; einfo; einfo = einfo->next) {
> +VNVRAMEntryInfo *nei = einfo->value;
> +monitor_printf(mon, "  entry%u: name=%s cur-size=%"PRIu64" "
> +   "max-size=%"PRIu64"\n",
> +   d++, nei->name, nei->cur_size, nei->max_size);
> +}
> +}
> +qapi_free_VNVRAMInfoList(info_list);
> +}
> +
>  void hmp_quit(Monitor *mon, const QDict *qdict)
>  {
>  monitor_suspend(mon);
> diff --git a/hmp.h b/hmp.h
> index 95fe76e..e26daf2 100644
> --- a/hmp.h
> +++ b/hmp.h
> @@ -37,6 +37,7 @@ void hmp_info_balloon(Monitor *mon, const QDict *qdict);
>  void hmp_info_pci(Monitor *mon, const QDict *qdict);
>  void hmp_info_block_jobs(Monitor *mon, const QDict *qdict);
>  void hmp_info_tpm(Monitor *mon, const QDict *qdict);
> +void hmp_info_vnvram(Monitor *mon, const QDict *dict);
>  void hmp_quit(Monitor *mon, const QDict *qdict);
>  void hmp_stop(Monitor *mon, const QDict *qdict);
>  void hmp_system_reset(Monitor *mon, const QDict *qdict);
> diff --git a/monitor.c b/monitor.c
> index 62aaebe..c10fe15 100644
> --- a/monitor.c
> +++ b/monitor.c
> @@ -2764,6 +2764,13 @@ static mon_cmd_t info_cmds[] = {
>  .mhandler.cmd = hmp_info_tpm,
>  },
>  {
> +.name   = "vnvram",
> +.args_type  = "",
> +.params = "",
> +.help   = "show VNVRAM information",
> +.mhandler.cmd = hmp_info_vnvram,
> +},
> +{
>  .name   = NULL,
>  },
>  };
> diff --git a/qapi-schema.json b/qapi-schema.json
> index 9302e7d..73d42d6 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -3619,3 +3619,50 @@
>  '*cpuid-input-ecx': 'int',
>  'cpuid-register': 'X86CPURegister32',
>  'features': 'int' } }
> +
> +# @VNVRAMEntryInfo:
> +#
> +# Information about an entry in the VNVRAM.
> +#
> +# @name: name of the entry
> +#
> +# @cur-size: current size of the entry's blob in bytes

It's preferable not to abbreviate, you can have current-size.

> +#
> +# @max-size: max size of the entry's blob in bytes
> +#
> +# Since: 1.6
> +#
> +##
> +{ 'type': 'VNVRAMEntryInfo',
> +  'data': {'name': 'str', 'cur-size': 'int', 'max-size': 'int', } }
> +
> +##
> +# @VNVRAMInfo:
> +#
> +# Information about the VNVRAM device.
> +#
> +# @drive-id: ID of the VNVRAM (and associated drive)
> +#
> +# @virtual-disk-size: Virtual size of the associated disk drive in bytes
> +#
> +# @vnvram-size: Size of the VNVRAM in bytes
> +#
> +# @entries: Array of @VNVRAMEntryInfo
> +#
> +# Since: 1.6
> +#
> +##
> +{ 'type': 'VNVRAMInfo',
> +  'data': {'drive-id': 'str', 'virtual-disk-size': 'int',
> +   'vnvram-size': 'int', 'entries' : ['VNVRAMEntryInfo']} }
> +
> +##
> +# @query-vnvram:
> +#
> +# Return information about the VNVRAM devices.
> +#
> +# Returns: @VNVRAMInfo on success
> +#
> +# Since: 1.6
> +##
> +{ 'command': 'query-vnvram', 'returns': ['VNVRAMInfo'] }
> diff --git a/qmp-commands.hx b/qmp-commands.hx
> index ffd130e..56a57b7 100644
> --- a/qmp-commands.hx
> +++ b/qmp-commands.hx
> @@ -2932,3 +2932,44 @@ Example:
>  <- { "return": {} }
>  
>  EQMP
> +
> +{
> +.name   = "query-vnvram",
> +.args_type  = "",
> +.mhandler.cmd_new = qmp_marshal_input_query_vnvram,
> +},
> +
> +SQMP
> +query-vnvram
> +
> +
> +Show VNVRAM info.
> +
> +Return a json-array of json-objects representing VNVRAMs.  Each VNVRAM
> +is descri

Re: [Qemu-devel] [PATCH v3 4/5] xilinx_devcfg: Zynq devcfg device model

[Paolo Bonzini]

Il 29/05/2013 19:04, Edgar E. Iglesias ha scritto:
>> > +for (i = 0; i < R_MAX; ++i) {
>> > +RegisterInfo *r = &s->regs_info[i];
>> > +
>> > +*r = (RegisterInfo) {
>> > +.data = &s->regs[i],
>> > +.data_size = sizeof(uint32_t),
>> > +.access = &xilinx_devcfg_regs_info[i],
>> > +.debug = XILINX_DEVCFG_ERR_DEBUG,
>> > +.prefix = prefix,
>> > +.opaque = s,
>> > +};
>> > +memory_region_init_io(&r->mem, &devcfg_reg_ops, r, "devcfg-regs", 
>> > 4);
> Hi Peter, Should we be putting r->access->name here instead of "devcfg-regs"?

Yes, that's why I preferred to wrap the memory_region_init_io into an
API that takes a RegisterInfo. :)

Paolo

Re: [Qemu-devel] VFIO VGA test branches

[Alex Williamson]

On Wed, 2013-05-29 at 18:16 +0200, Maik Broemme wrote:
> Hi,
> 
> Maik Broemme  wrote:
> > > > 
> > > > Here is the DEBUG_VFIO output:
> > > > 
> > > > vfio: vfio_initfn(:04:00.0) group 14
> > > > vfio: region_add 0 - afff [0x7f869800]
> > > > vfio: SKIPPING region_add fec0 - fec00fff
> > > > vfio: SKIPPING region_add fed0 - fed003ff
> > > > vfio: SKIPPING region_add fee0 - feef
> > > > vfio: region_add fffe -  [0x7f88aa40]
> > > > vfio: region_add 1 - 24fff [0x7f874800]
> > > > vfio: Device :04:00.0 flags: 3, regions: 9, irgs: 4
> > > > vfio: Device :04:00.0 region 0:
> > > > vfio:   size: 0x1000, offset: 0x0, flags: 0x7
> > > > vfio: Device :04:00.0 region 1:
> > > > vfio:   size: 0x0, offset: 0x100, flags: 0x0
> > > > vfio: Device :04:00.0 region 2:
> > > > vfio:   size: 0x4, offset: 0x200, flags: 0x7
> > > > vfio: Device :04:00.0 region 3:
> > > > vfio:   size: 0x0, offset: 0x300, flags: 0x0
> > > > vfio: Device :04:00.0 region 4:
> > > > vfio:   size: 0x100, offset: 0x400, flags: 0x3
> > > > vfio: Device :04:00.0 region 5:
> > > > vfio:   size: 0x0, offset: 0x500, flags: 0x0
> > > > vfio: Device :04:00.0 ROM:
> > > > vfio:   size: 0x2, offset: 0x600, flags: 0x1
> > > > vfio: Device :04:00.0 config:
> > > > vfio:   size: 0x1000, offset: 0x700, flags: 0x3
> > > > vfio: vfio_load_rom(:04:00.0)
> > > > vfio: Enabled ATI/AMD BAR2 0x4000 quirk for device :04:00.0
> > > > vfio: Enabled ATI/AMD BAR4 window quirk for device :04:00.0
> > > > vfio: Enabled ATI/AMD quirk 0x3c3 BAR4 for device :04:00.0
> > > > vfio: :04:00.0 PCI MSI CAP @0xa0
> > > > vfio: vfio_pci_read_config(:04:00.0, @0x3d, len=0x1) 1
> > > > vfio: vfio_pci_read_config(:04:00.0, @0x3d, len=0x1) 1
> > > > vfio: vfio_enable_intx_kvm(:04:00.0) KVM INTx accel enabled
> > > > vfio: vfio_enable_intx(:04:00.0)
> > > > vfio: vfio_initfn(:04:00.1) group 14
> > > > vfio: Device :04:00.1 flags: 3, regions: 9, irgs: 4
> > > > vfio: Device :04:00.1 region 0:
> > > > vfio:   size: 0x4000, offset: 0x0, flags: 0x7
> > > > vfio: Device :04:00.1 region 1:
> > > > vfio:   size: 0x0, offset: 0x100, flags: 0x0
> > > > vfio: Device :04:00.1 region 2:
> > > > vfio:   size: 0x0, offset: 0x200, flags: 0x0
> > > > vfio: Device :04:00.1 region 3:
> > > > vfio:   size: 0x0, offset: 0x300, flags: 0x0
> > > > vfio: Device :04:00.1 region 4:
> > > > vfio:   size: 0x0, offset: 0x400, flags: 0x0
> > > > vfio: Device :04:00.1 region 5:
> > > > vfio:   size: 0x0, offset: 0x500, flags: 0x0
> > > > vfio: Device :04:00.1 ROM:
> > > > vfio:   size: 0x0, offset: 0x600, flags: 0x0
> > > > vfio: Device :04:00.1 config:
> > > > vfio:   size: 0x1000, offset: 0x700, flags: 0x3
> > > > vfio: :04:00.1 PCI MSI CAP @0xa0
> > > > vfio: vfio_pci_read_config(:04:00.1, @0x3d, len=0x1) 2
> > > > vfio: vfio_pci_read_config(:04:00.1, @0x3d, len=0x1) 2
> > > > vfio: vfio_enable_intx_kvm(:04:00.1) KVM INTx accel enabled
> > > > vfio: vfio_enable_intx(:04:00.1)
> > > > vfio: region_del 0 - afff
> > > > vfio: region_add 0 - b [0x7f869800]
> > > > vfio: region_add c - d [0x7f88aa20]
> > > > vfio: region_add e - f [0x7f88aa40]
> > > > vfio: region_add 10 - afff [0x7f869810]
> > > > vfio: vfio_pci_reset(:04:00.0)
> > > > vfio: vfio_disable_intx_kvm(:04:00.0) KVM INTx accel disabled
> > > > vfio: vfio_disable_intx(:04:00.0)
> > > > vfio: vfio_pci_read_config(:04:00.0, @0x54, len=0x2) 0
> > > > vfio: vfio_pci_read_config(:04:00.0, @0x4, len=0x2) 3
> > > > vfio: vfio_pci_write_config(:04:00.0, @0x4, 0x0, len=0x2)
> > > > vfio: vfio_pci_read_config(:04:00.0, @0x3d, len=0x1) 1
> > > > vfio: vfio_enable_intx_kvm(:04:00.0) KVM INTx accel enabled
> > > > vfio: vfio_enable_intx(:04:00.0)
> > > > vfio: vfio_pci_reset(:04:00.1)
> > > > vfio: vfio_disable_intx_kvm(:04:00.1) KVM INTx accel disabled
> > > > vfio: vfio_disable_intx(:04:00.1)
> > > > vfio: vfio_pci_read_config(:04:00.1, @0x54, len=0x2) 0
> > > > vfio: vfio_pci_read_config(:04:00.1, @0x4, len=0x2) 6
> > > > vfio: vfio_pci_write_config(:04:00.1, @0x4, 0x0, len=0x2)
> > > > vfio: vfio_pci_read_config(:04:00.1, @0x3d, len=0x1) 2
> > > > vfio: vfio_enable_intx_kvm(:04:00.1) KVM INTx accel enabled
> > > > vfio: vfio_enable_intx(:04:00.1)
> > > > vfio: region_del 0 - b
> > > > vfio: region_del c - d
> > > > vfio: region_add 0 - c7fff [0x7f869800]
> > > > vfio: region_add c8000 - d [0x7f88aa208000]
> > > > vfio: region_del 0 - c7fff
> > > > vfio: region_del c8000 - d
> > > > vfio: region_add 0 - c [0x7f869800]
> > > > vfio: region_add d - d [0x7f88aa21]
> > > > vfio: region_del 0 - c
> > 

Re: [Qemu-devel] [PATCH v3 4/5] xilinx_devcfg: Zynq devcfg device model

[Edgar E. Iglesias]

On Fri, May 24, 2013 at 03:49:00PM +1000, peter.crosthwa...@xilinx.com wrote:
> From: "Peter A. G. Crosthwaite" 
> 
> Minimal device model for devcfg module of Zynq. DMA capabilities and
> interrupt generation supported.
> 
> Signed-off-by: Peter A. G. Crosthwaite 
> ---
> Changed since v2:
> Some QOM styling updates.
> Re-implemented nw0 for lock register as pre_write
> Changed since v1:
> Rebased against new version of Register API.
> Use action callbacks for side effects rather than switch.
> Documented reasons for ge0, ge1 (Verbatim from TRM)
> Added ui1 definitions for unimplemented major features
> Removed dead lock code
> 
>  default-configs/arm-softmmu.mak |   1 +
>  hw/dma/Makefile.objs|   1 +
>  hw/dma/xilinx_devcfg.c  | 495 
> 
>  3 files changed, 497 insertions(+)
>  create mode 100644 hw/dma/xilinx_devcfg.c
> 
> diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
> index 27cbe3d..5a17f64 100644
> --- a/default-configs/arm-softmmu.mak
> +++ b/default-configs/arm-softmmu.mak
> @@ -61,6 +61,7 @@ CONFIG_PXA2XX=y
>  CONFIG_BITBANG_I2C=y
>  CONFIG_FRAMEBUFFER=y
>  CONFIG_XILINX_SPIPS=y
> +CONFIG_ZYNQ_DEVCFG=y
>  
>  CONFIG_A9SCU=y
>  CONFIG_MARVELL_88W8618=y
> diff --git a/hw/dma/Makefile.objs b/hw/dma/Makefile.objs
> index 0e65ed0..96025cf 100644
> --- a/hw/dma/Makefile.objs
> +++ b/hw/dma/Makefile.objs
> @@ -5,6 +5,7 @@ common-obj-$(CONFIG_PL330) += pl330.o
>  common-obj-$(CONFIG_I82374) += i82374.o
>  common-obj-$(CONFIG_I8257) += i8257.o
>  common-obj-$(CONFIG_XILINX_AXI) += xilinx_axidma.o
> +common-obj-$(CONFIG_ZYNQ_DEVCFG) += xilinx_devcfg.o
>  common-obj-$(CONFIG_ETRAXFS) += etraxfs_dma.o
>  common-obj-$(CONFIG_STP2000) += sparc32_dma.o
>  common-obj-$(CONFIG_SUN4M) += sun4m_iommu.o
> diff --git a/hw/dma/xilinx_devcfg.c b/hw/dma/xilinx_devcfg.c
> new file mode 100644
> index 000..b82b7cc
> --- /dev/null
> +++ b/hw/dma/xilinx_devcfg.c
> @@ -0,0 +1,495 @@
> +/*
> + * QEMU model of the Xilinx Devcfg Interface
> + *
> + * Copyright (c) 2011 Peter A.G. Crosthwaite 
> (peter.crosthwa...@petalogix.com)
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a 
> copy
> + * of this software and associated documentation files (the "Software"), to 
> deal
> + * in the Software without restriction, including without limitation the 
> rights
> + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> + * copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
> FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> + * THE SOFTWARE.
> + */
> +
> +#include "sysemu/sysemu.h"
> +#include "sysemu/dma.h"
> +#include "hw/sysbus.h"
> +#include "hw/ptimer.h"
> +#include "qemu/bitops.h"
> +#include "hw/register.h"
> +#include "qemu/bitops.h"
> +
> +#define TYPE_XILINX_DEVCFG "xlnx.ps7-dev-cfg"
> +
> +#define XILINX_DEVCFG(obj) \
> +OBJECT_CHECK(XilinxDevcfg, (obj), TYPE_XILINX_DEVCFG)
> +
> +/* FIXME: get rid of hardcoded nastiness */
> +
> +#define FREQ_HZ 9
> +
> +#define BTT_MAX 0x400 /* bytes to transfer per delay inteval */
> +#define CYCLES_BTT_MAX 1 /*approximate 10k cycles per delay interval */
> +
> +#ifndef XILINX_DEVCFG_ERR_DEBUG
> +#define XILINX_DEVCFG_ERR_DEBUG 0
> +#endif
> +#define DB_PRINT(...) do { \
> +if (XILINX_DEVCFG_ERR_DEBUG) { \
> +fprintf(stderr,  ": %s: ", __func__); \
> +fprintf(stderr, ## __VA_ARGS__); \
> +} \
> +} while (0);
> +
> +#define R_CTRL(0x00/4)
> +#define FORCE_RST(1 << 31) /* Not supported, writes ignored 
> */
> +#define PCAP_PR  (1 << 27) /* Forced to 0 on bad unlock */
> +#define PCAP_MODE(1 << 26)
> +#define MULTIBOOT_EN (1 << 24)
> +#define USER_MODE(1 << 15)
> +#define PCFG_AES_FUSE(1 << 12) /* locked by AES_FUSE_LOCK */
> +#define PCFG_AES_EN_SHIFT9 /* locked by AES_EN_LOCK */
> +#define PCFG_AES_EN_LEN  3 /* locked by AES_EN_LOCK */
> +#define PCFG_AES_EN_MASK (((1 << PCFG_AES_EN_LEN) - 1) \
> +<< PCFG_AES_EN_SHIFT)
> +#define SEU_EN   (1 << 8) /* locked by SEU_LOCK */
> +#define SEC_EN   (1 << 7) /* locked by SEC_LOCK */
> +#define SPNIDEN 

Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28

[Markus Armbruster]

Anthony Liguori  writes:

> Gerd Hoffmann  writes:
>
>> On 05/29/13 01:53, Kevin O'Connor wrote:
>>> On Thu, May 23, 2013 at 03:41:32PM +0300, Michael S. Tsirkin wrote:
 Juan is not available now, and Anthony asked for
 agenda to be sent early.
 So here comes:

 Agenda for the meeting Tue, May 28:

 - Generating acpi tables
>>> 
>>> I didn't see any meeting notes, but I thought it would be worthwhile
>>> to summarize the call.  This is from memory so correct me if I got
>>> anything wrong.
>>> 
>>> Anthony believes that the generation of ACPI tables is the task of the
>>> firmware.  Reasons cited include security implications of running more
>>> code in qemu vs the guest context,
>>
>> I fail to see the security issues here.  It's not like the apci table
>> generation code operates on untrusted input from the guest ...
>
> But possibly untrusted input from a malicious user.  You can imagine
> something like a IaaS provider that let's a user input arbitrary values
> for memory, number of nics, etc.
>
> It's a stretch of an example, I agree, but the general principle I think
> is sound:  we should push as much work as possible to the least
> privileged part of the stack.  In this case, firmware has much less
> privileges than QEMU.

Firmware runs in a primitive, unforgiving environment, and should do as
little as humanly possible.  For an instructive example of deviating
from that rule, check out UEFI.

[...]

Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28

[Michael S. Tsirkin]

On Wed, May 29, 2013 at 11:18:03AM -0500, Anthony Liguori wrote:
> Gerd Hoffmann  writes:
> 
> > On 05/29/13 01:53, Kevin O'Connor wrote:
> >> On Thu, May 23, 2013 at 03:41:32PM +0300, Michael S. Tsirkin wrote:
> >>> Juan is not available now, and Anthony asked for
> >>> agenda to be sent early.
> >>> So here comes:
> >>>
> >>> Agenda for the meeting Tue, May 28:
> >>>
> >>> - Generating acpi tables
> >> 
> >> I didn't see any meeting notes, but I thought it would be worthwhile
> >> to summarize the call.  This is from memory so correct me if I got
> >> anything wrong.
> >> 
> >> Anthony believes that the generation of ACPI tables is the task of the
> >> firmware.  Reasons cited include security implications of running more
> >> code in qemu vs the guest context,
> >
> > I fail to see the security issues here.  It's not like the apci table
> > generation code operates on untrusted input from the guest ...
> 
> But possibly untrusted input from a malicious user.  You can imagine
> something like a IaaS provider that let's a user input arbitrary values
> for memory, number of nics, etc.
> 
> It's a stretch of an example, I agree, but the general principle I think
> is sound:  we should push as much work as possible to the least
> privileged part of the stack.  In this case, firmware has much less
> privileges than QEMU.

It's a big stretch. We have to draw the line somewhere, and I think
when *all* firmware people tell us that QEMU is a pain to work
with and should just supply ACPI table to BIOS, that line
has been crossed.

> >> complexities in running iasl on
> >> big-endian machines,
> >
> > We already have a bunch of prebuilt blobs in the qemu repo for simliar
> > reasons, we can do that with iasl output too.
> >
> >> possible complexity of having to regenerate
> >> tables on a vm reboot,
> >
> > Why tables should be regenerated at reboot?  I remember hotplug being
> > mentioned in the call.  Hmm?  Which hotplugged component needs acpi
> > table updates to work properly?  And what is the point of hotplugging if
> > you must reboot the guest anyway to get the acpi updates needed?
> > Details please.
> 
> See my response to Michael.
> 
> > Also mentioned in the call: "architectural reasons", which I understand
> > as "real hardware works that way".  Correct.  But qemu's virtual
> > hardware is configurable in more ways than real hardware, so we have
> > different needs.  For example: pci slots can or can't be hotpluggable.
> > On real hardware this is fixed.  IIRC this is one of the reasons why we
> > have to patch acpi tables.
> 
> It's not really fixed.  Hardware supports PCI expansion chassises.

These normally aren't reported in ACPI, so no hotplug,
or only native hotplug.

> Multi-node NUMA systems also affect the ACPI tables.

In a very minor way.

> >> overall sloppiness of doing it in QEMU.
> >
> > /me gets the feeling that this is the *main* reason, given that the
> > other ones don't look very convincing to me.
> >
> >> Raised
> >> that QOM interface should be sufficient.
> >
> > Agree on this one.  Ideally the acpi table generation code should be
> > able to gather all information it needs from the qom tree, so it can be
> > a standalone C file instead of being scattered over all qemu.
> 
> Ack.  So my basic argument is why not expose the QOM interfaces to
> firmware and move the generation code there?  Seems like it would be
> more or less a copy/paste once we had a proper implementation in QEMU.

Because that's just insanely rick interface we have no chance to
keep stable across versions.
Because it's a ton of QEMU specific firmware.
Because firmware devs don't want to maintain the ACPI that *is* there either.

> >> There were discussions on potentially introducing a middle component
> >> to generate the tables.  Coreboot was raised as a possibility, and
> >> David thought it would be okay to use coreboot for both OVMF and
> >> SeaBIOS.
> >
> > Certainly an option, but that is a long-term project.
> 
> Out of curiousity, are there other benefits to using coreboot as a core
> firmware in QEMU?
> 
> Is there a payload we would ever plausibly use besides OVMF and SeaBIOS?
> 
> Regards,
> 
> Anthony Liguori

The easier it is to switch firmware the better.

Gives us choice, we switched firmware several times,
we will do it again.

If firmware only has a simple loader for QEMU specific
stuff and is mostly generic, then it's easy.
If there's a lot of code for walking QOM, etc - it's
very painful.

-- 
MST

[Qemu-devel] [PATCH v2 2/2] block: move the bdrv_dev_change_media_cb()

[Pavel Hrdina]

The bdrv_dev_change_media_cb() should be called only for eject and
change commands. We should call that function only if that command
is successful.

What this function does is that it calls the change_media_cb() and
also emit the QEVENT_DEVICE_TRAY_MOVED event.

Signed-off-by: Pavel Hrdina 
---
 block.c| 8 
 blockdev.c | 5 +
 2 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/block.c b/block.c
index 99bc357..a64a9ec 100644
--- a/block.c
+++ b/block.c
@@ -1084,10 +1084,6 @@ int bdrv_open(BlockDriverState *bs, const char 
*filename, QDict *options,
 }
 QDECREF(options);
 
-if (!bdrv_key_required(bs)) {
-bdrv_dev_change_media_cb(bs, true);
-}
-
 /* throttling disk I/O limits */
 if (bs->io_limits_enabled) {
 bdrv_io_limits_enable(bs);
@@ -1389,8 +1385,6 @@ void bdrv_close(BlockDriverState *bs)
 }
 }
 
-bdrv_dev_change_media_cb(bs, false);
-
 /*throttling disk I/O limits*/
 if (bs->io_limits_enabled) {
 bdrv_io_limits_disable(bs);
@@ -2845,8 +2839,6 @@ int bdrv_set_key(BlockDriverState *bs, const char *key)
 bs->valid_key = 0;
 } else if (!bs->valid_key) {
 bs->valid_key = 1;
-/* call the change callback now, we skipped it on open */
-bdrv_dev_change_media_cb(bs, true);
 }
 return ret;
 }
diff --git a/blockdev.c b/blockdev.c
index d1ec99a..a9273de 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -1022,6 +1022,7 @@ static void eject_device(BlockDriverState *bs, int force, 
Error **errp)
 }
 
 bdrv_close(bs);
+bdrv_dev_change_media_cb(bs, false);
 }
 
 void qmp_eject(const char *device, bool has_force, bool force, Error **errp)
@@ -1071,14 +1072,18 @@ static void qmp_bdrv_open_encrypted(BlockDriverState 
*bs, const char *filename,
 if (password) {
 if (bdrv_set_key(bs, password) < 0) {
 error_set(errp, QERR_INVALID_PASSWORD);
+return;
 }
 } else {
 error_set(errp, QERR_DEVICE_ENCRYPTED, bdrv_get_device_name(bs),
   bdrv_get_encrypted_filename(bs));
+return;
 }
 } else if (password) {
 error_set(errp, QERR_DEVICE_NOT_ENCRYPTED, bdrv_get_device_name(bs));
 }
+
+bdrv_dev_change_media_cb(bs, true);
 }
 
 void qmp_change_blockdev(const char *device, const char *filename,
-- 
1.8.1.4

[Qemu-devel] [PATCH v2 1/2] block: make bdrv_dev_change_media_cb() public

[Pavel Hrdina]

From: Luiz Capitulino 

Next commit wants to use it.

Signed-off-by: Luiz Capitulino 
Signed-off-by: Pavel Hrdina 
---
 block.c   | 3 +--
 include/block/block.h | 1 +
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/block.c b/block.c
index 3f87489..99bc357 100644
--- a/block.c
+++ b/block.c
@@ -56,7 +56,6 @@ typedef enum {
 BDRV_REQ_ZERO_WRITE   = 0x2,
 } BdrvRequestFlags;
 
-static void bdrv_dev_change_media_cb(BlockDriverState *bs, bool load);
 static BlockDriverAIOCB *bdrv_aio_readv_em(BlockDriverState *bs,
 int64_t sector_num, QEMUIOVector *qiov, int nb_sectors,
 BlockDriverCompletionFunc *cb, void *opaque);
@@ -1681,7 +1680,7 @@ static void bdrv_emit_qmp_eject_event(BlockDriverState 
*bs, bool ejected)
 qobject_decref(data);
 }
 
-static void bdrv_dev_change_media_cb(BlockDriverState *bs, bool load)
+void bdrv_dev_change_media_cb(BlockDriverState *bs, bool load)
 {
 if (bs->dev_ops && bs->dev_ops->change_media_cb) {
 bool tray_was_closed = !bdrv_dev_is_tray_open(bs);
diff --git a/include/block/block.h b/include/block/block.h
index 1251c5c..7a238bc 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -158,6 +158,7 @@ void bdrv_set_dev_ops(BlockDriverState *bs, const 
BlockDevOps *ops,
   void *opaque);
 void bdrv_dev_eject_request(BlockDriverState *bs, bool force);
 bool bdrv_dev_has_removable_media(BlockDriverState *bs);
+void bdrv_dev_change_media_cb(BlockDriverState *bs, bool load);
 bool bdrv_dev_is_tray_open(BlockDriverState *bs);
 bool bdrv_dev_is_medium_locked(BlockDriverState *bs);
 int bdrv_read(BlockDriverState *bs, int64_t sector_num,
-- 
1.8.1.4

Re: [Qemu-devel] KVM call agenda for 2013-05-28

[Michael S. Tsirkin]

On Wed, May 29, 2013 at 11:12:06AM -0500, Anthony Liguori wrote:
> "Michael S. Tsirkin"  writes:
> 
> > On Tue, May 28, 2013 at 07:53:09PM -0400, Kevin O'Connor wrote:
> >> On Thu, May 23, 2013 at 03:41:32PM +0300, Michael S. Tsirkin wrote:
> >> > Juan is not available now, and Anthony asked for
> >> > agenda to be sent early.
> >> > So here comes:
> >> > 
> >> > Agenda for the meeting Tue, May 28:
> >> > 
> >> > - Generating acpi tables
> >> 
> >> I didn't see any meeting notes, but I thought it would be worthwhile
> >> to summarize the call.  This is from memory so correct me if I got
> >> anything wrong.
> >> 
> >> Anthony believes that the generation of ACPI tables is the task of the
> >> firmware.  Reasons cited include security implications of running more
> >> code in qemu vs the guest context, complexities in running iasl on
> >> big-endian machines, possible complexity of having to regenerate
> >> tables on a vm reboot, overall sloppiness of doing it in QEMU.  Raised
> >> that QOM interface should be sufficient.
> >> 
> >> Kevin believes that the bios table code should be moved up into QEMU.
> >> Reasons cited include the churn rate in SeaBIOS for this QEMU feature
> >> (15-20% of all SeaBIOS commits since integrating with QEMU have been
> >> for bios tables; 20% of SeaBIOS commits in last year), complexity of
> >> trying to pass all the content needed to generate the tables (eg,
> >> device details, power tree, irq routing), complexity of scheduling
> >> changes across different repos and synchronizing their rollout,
> >> complexity of implemeting the code in both OVMF and SeaBIOS.  Kevin
> >> wasn't aware of a requirement to regenerate acpi tables on a vm
> >> reboot.
> >
> > I think this last one is based on a misunderstanding: it's based
> > on assumption that we we change hardware by hotplug
> > we should regenerate the tables to match.
> > But there's no management that can take advantage of
> > this.
> > Two possible reasonable things we can tell management:
> > - hotplug for device XXX is not supported: restart qemu
> >   to make guest use the device
> > - hotplug for device XXX is supported
> 
> This introduces an assumption: that the device model never radically
> changes across resets.
> 
> Why should this be true?  Shouldn't we be allowed to increase the amount
> of memory the guest has across reboots?  That's equivalent to adding
> another DIMM after power off.
> 

You can argue the same thing about non hotpluggable devices:
you might be able to replace them when guest is powered off.

It's not supported ATM and if/when it is, there's a bunch of
code to be written.

> Not generating tables on reset does limit what we can do in a pretty
> fundamental way.  Even if you can argue it in the short term, I don't
> think it's viable in the long term.
> 
> Regards,
> 
> Anthony Liguori

No because that's not "at reset".
We need a separate state for power off.

You power off the machine, add DIMM, restart it.

Its not something you can do from inside the guest,
unlike reset.

At the moment, the only way to implement this is by
exiting from QEMU.
So we are not introducing any regressions here.
When qemu gains power off state we can add a handler
and regenerate the tables.

-- 
MST

Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28

[Anthony Liguori]

Gerd Hoffmann  writes:

> On 05/29/13 01:53, Kevin O'Connor wrote:
>> On Thu, May 23, 2013 at 03:41:32PM +0300, Michael S. Tsirkin wrote:
>>> Juan is not available now, and Anthony asked for
>>> agenda to be sent early.
>>> So here comes:
>>>
>>> Agenda for the meeting Tue, May 28:
>>>
>>> - Generating acpi tables
>> 
>> I didn't see any meeting notes, but I thought it would be worthwhile
>> to summarize the call.  This is from memory so correct me if I got
>> anything wrong.
>> 
>> Anthony believes that the generation of ACPI tables is the task of the
>> firmware.  Reasons cited include security implications of running more
>> code in qemu vs the guest context,
>
> I fail to see the security issues here.  It's not like the apci table
> generation code operates on untrusted input from the guest ...

But possibly untrusted input from a malicious user.  You can imagine
something like a IaaS provider that let's a user input arbitrary values
for memory, number of nics, etc.

It's a stretch of an example, I agree, but the general principle I think
is sound:  we should push as much work as possible to the least
privileged part of the stack.  In this case, firmware has much less
privileges than QEMU.

>> complexities in running iasl on
>> big-endian machines,
>
> We already have a bunch of prebuilt blobs in the qemu repo for simliar
> reasons, we can do that with iasl output too.
>
>> possible complexity of having to regenerate
>> tables on a vm reboot,
>
> Why tables should be regenerated at reboot?  I remember hotplug being
> mentioned in the call.  Hmm?  Which hotplugged component needs acpi
> table updates to work properly?  And what is the point of hotplugging if
> you must reboot the guest anyway to get the acpi updates needed?
> Details please.

See my response to Michael.

> Also mentioned in the call: "architectural reasons", which I understand
> as "real hardware works that way".  Correct.  But qemu's virtual
> hardware is configurable in more ways than real hardware, so we have
> different needs.  For example: pci slots can or can't be hotpluggable.
> On real hardware this is fixed.  IIRC this is one of the reasons why we
> have to patch acpi tables.

It's not really fixed.  Hardware supports PCI expansion chassises.
Multi-node NUMA systems also affect the ACPI tables.

>> overall sloppiness of doing it in QEMU.
>
> /me gets the feeling that this is the *main* reason, given that the
> other ones don't look very convincing to me.
>
>> Raised
>> that QOM interface should be sufficient.
>
> Agree on this one.  Ideally the acpi table generation code should be
> able to gather all information it needs from the qom tree, so it can be
> a standalone C file instead of being scattered over all qemu.

Ack.  So my basic argument is why not expose the QOM interfaces to
firmware and move the generation code there?  Seems like it would be
more or less a copy/paste once we had a proper implementation in QEMU.

>> There were discussions on potentially introducing a middle component
>> to generate the tables.  Coreboot was raised as a possibility, and
>> David thought it would be okay to use coreboot for both OVMF and
>> SeaBIOS.
>
> Certainly an option, but that is a long-term project.

Out of curiousity, are there other benefits to using coreboot as a core
firmware in QEMU?

Is there a payload we would ever plausibly use besides OVMF and SeaBIOS?

Regards,

Anthony Liguori

[Qemu-devel] [PATCH v2 0/2] block: fix spurious DEVICE_TRAY_MOVED events on shutdown

[Pavel Hrdina]

This fixes a regression introduced by commit 9ca111544.

The first commit is done by Luiz and I've just use it as it is.

The second commit moves the bdrv_dev_change_media_cb() into eject_device(),
called by QMP and HMP eject command, and into qmp_bdrv_open_encrypted(),
called by QMP and HMP change command. These are the only place where I think
that should call the bdrv_dev_change_media_cb() function.

There is no reason to call this function while we are removing the device
from the guest, for example while closing and deleting all devices on shutdown.

Luiz Capitulino (1):
  block: make bdrv_dev_change_media_cb() public

Pavel Hrdina (1):
  block: move the bdrv_dev_change_media_cb()

 block.c   | 11 +--
 blockdev.c|  5 +
 include/block/block.h |  1 +
 3 files changed, 7 insertions(+), 10 deletions(-)

-- 
1.8.1.4

Re: [Qemu-devel] VFIO VGA test branches

[Maik Broemme]

Hi,

Maik Broemme  wrote:
> > > 
> > > Here is the DEBUG_VFIO output:
> > > 
> > > vfio: vfio_initfn(:04:00.0) group 14
> > > vfio: region_add 0 - afff [0x7f869800]
> > > vfio: SKIPPING region_add fec0 - fec00fff
> > > vfio: SKIPPING region_add fed0 - fed003ff
> > > vfio: SKIPPING region_add fee0 - feef
> > > vfio: region_add fffe -  [0x7f88aa40]
> > > vfio: region_add 1 - 24fff [0x7f874800]
> > > vfio: Device :04:00.0 flags: 3, regions: 9, irgs: 4
> > > vfio: Device :04:00.0 region 0:
> > > vfio:   size: 0x1000, offset: 0x0, flags: 0x7
> > > vfio: Device :04:00.0 region 1:
> > > vfio:   size: 0x0, offset: 0x100, flags: 0x0
> > > vfio: Device :04:00.0 region 2:
> > > vfio:   size: 0x4, offset: 0x200, flags: 0x7
> > > vfio: Device :04:00.0 region 3:
> > > vfio:   size: 0x0, offset: 0x300, flags: 0x0
> > > vfio: Device :04:00.0 region 4:
> > > vfio:   size: 0x100, offset: 0x400, flags: 0x3
> > > vfio: Device :04:00.0 region 5:
> > > vfio:   size: 0x0, offset: 0x500, flags: 0x0
> > > vfio: Device :04:00.0 ROM:
> > > vfio:   size: 0x2, offset: 0x600, flags: 0x1
> > > vfio: Device :04:00.0 config:
> > > vfio:   size: 0x1000, offset: 0x700, flags: 0x3
> > > vfio: vfio_load_rom(:04:00.0)
> > > vfio: Enabled ATI/AMD BAR2 0x4000 quirk for device :04:00.0
> > > vfio: Enabled ATI/AMD BAR4 window quirk for device :04:00.0
> > > vfio: Enabled ATI/AMD quirk 0x3c3 BAR4 for device :04:00.0
> > > vfio: :04:00.0 PCI MSI CAP @0xa0
> > > vfio: vfio_pci_read_config(:04:00.0, @0x3d, len=0x1) 1
> > > vfio: vfio_pci_read_config(:04:00.0, @0x3d, len=0x1) 1
> > > vfio: vfio_enable_intx_kvm(:04:00.0) KVM INTx accel enabled
> > > vfio: vfio_enable_intx(:04:00.0)
> > > vfio: vfio_initfn(:04:00.1) group 14
> > > vfio: Device :04:00.1 flags: 3, regions: 9, irgs: 4
> > > vfio: Device :04:00.1 region 0:
> > > vfio:   size: 0x4000, offset: 0x0, flags: 0x7
> > > vfio: Device :04:00.1 region 1:
> > > vfio:   size: 0x0, offset: 0x100, flags: 0x0
> > > vfio: Device :04:00.1 region 2:
> > > vfio:   size: 0x0, offset: 0x200, flags: 0x0
> > > vfio: Device :04:00.1 region 3:
> > > vfio:   size: 0x0, offset: 0x300, flags: 0x0
> > > vfio: Device :04:00.1 region 4:
> > > vfio:   size: 0x0, offset: 0x400, flags: 0x0
> > > vfio: Device :04:00.1 region 5:
> > > vfio:   size: 0x0, offset: 0x500, flags: 0x0
> > > vfio: Device :04:00.1 ROM:
> > > vfio:   size: 0x0, offset: 0x600, flags: 0x0
> > > vfio: Device :04:00.1 config:
> > > vfio:   size: 0x1000, offset: 0x700, flags: 0x3
> > > vfio: :04:00.1 PCI MSI CAP @0xa0
> > > vfio: vfio_pci_read_config(:04:00.1, @0x3d, len=0x1) 2
> > > vfio: vfio_pci_read_config(:04:00.1, @0x3d, len=0x1) 2
> > > vfio: vfio_enable_intx_kvm(:04:00.1) KVM INTx accel enabled
> > > vfio: vfio_enable_intx(:04:00.1)
> > > vfio: region_del 0 - afff
> > > vfio: region_add 0 - b [0x7f869800]
> > > vfio: region_add c - d [0x7f88aa20]
> > > vfio: region_add e - f [0x7f88aa40]
> > > vfio: region_add 10 - afff [0x7f869810]
> > > vfio: vfio_pci_reset(:04:00.0)
> > > vfio: vfio_disable_intx_kvm(:04:00.0) KVM INTx accel disabled
> > > vfio: vfio_disable_intx(:04:00.0)
> > > vfio: vfio_pci_read_config(:04:00.0, @0x54, len=0x2) 0
> > > vfio: vfio_pci_read_config(:04:00.0, @0x4, len=0x2) 3
> > > vfio: vfio_pci_write_config(:04:00.0, @0x4, 0x0, len=0x2)
> > > vfio: vfio_pci_read_config(:04:00.0, @0x3d, len=0x1) 1
> > > vfio: vfio_enable_intx_kvm(:04:00.0) KVM INTx accel enabled
> > > vfio: vfio_enable_intx(:04:00.0)
> > > vfio: vfio_pci_reset(:04:00.1)
> > > vfio: vfio_disable_intx_kvm(:04:00.1) KVM INTx accel disabled
> > > vfio: vfio_disable_intx(:04:00.1)
> > > vfio: vfio_pci_read_config(:04:00.1, @0x54, len=0x2) 0
> > > vfio: vfio_pci_read_config(:04:00.1, @0x4, len=0x2) 6
> > > vfio: vfio_pci_write_config(:04:00.1, @0x4, 0x0, len=0x2)
> > > vfio: vfio_pci_read_config(:04:00.1, @0x3d, len=0x1) 2
> > > vfio: vfio_enable_intx_kvm(:04:00.1) KVM INTx accel enabled
> > > vfio: vfio_enable_intx(:04:00.1)
> > > vfio: region_del 0 - b
> > > vfio: region_del c - d
> > > vfio: region_add 0 - c7fff [0x7f869800]
> > > vfio: region_add c8000 - d [0x7f88aa208000]
> > > vfio: region_del 0 - c7fff
> > > vfio: region_del c8000 - d
> > > vfio: region_add 0 - c [0x7f869800]
> > > vfio: region_add d - d [0x7f88aa21]
> > > vfio: region_del 0 - c
> > > vfio: region_del d - d
> > > vfio: region_add 0 - d7fff [0x7f869800]
> > > vfio: region_add d8000 - d [0x7f88aa218000]
> > > vfio: region_del 0 - d7fff
> > > vfio: region_del d8000 - d
> > > vfio: region_add 0 - d [0x

Re: [Qemu-devel] KVM call agenda for 2013-05-28

[Anthony Liguori]

"Michael S. Tsirkin"  writes:

> On Tue, May 28, 2013 at 07:53:09PM -0400, Kevin O'Connor wrote:
>> On Thu, May 23, 2013 at 03:41:32PM +0300, Michael S. Tsirkin wrote:
>> > Juan is not available now, and Anthony asked for
>> > agenda to be sent early.
>> > So here comes:
>> > 
>> > Agenda for the meeting Tue, May 28:
>> > 
>> > - Generating acpi tables
>> 
>> I didn't see any meeting notes, but I thought it would be worthwhile
>> to summarize the call.  This is from memory so correct me if I got
>> anything wrong.
>> 
>> Anthony believes that the generation of ACPI tables is the task of the
>> firmware.  Reasons cited include security implications of running more
>> code in qemu vs the guest context, complexities in running iasl on
>> big-endian machines, possible complexity of having to regenerate
>> tables on a vm reboot, overall sloppiness of doing it in QEMU.  Raised
>> that QOM interface should be sufficient.
>> 
>> Kevin believes that the bios table code should be moved up into QEMU.
>> Reasons cited include the churn rate in SeaBIOS for this QEMU feature
>> (15-20% of all SeaBIOS commits since integrating with QEMU have been
>> for bios tables; 20% of SeaBIOS commits in last year), complexity of
>> trying to pass all the content needed to generate the tables (eg,
>> device details, power tree, irq routing), complexity of scheduling
>> changes across different repos and synchronizing their rollout,
>> complexity of implemeting the code in both OVMF and SeaBIOS.  Kevin
>> wasn't aware of a requirement to regenerate acpi tables on a vm
>> reboot.
>
> I think this last one is based on a misunderstanding: it's based
> on assumption that we we change hardware by hotplug
> we should regenerate the tables to match.
> But there's no management that can take advantage of
> this.
> Two possible reasonable things we can tell management:
> - hotplug for device XXX is not supported: restart qemu
>   to make guest use the device
> - hotplug for device XXX is supported

This introduces an assumption: that the device model never radically
changes across resets.

Why should this be true?  Shouldn't we be allowed to increase the amount
of memory the guest has across reboots?  That's equivalent to adding
another DIMM after power off.

Not generating tables on reset does limit what we can do in a pretty
fundamental way.  Even if you can argue it in the short term, I don't
think it's viable in the long term.

Regards,

Anthony Liguori

Re: [Qemu-devel] snabbswitch integration with QEMU for userspace ethernet I/O

[Julian Stecklina]

On 05/29/2013 04:21 PM, Stefan Hajnoczi wrote:
> The fact that a single switch process has shared memory access to all
> guests' RAM is critical.  If the switch process is exploited, then that
> exposes other guests' data!  (Think of a multi-tenant host with guests
> belonging to different users.)

True. But people don't mind having instruction decoding and half of
virtio in the kernel these days, so it can't be that security critical...

Julian



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] snabbswitch integration with QEMU for userspace ethernet I/O

[Julian Stecklina]

On 05/29/2013 04:31 PM, Stefan Hajnoczi wrote:
> On Wed, May 29, 2013 at 02:32:50PM +0200, Julian Stecklina wrote:
>> On 05/28/2013 07:00 PM, Anthony Liguori wrote:
>>> We aren't going to support any interface that enables out of tree
>>> devices.  This is just plugins in a different form with even more
>>> downsides.  You cannot easily keep track of dirty info, the guest
>>> physical address translation to host is difficult to keep in sync
>>> (imagine the complexity of memory hotplug).
>>
>> Is there a document describing the current qemu VM migration process,
>> especially the dirty page tracking, except the code?
>>
>> As a side note: The downsides of a naive approach are about that of PCI
>> passtrough devices with the opportunity to fix them later on. That being
>> said, I can live with this not being included in mainline qemu.
> 
> Asking for documentation and in the next paragraph stating you don't
> mind keeping patches out-of-tree...
> 
> The QEMU community exists because people are willing to contribute.  If
> you intend to only "take" and not "give", then you'll find that people
> gradually stop responding to your emails.

I am not saying that this will be closed in any way. I'll create a
github repo once I have to show something. If there is interest in
getting this into mainline qemu, then why not. Currently, it seems that
there is a categorical rejection of such functionality.

But this discussion is moot until there is working code. ;)

Julian




signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] VFIO VGA test branches

[Maik Broemme]

Hi,

Alex Williamson  wrote:
> On Tue, 2013-05-28 at 20:45 +0200, Maik Broemme wrote:
> > Hi,
> > 
> > Maik Broemme  wrote:
> > > Hi Alex,
> > > 
> > > Maik Broemme  wrote:
> > > > Hi Alex,
> > > > 
> > > > Alex Williamson  wrote:
> > > > > 
> > > > > Good to hear.  It looks like you have the same motherboard as my AMD
> > > > > test system.  An HD7850 in that system runs quite reliably with the
> > > > > branches above although I do occasionally get VGA palette corruption.
> > > > > 
> > > > 
> > > > Good to know. I'm using a Radeon HD7870 which works fine now. I have the
> > > > same VGA palette corruption occasionally but only until Catalyst driver
> > > > is loaded. So it happens sometimes during VGA init if Windows 7 boot
> > > > logo is shown with very strange colors and went away if Catalyst driver
> > > > is loaded.
> > > > 
> > > > > Are you still require -vga cirrus or do the -vga none, x-vga=on cases
> > > > > work now too?  Thanks,
> > > > > 
> > > > 
> > > > No longer required, -vga none with x-vga=on work on your branches fine
> > > > now. Not sure if there was something more changed because with original
> > > > Fedora 3.9.2 kernel it still doesn't work.
> > > > 
> > > 
> > > Alex, I have a strange issue now with either the 'vfio-vga-reset'
> > > branches or with the stable 3.9.4 kernel. This is my 'lspci' output:
> > > 
> > > 00:14.2 Audio device: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia 
> > > (Intel HDA) (rev 40)
> > > 01:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce GT 
> > > 520] (rev a1)
> > > 01:00.1 Audio device: NVIDIA Corporation GF119 HDMI Audio Controller (rev 
> > > a1)
> > > 02:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI 
> > > Pitcairn [Radeon HD 7800]
> > > 02:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Cape 
> > > Verde/Pitcairn HDMI Audio [Radeon HD 7700/7800 Series]
> > > 
> > > The '01:00.0' is my primary device used for Linux and '02:00.0' my
> > > secondary for QEMU. Two new different problems:
> > > 
> > > 1) If the 'nvidia.ko' binary driver is loaded for the first card, QEMU
> > > immediately get stuck after startup and hangs with:
> > > 
> > > 1140  futex(0x7f0ad9b21300, FUTEX_WAIT_PRIVATE, 2, NULL
> > > 
> > > I have the complete strace output if needed. After that I can only
> > > terminate qemu with 'kill -9' and if I start it again the following
> > > Oops occurs:
> > > 
> > > [  655.684121] [ cut here ]
> > > [  655.684134] WARNING: at lib/list_debug.c:29 __list_add+0x77/0xd0()
> > > [  655.684151] Hardware name: GA-990FXA-UD3
> > > [  655.684271] list_add corruption. next->prev should be prev 
> > > (81ca3d98), but was   (null). (next=88041bc3fe08).
> > > [  655.684477] Modules linked in: vhost_net macvtap macvlan tun arc4 md4 
> > > nls_utf8 cifs dns_resolver fscache vfio_pci vfio_iommu_type1 vfio bridge 
> > > stp llc ip6table_filter ip6_tables it87 hwmon_vid snd_hda_codec_hdmi 
> > > nvidia(POF) acpi_cpufreq mperf kvm_amd snd_hda_codec_realtek kvm 
> > > crc32_pclmul crc32c_intel ghash_clmulni_intel snd_hda_intel snd_hda_codec 
> > > microcode edac_core snd_hwdep fam15h_power snd_seq edac_mce_amd 
> > > snd_seq_device k10temp r8169 sp5100_tco snd_pcm mii i2c_piix4 
> > > snd_page_alloc snd_timer i2c_core snd soundcore mxm_wmi firewire_ohci 
> > > firewire_core crc_itu_t wmi
> > > [  655.685451] Pid: 2097, comm: qemu-system-x86 Tainted: PF  O 
> > > 3.9.4-200.fc18.x86_64 #1
> > > [  655.685642] Call Trace:
> > > [  655.685738]  [] warn_slowpath_common+0x75/0xa0
> > > [  655.685851]  [] warn_slowpath_fmt+0x46/0x50
> > > [  655.685955]  [] __list_add+0x77/0xd0
> > > [  655.686058]  [] add_wait_queue+0x3c/0x60
> > > [  655.686162]  [] vga_get+0xdd/0x190
> > > [  655.686266]  [] ? try_to_wake_up+0x2d0/0x2d0
> > > [  655.686373]  [] vfio_pci_vga_rw+0xb5/0x230 [vfio_pci]
> > > [  655.686481]  [] vfio_pci_rw+0x39/0x80 [vfio_pci]
> > > [  655.686587]  [] vfio_pci_read+0x1c/0x20 [vfio_pci]
> > > [  655.686701]  [] vfio_device_fops_read+0x23/0x30 
> > > [vfio]
> > > [  655.686814]  [] vfs_read+0xa9/0x180
> > > [  655.686915]  [] sys_pread64+0x9a/0xb0
> > > [  655.687018]  [] system_call_fastpath+0x16/0x1b
> > > [  655.687123] ---[ end trace a68eabc3660237b1 ]---
> > > 
> > > This is always reproducible. I know it is the binary driver and maybe
> > > nobody cares but it is widely used. :)
> > 
> > Here is the DEBUG_VFIO output:
> > 
> > vfio: vfio_initfn(:04:00.0) group 14
> > vfio: region_add 0 - afff [0x7f869800]
> > vfio: SKIPPING region_add fec0 - fec00fff
> > vfio: SKIPPING region_add fed0 - fed003ff
> > vfio: SKIPPING region_add fee0 - feef
> > vfio: region_add fffe -  [0x7f88aa40]
> > vfio: region_add 1 - 24fff [0x7f874800]
> > vfio: Device :04:00.0 flags: 3, regions: 9, irgs: 4
> > vfio: Device :04:00.0 region 0:
> > vfio:   size: 0x1000, offset: 0x0, flags: 0x7
> > vfio: Dev

Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

[Badari Pulavarty]

On 05/29/2013 02:05 AM, Wenchao Xia wrote:

于 2013-5-28 17:00, Wenchao Xia 写道:

于 2013-5-28 16:33, Asias He 写道:

On Tue, May 28, 2013 at 10:01:14AM +0200, Paolo Bonzini wrote:

Il 28/05/2013 09:13, Wenchao Xia ha scritto:

From: Nicholas Bellinger 

The WWPN specified in configfs is passed to "-device 
vhost-scsi-pci".

The tgpt field of the SET_ENDPOINT ioctl is obsolete now, so it is
not
available from the QEMU command-line.  Instead, I hardcode it to
zero.


Hi, Paolo
   Any document about how to config it correctly in configfs, before
invoking qemu with the WWPN number?


Unfortunately no, but vhost-scsi doesn't have many knobs (unlike
iSCSI for example) so it's quite simple.  Here is an example:

cd /sys/kernel/config/target
mkdir -p core/fileio_0/fileio
echo 'fd_dev_name=/home/pbonzini/test.img,fd_dev_size=5905580032' >
core/fileio_0/fileio/control
echo 1 > core/fileio_0/fileio/enable
mkdir -p vhost/naa.600140554cf3a18e/tpgt_0/lun/lun_0
cd vhost/naa.600140554cf3a18e/tpgt_0
ln -sf ../../../../../core/fileio_0/fileio/ 
lun/lun_0/virtual_scsi_port

echo naa.60014053226f0388 > nexus

The "nexus" value is the initiator WWN. naa.600140554cf3a18e is the
target WWN that you have to pass to "-device vhost-scsi-pci".

Paolo


For me, I always use targetcli utils instead of the sysfs interface.
targetcli in F18 has vhost support now.


   Thanks very much for above information, I'll try it for test.


  I have done a basic test of vhost-scsi, following is the result I'd
like to post, generally it seems fine:

Result:
  fdisk/mkfs: fdisk can find it, mke2fs works fine.
  mount: can mount it.
  file I/O: dd 90M zero to a file in that disk succeed.




I tried without nested kvm.



Issues:
  1) in fdisk -l, sometime timeout with dmesg "end_request: I/O error,
dev  fd0, sector 0", I guess it is caused by nested KVM that failed
to kick host kernel?



I don't see this issue. Are you sure "fd0" is actually the scsi device ?
what is "fd0" ?


  2) in fdisk -l, it shows 512 bytes larger than the parameter I
specified in fd_dev_size parameter in configfs on host.(shows
104858112 bytes, see the invocation script below)



I see the same. For some reason "fdisk -l" in the VM shows
512-bytes more than the actual size for the file (on the host).

Thanks,
Badari

Re: [Qemu-devel] [PATCH v4 0/3] ARM aarch64 TCG target

[Richard Henderson]

On 05/29/2013 02:04 AM, Claudio Fontana wrote:
> This series implements preliminary support for the ARM aarch64 TCG target.
> 
> Limitations of this initial implementation (TODOs) include:
> 
>  * missing TLB lookup in qemu_ld/st [C helpers always called].
>An incremental patch, which requires this series, is coming up
>from colleague Jani Kokkonen to implement this.
>  * most optional opcodes are not implemented yet (only rotation done).
>  * CONFIG_SOFTMMU only
> 
> Tested running on a x86-64 physical machine running Foundation v8,
> running a linux 3.8.0-rc6+ minimal host system based on linaro v8
> image 201301271620 for user space.
> 
> Tested guests: arm v5 test image, i386 FreeDOS test image,
> i386 linux test image, all from qemu-devel testing page.
> Also tested on x86-64/linux built with buildroot,
> and on arm v7/linux built with buildroot as well.
> 
> Changes in v2:
> 
>  * for icache flushing, removed placeholder for old gcc
>  * aligned defines values in the elf aarch64 relocations
>  * added comment in the elf aarch64 relocations
>  * use X16 and X17 as well, they should be safe to use
>  * defined TCG_REG_TMP to TCG_REG_X8
>  * fix relocs and gotos to be more robust during retranslation
>  * removed declarations and assignments on same line
>  * added braces in 'if's even when unnecessary
>  * added comment about COND_NV behaving like COND_AL in aarch64
>  * added comment about no-extend field
>  * remove trampoline for the conditional branches, add CONDBR19
>  * set MAX_CODE_GEN_BUFFER_SIZE for aarch64, matching JUMP26
>  * improved left rotations, by using one less instruction
>  * for setcond_i32/i64 use CSET instead of CSEL
>  * implement andi and subi for working with the stack
>  * do not rely on temp_buf for tcg_set_frame: use stack
>  * remove unused constrained ARM constant
>  * redefine enums with same value to one-another
>  * fix setting of available regs (set all 32 bits)
>  * moved configure patch to after the tcg target in the series
>  * added low level operations useful in preparation of tlb lookup
> 
> Changes in v3:
>  * removed low level operations introduced in v2, will be in separate series
>  * honor 'addend' in patch_reloc, although it's always 0
>  * replace use of 'int' with 'TCGReg' when registers are expected
>  * merge movi32 and movi64 into movi_aux
>  * use 32bit version of the instructions when possible, to save energy/cycles
>  * do not clobber a passed register for INDEX_op_rotl_i32/i64
>  * removed hard coded SP and FP in stack functions, make them params
>  * zero-extend addr_reg for 32bit guests in qemu_ld/st
>  * make use of deposit32 (bitops) in reloc_pc26 and reloc_pc19
>  * never use multiple cases per line in switches even when empty
>  * less pessimistic range checks for instructions
>  * other formatting fixes that fell through the cracks in v2
> 
> Changes in v4:
>  * made move immediate implementation more concise
>  * added comments explaining how the move immediate works
>  * reserve the frame pointer register (FP)
> 
> Claudio Fontana (3):
>   include/elf.h: add aarch64 ELF machine and relocs
>   tcg/aarch64: implement new TCG target for aarch64
>   configure: permit compilation on arm aarch64

Reviewed-by: Richard Henderson 


r~

[Qemu-devel] [PATCH v2] i.MX: Improve EPIT timer code.

[Jean-Christophe DUBOIS]

* Unify function and type naming
* use dynamic cast whenever possible
* simplify Debug printf.
* use new style device intialization.

Signed-off-by: Jean-Christophe DUBOIS 
---

Change since v1:
* use shorter unified name
* fix a debug print bug in imx_epit_set_freq()

 hw/timer/imx_epit.c | 236 +---
 1 file changed, 132 insertions(+), 104 deletions(-)

diff --git a/hw/timer/imx_epit.c b/hw/timer/imx_epit.c
index 451e646..7cdb006 100644
--- a/hw/timer/imx_epit.c
+++ b/hw/timer/imx_epit.c
@@ -5,6 +5,7 @@
  * Copyright (c) 2011 NICTA Pty Ltd
  * Originally written by Hans Jiang
  * Updated by Peter Chubb
+ * Updated by Jean-Christophe Dubois
  *
  * This code is licensed under GPL version 2 or later.  See
  * the COPYING file in the top-level directory.
@@ -18,10 +19,31 @@
 #include "hw/sysbus.h"
 #include "hw/arm/imx.h"
 
-//#define DEBUG_TIMER 1
-#ifdef DEBUG_TIMER
+#define TYPE_IMX_EPIT "imx.epit"
+
+#define DEBUG_TIMER 0
+#if DEBUG_TIMER
+
+static char const *imx_epit_reg_name(uint32_t reg)
+{
+switch (reg) {
+case 0:
+return "CR";
+case 1:
+return "SR";
+case 2:
+return "LR";
+case 3:
+return "CMP";
+case 4:
+return "CNT";
+default:
+return "[?]";
+}
+}
+
 #  define DPRINTF(fmt, args...) \
-  do { printf("imx_timer: " fmt , ##args); } while (0)
+  do { printf("%s: " fmt , __func__, ##args); } while (0)
 #else
 #  define DPRINTF(fmt, args...) do {} while (0)
 #endif
@@ -32,12 +54,15 @@
  */
 #define DEBUG_IMPLEMENTATION 1
 #if DEBUG_IMPLEMENTATION
-#  define IPRINTF(fmt, args...) \
-do  { fprintf(stderr, "imx_timer: " fmt, ##args); } while (0)
+#  define IPRINTF(fmt, args...) \
+  do { fprintf(stderr, "%s: " fmt, __func__, ##args); } while (0)
 #else
 #  define IPRINTF(fmt, args...) do {} while (0)
 #endif
 
+#define IMX_EPIT(obj) \
+OBJECT_CHECK(IMXEPITState, (obj), TYPE_IMX_EPIT)
+
 /*
  * EPIT: Enhanced periodic interrupt timer
  */
@@ -63,7 +88,7 @@
  * Exact clock frequencies vary from board to board.
  * These are typical.
  */
-static const IMXClk imx_timerp_clocks[] =  {
+static const IMXClk imx_epit_clocks[] =  {
 0,/* 00 disabled */
 IPG,  /* 01 ipg_clk, ~532MHz */
 IPG,  /* 10 ipg_clk_highfreq */
@@ -85,32 +110,33 @@ typedef struct {
 
 uint32_t freq;
 qemu_irq irq;
-} IMXTimerPState;
+} IMXEPITState;
 
 /*
  * Update interrupt status
  */
-static void imx_timerp_update(IMXTimerPState *s)
+static void imx_epit_update_int(IMXEPITState *s)
 {
-if (s->sr && (s->cr & CR_OCIEN)) {
+if (s->sr && (s->cr & CR_OCIEN) && (s->cr & CR_EN)) {
 qemu_irq_raise(s->irq);
 } else {
 qemu_irq_lower(s->irq);
 }
 }
 
-static void set_timerp_freq(IMXTimerPState *s)
+static void imx_epit_set_freq(IMXEPITState *s)
 {
-unsigned clksrc;
-unsigned prescaler;
+uint32_t clksrc;
+uint32_t prescaler;
 uint32_t freq;
 
 clksrc = extract32(s->cr, CR_CLKSRC_SHIFT, 2);
 prescaler = 1 + extract32(s->cr, CR_PRESCALE_SHIFT, 12);
 
-freq = imx_clock_frequency(s->ccm, imx_timerp_clocks[clksrc]) / prescaler;
+freq = imx_clock_frequency(s->ccm, imx_epit_clocks[clksrc]) / prescaler;
 
 s->freq = freq;
+
 DPRINTF("Setting ptimer frequency to %u\n", freq);
 
 if (freq) {
@@ -119,9 +145,9 @@ static void set_timerp_freq(IMXTimerPState *s)
 }
 }
 
-static void imx_timerp_reset(DeviceState *dev)
+static void imx_epit_reset(DeviceState *dev)
 {
-IMXTimerPState *s = container_of(dev, IMXTimerPState, busdev.qdev);
+IMXEPITState *s = IMX_EPIT(dev);
 
 /*
  * Soft reset doesn't touch some bits; hard reset clears them
@@ -135,7 +161,7 @@ static void imx_timerp_reset(DeviceState *dev)
 ptimer_stop(s->timer_cmp);
 ptimer_stop(s->timer_reload);
 /* compute new frequency */
-set_timerp_freq(s);
+imx_epit_set_freq(s);
 /* init both timers to TIMER_MAX */
 ptimer_set_limit(s->timer_cmp, TIMER_MAX, 1);
 ptimer_set_limit(s->timer_reload, TIMER_MAX, 1);
@@ -145,52 +171,56 @@ static void imx_timerp_reset(DeviceState *dev)
 }
 }
 
-static uint32_t imx_timerp_update_counts(IMXTimerPState *s)
+static uint32_t imx_epit_update_count(IMXEPITState *s)
 {
  s->cnt = ptimer_get_count(s->timer_reload);
 
  return s->cnt;
 }
 
-static uint64_t imx_timerp_read(void *opaque, hwaddr offset,
-unsigned size)
+static uint64_t imx_epit_read(void *opaque, hwaddr offset, unsigned size)
 {
-IMXTimerPState *s = (IMXTimerPState *)opaque;
+IMXEPITState *s = IMX_EPIT(opaque);
+uint32_t reg_value = 0;
+uint32_t reg = offset >> 2;
 
-DPRINTF("p-read(offset=%x)", (unsigned int)(offset >> 2));
-switch (offset >> 2) {
+switch (reg) {
 case 0: /* Control Register */
-DPRINTF("cr %x\n", s->cr);
-return s->cr;
+reg_value = s->cr;

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Anthony Liguori]

"Michael S. Tsirkin"  writes:

> On Wed, May 29, 2013 at 08:05:29AM -0500, Anthony Liguori wrote:
>> Rusty Russell  writes:
>> 
>> > Anthony Liguori  writes:
>> >> The headers say they are BSD licensed... but they include a GPLv2+
>> >> header.  Doesn't make a lot of sense, does it?
>> >
>> > It makes perfect sense: you're overthinking it.  It just means that
>> > copying the BSD headers outside Linux is encouraged.
>> 
>> Copying by hand and modifying.  This patch series attempts to do it
>> automatically within QEMU.
>> 
>> > And it's clearly nonsensical to claim the GPL on kernel headers means
>> > that userspace needs to be GPL.  So please ignore this licensing
>> > red-herring.
>> 
>> You're missing context, I suspect.  This series is trying to
>> automatically copy the headers from Linux.  We currently have a manually
>> copied version.
>> 
>> The headers are not currently well suited for automatic copying because
>> (1) they use kernel types (2) they pull in dependencies from throughout
>> the kernel.
>> 
>> This discussion comes down to whether we want to make it easier to
>> automatically copy the headers or do we maintain the status quo and
>> require manual munging to pull in the headers.
>> 
>> Regards,
>> 
>> Anthony Liguori
>
> Okay, what if I
>
> 1. add a stub if_ether.h with a couple of macros we want
> 2. replace the types during copying
>
> Would this address all concerns?

If Rusty doesn't like the idea of making the headers usable directly,
then I don't object to having stubs/scripts to sanitize them in QEMU.

Regards,

Anthony Liguori

>
>> >
>> > And we'll bikeshed the headers in the standard when we have to :)  They
>> > certainly don't need to be cut&paste into the kernel sources.
>> >
>> > Cheers,
>> > Rusty.

Re: [Qemu-devel] QEMU ARM Cortex-A9 emulation boards

[Peter Maydell]

On 29 May 2013 15:24, Erlon Cruz  wrote:
> So, this hardware we intend to emulate doesn't need to use
> any specific SoC.

This doesn't make sense. If it's hardware it must be using
*some* SoC or system board or PCI interface or similar. It
doesn't just float around in a vacuum.

> The only
> requirement is that it must use an Arm Cortex A9 core. Is
> the Cortex-A9 core fully implemented in QEMU?

More or less, yes (we have some notable missing bits like
TrustZone support but typically they are not a problem).

> My first idea was to use the xilinx board (may realview-pbx-a9
> or vexpress-a9) because it already uses the Arm Cortex A9
> processor

These are all actual models of actual hardware -- is the
device you want to emulate present on the real boards?

> but Im not sure if they supports graphical display. Do they?

the realview and vexpress boards do. Don't know about xilinx.

> Then, I thought that we could write an OMAP4 implementation
> based on the already existing OMAP3 SoC

An OMAP4 emulation would be a colossal undertaking (probably
about 10,000 lines of code). It would be a project all by
itself.

> May be it would be possible to use OMAP3 just with a few
> tweaks so we could pass a cortex-A9 in spite of the actual
> cores, is that possible?

No, because the OMAP3 is not an A9 SoC. (Also, the OMAP3
support is not yet in upstream QEMU).

thanks
-- PMM

Re: [Qemu-devel] snabbswitch integration with QEMU for userspace ethernet I/O

[Michael S. Tsirkin]

On Wed, May 29, 2013 at 04:21:43PM +0200, Stefan Hajnoczi wrote:
> On Wed, May 29, 2013 at 12:08:59PM +0300, Michael S. Tsirkin wrote:
> > On Wed, May 29, 2013 at 09:49:29AM +0200, Stefan Hajnoczi wrote:
> > > On Tue, May 28, 2013 at 08:17:42PM +0300, Michael S. Tsirkin wrote:
> > > > On Tue, May 28, 2013 at 12:00:38PM -0500, Anthony Liguori wrote:
> > > > > Julian Stecklina  writes:
> > > > > 
> > > > > > On 05/28/2013 12:10 PM, Luke Gorrie wrote:
> > > > > >> On 27 May 2013 11:34, Stefan Hajnoczi  > > > > >> > wrote:
> > > > > >> 
> > > > > >> vhost_net is about connecting the a virtio-net speaking 
> > > > > >> process to a
> > > > > >> tun-like device.  The problem you are trying to solve is 
> > > > > >> connecting a
> > > > > >> virtio-net speaking process to Snabb Switch.
> > > > > >> 
> > > > > >> 
> > > > > >> Yep!
> > > > > >
> > > > > > Since I am on a similar path as Luke, let me share another idea.
> > > > > >
> > > > > > What about extending qemu in a way to allow PCI device models to be
> > > > > > implemented in another process.
> > > > > 
> > > > > We aren't going to support any interface that enables out of tree
> > > > > devices.  This is just plugins in a different form with even more
> > > > > downsides.  You cannot easily keep track of dirty info, the guest
> > > > > physical address translation to host is difficult to keep in sync
> > > > > (imagine the complexity of memory hotplug).
> > > > > 
> > > > > Basically, it's easy to hack up but extremely hard to do something 
> > > > > that
> > > > > works correctly overall.
> > > > > 
> > > > > There isn't a compelling reason to implement something like this other
> > > > > than avoiding getting code into QEMU.  Best to just submit your device
> > > > > to QEMU for inclusion.
> > > > > 
> > > > > If you want to avoid copying in a vswitch, better to use something 
> > > > > like
> > > > > vmsplice as I outlined in another thread.
> > > > > 
> > > > > > This is not as hard as it may sound.
> > > > > > qemu would open a domain socket to this process and map VM memory 
> > > > > > over
> > > > > > to the other side. This can be accomplished by having file 
> > > > > > descriptors
> > > > > > in qemu to VM memory (reusing -mem-path code) and passing those 
> > > > > > over the
> > > > > > domain socket. The other side can then just mmap them. The socket 
> > > > > > would
> > > > > > also be used for configuration and I/O by the guest on the PCI
> > > > > > I/O/memory regions. You could also use this to do IRQs or use 
> > > > > > eventfds,
> > > > > > whatever works better.
> > > > > >
> > > > > > To have a zero copy userspace switch, the switch would offer 
> > > > > > virtio-net
> > > > > > devices to any qemu that wants to connect to it and implement the
> > > > > > complete device logic itself. Since it has access to all guest 
> > > > > > memory,
> > > > > > it can just do memcpy for packet data. Of course, this only works 
> > > > > > for
> > > > > > 64-bit systems, because you need vast amounts of virtual address 
> > > > > > space.
> > > > > > In my experience, doing this in userspace is _way less painful_.
> > > > > >
> > > > > > If you can get away with polling in the switch the overhead of 
> > > > > > doing all
> > > > > > this in userspace is zero. And as long as you can rate-limit 
> > > > > > explicit
> > > > > > notifications over the socket even that overhead should be okay.
> > > > > >
> > > > > > Opinions?
> > > > > 
> > > > > I don't see any compelling reason to do something like this.  It's
> > > > > jumping through a tremendous number of hoops to avoid putting code 
> > > > > that
> > > > > belongs in QEMU in tree.
> > > > > 
> > > > > Regards,
> > > > > 
> > > > > Anthony Liguori
> > > > > 
> > > > > >
> > > > > > Julian
> > > > 
> > > > OTOH an in-tree device that runs in a separate process would
> > > > be useful e.g. for security.
> > > > For example, we could limit a virtio-net device process
> > > > to only access tap and vhost files.
> > > 
> > > For tap or vhost files only this is good for security.  I'm not sure it
> > > has many advantages over a QEMU process under SELinux though.
> > 
> > At the moment SELinux necessarily gives QEMU rights to
> > e.g. access the filesystem.
> > This process would only get access to tap and vhost.
> > 
> > We can also run it as a different user.
> > Defence in depth.
> > 
> > We can also limit e.g. the CPU of this process aggressively
> > (as it's not doing anything on data path).
> > 
> > I could go on.
> > 
> > And it's really easy too, until you want to use it in production,
> > at which point you need to cover lots of
> > nasty details like hotplug and migration.
> 
> I think there are diminishing returns.  Once QEMU is isolated so it
> cannot open arbitrary files, just has access to the resources granted by
> the management tool on startup, etc then I'm not sure it's worth the
> complexity and performance-cost of splitting the model

Re: [Qemu-devel] [PATCH v2 3/3] xen_machine_pv: do not create a dummy CPU in machine->init

[Igor Mammedov]

On Wed, 29 May 2013 14:29:51 +0200
Paolo Bonzini  wrote:

> Il 29/05/2013 14:11, Andreas Färber ha scritto:
> >> xen_machine_pv uses cpu_x86_init, therefore it has been broken.
> >>
> >> This patch fixes the problem by removing the dummy CPU creation
> >> altogether from xen_init_pv, relying on the fact that QEMU can now cope
> >> with a machine without an emulated CPU.
> >>
> >> This fix should be backported to QEMU 1.5.
> >>
> >> Signed-off-by: Stefano Stabellini 
> >> CC: imamm...@redhat.com
> >> CC: qemu-sta...@nongnu.org
> > 
> > Change looks okay,
> > 
> > Reviewed-by: Andreas Färber 
> > 
> > But for the future please avoid "this patch" in the commit message
> > (because later on it's a "commit", not a patch) and also please put
> > additional notices such as for backporting below the --- line.
> 
> I read it as a warning to backporters that the patch, even though it may
> apply, was not tested and may even be wrong in 1.4.
it only needs to be backported to 1.5, 1.4 is not affected.

> 
> Paolo
> 

Re: [Qemu-devel] snabbswitch integration with QEMU for userspace ethernet I/O

[Stefan Hajnoczi]

On Wed, May 29, 2013 at 02:32:50PM +0200, Julian Stecklina wrote:
> On 05/28/2013 07:00 PM, Anthony Liguori wrote:
> > We aren't going to support any interface that enables out of tree
> > devices.  This is just plugins in a different form with even more
> > downsides.  You cannot easily keep track of dirty info, the guest
> > physical address translation to host is difficult to keep in sync
> > (imagine the complexity of memory hotplug).
> 
> Is there a document describing the current qemu VM migration process,
> especially the dirty page tracking, except the code?
> 
> As a side note: The downsides of a naive approach are about that of PCI
> passtrough devices with the opportunity to fix them later on. That being
> said, I can live with this not being included in mainline qemu.

Asking for documentation and in the next paragraph stating you don't
mind keeping patches out-of-tree...

The QEMU community exists because people are willing to contribute.  If
you intend to only "take" and not "give", then you'll find that people
gradually stop responding to your emails.

Stefan

Re: [Qemu-devel] [PATCH] target-i386: Disable CPUID_EXT_MONITOR when KVM is enabled

[Eduardo Habkost]

(CCing libvirt people)

On Tue, May 28, 2013 at 06:48:52PM +0200, Andreas Färber wrote:
> Am 28.05.2013 18:46, schrieb Paolo Bonzini:
> > Il 28/05/2013 18:34, Bandan Das ha scritto:
> >> Eduardo Habkost  writes:
> >>
> >>> On Mon, May 27, 2013 at 02:21:36PM +0200, Paolo Bonzini wrote:
>  Il 27/05/2013 14:09, Eduardo Habkost ha scritto:
> > On Sat, May 25, 2013 at 08:25:49AM +0200, Paolo Bonzini wrote:
> >> Il 25/05/2013 03:21, Bandan Das ha scritto:
> >>> There is one user-visible effect: "-cpu ...,enforce" will stop failing
> >>> because of missing KVM support for CPUID_EXT_MONITOR. But that's 
> >>> exactly
> >>> the point: there's no point in having CPU model definitions that would
> >>> never work as-is with neither TCG or KVM. This patch is changing the
> >>> meaning of (e.g.) "-machine ...,accel=kvm -cpu Opteron_G3" to match 
> >>> what
> >>> was already happening in practice.
> >>
> >> But then -cpu Opteron_G3 does not match a "real" Opteron G3.  Is it
> >> worth it?
> >
> > No models match a "real" CPU this way, because neither TCG or KVM
> > support all features supported by a real CPU. I ask the opposite
> > question: is it worth maintaining an "accurate" CPU model definition
> > that would never work without feature-bit tweaking in the command-line?
> 
>  It would work with TCG.  Changing TCG to KVM should not change hardware
>  if you use "-cpu ...,enforce", so it is right that it fails when
>  starting with KVM.
> 
> >>>
> >>> Changing between KVM and TCG _does_ change hardware, today (with or
> >>> without check/enforce). All CPU models on TCG have features not
> >>> supported by TCG automatically removed. See the "if (!kvm_enabled())"
> >>> block at x86_cpu_realizefn().
> >>
> >> Yes, this is exactly why I was inclined to remove the monitor flag. 
> >> We already have uses of kvm_enabled() to set (or remove) kvm specific 
> >> stuff,
> >> and this change is no different.
> > 
> > Do any of these affect something that is part of x86_def_t?
> 
> The vendor comes to mind.

I believe we can still consider the "vendor" field a special one: if
other components care about the TCG/KVM difference regarding the
"vendor" field, they can simply set "vendor" explicitly on the
command-line.

> >> I can see Paolo's point though, having 
> >> a common definition probably makes sense too.
> > 

Paolo is convincing me that keeping the rest of the features exactly the
same on TCG and KVM modes (and making check/enforce work for TCG as
well) would simplify the logic a lot. This will add a little extra work
for libvirt, that will probably need to use "-cpu Opteron_G3,-monitor"
once it implements enforce-mode (to make sure the results really match
existing libvirt assumptions about the Opteron_G* models), but it is
probably worth it.

I will give it a try and send a proposal soon.


> >>> (That's why I argue that we need separate classes/names for TCG and KVM
> >>> modes. Otherwise our predefined models get less useful as they will
> >>> require low-level feature-bit fiddling on the libvirt side to make them
> >>> work as expected.)
> >>
> >> Agreed. From a user's perspective, I think the more a CPU model "just 
> >> works",
> >> whether it's KVM or TCG, the better.
> > 
> > Yes, that's right.  But I think extending the same expectation to "-cpu
> > ...,enforce" is not necessary, and perhaps even wrong for "-cpu
> > ...,check" since it's only a warning rather than a fatal error.
> > 
> > Paolo
> > 
> 
> 
> -- 
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

-- 
Eduardo

Re: [Qemu-devel] snabbswitch integration with QEMU for userspace ethernet I/O

[Stefan Hajnoczi]

On Wed, May 29, 2013 at 12:08:59PM +0300, Michael S. Tsirkin wrote:
> On Wed, May 29, 2013 at 09:49:29AM +0200, Stefan Hajnoczi wrote:
> > On Tue, May 28, 2013 at 08:17:42PM +0300, Michael S. Tsirkin wrote:
> > > On Tue, May 28, 2013 at 12:00:38PM -0500, Anthony Liguori wrote:
> > > > Julian Stecklina  writes:
> > > > 
> > > > > On 05/28/2013 12:10 PM, Luke Gorrie wrote:
> > > > >> On 27 May 2013 11:34, Stefan Hajnoczi  > > > >> > wrote:
> > > > >> 
> > > > >> vhost_net is about connecting the a virtio-net speaking process 
> > > > >> to a
> > > > >> tun-like device.  The problem you are trying to solve is 
> > > > >> connecting a
> > > > >> virtio-net speaking process to Snabb Switch.
> > > > >> 
> > > > >> 
> > > > >> Yep!
> > > > >
> > > > > Since I am on a similar path as Luke, let me share another idea.
> > > > >
> > > > > What about extending qemu in a way to allow PCI device models to be
> > > > > implemented in another process.
> > > > 
> > > > We aren't going to support any interface that enables out of tree
> > > > devices.  This is just plugins in a different form with even more
> > > > downsides.  You cannot easily keep track of dirty info, the guest
> > > > physical address translation to host is difficult to keep in sync
> > > > (imagine the complexity of memory hotplug).
> > > > 
> > > > Basically, it's easy to hack up but extremely hard to do something that
> > > > works correctly overall.
> > > > 
> > > > There isn't a compelling reason to implement something like this other
> > > > than avoiding getting code into QEMU.  Best to just submit your device
> > > > to QEMU for inclusion.
> > > > 
> > > > If you want to avoid copying in a vswitch, better to use something like
> > > > vmsplice as I outlined in another thread.
> > > > 
> > > > > This is not as hard as it may sound.
> > > > > qemu would open a domain socket to this process and map VM memory over
> > > > > to the other side. This can be accomplished by having file descriptors
> > > > > in qemu to VM memory (reusing -mem-path code) and passing those over 
> > > > > the
> > > > > domain socket. The other side can then just mmap them. The socket 
> > > > > would
> > > > > also be used for configuration and I/O by the guest on the PCI
> > > > > I/O/memory regions. You could also use this to do IRQs or use 
> > > > > eventfds,
> > > > > whatever works better.
> > > > >
> > > > > To have a zero copy userspace switch, the switch would offer 
> > > > > virtio-net
> > > > > devices to any qemu that wants to connect to it and implement the
> > > > > complete device logic itself. Since it has access to all guest memory,
> > > > > it can just do memcpy for packet data. Of course, this only works for
> > > > > 64-bit systems, because you need vast amounts of virtual address 
> > > > > space.
> > > > > In my experience, doing this in userspace is _way less painful_.
> > > > >
> > > > > If you can get away with polling in the switch the overhead of doing 
> > > > > all
> > > > > this in userspace is zero. And as long as you can rate-limit explicit
> > > > > notifications over the socket even that overhead should be okay.
> > > > >
> > > > > Opinions?
> > > > 
> > > > I don't see any compelling reason to do something like this.  It's
> > > > jumping through a tremendous number of hoops to avoid putting code that
> > > > belongs in QEMU in tree.
> > > > 
> > > > Regards,
> > > > 
> > > > Anthony Liguori
> > > > 
> > > > >
> > > > > Julian
> > > 
> > > OTOH an in-tree device that runs in a separate process would
> > > be useful e.g. for security.
> > > For example, we could limit a virtio-net device process
> > > to only access tap and vhost files.
> > 
> > For tap or vhost files only this is good for security.  I'm not sure it
> > has many advantages over a QEMU process under SELinux though.
> 
> At the moment SELinux necessarily gives QEMU rights to
> e.g. access the filesystem.
> This process would only get access to tap and vhost.
> 
> We can also run it as a different user.
> Defence in depth.
> 
> We can also limit e.g. the CPU of this process aggressively
> (as it's not doing anything on data path).
> 
> I could go on.
> 
> And it's really easy too, until you want to use it in production,
> at which point you need to cover lots of
> nasty details like hotplug and migration.

I think there are diminishing returns.  Once QEMU is isolated so it
cannot open arbitrary files, just has access to the resources granted by
the management tool on startup, etc then I'm not sure it's worth the
complexity and performance-cost of splitting the model up into even
smaller pieces.  IMO there isn't a trust boundary that's worth isolating
here (compare to sshd privilege separation where separate uids really
make sense and are necessary, with QEMU having multiple uids that lack
capabilities to do much doesn't win much over the SELinux setup).

> > Obviously when the switch process has shared memory access to multiple
> > gue