date:20170116

On Mon, Jan 16, 2017 at 03:47:08PM +0800, Jason Wang wrote:
> 
> 
> On 2017年01月16日 15:31, Peter Xu wrote:
> >On Fri, Jan 13, 2017 at 05:26:06PM +0800, Jason Wang wrote:
> >>
> >>On 2017年01月13日 11:06, Peter Xu wrote:
> >>>The default replay() don't work for VT-d since vt-d will have a huge
> >>>default memory region which covers address range 0-(2^64-1). This will
> >>>normally bring a dead loop when guest starts.
> >>I think it just takes too much time instead of dead loop?
> >Hmm, I can touch the commit message above to make it more precise.
> >
> >>>The solution is simple - we don't walk over all the regions. Instead, we
> >>>jump over the regions when we found that the page directories are empty.
> >>>It'll greatly reduce the time to walk the whole region.
> >>Yes, the problem is memory_region_is_iommu_reply() not smart because:
> >>
> >>- It doesn't understand large page
> >>- try go over all possible iova
> >>
> >>So I'm thinking to introduce something like iommu_ops->iova_iterate() which
> >>
> >>1) accept an start iova and return the next exist map
> >>2) understand large page
> >>3) skip unmapped iova
> >Though I haven't tested with huge pages yet, but this patch should
> >both solve above issue? I don't know whether you went over the page
> >walk logic - it should both support huge page, and it will skip
> >unmapped iova range (at least that's my goal to have this patch). In
> >that case, looks like this patch is solving the same problem? :)
> >(though without introducing iova_iterate() interface)
> >
> >Please correct me if I misunderstood it.
> 
> Kind of :) I'm fine with this patch, but just want:
> 
> - reuse most of the codes in the patch
> - current memory_region_iommu_replay() logic
> 
> So what I'm suggesting is a just slight change of API which can let caller
> decide it need to do with each range of iova. So it could be reused for
> other things except for replaying.
> 
> But if you like to keep this patch as is, I don't object it.

I see. Then I can understand your mean here. I had the same thought
before, that's why I exposed the vtd_page_walk with a hook. If you
check the page_walk function comment:

/**
 * vtd_page_walk - walk specific IOVA range, and call the hook
 *
 * @ce: context entry to walk upon
 * @start: IOVA address to start the walk
 * @end: IOVA range end address (start <= addr < end)
 * @hook_fn: the hook that to be called for each detected area
 * @private: private data for the hook function
 */

So I didn't implement the notification in page_walk at all - but in
the hook_fn. If any caller that is interested in doing something else
rather than the notification, we can just simply export the page walk
interface and provide his/her own "hook_fn", then it'll be triggered
for each valid page (no matter a huge/small one).

If we can have a more general interface in the future - no matter
whether we call it iova_iterate() or something else (I'll prefer the
hooker way to do it, so maybe a common page walker with a hook
function), we can do it simply (at least for Intel platform) based on
this vtd_page_walk thing.

Thanks,

-- peterx

Re: [Qemu-devel] [PATCH RFC v3 13/14] intel_iommu: allow dynamic switch of IOMMU region




On 2017年01月16日 15:50, Peter Xu wrote:

On Mon, Jan 16, 2017 at 02:20:31PM +0800, Jason Wang wrote:

[...]


diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index fd75112..2596f11 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -1343,9 +1343,49 @@ static void vtd_handle_gcmd_sirtp(IntelIOMMUState *s)
  vtd_set_clear_mask_long(s, DMAR_GSTS_REG, 0, VTD_GSTS_IRTPS);
  }
+static void vtd_switch_address_space(VTDAddressSpace *as, bool iommu_enabled)

Looks like you can check s->dmar_enabled here?

Yes, we need to check old state in case we don't need a switch at all.
Actually I checked it...



I mean is there a chance that iommu_enabled( better name should be 
dmar_enabled) is not equal to s->dmar_enabled? Looks not.


vtd_handle_gcmd_te() did:

...
if (en) {
s->dmar_enabled = true;
/* Ok - report back to driver */
vtd_set_clear_mask_long(s, DMAR_GSTS_REG, 0, VTD_GSTS_TES);
} else {
s->dmar_enabled = false;
...

You can vtd_switch_address_space_all(s, en) after this which will call 
this function. And another caller like you've pointed out has already 
call this through s->dmar_enabled. So en here is always s->dmar_enalbed?


Thanks

Re: [Qemu-devel] [PATCH RFC v3 12/14] intel_iommu: do replay when context invalidate

On Mon, Jan 16, 2017 at 03:52:10PM +0800, Jason Wang wrote:
> 
> 
> On 2017年01月16日 15:43, Peter Xu wrote:
> >On Mon, Jan 16, 2017 at 01:53:54PM +0800, Jason Wang wrote:
> >>
> >>On 2017年01月13日 11:06, Peter Xu wrote:
> >>>Before this one we only invalidate context cache when we receive context
> >>>entry invalidations. However it's possible that the invalidation also
> >>>contains a domain switch (only if cache-mode is enabled for vIOMMU).
> >>So let's check for CM before replaying?
> >When CM is not set, there should have no device needs
> >IOMMU_NOTIFIER_MAP notifies. So IMHO it won't hurt if we replay here
> >(so the notifier_list will only contain UNMAP notifiers at most, and
> >sending UNMAP to those devices should not affect them at all).
> >
> >If we check CM before replay, it'll be faster when guest change iommu
> >domain for a specific device. But after all this kind of operation is
> >extremely rare, while if we check CM bit, we have a "assumption" in
> >the code that MAP is depending on CM. In that case, to make the codes
> >cleaner, I'd slightly prefer not check it here. How do you think?
> 
> Ok, I think maybe it's better to add a comment here.

Will do it. Thanks!

-- peterx

Re: [Qemu-devel] [PATCH RFC v3 11/14] intel_iommu: provide its own replay() callback




On 2017年01月16日 15:59, Peter Xu wrote:

On Mon, Jan 16, 2017 at 03:47:08PM +0800, Jason Wang wrote:


On 2017年01月16日 15:31, Peter Xu wrote:

On Fri, Jan 13, 2017 at 05:26:06PM +0800, Jason Wang wrote:

On 2017年01月13日 11:06, Peter Xu wrote:

The default replay() don't work for VT-d since vt-d will have a huge
default memory region which covers address range 0-(2^64-1). This will
normally bring a dead loop when guest starts.

I think it just takes too much time instead of dead loop?

Hmm, I can touch the commit message above to make it more precise.


The solution is simple - we don't walk over all the regions. Instead, we
jump over the regions when we found that the page directories are empty.
It'll greatly reduce the time to walk the whole region.

Yes, the problem is memory_region_is_iommu_reply() not smart because:

- It doesn't understand large page
- try go over all possible iova

So I'm thinking to introduce something like iommu_ops->iova_iterate() which

1) accept an start iova and return the next exist map
2) understand large page
3) skip unmapped iova

Though I haven't tested with huge pages yet, but this patch should
both solve above issue? I don't know whether you went over the page
walk logic - it should both support huge page, and it will skip
unmapped iova range (at least that's my goal to have this patch). In
that case, looks like this patch is solving the same problem? :)
(though without introducing iova_iterate() interface)

Please correct me if I misunderstood it.

Kind of :) I'm fine with this patch, but just want:

- reuse most of the codes in the patch
- current memory_region_iommu_replay() logic

So what I'm suggesting is a just slight change of API which can let caller
decide it need to do with each range of iova. So it could be reused for
other things except for replaying.

But if you like to keep this patch as is, I don't object it.

I see. Then I can understand your mean here. I had the same thought
before, that's why I exposed the vtd_page_walk with a hook. If you
check the page_walk function comment:

/**
  * vtd_page_walk - walk specific IOVA range, and call the hook
  *
  * @ce: context entry to walk upon
  * @start: IOVA address to start the walk
  * @end: IOVA range end address (start <= addr < end)
  * @hook_fn: the hook that to be called for each detected area
  * @private: private data for the hook function
  */

So I didn't implement the notification in page_walk at all - but in
the hook_fn. If any caller that is interested in doing something else
rather than the notification, we can just simply export the page walk
interface and provide his/her own "hook_fn", then it'll be triggered
for each valid page (no matter a huge/small one).

If we can have a more general interface in the future - no matter
whether we call it iova_iterate() or something else (I'll prefer the
hooker way to do it, so maybe a common page walker with a hook
function), we can do it simply (at least for Intel platform) based on
this vtd_page_walk thing.

Thanks,

-- peterx


Yes but the problem is hook_fn is only visible inside intel iommu code.

Thanks

Re: [Qemu-devel] [PATCH RFC v3 11/14] intel_iommu: provide its own replay() callback

On Mon, Jan 16, 2017 at 04:03:22PM +0800, Jason Wang wrote:

[...]

> >>>Though I haven't tested with huge pages yet, but this patch should
> >>>both solve above issue? I don't know whether you went over the page
> >>>walk logic - it should both support huge page, and it will skip
> >>>unmapped iova range (at least that's my goal to have this patch). In
> >>>that case, looks like this patch is solving the same problem? :)
> >>>(though without introducing iova_iterate() interface)
> >>>
> >>>Please correct me if I misunderstood it.
> >>Kind of :) I'm fine with this patch, but just want:
> >>
> >>- reuse most of the codes in the patch
> >>- current memory_region_iommu_replay() logic
> >>
> >>So what I'm suggesting is a just slight change of API which can let caller
> >>decide it need to do with each range of iova. So it could be reused for
> >>other things except for replaying.
> >>
> >>But if you like to keep this patch as is, I don't object it.
> >I see. Then I can understand your mean here. I had the same thought
> >before, that's why I exposed the vtd_page_walk with a hook. If you
> >check the page_walk function comment:
> >
> >/**
> >  * vtd_page_walk - walk specific IOVA range, and call the hook
> >  *
> >  * @ce: context entry to walk upon
> >  * @start: IOVA address to start the walk
> >  * @end: IOVA range end address (start <= addr < end)
> >  * @hook_fn: the hook that to be called for each detected area
> >  * @private: private data for the hook function
> >  */
> >
> >So I didn't implement the notification in page_walk at all - but in
> >the hook_fn. If any caller that is interested in doing something else
> >rather than the notification, we can just simply export the page walk
> >interface and provide his/her own "hook_fn", then it'll be triggered
> >for each valid page (no matter a huge/small one).
> >
> >If we can have a more general interface in the future - no matter
> >whether we call it iova_iterate() or something else (I'll prefer the
> >hooker way to do it, so maybe a common page walker with a hook
> >function), we can do it simply (at least for Intel platform) based on
> >this vtd_page_walk thing.
> >
> >Thanks,
> >
> >-- peterx
> 
> Yes but the problem is hook_fn is only visible inside intel iommu code.

Right.

Btw, do we have existing issue that can leverage this interface
besides replay?

-- peterx

Re: [Qemu-devel] [PULL 000/180] QAPI patches for 2017-01-13

2017-01-16 Thread Markus Armbruster

Eric Blake  writes:

> On 01/13/2017 10:44 AM, Markus Armbruster wrote:
>> This is Marc-André's "[PATCH v8 00/21] qapi doc generation (whole
>> version, squashed)" with a few commit messages tweaked, and "[PATCH v8
>> 14/21] (SQUASHED) move doc to schema" unsquashed into 161 patches.
>> 
>> We did all the respins with in this squashed form to reduce noise.
>> However, since the unsquashed form is better suited for review, and
>> probably nicer if we have to revisit this part of the work down the
>> road, I'm proposing to merge this unsquashed.
>> 
>> If you want me to post the unsquashed patches, I'm happy to redo this
>> pull request.
>> 
>> If you'd rather pull the squashed version, likewise.
>> 
>> I'm afraid this is a bit of a doc conflict magnet.  The sooner we can
>> get it in, the easier for Marc-André and me.
>
> Indeed - there's already a merge conflict with commit e1ff3c6, which
> landed between the time you created the pull request and now.
>
> Also, in trying to merge your branch locally, I get a rejection message
> from my git hooks:
>
> $ git commit
> tests/qapi-schema/comments.out:7: new blank line at EOF.
> tests/qapi-schema/event-case.out:8: new blank line at EOF.
> tests/qapi-schema/ident-with-escape.out:10: new blank line at EOF.
> tests/qapi-schema/include-relpath.out:7: new blank line at EOF.
> tests/qapi-schema/include-repetition.out:7: new blank line at EOF.
> tests/qapi-schema/include-simple.out:7: new blank line at EOF.
> tests/qapi-schema/indented-expr.out:13: new blank line at EOF.
> tests/qapi-schema/qapi-schema-test.out:446: new blank line at EOF.
>
> Worth respinning to fix those issues?

Since I have to respin anyway, why not.

>>   qmp-commands: move 'query-memdev' doc to schema
>
> This one is the conflict with current master.

Thanks for the heads-up, v2 coming.

Re: [Qemu-devel] [PATCH RFC v3 13/14] intel_iommu: allow dynamic switch of IOMMU region

On Mon, Jan 16, 2017 at 04:01:00PM +0800, Jason Wang wrote:
> 
> 
> On 2017年01月16日 15:50, Peter Xu wrote:
> >On Mon, Jan 16, 2017 at 02:20:31PM +0800, Jason Wang wrote:
> >
> >[...]
> >
> >>>diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> >>>index fd75112..2596f11 100644
> >>>--- a/hw/i386/intel_iommu.c
> >>>+++ b/hw/i386/intel_iommu.c
> >>>@@ -1343,9 +1343,49 @@ static void vtd_handle_gcmd_sirtp(IntelIOMMUState 
> >>>*s)
> >>>  vtd_set_clear_mask_long(s, DMAR_GSTS_REG, 0, VTD_GSTS_IRTPS);
> >>>  }
> >>>+static void vtd_switch_address_space(VTDAddressSpace *as, bool 
> >>>iommu_enabled)
> >>Looks like you can check s->dmar_enabled here?
> >Yes, we need to check old state in case we don't need a switch at all.
> >Actually I checked it...
> >
> 
> I mean is there a chance that iommu_enabled( better name should be
> dmar_enabled) is not equal to s->dmar_enabled? Looks not.
> 
> vtd_handle_gcmd_te() did:
> 
> ...
> if (en) {
> s->dmar_enabled = true;
> /* Ok - report back to driver */
> vtd_set_clear_mask_long(s, DMAR_GSTS_REG, 0, VTD_GSTS_TES);
> } else {
> s->dmar_enabled = false;
> ...
> 
> You can vtd_switch_address_space_all(s, en) after this which will call this
> function. And another caller like you've pointed out has already call this
> through s->dmar_enabled. So en here is always s->dmar_enalbed?

Hmm, yes...

(I would still prefer keeping this parameter for readablility.
 Though, I prefer your suggestion to rename it to dmar_enabled)

-- peterx

Re: [Qemu-devel] [PATCH RFC v3 12/14] intel_iommu: do replay when context invalidate

On Mon, Jan 16, 2017 at 03:52:10PM +0800, Jason Wang wrote:
> 
> 
> On 2017年01月16日 15:43, Peter Xu wrote:
> >On Mon, Jan 16, 2017 at 01:53:54PM +0800, Jason Wang wrote:
> >>
> >>On 2017年01月13日 11:06, Peter Xu wrote:
> >>>Before this one we only invalidate context cache when we receive context
> >>>entry invalidations. However it's possible that the invalidation also
> >>>contains a domain switch (only if cache-mode is enabled for vIOMMU).
> >>So let's check for CM before replaying?
> >When CM is not set, there should have no device needs
> >IOMMU_NOTIFIER_MAP notifies. So IMHO it won't hurt if we replay here
> >(so the notifier_list will only contain UNMAP notifiers at most, and
> >sending UNMAP to those devices should not affect them at all).
> >
> >If we check CM before replay, it'll be faster when guest change iommu
> >domain for a specific device. But after all this kind of operation is
> >extremely rare, while if we check CM bit, we have a "assumption" in
> >the code that MAP is depending on CM. In that case, to make the codes
> >cleaner, I'd slightly prefer not check it here. How do you think?
> 
> Ok, I think maybe it's better to add a comment here.

How about this?

+/*
+ * So a device is moving out of (or moving into) a
+ * domain, a replay() suites here to notify all the
+ * IOMMU_NOTIFIER_MAP registers about this change.
+ * This won't bring bad even if we have no such
+ * notifier registered - the IOMMU notification
+ * framework will skip MAP notifications if that
+ * happened.
+ */
 memory_region_iommu_replay_all(&vtd_as->iommu);

Thanks,

-- peterx

Re: [Qemu-devel] [PATCH v2 11/11] aspeed/smc: handle dummy bytes when doing fast reads in command mode

2017-01-16 Thread Cédric Le Goater

> I did not notice that this function is also called in writes, isn't it?
> If yes, dummy cycles are used only during reads so probably CTRL_FREADMODE
> needs to be tested.

yes. I can take care of that in a follow up patchset for 
dummy support.
 
Dummies in user mode is a bit painful to implement, as I had 
to snoop into the command flow to catch the fast read op.
Not sure this is the right approach so I kept it for later.


Did you have time to take look at the other patches adding 
Command mode and extending the tests ? I should have addressed
your comments there.

Thanks,

C.

Re: [Qemu-devel] [PATCH RFC v3 11/14] intel_iommu: provide its own replay() callback




On 2017年01月16日 16:06, Peter Xu wrote:

On Mon, Jan 16, 2017 at 04:03:22PM +0800, Jason Wang wrote:

[...]


Though I haven't tested with huge pages yet, but this patch should
both solve above issue? I don't know whether you went over the page
walk logic - it should both support huge page, and it will skip
unmapped iova range (at least that's my goal to have this patch). In
that case, looks like this patch is solving the same problem? :)
(though without introducing iova_iterate() interface)

Please correct me if I misunderstood it.

Kind of :) I'm fine with this patch, but just want:

- reuse most of the codes in the patch
- current memory_region_iommu_replay() logic

So what I'm suggesting is a just slight change of API which can let caller
decide it need to do with each range of iova. So it could be reused for
other things except for replaying.

But if you like to keep this patch as is, I don't object it.

I see. Then I can understand your mean here. I had the same thought
before, that's why I exposed the vtd_page_walk with a hook. If you
check the page_walk function comment:

/**
  * vtd_page_walk - walk specific IOVA range, and call the hook
  *
  * @ce: context entry to walk upon
  * @start: IOVA address to start the walk
  * @end: IOVA range end address (start <= addr < end)
  * @hook_fn: the hook that to be called for each detected area
  * @private: private data for the hook function
  */

So I didn't implement the notification in page_walk at all - but in
the hook_fn. If any caller that is interested in doing something else
rather than the notification, we can just simply export the page walk
interface and provide his/her own "hook_fn", then it'll be triggered
for each valid page (no matter a huge/small one).

If we can have a more general interface in the future - no matter
whether we call it iova_iterate() or something else (I'll prefer the
hooker way to do it, so maybe a common page walker with a hook
function), we can do it simply (at least for Intel platform) based on
this vtd_page_walk thing.

Thanks,

-- peterx

Yes but the problem is hook_fn is only visible inside intel iommu code.

Right.

Btw, do we have existing issue that can leverage this interface
besides replay?

-- peterx


Seems not, so I'm fine with current code, just want to show the 
possibility for it to be reused in the future.


Thanks

Re: [Qemu-devel] [PATCH RFC v3 13/14] intel_iommu: allow dynamic switch of IOMMU region




On 2017年01月16日 16:12, Peter Xu wrote:

On Mon, Jan 16, 2017 at 04:01:00PM +0800, Jason Wang wrote:


On 2017年01月16日 15:50, Peter Xu wrote:

On Mon, Jan 16, 2017 at 02:20:31PM +0800, Jason Wang wrote:

[...]


diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index fd75112..2596f11 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -1343,9 +1343,49 @@ static void vtd_handle_gcmd_sirtp(IntelIOMMUState *s)
  vtd_set_clear_mask_long(s, DMAR_GSTS_REG, 0, VTD_GSTS_IRTPS);
  }
+static void vtd_switch_address_space(VTDAddressSpace *as, bool iommu_enabled)

Looks like you can check s->dmar_enabled here?

Yes, we need to check old state in case we don't need a switch at all.
Actually I checked it...


I mean is there a chance that iommu_enabled( better name should be
dmar_enabled) is not equal to s->dmar_enabled? Looks not.

vtd_handle_gcmd_te() did:

 ...
 if (en) {
 s->dmar_enabled = true;
 /* Ok - report back to driver */
 vtd_set_clear_mask_long(s, DMAR_GSTS_REG, 0, VTD_GSTS_TES);
 } else {
 s->dmar_enabled = false;
 ...

You can vtd_switch_address_space_all(s, en) after this which will call this
function. And another caller like you've pointed out has already call this
through s->dmar_enabled. So en here is always s->dmar_enalbed?

Hmm, yes...

(I would still prefer keeping this parameter for readablility.
  Though, I prefer your suggestion to rename it to dmar_enabled)

-- peterx


I think this does not give more readability :) May I was wrong, let 
leave this for maintainer.


Thanks :)

Re: [Qemu-devel] [PATCH v5 3/4] migration: disallow migrate_add_blocker during migration

2017-01-16 Thread Ashijeet Acharya

On Mon, Jan 16, 2017 at 1:17 AM, Greg Kurz  wrote:
> On Thu, 12 Jan 2017 21:22:33 +0530
> Ashijeet Acharya  wrote:
>
>> If a migration is already in progress and somebody attempts
>> to add a migration blocker, this should rightly fail.
>>
>> Add an errp parameter and a retcode return value to migrate_add_blocker.
>>
>> Signed-off-by: John Snow 
>> Signed-off-by: Ashijeet Acharya 
>> ---
>>  block/qcow.c  |  7 ++-
>>  block/vdi.c   |  7 ++-
>>  block/vhdx.c  | 16 ++--
>>  block/vmdk.c  |  8 +++-
>>  block/vpc.c   | 10 +++---
>>  block/vvfat.c | 20 
>>  hw/9pfs/9p.c  | 31 ---
>>  hw/display/virtio-gpu.c   | 31 ++-
>>  hw/intc/arm_gic_kvm.c | 16 ++--
>>  hw/intc/arm_gicv3_its_kvm.c   | 19 ---
>>  hw/intc/arm_gicv3_kvm.c   | 18 +++---
>>  hw/misc/ivshmem.c | 13 +
>>  hw/scsi/vhost-scsi.c  | 24 ++--
>>  hw/virtio/vhost.c |  7 ++-
>>  include/migration/migration.h |  7 ++-
>>  migration/migration.c | 38 --
>>  stubs/migr-blocker.c  |  3 ++-
>>  target-i386/kvm.c | 15 ---
>>  18 files changed, 208 insertions(+), 82 deletions(-)
>>
>> diff --git a/block/qcow.c b/block/qcow.c
>> index 7540f43..90ebe78 100644
>> --- a/block/qcow.c
>> +++ b/block/qcow.c
>> @@ -104,6 +104,7 @@ static int qcow_open(BlockDriverState *bs, QDict 
>> *options, int flags,
>>  unsigned int len, i, shift;
>>  int ret;
>>  QCowHeader header;
>> +Error *local_err = NULL;
>>
>>  ret = bdrv_pread(bs->file, 0, &header, sizeof(header));
>>  if (ret < 0) {
>> @@ -252,7 +253,11 @@ static int qcow_open(BlockDriverState *bs, QDict 
>> *options, int flags,
>>  error_setg(&s->migration_blocker, "The qcow format used by node '%s' "
>> "does not support live migration",
>> bdrv_get_device_or_node_name(bs));
>> -migrate_add_blocker(s->migration_blocker);
>> +ret = migrate_add_blocker(s->migration_blocker, &local_err);
>> +if (local_err) {
>> +error_propagate(errp, local_err);
>> +goto fail;
>> +}
>>
>>  qemu_co_mutex_init(&s->lock);
>>  return 0;
>> diff --git a/block/vdi.c b/block/vdi.c
>> index 96b78d5..2cb8ef0 100644
>> --- a/block/vdi.c
>> +++ b/block/vdi.c
>> @@ -361,6 +361,7 @@ static int vdi_open(BlockDriverState *bs, QDict 
>> *options, int flags,
>>  VdiHeader header;
>>  size_t bmap_size;
>>  int ret;
>> +Error *local_err = NULL;
>>
>>  logout("\n");
>>
>> @@ -471,7 +472,11 @@ static int vdi_open(BlockDriverState *bs, QDict 
>> *options, int flags,
>>  error_setg(&s->migration_blocker, "The vdi format used by node '%s' "
>> "does not support live migration",
>> bdrv_get_device_or_node_name(bs));
>> -migrate_add_blocker(s->migration_blocker);
>> +ret = migrate_add_blocker(s->migration_blocker, &local_err);
>> +if (local_err) {
>> +error_propagate(errp, local_err);
>> +goto fail_free_bmap;
>> +}
>>
>>  qemu_co_mutex_init(&s->write_lock);
>>
>> diff --git a/block/vhdx.c b/block/vhdx.c
>> index 0ba2f0a..77ced7c 100644
>> --- a/block/vhdx.c
>> +++ b/block/vhdx.c
>> @@ -991,6 +991,16 @@ static int vhdx_open(BlockDriverState *bs, QDict 
>> *options, int flags,
>>  }
>>  }
>>
>> +/* Disable migration when VHDX images are used */
>> +error_setg(&s->migration_blocker, "The vhdx format used by node '%s' "
>> +   "does not support live migration",
>> +   bdrv_get_device_or_node_name(bs));
>> +ret = migrate_add_blocker(s->migration_blocker, &local_err);
>> +if (local_err) {
>> +error_propagate(errp, local_err);
>> +goto fail;
>> +}
>> +
>>  if (flags & BDRV_O_RDWR) {
>>  ret = vhdx_update_headers(bs, s, false, NULL);
>>  if (ret < 0) {
>> @@ -1000,12 +1010,6 @@ static int vhdx_open(BlockDriverState *bs, QDict 
>> *options, int flags,
>>
>>  /* TODO: differencing files */
>>
>> -/* Disable migration when VHDX images are used */
>> -error_setg(&s->migration_blocker, "The vhdx format used by node '%s' "
>> -   "does not support live migration",
>> -   bdrv_get_device_or_node_name(bs));
>> -migrate_add_blocker(s->migration_blocker);
>> -
>>  return 0;
>>  fail:
>>  vhdx_close(bs);
>> diff --git a/block/vmdk.c b/block/vmdk.c
>> index a11c27a..f1d75ae 100644
>> --- a/block/vmdk.c
>> +++ b/block/vmdk.c
>> @@ -941,6 +941,7 @@ static int vmdk_open(BlockDriverState *bs, QDict 
>> *options, int flags,
>>  int ret;
>>  BDRVVmdkState *s = bs->opaque;
>>  uint32_t magic;
>> +Error *local_err = NULL;
>>
>>  buf = vmd

Re: [Qemu-devel] [PULL 10/65] tcg/s390: Expose host facilities to tcg-target.h

2017-01-16 Thread Christian Borntraeger

On 01/13/2017 10:18 AM, Christian Borntraeger wrote:
> On 01/11/2017 03:17 AM, Richard Henderson wrote:
>> This lets us expose facilities to TCG_TARGET_HAS_* defines
>> directly, rather than hiding behind function calls.
>>
>> Signed-off-by: Richard Henderson 
>> ---
>>  tcg/s390/tcg-target.h | 126 
>> --
>>  tcg/s390/tcg-target.inc.c |  74 +++
>>  2 files changed, 96 insertions(+), 104 deletions(-)
> 
> This broke compilation.Seems that you forgot one replacement:
> 
> In file included from /home/cborntra/REPOS/qemu/tcg/tcg.c:253:0:
> /home/cborntra/REPOS/qemu/tcg/s390/tcg-target.inc.c: In function ‘tgen_cmp’:
> /home/cborntra/REPOS/qemu/tcg/s390/tcg-target.inc.c:1096:19: error: 
> ‘facilities’ undeclared (first use in this function)
>  if (!(facilities & FACILITY_EXT_IMM)) {
>^~
> /home/cborntra/REPOS/qemu/tcg/s390/tcg-target.inc.c:1096:19: note: each 
> undeclared identifier is reported only once for each function it appears in
> /home/cborntra/REPOS/qemu/rules.mak:64: recipe for target 'tcg/tcg.o' failed
> make[1]: *** [tcg/tcg.o] Error 1
> Makefile:203: recipe for target 'subdir-s390x-softmmu' failed
> make: *** [subdir-s390x-softmmu] Error 2
> make: Leaving directory '/home/cborntra/REPOS/qemu/build'
> 
> 
> 

Can we get a fix for this? Seems that a simple replacement of facilities -> 
s390_facilities
would do the trick.

Christian

Re: [Qemu-devel] [PATCH RFC v3 12/14] intel_iommu: do replay when context invalidate




On 2017年01月16日 16:18, Peter Xu wrote:

On Mon, Jan 16, 2017 at 03:52:10PM +0800, Jason Wang wrote:


On 2017年01月16日 15:43, Peter Xu wrote:

On Mon, Jan 16, 2017 at 01:53:54PM +0800, Jason Wang wrote:

On 2017年01月13日 11:06, Peter Xu wrote:

Before this one we only invalidate context cache when we receive context
entry invalidations. However it's possible that the invalidation also
contains a domain switch (only if cache-mode is enabled for vIOMMU).

So let's check for CM before replaying?

When CM is not set, there should have no device needs
IOMMU_NOTIFIER_MAP notifies. So IMHO it won't hurt if we replay here
(so the notifier_list will only contain UNMAP notifiers at most, and
sending UNMAP to those devices should not affect them at all).

If we check CM before replay, it'll be faster when guest change iommu
domain for a specific device. But after all this kind of operation is
extremely rare, while if we check CM bit, we have a "assumption" in
the code that MAP is depending on CM. In that case, to make the codes
cleaner, I'd slightly prefer not check it here. How do you think?

Ok, I think maybe it's better to add a comment here.

How about this?

+/*
+ * So a device is moving out of (or moving into) a
+ * domain, a replay() suites here to notify all the
+ * IOMMU_NOTIFIER_MAP registers about this change.
+ * This won't bring bad even if we have no such
+ * notifier registered - the IOMMU notification
+ * framework will skip MAP notifications if that
+ * happened.
+ */
  memory_region_iommu_replay_all(&vtd_as->iommu);

Thanks,

-- peterx


I'm fine with this.

Thanks

Re: [Qemu-devel] [PATCH RFC v3 13/14] intel_iommu: allow dynamic switch of IOMMU region

On Mon, Jan 16, 2017 at 04:25:35PM +0800, Jason Wang wrote:
> 
> 
> On 2017年01月16日 16:12, Peter Xu wrote:
> >On Mon, Jan 16, 2017 at 04:01:00PM +0800, Jason Wang wrote:
> >>
> >>On 2017年01月16日 15:50, Peter Xu wrote:
> >>>On Mon, Jan 16, 2017 at 02:20:31PM +0800, Jason Wang wrote:
> >>>
> >>>[...]
> >>>
> >diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> >index fd75112..2596f11 100644
> >--- a/hw/i386/intel_iommu.c
> >+++ b/hw/i386/intel_iommu.c
> >@@ -1343,9 +1343,49 @@ static void vtd_handle_gcmd_sirtp(IntelIOMMUState 
> >*s)
> >  vtd_set_clear_mask_long(s, DMAR_GSTS_REG, 0, VTD_GSTS_IRTPS);
> >  }
> >+static void vtd_switch_address_space(VTDAddressSpace *as, bool 
> >iommu_enabled)
> Looks like you can check s->dmar_enabled here?
> >>>Yes, we need to check old state in case we don't need a switch at all.
> >>>Actually I checked it...
> >>>
> >>I mean is there a chance that iommu_enabled( better name should be
> >>dmar_enabled) is not equal to s->dmar_enabled? Looks not.
> >>
> >>vtd_handle_gcmd_te() did:
> >>
> >> ...
> >> if (en) {
> >> s->dmar_enabled = true;
> >> /* Ok - report back to driver */
> >> vtd_set_clear_mask_long(s, DMAR_GSTS_REG, 0, VTD_GSTS_TES);
> >> } else {
> >> s->dmar_enabled = false;
> >> ...
> >>
> >>You can vtd_switch_address_space_all(s, en) after this which will call this
> >>function. And another caller like you've pointed out has already call this
> >>through s->dmar_enabled. So en here is always s->dmar_enalbed?
> >Hmm, yes...
> >
> >(I would still prefer keeping this parameter for readablility.
> >  Though, I prefer your suggestion to rename it to dmar_enabled)
> >
> >-- peterx
> 
> I think this does not give more readability :) May I was wrong, let leave
> this for maintainer.
> 
> Thanks :)

Thanks for reviewing this series so fast!

I have no strong opinion as well. Maybe you are right. :-)

Michael, please let me know if you dislike this, so I can remove this
parameter (it equals to as->iommu_state->dmar_enabled).

Thanks,

-- peterx

[Qemu-devel] Towards an ivshmem 2.0?

2017-01-16 Thread Jan Kiszka

Hi,

some of you may know that we are using a shared memory device similar to
ivshmem in the partitioning hypervisor Jailhouse [1].

We started as being compatible to the original ivshmem that QEMU
implements, but we quickly deviated in some details, and in the recent
months even more. Some of the deviations are related to making the
implementation simpler. The new ivshmem takes <500 LoC - Jailhouse is
aiming at safety critical systems and, therefore, a small code base.
Other changes address deficits in the original design, like missing
life-cycle management.

Now the question is if there is interest in defining a common new
revision of this device and maybe also of some protocols used on top,
such as virtual network links. Ideally, this would enable us to share
Linux drivers. We will definitely go for upstreaming at least a network
driver such as [2], a UIO driver and maybe also a serial port/console.

I've attached a first draft of the specification of our new ivshmem
device. A working implementation can be found in the wip/ivshmem2 branch
of Jailhouse [3], the corresponding ivshmem-net driver in [4].

Deviations from the original design:

- Only two peers per link

This simplifies the implementation and also the interfaces (think of
life-cycle management in a multi-peer environment). Moreover, we do
not have an urgent use case for multiple peers, thus also not
reference for a protocol that could be used in such setups. If someone
else happens to share such a protocol, it would be possible to discuss
potential extensions and their implications.

- Side-band registers to discover and configure share memory regions

This was one of the first changes: We removed the memory regions from
the PCI BARs and gave them special configuration space registers. By
now, these registers are embedded in a PCI capability. The reasons are
that Jailhouse does not allow to relocate the regions in guest address
space (but other hypervisors may if they like to) and that we now have
up to three of them.

- Changed PCI base class code to 0xff (unspecified class)

This allows us to define our own sub classes and interfaces. That is
now exploited for specifying the shared memory protocol the two
connected peers should use. It also allows the Linux drivers to match
on that.

- INTx interrupts support is back

This is needed on target platforms without MSI controllers, i.e.
without the required guest support. Namely some PCI-less ARM SoCs
required the reintroduction. While doing this, we also took care of
keeping the MMIO registers free of privileged controls so that a
guest OS can map them safely into a guest userspace application.

And then there are some extensions of the original ivshmem:

- Multiple shared memory regions, including unidirectional ones

It is now possible to expose up to three different shared memory
regions: The first one is read/writable for both sides. The second
region is read/writable for the local peer and read-only for the
remote peer (useful for output queues). And the third is read-only
locally but read/writable remotely (ie. for input queues).
Unidirectional regions prevent that the receiver of some data can
interfere with the sender while it is still building the message, a
property that is not only useful for safety critical communication,
we are sure.

- Life-cycle management via local and remote state

Each device can now signal its own state in form of a value to the
remote side, which triggers an event there. Moreover, state changes
done by the hypervisor to one peer are signalled to the other side.
And we introduced a write-to-shared-memory mechanism for the
respective remote state so that guests do not have to issue an MMIO
access in order to check the state.

So, this is our proposal. Would be great to hear some opinions if you
see value in adding support for such an "ivshmem 2.0" device to QEMU as
well and expand its ecosystem towards Linux upstream, maybe also DPDK
again. If you see problems in the new design /wrt what QEMU provides so
far with its ivshmem device, let's discuss how to resolve them. Looking
forward to any feedback!

Jan

[1] https://github.com/siemens/jailhouse
[2]
http://git.kiszka.org/?p=linux.git;a=blob;f=drivers/net/ivshmem-net.c;h=0e770ca293a4aca14a55ac0e66871b09c82647af;hb=refs/heads/queues/jailhouse
[3] https://github.com/siemens/jailhouse/commits/wip/ivshmem2
[4]
http://git.kiszka.org/?p=linux.git;a=shortlog;h=refs/heads/queues/jailhouse-ivshmem2

--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
IVSHMEM Device Specification

The Inter-VM Shared Memory device provides the following features to its users:

- Interconnection between two peers

- Up to three shared memory regions per connection

- one read/writable for both sides

- two unidirectional, i.e. read/writable for one side and only readable for
the

[Qemu-devel] [PATCH v4 1/2] memory: tune mtree_print_mr() to dump mr type

We were dumping RW bits for each memory region, that might be confusing.
It'll make more sense to dump the memory region type directly rather
than the RW bits since that's how the bits are derived.

Meanwhile, with some slight cleanup in the function.

Signed-off-by: Peter Xu 
---
 memory.c | 48 +++-
 1 file changed, 27 insertions(+), 21 deletions(-)

diff --git a/memory.c b/memory.c
index 2bfc37f..c42bde4 100644
--- a/memory.c
+++ b/memory.c
@@ -2450,6 +2450,21 @@ void address_space_destroy(AddressSpace *as)
 call_rcu(as, do_address_space_destroy, rcu);
 }
 
+static const char *memory_region_type(MemoryRegion *mr)
+{
+if (memory_region_is_ram_device(mr)) {
+return "ramd";
+} else if (memory_region_is_romd(mr)) {
+return "romd";
+} else if (memory_region_is_rom(mr)) {
+return "rom";
+} else if (memory_region_is_ram(mr)) {
+return "ram";
+} else {
+return "i/o";
+}
+}
+
 typedef struct MemoryRegionList MemoryRegionList;
 
 struct MemoryRegionList {
@@ -2459,6 +2474,10 @@ struct MemoryRegionList {
 
 typedef QTAILQ_HEAD(queue, MemoryRegionList) MemoryRegionListHead;
 
+#define MR_SIZE(size) (int128_nz(size) ? (hwaddr)int128_get64( \
+   int128_sub((size), int128_one())) : 0)
+#define MTREE_INDENT "  "
+
 static void mtree_print_mr(fprintf_function mon_printf, void *f,
const MemoryRegion *mr, unsigned int level,
hwaddr base,
@@ -2474,7 +2493,7 @@ static void mtree_print_mr(fprintf_function mon_printf, 
void *f,
 }
 
 for (i = 0; i < level; i++) {
-mon_printf(f, "  ");
+mon_printf(f, MTREE_INDENT);
 }
 
 if (mr->alias) {
@@ -2494,37 +2513,24 @@ static void mtree_print_mr(fprintf_function mon_printf, 
void *f,
 QTAILQ_INSERT_TAIL(alias_print_queue, ml, queue);
 }
 mon_printf(f, TARGET_FMT_plx "-" TARGET_FMT_plx
-   " (prio %d, %c%c): alias %s @%s " TARGET_FMT_plx
+   " (prio %d, %s): alias %s @%s " TARGET_FMT_plx
"-" TARGET_FMT_plx "%s\n",
base + mr->addr,
-   base + mr->addr
-   + (int128_nz(mr->size) ?
-  (hwaddr)int128_get64(int128_sub(mr->size,
-  int128_one())) : 0),
+   base + mr->addr + MR_SIZE(mr->size),
mr->priority,
-   mr->romd_mode ? 'R' : '-',
-   !mr->readonly && !(mr->rom_device && mr->romd_mode) ? 'W'
-   : '-',
+   memory_region_type((MemoryRegion *)mr),
memory_region_name(mr),
memory_region_name(mr->alias),
mr->alias_offset,
-   mr->alias_offset
-   + (int128_nz(mr->size) ?
-  (hwaddr)int128_get64(int128_sub(mr->size,
-  int128_one())) : 0),
+   mr->alias_offset + MR_SIZE(mr->size),
mr->enabled ? "" : " [disabled]");
 } else {
 mon_printf(f,
-   TARGET_FMT_plx "-" TARGET_FMT_plx " (prio %d, %c%c): 
%s%s\n",
+   TARGET_FMT_plx "-" TARGET_FMT_plx " (prio %d, %s): %s%s\n",
base + mr->addr,
-   base + mr->addr
-   + (int128_nz(mr->size) ?
-  (hwaddr)int128_get64(int128_sub(mr->size,
-  int128_one())) : 0),
+   base + mr->addr + MR_SIZE(mr->size),
mr->priority,
-   mr->romd_mode ? 'R' : '-',
-   !mr->readonly && !(mr->rom_device && mr->romd_mode) ? 'W'
-   : '-',
+   memory_region_type((MemoryRegion *)mr),
memory_region_name(mr),
mr->enabled ? "" : " [disabled]");
 }
-- 
2.7.4

[Qemu-devel] [PATCH v4 0/2] memory: extend "info mtree" with flat view dump

v4:
- do unref of flatview when no view is there [Dave]

v3:
- rather than dump flatview directly in "info mtree", provide a new
  parameter "-f" for it. [Paolo]
- replace "RW" chars with the type of memory region [Paolo]
- (cc dave as well since it touches HMP interface)

v2:
- fix a size error in patch 2
- add r-b for Marc-André in patch 1

Each address space has its own flatview. It's another way to observe
memory info besides the default memory region hierachy, for example,
if we want to know which memory region will handle the write to
specific address, a flatview will suite more here than the default
hierachical dump.

Please review. Thanks,

Peter Xu (2):
  memory: tune mtree_print_mr() to dump mr type
  memory: hmp: add "-f" for "info mtree"

 hmp-commands-info.hx  |  6 ++--
 include/exec/memory.h |  2 +-
 memory.c  | 89 ++-
 monitor.c |  4 ++-
 4 files changed, 74 insertions(+), 27 deletions(-)

-- 
2.7.4

[Qemu-devel] [PATCH v4 2/2] memory: hmp: add "-f" for "info mtree"

Adding one more option "-f" for "info mtree" to dump the flat views of
all the address spaces.

This will be useful to debug the memory rendering logic, also it'll be
much easier with it to know what memory region is handling what address
range.

Signed-off-by: Peter Xu 
---
 hmp-commands-info.hx  |  6 +++---
 include/exec/memory.h |  2 +-
 memory.c  | 41 -
 monitor.c |  4 +++-
 4 files changed, 47 insertions(+), 6 deletions(-)

diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
index 55d50c4..b0f35e6 100644
--- a/hmp-commands-info.hx
+++ b/hmp-commands-info.hx
@@ -249,9 +249,9 @@ ETEXI
 
 {
 .name   = "mtree",
-.args_type  = "",
-.params = "",
-.help   = "show memory tree",
+.args_type  = "flatview:-f",
+.params = "[-f]",
+.help   = "show memory tree (-f: dump flat view for address 
spaces)",
 .cmd= hmp_info_mtree,
 },
 
diff --git a/include/exec/memory.h b/include/exec/memory.h
index bec9756..71db380 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -1254,7 +1254,7 @@ void memory_global_dirty_log_start(void);
  */
 void memory_global_dirty_log_stop(void);
 
-void mtree_info(fprintf_function mon_printf, void *f);
+void mtree_info(fprintf_function mon_printf, void *f, bool flatview);
 
 /**
  * memory_region_dispatch_read: perform a read directly to the specified
diff --git a/memory.c b/memory.c
index c42bde4..6498727 100644
--- a/memory.c
+++ b/memory.c
@@ -2564,12 +2564,51 @@ static void mtree_print_mr(fprintf_function mon_printf, 
void *f,
 }
 }
 
-void mtree_info(fprintf_function mon_printf, void *f)
+static void mtree_print_flatview(fprintf_function p, void *f,
+ AddressSpace *as)
+{
+FlatView *view = address_space_get_flatview(as);
+FlatRange *range = &view->ranges[0];
+MemoryRegion *mr;
+int n = view->nr;
+
+if (n <= 0) {
+p(f, MTREE_INDENT "No rendered FlatView for "
+  "address space '%s'\n", as->name);
+flatview_unref(view);
+return;
+}
+
+while (n--) {
+mr = range->mr;
+p(f, MTREE_INDENT TARGET_FMT_plx "-"
+  TARGET_FMT_plx " (prio %d, %s): %s\n",
+  int128_get64(range->addr.start),
+  int128_get64(range->addr.start) + MR_SIZE(range->addr.size),
+  mr->priority,
+  memory_region_type(mr),
+  memory_region_name(mr));
+range++;
+}
+
+flatview_unref(view);
+}
+
+void mtree_info(fprintf_function mon_printf, void *f, bool flatview)
 {
 MemoryRegionListHead ml_head;
 MemoryRegionList *ml, *ml2;
 AddressSpace *as;
 
+if (flatview) {
+QTAILQ_FOREACH(as, &address_spaces, address_spaces_link) {
+mon_printf(f, "address-space (flat view): %s\n", as->name);
+mtree_print_flatview(mon_printf, f, as);
+mon_printf(f, "\n");
+}
+return;
+}
+
 QTAILQ_INIT(&ml_head);
 
 QTAILQ_FOREACH(as, &address_spaces, address_spaces_link) {
diff --git a/monitor.c b/monitor.c
index 0841d43..679cd52 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1529,7 +1529,9 @@ static void hmp_boot_set(Monitor *mon, const QDict *qdict)
 
 static void hmp_info_mtree(Monitor *mon, const QDict *qdict)
 {
-mtree_info((fprintf_function)monitor_printf, mon);
+bool flatview = qdict_get_try_bool(qdict, "flatview", false);
+
+mtree_info((fprintf_function)monitor_printf, mon, flatview);
 }
 
 static void hmp_info_numa(Monitor *mon, const QDict *qdict)
-- 
2.7.4

Re: [Qemu-devel] Virtual Machine Generation ID

2017-01-16 Thread Igor Mammedov

On Sat, 14 Jan 2017 22:17:53 -0800
Ben Warren  wrote:

> Hi Michael,
> 
> > On Dec 10, 2016, at 7:28 PM, Michael S. Tsirkin  wrote:
> > 
> > On Tue, Dec 06, 2016 at 06:15:34PM -0800, Ben Warren wrote:  
> >> Hi Michael,
> >> 
> >> I’m well on my way to implementing this, but I am really new to the QEMU 
> >> code base and am struggling with some concepts.  Please see below:  
> >>> On Oct 5, 2016, at 6:29 PM, Michael S. Tsirkin  wrote:
> >>> 
> >>> On Tue, Oct 04, 2016 at 03:51:40PM -0700, Ed Swierk wrote:  
>  On Thu, Sep 15, 2016 at 5:36 PM, Michael S. Tsirkin  
>  wrote:  
> > On Thu, Sep 15, 2016 at 05:23:28PM -0700, Ed Swierk wrote:  
> >> I'm wondering what it will take to finish up work on vmgenid.
> >> 
> >> https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg05599.html  
> > 
> > We have ACPI_BUILD_TPMLOG_FILE in tree now and I think it could be
> > allocated in a similar way.
> > Integrate patch "fw-cfg: support writeable blobs" to communicate the
> > allocated address back to QEMU.  
>  
>  Starting with Igor's last version at
>  https://github.com/imammedo/qemu/commits/vmgen_wip , it's not clear to
>  me which changes need to be ported, which changes are obsoleted by
>  your new fw-cfg stuff and/or upstream churn in ACPI, device
>  properties, etc. In particular ACPI is still a total mystery to me,
>  though passing a single address from guest to host can't be that hard,
>  can it?
>  
>  Any clues would be appreciated.
>  
>  --Ed  
> >>> 
> >>> It might be best to just re-start from the beginning.
> >>> So the idea is that ACPI should be about supplying the address
> >>> to guest. To supply address to host we'll use fw cfg.
> >>> This would be new I think:
> >>> 
> >>> - add support for writeable fw cfg blobs  
> >> patch applied  
> >>> - add linker/loader command to write address of a blob into
> >>> such a fw cfg file
> >>> - add a new file used for vm gen id, use loader command above
> >>> to pass the address of a blob allocated for it to host  
> >> I don’t really understand the meaning of “file” in this context.  It seems 
> >> to be a way of specifying individual fw_cfg entries without explicitly 
> >> giving an index, but is not something that is visible in either the host 
> >> or guest file system.  Is this about right?  In my code I’m using 
> >> “/etc/vmgenid”  
> > 
> > yes
> >   
> >> As for the blob, I’m thinking this is where my main problem is.  The 
> >> ‘fw_cfg_add_*()’ functions take a data pointer but doesn’t seem to copy 
> >> the data anywhere.  We pass essentially a pointer via ACPI to the guest, 
> >> so what it points to needs to be in an accessible region.  I don’t get how 
> >> to define the blob contents.  There are command-line ‘fw-cfg’ options 
> >> where you can specify a file, but it’s not clear to me how to use them.  
> >> Maybe I reserve some IO memory or something?  
> > 
> > Not sure I understand the question. fw cfg device will make
> > memory accessible to guest. Put the guest physical address there.
> > the address needs to be calculated by linker.
> >   
> I’m almost ready to submit a V2 of the patch set, but there’s still one issue 
> that I can’t figure out.  From the guest, I can read the contents of the 
> blob.  If I make a change to the contents of the blob (via QMP) the guest 
> does not see the changes.  Is there something I need to do on the QEMU side 
> to “push” the updated fw_cfg contents to the guest?  I’ve noticed this both 
> when writing a qtest for the feature, and also in a Linux kernel module I 
> wrote that reads the ACPI contents in a guest.
post here a link to your current repo so I could check it

> 
> thanks,
> Ben

Re: [Qemu-devel] [PATCH RFC v3 14/14] intel_iommu: enable vfio devices

On Mon, Jan 16, 2017 at 02:30:20PM +0800, Jason Wang wrote:
> 
> 
> On 2017年01月13日 11:06, Peter Xu wrote:
> >This patch is based on Aviv Ben-David ()'s patch
> >upstream:
> >
> >   "IOMMU: enable intel_iommu map and unmap notifiers"
> >   https://lists.gnu.org/archive/html/qemu-devel/2016-11/msg01453.html
> >
> >However I removed/fixed some content, and added my own codes.
> >
> >Instead of translate() every page for iotlb invalidations (which is
> >slower), we walk the pages when needed and notify in a hook function.
> >
> >This patch enables vfio devices for VT-d emulation.
> >
> >Signed-off-by: Peter Xu 
> >---
> >  hw/i386/intel_iommu.c | 68 
> > +--
> >  include/hw/i386/intel_iommu.h |  8 +
> >  2 files changed, 67 insertions(+), 9 deletions(-)
> >
> >diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> >index 2596f11..104200b 100644
> >--- a/hw/i386/intel_iommu.c
> >+++ b/hw/i386/intel_iommu.c
> >@@ -839,7 +839,8 @@ next:
> >   * @private: private data for the hook function
> >   */
> >  static int vtd_page_walk(VTDContextEntry *ce, uint64_t start, uint64_t end,
> >- vtd_page_walk_hook hook_fn, void *private)
> >+ vtd_page_walk_hook hook_fn, void *private,
> >+ bool notify_unmap)
> >  {
> >  dma_addr_t addr = vtd_get_slpt_base_from_context(ce);
> >  uint32_t level = vtd_get_level_from_context_entry(ce);
> >@@ -858,7 +859,7 @@ static int vtd_page_walk(VTDContextEntry *ce, uint64_t 
> >start, uint64_t end,
> >  trace_vtd_page_walk(ce->hi, ce->lo, start, end);
> >  return vtd_page_walk_level(addr, start, end, hook_fn, private,
> >-   level, true, true, NULL, false);
> >+   level, true, true, NULL, notify_unmap);
> >  }
> >  /* Map a device to its corresponding domain (context-entry) */
> >@@ -1212,6 +1213,34 @@ static void 
> >vtd_iotlb_domain_invalidate(IntelIOMMUState *s, uint16_t domain_id)
> >  &domain_id);
> >  }
> >+static int vtd_page_invalidate_notify_hook(IOMMUTLBEntry *entry,
> >+   void *private)
> >+{
> >+memory_region_notify_iommu((MemoryRegion *)private, *entry);
> >+return 0;
> >+}
> >+
> >+static void vtd_iotlb_page_invalidate_notify(IntelIOMMUState *s,
> >+   uint16_t domain_id, hwaddr addr,
> >+   uint8_t am)
> >+{
> >+IntelIOMMUNotifierNode *node;
> >+VTDContextEntry ce;
> >+int ret;
> >+
> >+QLIST_FOREACH(node, &(s->notifiers_list), next) {
> >+VTDAddressSpace *vtd_as = node->vtd_as;
> >+ret = vtd_dev_to_context_entry(s, pci_bus_num(vtd_as->bus),
> >+   vtd_as->devfn, &ce);
> >+if (!ret && domain_id == VTD_CONTEXT_ENTRY_DID(ce.hi)) {
> >+vtd_page_walk(&ce, addr, addr + (1 << am) * VTD_PAGE_SIZE,
> >+  vtd_page_invalidate_notify_hook,
> >+  (void *)&vtd_as->iommu, true);
> >+}
> >+}
> >+}
> >+
> >+
> >  static void vtd_iotlb_page_invalidate(IntelIOMMUState *s, uint16_t 
> > domain_id,
> >hwaddr addr, uint8_t am)
> >  {
> >@@ -1222,6 +1251,7 @@ static void vtd_iotlb_page_invalidate(IntelIOMMUState 
> >*s, uint16_t domain_id,
> >  info.addr = addr;
> >  info.mask = ~((1 << am) - 1);
> >  g_hash_table_foreach_remove(s->iotlb, vtd_hash_remove_by_page, &info);
> >+vtd_iotlb_page_invalidate_notify(s, domain_id, addr, am);
> 
> Is the case of GLOBAL or DSI flush missed, or we don't care it at all?

IMHO we don't. For device assignment, since we are having CM=1 here,
we should have explicit page invalidations even if guest sends
global/domain invalidations.

Thanks,

-- peterx

Re: [Qemu-devel] [PATCH RFC v3 14/14] intel_iommu: enable vfio devices

On Mon, Jan 16, 2017 at 02:30:20PM +0800, Jason Wang wrote:

[...]

> >  }
> >  /* Flush IOTLB
> >@@ -2244,15 +2274,34 @@ static void 
> >vtd_iommu_notify_flag_changed(MemoryRegion *iommu,
> >IOMMUNotifierFlag new)
> >  {
> >  VTDAddressSpace *vtd_as = container_of(iommu, VTDAddressSpace, iommu);
> >+IntelIOMMUState *s = vtd_as->iommu_state;
> >+IntelIOMMUNotifierNode *node = NULL;
> >+IntelIOMMUNotifierNode *next_node = NULL;
> >-if (new & IOMMU_NOTIFIER_MAP) {
> >-error_report("Device at bus %s addr %02x.%d requires iommu "
> >- "notifier which is currently not supported by "
> >- "intel-iommu emulation",
> >- vtd_as->bus->qbus.name, PCI_SLOT(vtd_as->devfn),
> >- PCI_FUNC(vtd_as->devfn));
> >+if (!s->cache_mode_enabled && new & IOMMU_NOTIFIER_MAP) {
> >+error_report("We need to set cache_mode=1 for intel-iommu to enable 
> >"
> >+ "device assignment with IOMMU protection.");
> >  exit(1);
> >  }
> >+
> >+/* Add new ndoe if no mapping was exising before this call */
> 
> "node"?

Sorry I missed this one - let me just remove above comment since it
just describes what the codes has done below.

Thanks,

> 
> >+if (old == IOMMU_NOTIFIER_NONE) {
> >+node = g_malloc0(sizeof(*node));
> >+node->vtd_as = vtd_as;
> >+QLIST_INSERT_HEAD(&s->notifiers_list, node, next);
> >+return;
> >+}

-- peterx

[Qemu-devel] [PATCH RFC 1/6] headers: update linux headers

From: Shannon Zhao 

Signed-off-by: Shannon Zhao 
---
 linux-headers/asm-arm64/kvm.h | 1 +
 linux-headers/linux/kvm.h | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/linux-headers/asm-arm64/kvm.h b/linux-headers/asm-arm64/kvm.h
index fd5a276..f914eac 100644
--- a/linux-headers/asm-arm64/kvm.h
+++ b/linux-headers/asm-arm64/kvm.h
@@ -97,6 +97,7 @@ struct kvm_regs {
 #define KVM_ARM_VCPU_EL1_32BIT 1 /* CPU running a 32bit VM */
 #define KVM_ARM_VCPU_PSCI_0_2  2 /* CPU uses PSCI v0.2 */
 #define KVM_ARM_VCPU_PMU_V33 /* Support guest PMUv3 */
+#define KVM_ARM_VCPU_CROSS 4 /* Support cross type vCPU */
 
 struct kvm_vcpu_init {
__u32 target;
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index bb0ed71..ea9e288 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -870,6 +870,8 @@ struct kvm_ppc_smmu_info {
 #define KVM_CAP_S390_USER_INSTR0 130
 #define KVM_CAP_MSI_DEVID 131
 #define KVM_CAP_PPC_HTM 132
+#define KVM_CAP_ARM_CROSS_VCPU 133
+#define KVM_CAP_ARM_HETEROGENEOUS 134
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
-- 
2.0.4

[Qemu-devel] [PATCH RFC 6/6] target-arm: cpu64: Add support for Cortex-A72

From: Shannon Zhao 

Add the ARM Cortex-A72 processor definition. It's similar to A57.

Signed-off-by: Shannon Zhao 
---
 hw/arm/virt.c  |  1 +
 target/arm/cpu64.c | 56 ++
 2 files changed, 57 insertions(+)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 49b7b65..2ba93e3 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -166,6 +166,7 @@ static const char *valid_cpus[] = {
 "cortex-a15",
 "cortex-a53",
 "cortex-a57",
+"cortex-a72",
 "generic",
 "host",
 NULL
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index 223f31e..4f00ceb 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -204,6 +204,61 @@ static void aarch64_a53_initfn(Object *obj)
 define_arm_cp_regs(cpu, cortex_a57_a53_cp_reginfo);
 }
 
+static void aarch64_a72_initfn(Object *obj)
+{
+ARMCPU *cpu = ARM_CPU(obj);
+
+cpu->dtb_compatible = "arm,cortex-a72";
+set_feature(&cpu->env, ARM_FEATURE_V8);
+set_feature(&cpu->env, ARM_FEATURE_VFP4);
+set_feature(&cpu->env, ARM_FEATURE_NEON);
+set_feature(&cpu->env, ARM_FEATURE_GENERIC_TIMER);
+set_feature(&cpu->env, ARM_FEATURE_AARCH64);
+set_feature(&cpu->env, ARM_FEATURE_CBAR_RO);
+set_feature(&cpu->env, ARM_FEATURE_V8_AES);
+set_feature(&cpu->env, ARM_FEATURE_V8_SHA1);
+set_feature(&cpu->env, ARM_FEATURE_V8_SHA256);
+set_feature(&cpu->env, ARM_FEATURE_V8_PMULL);
+set_feature(&cpu->env, ARM_FEATURE_CRC);
+set_feature(&cpu->env, ARM_FEATURE_EL3);
+cpu->kvm_target = QEMU_KVM_ARM_TARGET_GENERIC_V8;
+cpu->midr = 0x410fd081;
+cpu->revidr = 0x;
+cpu->reset_fpsid = 0x41034080;
+cpu->mvfr0 = 0x10110222;
+cpu->mvfr1 = 0x1211;
+cpu->mvfr2 = 0x0043;
+cpu->ctr = 0x8444c004;
+cpu->reset_sctlr = 0x00c50838;
+cpu->id_pfr0 = 0x0131;
+cpu->id_pfr1 = 0x00011011;
+cpu->id_dfr0 = 0x03010066;
+cpu->id_afr0 = 0x;
+cpu->id_mmfr0 = 0x10201105;
+cpu->id_mmfr1 = 0x4000;
+cpu->id_mmfr2 = 0x0126;
+cpu->id_mmfr3 = 0x02102211;
+cpu->id_isar0 = 0x02101110;
+cpu->id_isar1 = 0x13112111;
+cpu->id_isar2 = 0x21232042;
+cpu->id_isar3 = 0x01112131;
+cpu->id_isar4 = 0x00011142;
+cpu->id_isar5 = 0x00011121;
+cpu->id_aa64pfr0 = 0x;
+cpu->id_aa64dfr0 = 0x10305106;
+cpu->pmceid0 = 0x;
+cpu->pmceid1 = 0x;
+cpu->id_aa64isar0 = 0x00011120;
+cpu->id_aa64mmfr0 = 0x1124;
+cpu->dbgdidr = 0x3516d000;
+cpu->clidr = 0x0a200023;
+cpu->ccsidr[0] = 0x701fe00a; /* 32KB L1 dcache */
+cpu->ccsidr[1] = 0x201fe012; /* 48KB L1 icache */
+cpu->ccsidr[2] = 0x71ffe07a; /* 4096KB L2 cache */
+cpu->dcz_blocksize = 4; /* 64 bytes */
+define_arm_cp_regs(cpu, cortex_a57_a53_cp_reginfo);
+}
+
 static void aarch64_generic_initfn(Object *obj)
 {
 ARMCPU *cpu = ARM_CPU(obj);
@@ -285,6 +340,7 @@ typedef struct ARMCPUInfo {
 static const ARMCPUInfo aarch64_cpus[] = {
 { .name = "cortex-a57", .initfn = aarch64_a57_initfn },
 { .name = "cortex-a53", .initfn = aarch64_a53_initfn },
+{ .name = "cortex-a72", .initfn = aarch64_a72_initfn },
 { .name = "generic",.initfn = aarch64_generic_initfn },
 #ifdef CONFIG_USER_ONLY
 { .name = "any", .initfn = aarch64_any_initfn },
-- 
2.0.4

[Qemu-devel] [PATCH RFC 5/6] arm: virt: Enable generic type CPU in virt machine

From: Shannon Zhao 

Signed-off-by: Shannon Zhao 
---
 hw/arm/virt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 4b301c2..49b7b65 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -166,6 +166,7 @@ static const char *valid_cpus[] = {
 "cortex-a15",
 "cortex-a53",
 "cortex-a57",
+"generic",
 "host",
 NULL
 };
-- 
2.0.4

[Qemu-devel] [PATCH RFC 3/6] arm: kvm64: Check if kvm supports cross type vCPU

From: Shannon Zhao 

If user requests a specific type vCPU which is not same with the
physical ones and if kvm supports cross type vCPU, we set the
KVM_ARM_VCPU_CROSS bit and set the CPU ID registers.

Signed-off-by: Shannon Zhao 
---
 target/arm/kvm64.c | 182 +
 1 file changed, 182 insertions(+)

diff --git a/target/arm/kvm64.c b/target/arm/kvm64.c
index 609..70442ea 100644
--- a/target/arm/kvm64.c
+++ b/target/arm/kvm64.c
@@ -481,7 +481,151 @@ bool kvm_arm_get_host_cpu_features(ARMHostCPUClass *ahcc)
 return true;
 }
 
+#define ARM_CPU_ID_MIDR3, 0, 0, 0, 0
 #define ARM_CPU_ID_MPIDR   3, 0, 0, 0, 5
+/* ID group 1 registers */
+#define ARM_CPU_ID_REVIDR  3, 0, 0, 0, 6
+#define ARM_CPU_ID_AIDR3, 1, 0, 0, 7
+
+/* ID group 2 registers */
+#define ARM_CPU_ID_CCSIDR  3, 1, 0, 0, 0
+#define ARM_CPU_ID_CLIDR   3, 1, 0, 0, 1
+#define ARM_CPU_ID_CSSELR  3, 2, 0, 0, 0
+#define ARM_CPU_ID_CTR 3, 3, 0, 0, 1
+
+/* ID group 3 registers */
+#define ARM_CPU_ID_PFR03, 0, 0, 1, 0
+#define ARM_CPU_ID_PFR13, 0, 0, 1, 1
+#define ARM_CPU_ID_DFR03, 0, 0, 1, 2
+#define ARM_CPU_ID_AFR03, 0, 0, 1, 3
+#define ARM_CPU_ID_MMFR0   3, 0, 0, 1, 4
+#define ARM_CPU_ID_MMFR1   3, 0, 0, 1, 5
+#define ARM_CPU_ID_MMFR2   3, 0, 0, 1, 6
+#define ARM_CPU_ID_MMFR3   3, 0, 0, 1, 7
+#define ARM_CPU_ID_ISAR0   3, 0, 0, 2, 0
+#define ARM_CPU_ID_ISAR1   3, 0, 0, 2, 1
+#define ARM_CPU_ID_ISAR2   3, 0, 0, 2, 2
+#define ARM_CPU_ID_ISAR3   3, 0, 0, 2, 3
+#define ARM_CPU_ID_ISAR4   3, 0, 0, 2, 4
+#define ARM_CPU_ID_ISAR5   3, 0, 0, 2, 5
+#define ARM_CPU_ID_MMFR4   3, 0, 0, 2, 6
+#define ARM_CPU_ID_MVFR0   3, 0, 0, 3, 0
+#define ARM_CPU_ID_MVFR1   3, 0, 0, 3, 1
+#define ARM_CPU_ID_MVFR2   3, 0, 0, 3, 2
+#define ARM_CPU_ID_AA64PFR03, 0, 0, 4, 0
+#define ARM_CPU_ID_AA64PFR13, 0, 0, 4, 1
+#define ARM_CPU_ID_AA64DFR03, 0, 0, 5, 0
+#define ARM_CPU_ID_AA64DFR13, 0, 0, 5, 1
+#define ARM_CPU_ID_AA64AFR03, 0, 0, 5, 4
+#define ARM_CPU_ID_AA64AFR13, 0, 0, 5, 5
+#define ARM_CPU_ID_AA64ISAR0   3, 0, 0, 6, 0
+#define ARM_CPU_ID_AA64ISAR1   3, 0, 0, 6, 1
+#define ARM_CPU_ID_AA64MMFR0   3, 0, 0, 7, 0
+#define ARM_CPU_ID_AA64MMFR1   3, 0, 0, 7, 1
+#define ARM_CPU_ID_MAX 36
+
+static int kvm_arm_set_id_registers(CPUState *cs)
+{
+int ret = 0;
+uint32_t i;
+ARMCPU *cpu = ARM_CPU(cs);
+struct kvm_one_reg id_regitsers[ARM_CPU_ID_MAX];
+
+memset(id_regitsers, 0, ARM_CPU_ID_MAX * sizeof(struct kvm_one_reg));
+
+id_regitsers[0].id = ARM64_SYS_REG(ARM_CPU_ID_MIDR);
+id_regitsers[0].addr = (uintptr_t)&cpu->midr;
+
+id_regitsers[1].id = ARM64_SYS_REG(ARM_CPU_ID_REVIDR);
+id_regitsers[1].addr = (uintptr_t)&cpu->revidr;
+
+id_regitsers[2].id = ARM64_SYS_REG(ARM_CPU_ID_MVFR0);
+id_regitsers[2].addr = (uintptr_t)&cpu->mvfr0;
+
+id_regitsers[3].id = ARM64_SYS_REG(ARM_CPU_ID_MVFR1);
+id_regitsers[3].addr = (uintptr_t)&cpu->mvfr1;
+
+id_regitsers[4].id = ARM64_SYS_REG(ARM_CPU_ID_MVFR2);
+id_regitsers[4].addr = (uintptr_t)&cpu->mvfr2;
+
+id_regitsers[5].id = ARM64_SYS_REG(ARM_CPU_ID_PFR0);
+id_regitsers[5].addr = (uintptr_t)&cpu->id_pfr0;
+
+id_regitsers[6].id = ARM64_SYS_REG(ARM_CPU_ID_PFR1);
+id_regitsers[6].addr = (uintptr_t)&cpu->id_pfr1;
+
+id_regitsers[7].id = ARM64_SYS_REG(ARM_CPU_ID_DFR0);
+id_regitsers[7].addr = (uintptr_t)&cpu->id_dfr0;
+
+id_regitsers[8].id = ARM64_SYS_REG(ARM_CPU_ID_AFR0);
+id_regitsers[8].addr = (uintptr_t)&cpu->id_afr0;
+
+id_regitsers[9].id = ARM64_SYS_REG(ARM_CPU_ID_MMFR0);
+id_regitsers[9].addr = (uintptr_t)&cpu->id_mmfr0;
+
+id_regitsers[10].id = ARM64_SYS_REG(ARM_CPU_ID_MMFR1);
+id_regitsers[10].addr = (uintptr_t)&cpu->id_mmfr1;
+
+id_regitsers[11].id = ARM64_SYS_REG(ARM_CPU_ID_MMFR2);
+id_regitsers[11].addr = (uintptr_t)&cpu->id_mmfr2;
+
+id_regitsers[12].id = ARM64_SYS_REG(ARM_CPU_ID_MMFR3);
+id_regitsers[12].addr = (uintptr_t)&cpu->id_mmfr3;
+
+id_regitsers[13].id = ARM64_SYS_REG(ARM_CPU_ID_ISAR0);
+id_regitsers[13].addr = (uintptr_t)&cpu->id_isar0;
+
+id_regitsers[14].id = ARM64_SYS_REG(ARM_CPU_ID_ISAR1);
+id_regitsers[14].addr = (uintptr_t)&cpu->id_isar1;
+
+id_regitsers[15].id = ARM64_SYS_REG(ARM_CPU_ID_ISAR2);
+id_regitsers[15].addr = (uintptr_t)&cpu->id_isar2;
+
+id_regitsers[16].id = ARM64_SYS_REG(ARM_CPU_ID_ISAR3);
+id_regitsers[16].addr = (uintptr_t)&cpu->id_isar3;
+
+id_regitsers[17].id = ARM64_SYS_REG(ARM_CPU_ID_ISAR4);
+id_regitsers[17].addr = (uintptr_t)&cpu->id_isar4;
+
+id_regitsers[18].id = ARM64_SYS_REG(ARM_CPU_ID_ISAR5);
+id_regitsers[18].addr = (uintptr_t)&cpu->id_isar5;
+
+id_regitsers[19].id = ARM64_SYS_REG(ARM_CPU_ID_AA64PFR0);
+id_regitsers[19].addr = (uintptr_t)&cpu->id_aa64pfr0;
+
+id_regitsers[20].id = ARM64_SYS_REG(ARM_CPU_ID_AA

[Qemu-devel] [PATCH RFC 4/6] target: arm: Add a generic type cpu

From: Shannon Zhao 

Add a generic type cpu, it's useful for migration when running on
different hardwares.

Signed-off-by: Shannon Zhao 
---
 target/arm/cpu64.c | 54 ++
 1 file changed, 54 insertions(+)

diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index 549cb1e..223f31e 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -204,6 +204,59 @@ static void aarch64_a53_initfn(Object *obj)
 define_arm_cp_regs(cpu, cortex_a57_a53_cp_reginfo);
 }
 
+static void aarch64_generic_initfn(Object *obj)
+{
+ARMCPU *cpu = ARM_CPU(obj);
+
+cpu->dtb_compatible = "arm,armv8";
+set_feature(&cpu->env, ARM_FEATURE_V8);
+set_feature(&cpu->env, ARM_FEATURE_VFP4);
+set_feature(&cpu->env, ARM_FEATURE_NEON);
+set_feature(&cpu->env, ARM_FEATURE_GENERIC_TIMER);
+set_feature(&cpu->env, ARM_FEATURE_AARCH64);
+set_feature(&cpu->env, ARM_FEATURE_CBAR_RO);
+set_feature(&cpu->env, ARM_FEATURE_V8_AES);
+set_feature(&cpu->env, ARM_FEATURE_V8_SHA1);
+set_feature(&cpu->env, ARM_FEATURE_V8_SHA256);
+set_feature(&cpu->env, ARM_FEATURE_V8_PMULL);
+set_feature(&cpu->env, ARM_FEATURE_CRC);
+set_feature(&cpu->env, ARM_FEATURE_EL3);
+cpu->kvm_target = QEMU_KVM_ARM_TARGET_GENERIC_V8;
+cpu->midr = 0x410fd000; /* FIXME: this needs to adjust */
+cpu->revidr = 0x;
+cpu->reset_fpsid = 0x41034070;
+cpu->mvfr0 = 0x10110222;
+cpu->mvfr1 = 0x1211;
+cpu->mvfr2 = 0x0043;
+cpu->ctr = 0x84448004; /* L1Ip = VIPT */
+cpu->reset_sctlr = 0x00c50838;
+cpu->id_pfr0 = 0x0131;
+cpu->id_pfr1 = 0x00011011;
+cpu->id_dfr0 = 0x03010066;
+cpu->id_afr0 = 0x;
+cpu->id_mmfr0 = 0x10101105;
+cpu->id_mmfr1 = 0x4000;
+cpu->id_mmfr2 = 0x0126;
+cpu->id_mmfr3 = 0x02102211;
+cpu->id_isar0 = 0x02101110;
+cpu->id_isar1 = 0x13112111;
+cpu->id_isar2 = 0x21232042;
+cpu->id_isar3 = 0x01112131;
+cpu->id_isar4 = 0x00011142;
+cpu->id_isar5 = 0x00011121;
+cpu->id_aa64pfr0 = 0x;
+cpu->id_aa64dfr0 = 0x10305106;
+cpu->id_aa64isar0 = 0x00011120;
+cpu->id_aa64mmfr0 = 0x0f001101; /* only support 4k page, 36 bit physical 
addr */
+cpu->dbgdidr = 0x3516d000;
+cpu->clidr = 0x0a200023;
+cpu->ccsidr[0] = 0x7003e01a; /* 8KB L1 dcache */
+cpu->ccsidr[1] = 0x2007e00a; /* 8KB L1 icache */
+cpu->ccsidr[2] = 0x700fe07a; /* 128KB L2 cache */
+cpu->dcz_blocksize = 4; /* 64 bytes */
+define_arm_cp_regs(cpu, cortex_a57_a53_cp_reginfo);
+}
+
 #ifdef CONFIG_USER_ONLY
 static void aarch64_any_initfn(Object *obj)
 {
@@ -232,6 +285,7 @@ typedef struct ARMCPUInfo {
 static const ARMCPUInfo aarch64_cpus[] = {
 { .name = "cortex-a57", .initfn = aarch64_a57_initfn },
 { .name = "cortex-a53", .initfn = aarch64_a53_initfn },
+{ .name = "generic",.initfn = aarch64_generic_initfn },
 #ifdef CONFIG_USER_ONLY
 { .name = "any", .initfn = aarch64_any_initfn },
 #endif
-- 
2.0.4

[Qemu-devel] [PULL v2 000/180] QAPI patches for 2017-01-16

2017-01-16 Thread Markus Armbruster

This is Marc-André's "[PATCH v8 00/21] qapi doc generation (whole
version, squashed)" with a few commit messages tweaked, and "[PATCH v8
14/21] (SQUASHED) move doc to schema" unsquashed into 161 patches.

We did all the respins with in this squashed form to reduce noise.
However, since the unsquashed form is better suited for review, and
probably nicer if we have to revisit this part of the work down the
road, I'm proposing to merge this unsquashed.

If you want me to post the unsquashed patches, I'm happy to redo this
pull request.

If you'd rather pull the squashed version, likewise.

I'm afraid this is a bit of a doc conflict magnet.  The sooner we can
get it in, the easier for Marc-André and me.

v2:
* Rebased (v1 conflicts with commit e1ff3c6)
* test-qapi.py tweaked to avoid trailing empty lines in .out

The following changes since commit b6af8ea60282df514f87d32e36afd1c9aeee28c8:

  Merge remote-tracking branch 
'remotes/ehabkost/tags/x86-and-machine-pull-request' into staging (2017-01-13 
14:38:21 +)

are available in the git repository at:

  git://repo.or.cz/qemu/armbru.git tags/pull-qapi-2017-01-16

for you to fetch changes up to 56e8bdd46a8a42d89b0afea9da83ae7679cc0439:

  build-sys: add qapi doc generation targets (2017-01-16 10:11:43 +0100)


QAPI patches for 2017-01-16


Marc-André Lureau (180):
  qapi: replace 'o' for list items
  qapi: move QKeyCode doc body at the top
  qapi: Format TODO comments more consistently
  qapi: improve device_add schema
  qapi: improve TransactionAction doc
  qga/schema: improve guest-set-vcpus Returns: section
  qapi: Reorder doc comments for future doc generator
  qapi: Move "command is experimental" notes down
  qapi: add some sections in docs
  docs: add master qapi texi files
  qapi: rework qapi Exception
  texi2pod: learn quotation, deftp and deftypefn
  qmp-commands: move 'add_client' doc to schema
  qmp-commands: move 'query-name' doc to schema
  qmp-commands: move 'query-kvm' doc to schema
  qmp-commands: move 'query-status' doc to schema
  qmp-commands: move 'query-uuid' doc to schema
  qmp-commands: move 'query-chardev' doc to schema
  qmp-commands: move 'query-chardev-backends' doc to schema
  qmp-commands: move 'ringbuf-write' doc to schema
  qmp-commands: move 'ringbuf-read' doc to schema
  qmp-commands: move 'query-events' doc to schema
  qmp-commands: move 'query-migrate' doc to schema
  qmp-commands: move 'migrate-set-capabilities' doc to schema
  qmp-commands: move 'query-migrate-capabilities' doc to schema
  qmp-commands: move 'migrate-set-parameters' doc to schema
  qmp-commands: move 'query-migrate-parameters' doc to schema
  qmp-commands: move 'client_migrate_info' doc to schema
  qmp-commands: move 'migrate-start-postcopy' doc to schema
  qmp-commands: move 'query-mice' doc to schema
  qmp-commands: move 'query-cpus' doc to schema
  qmp-commands: move 'query-iothreads' doc to schema
  qmp-commands: move 'query-vnc' doc to schema
  qmp-commands: move 'query-spice' doc to schema
  qmp-commands: move 'query-balloon' doc to schema
  qmp-commands: move 'query-pci' doc to schema
  qmp-commands: move 'quit' doc to schema
  qmp-commands: move 'stop' doc to schema
  qmp-commands: move 'system_reset' doc to schema
  qmp-commands: move 'system_powerdown' doc to schema
  qmp-commands: move 'cpu-add' doc to schema
  qmp-commands: move 'memsave' doc to schema
  qmp-commands: move 'pmemsave' doc to schema
  qmp-commands: move 'cont' doc to schema
  qmp-commands: move 'system_wakeup' doc to schema
  qmp-commands: move 'inject-nmi' doc to schema
  qmp-commands: move 'set_link' doc to schema
  qmp-commands: move 'balloon' doc to schema
  qmp-commands: move 'transaction' doc to schema
  qmp-commands: move 'human-monitor-command' doc to schema
  qmp-commands: move 'migrate_cancel' doc to schema
  qmp-commands: move 'migrate_set_downtime' doc to schema
  qmp-commands: move 'migrate_set_speed' doc to schema
  qmp-commands: move 'query-migrate-cache-size' doc to schema
  qmp-commands: move 'set_password' doc to schema
  qmp-commands: move 'expire_password' doc to schema
  qmp-commands: move 'change' doc to schema
  qmp-commands: move 'migrate' doc to schema
  qmp-commands: move 'migrate-incoming' doc to schema
  qmp-commands: move 'xen-save-devices-state' doc to schema
  qmp-commands: move 'xen-set-global-dirty-log' doc to schema
  qmp-commands: move 'device_del' doc to schema
  qmp-commands: move 'dump-guest-memory' doc to schema
  qmp-commands: move 'query-dump-guest-memory-capability' doc to schema
  qmp-commands: move 'dump-skeys' doc to schema
  qmp-commands: move 'netd

[Qemu-devel] [PATCH RFC 2/6] target: arm: Add the qemu target for KVM_ARM_TARGET_GENERIC_V8

From: Shannon Zhao 

Signed-off-by: Shannon Zhao 
---
 target/arm/kvm-consts.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/arm/kvm-consts.h b/target/arm/kvm-consts.h
index a2c9518..fc01ac5 100644
--- a/target/arm/kvm-consts.h
+++ b/target/arm/kvm-consts.h
@@ -128,6 +128,7 @@ MISMATCH_CHECK(QEMU_PSCI_RET_DISABLED, PSCI_RET_DISABLED)
 #define QEMU_KVM_ARM_TARGET_CORTEX_A57 2
 #define QEMU_KVM_ARM_TARGET_XGENE_POTENZA 3
 #define QEMU_KVM_ARM_TARGET_CORTEX_A53 4
+#define QEMU_KVM_ARM_TARGET_GENERIC_V8 5
 
 /* There's no kernel define for this: sentinel value which
  * matches no KVM target value for either 64 or 32 bit
@@ -140,6 +141,7 @@ MISMATCH_CHECK(QEMU_KVM_ARM_TARGET_FOUNDATION_V8, 
KVM_ARM_TARGET_FOUNDATION_V8)
 MISMATCH_CHECK(QEMU_KVM_ARM_TARGET_CORTEX_A57, KVM_ARM_TARGET_CORTEX_A57)
 MISMATCH_CHECK(QEMU_KVM_ARM_TARGET_XGENE_POTENZA, KVM_ARM_TARGET_XGENE_POTENZA)
 MISMATCH_CHECK(QEMU_KVM_ARM_TARGET_CORTEX_A53, KVM_ARM_TARGET_CORTEX_A53)
+MISMATCH_CHECK(QEMU_KVM_ARM_TARGET_GENERIC_V8, KVM_ARM_TARGET_GENERIC_V8)
 #else
 MISMATCH_CHECK(QEMU_KVM_ARM_TARGET_CORTEX_A15, KVM_ARM_TARGET_CORTEX_A15)
 MISMATCH_CHECK(QEMU_KVM_ARM_TARGET_CORTEX_A7, KVM_ARM_TARGET_CORTEX_A7)
-- 
2.0.4

[Qemu-devel] [PATCH RFC 0/6] target-arm: KVM64: Cross type vCPU support

From: Shannon Zhao 

This patch set support use cross type vCPU when using KVM on ARM and add
two new CPU types: generic and cortex-a72.

You can test this patch set with QEMU using
-cpu cortex-a53/cortex-a57/generic/cortex-a72

These patches can be fetched from:
https://git.linaro.org/people/shannon.zhao/qemu.git cross_vcpu_rfc

You corresponding KVM patches can be fetched from:
https://git.linaro.org/people/shannon.zhao/linux-mainline.git cross_vcpu_rfc

Shannon Zhao (6):
  headers: update linux headers
  target: arm: Add the qemu target for KVM_ARM_TARGET_GENERIC_V8
  arm: kvm64: Check if kvm supports cross type vCPU
  target: arm: Add a generic type cpu
  arm: virt: Enable generic type CPU in virt machine
  target-arm: cpu64: Add support for Cortex-A72

 hw/arm/virt.c |   2 +
 linux-headers/asm-arm64/kvm.h |   1 +
 linux-headers/linux/kvm.h |   2 +
 target/arm/cpu64.c| 110 +
 target/arm/kvm-consts.h   |   2 +
 target/arm/kvm64.c| 182 ++
 6 files changed, 299 insertions(+)

-- 
2.0.4

Re: [Qemu-devel] [PULL v2 02/11] ui: use evdev keymap when running under wayland

2017-01-16 Thread Daniel P. Berrange

CC qemu-stable

This patch should go into active stable branches given that wayland is
now the default on some OS distro

On Mon, Jan 09, 2017 at 02:09:36PM +0100, Gerd Hoffmann wrote:
> From: "Daniel P. Berrange" 
> 
> Wayland always uses evdev as its input source, so QEMU
> can use the existing evdev keymap data
> 
> Signed-off-by: Daniel P. Berrange 
> Tested-by: Stefan Hajnoczi 
> Message-id: 20161201094117.16407-1-berra...@redhat.com
> Signed-off-by: Gerd Hoffmann 
> ---
>  include/ui/gtk.h | 4 
>  ui/gtk.c | 7 +++
>  2 files changed, 11 insertions(+)
> 
> diff --git a/include/ui/gtk.h b/include/ui/gtk.h
> index 42ca0fe..b3b5005 100644
> --- a/include/ui/gtk.h
> +++ b/include/ui/gtk.h
> @@ -18,6 +18,10 @@
>  #include 
>  #endif
>  
> +#ifdef GDK_WINDOWING_WAYLAND
> +#include 
> +#endif
> +
>  #if defined(CONFIG_OPENGL)
>  #include "ui/egl-helpers.h"
>  #include "ui/egl-context.h"
> diff --git a/ui/gtk.c b/ui/gtk.c
> index 406de4f..356f400 100644
> --- a/ui/gtk.c
> +++ b/ui/gtk.c
> @@ -90,6 +90,9 @@
>  #ifndef GDK_IS_X11_DISPLAY
>  #define GDK_IS_X11_DISPLAY(dpy) (dpy == dpy)
>  #endif
> +#ifndef GDK_IS_WAYLAND_DISPLAY
> +#define GDK_IS_WAYLAND_DISPLAY(dpy) (dpy == dpy)
> +#endif
>  #ifndef GDK_IS_WIN32_DISPLAY
>  #define GDK_IS_WIN32_DISPLAY(dpy) (dpy == dpy)
>  #endif
> @@ -1054,6 +1057,10 @@ static int gd_map_keycode(GtkDisplayState *s, 
> GdkDisplay *dpy, int gdk_keycode)
>  qemu_keycode = translate_xfree86_keycode(gdk_keycode - 97);
>  }
>  #endif
> +#ifdef GDK_WINDOWING_WAYLAND
> +} else if (GDK_IS_WAYLAND_DISPLAY(dpy) && gdk_keycode < 158) {
> +qemu_keycode = translate_evdev_keycode(gdk_keycode - 97);
> +#endif
>  } else if (gdk_keycode == 208) { /* Hiragana_Katakana */
>  qemu_keycode = 0x70;
>  } else if (gdk_keycode == 211) { /* backslash */
> -- 
> 1.8.3.1
> 

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

Re: [Qemu-devel] [PATCH v8 15/21] qapi: add qapi2texi script

2017-01-16 Thread Markus Armbruster

Marc-André Lureau  writes:

> As the name suggests, the qapi2texi script converts JSON QAPI
> description into a texi file suitable for different target
> formats (info/man/txt/pdf/html...).
>
> It parses the following kind of blocks:
>
> Free-form:
>
>   ##
>   # = Section
>   # == Subsection
>   #
>   # Some text foo with *emphasis*
>   # 1. with a list
>   # 2. like that
>   #
>   # And some code:
>   # | $ echo foo
>   # | -> do this
>   # | <- get that
>   #
>   ##
>
> Symbol description:
>
>   ##
>   # @symbol:
>   #
>   # Symbol body ditto ergo sum. Foo bar
>   # baz ding.
>   #
>   # @param1: the frob to frobnicate
>   # @param2: #optional how hard to frobnicate
>   #
>   # Returns: the frobnicated frob.
>   #  If frob isn't frobnicatable, GenericError.
>   #
>   # Since: version
>   # Notes: notes, comments can have
>   #- itemized list
>   #- like this
>   #
>   # Example:
>   #
>   # -> { "execute": "quit" }
>   # <- { "return": {} }
>   #
>   ##
>
> That's roughly following the following EBNF grammar:
>
> api_comment = "##\n" comment "##\n"
> comment = freeform_comment | symbol_comment
> freeform_comment = { "# " text "\n" | "#\n" }
> symbol_comment = "# @" name ":\n" { member | tag_section | freeform_comment }
> member = "# @" name ':' [ text ] "\n" freeform_comment
> tag_section = "# " ( "Returns:", "Since:", "Note:", "Notes:", "Example:", 
> "Examples:" ) [ text ]  "\n" freeform_comment
> text = free text with markup
>
> Note that the grammar is ambiguous: a line "# @foo:\n" can be parsed
> both as freeform_comment and as symbol_comment.  The actual parser
> recognizes symbol_comment.
>
> See docs/qapi-code-gen.txt for more details.
>
> Deficiencies and limitations:
> - the generated QMP documentation includes internal types
> - union type support is lacking
> - type information is lacking in generated documentation
> - doc comment error message positions are imprecise, they point
>   to the beginning of the comment.
> - a few minor issues, all marked TODO/FIXME in the code
>
> Signed-off-by: Marc-André Lureau 

Squashing in the appended patch along with updates to expected output to
avoid git complaining about trailing blank lines like this:

tests/qapi-schema/comments.out:7: new blank line at EOF.
tests/qapi-schema/event-case.out:8: new blank line at EOF.
tests/qapi-schema/ident-with-escape.out:10: new blank line at EOF.
tests/qapi-schema/include-relpath.out:7: new blank line at EOF.
tests/qapi-schema/include-repetition.out:7: new blank line at EOF.
tests/qapi-schema/include-simple.out:7: new blank line at EOF.
tests/qapi-schema/indented-expr.out:13: new blank line at EOF.
tests/qapi-schema/qapi-schema-test.out:446: new blank line at EOF.

diff --git a/tests/qapi-schema/test-qapi.py b/tests/qapi-schema/test-qapi.py
index 39b55b9..b4cde4f 100644
--- a/tests/qapi-schema/test-qapi.py
+++ b/tests/qapi-schema/test-qapi.py
@@ -66,4 +66,6 @@ for doc in schema.docs:
 print 'arg=%s\n%s' % (arg, section)
 for section in doc.sections:
 print 'section=%s\n%s' % (section.name, section)
-print 'body=\n%s' % doc.body
+body = str(doc.body)
+if body:
+print 'body=\n%s' % body

Re: [Qemu-devel] [PATCH RFC 0/6] target-arm: KVM64: Cross type vCPU support

2017-01-16 Thread no-reply

Hi,

Your series seems to have some coding style problems. See output below for
more information:

Type: series
Message-id: 1484558821-15512-1-git-send-email-zhaoshengl...@huawei.com
Subject: [Qemu-devel] [PATCH RFC 0/6] target-arm: KVM64: Cross type vCPU support

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

# Useful git options
git config --local diff.renamelimit 0
git config --local diff.renames True

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] 
patchew/1484558821-15512-1-git-send-email-zhaoshengl...@huawei.com -> 
patchew/1484558821-15512-1-git-send-email-zhaoshengl...@huawei.com
Switched to a new branch 'test'
ad5e87b target-arm: cpu64: Add support for Cortex-A72
d4f6c86 arm: virt: Enable generic type CPU in virt machine
db2426e target: arm: Add a generic type cpu
042dff8 arm: kvm64: Check if kvm supports cross type vCPU
d8b8db1 target: arm: Add the qemu target for KVM_ARM_TARGET_GENERIC_V8
71eb07d headers: update linux headers

=== OUTPUT BEGIN ===
Checking PATCH 1/6: headers: update linux headers...
Checking PATCH 2/6: target: arm: Add the qemu target for 
KVM_ARM_TARGET_GENERIC_V8...
Checking PATCH 3/6: arm: kvm64: Check if kvm supports cross type vCPU...
ERROR: Macros with complex values should be enclosed in parenthesis
#21: FILE: target/arm/kvm64.c:484:
+#define ARM_CPU_ID_MIDR3, 0, 0, 0, 0

ERROR: Macros with complex values should be enclosed in parenthesis
#24: FILE: target/arm/kvm64.c:487:
+#define ARM_CPU_ID_REVIDR  3, 0, 0, 0, 6

ERROR: Macros with complex values should be enclosed in parenthesis
#25: FILE: target/arm/kvm64.c:488:
+#define ARM_CPU_ID_AIDR3, 1, 0, 0, 7

ERROR: Macros with complex values should be enclosed in parenthesis
#28: FILE: target/arm/kvm64.c:491:
+#define ARM_CPU_ID_CCSIDR  3, 1, 0, 0, 0

ERROR: Macros with complex values should be enclosed in parenthesis
#29: FILE: target/arm/kvm64.c:492:
+#define ARM_CPU_ID_CLIDR   3, 1, 0, 0, 1

ERROR: Macros with complex values should be enclosed in parenthesis
#30: FILE: target/arm/kvm64.c:493:
+#define ARM_CPU_ID_CSSELR  3, 2, 0, 0, 0

ERROR: Macros with complex values should be enclosed in parenthesis
#31: FILE: target/arm/kvm64.c:494:
+#define ARM_CPU_ID_CTR 3, 3, 0, 0, 1

ERROR: Macros with complex values should be enclosed in parenthesis
#34: FILE: target/arm/kvm64.c:497:
+#define ARM_CPU_ID_PFR03, 0, 0, 1, 0

ERROR: Macros with complex values should be enclosed in parenthesis
#35: FILE: target/arm/kvm64.c:498:
+#define ARM_CPU_ID_PFR13, 0, 0, 1, 1

ERROR: Macros with complex values should be enclosed in parenthesis
#36: FILE: target/arm/kvm64.c:499:
+#define ARM_CPU_ID_DFR03, 0, 0, 1, 2

ERROR: Macros with complex values should be enclosed in parenthesis
#37: FILE: target/arm/kvm64.c:500:
+#define ARM_CPU_ID_AFR03, 0, 0, 1, 3

ERROR: Macros with complex values should be enclosed in parenthesis
#38: FILE: target/arm/kvm64.c:501:
+#define ARM_CPU_ID_MMFR0   3, 0, 0, 1, 4

ERROR: Macros with complex values should be enclosed in parenthesis
#39: FILE: target/arm/kvm64.c:502:
+#define ARM_CPU_ID_MMFR1   3, 0, 0, 1, 5

ERROR: Macros with complex values should be enclosed in parenthesis
#40: FILE: target/arm/kvm64.c:503:
+#define ARM_CPU_ID_MMFR2   3, 0, 0, 1, 6

ERROR: Macros with complex values should be enclosed in parenthesis
#41: FILE: target/arm/kvm64.c:504:
+#define ARM_CPU_ID_MMFR3   3, 0, 0, 1, 7

ERROR: Macros with complex values should be enclosed in parenthesis
#42: FILE: target/arm/kvm64.c:505:
+#define ARM_CPU_ID_ISAR0   3, 0, 0, 2, 0

ERROR: Macros with complex values should be enclosed in parenthesis
#43: FILE: target/arm/kvm64.c:506:
+#define ARM_CPU_ID_ISAR1   3, 0, 0, 2, 1

ERROR: Macros with complex values should be enclosed in parenthesis
#44: FILE: target/arm/kvm64.c:507:
+#define ARM_CPU_ID_ISAR2   3, 0, 0, 2, 2

ERROR: Macros with complex values should be enclosed in parenthesis
#45: FILE: target/arm/kvm64.c:508:
+#define ARM_CPU_ID_ISAR3   3, 0, 0, 2, 3

ERROR: Macros with complex values should be enclosed in parenthesis
#46: FILE: target/arm/kvm64.c:509:
+#define ARM_CPU_ID_ISAR4   3, 0, 0, 2, 4

ERROR: Macros with complex values should be enclosed in parenthesis
#47: FILE: target/arm/kvm64.c:510:
+#define ARM_CPU_ID_ISAR5   3, 0, 0, 2, 5

ERROR: Macros with complex values should be enclosed in parenthesis
#48: FILE: target/arm/kvm64.c:511:
+#define ARM_CPU_ID_MMFR4   3, 0, 0, 2, 6

ERROR: Macros with complex values should be enclosed in parenthe

Re: [Qemu-devel] [PULL 00/30] target-sparc sun4v support

2017-01-16 Thread Artyom Tarasenko

On Fri, Jan 13, 2017 at 3:01 PM, Peter Maydell  wrote:
> On 12 January 2017 at 02:55, Richard Henderson  wrote:
>> Mark Cave-Ayland asked me to handle the merge of this patch set
>> while he is traveling.
>>
>> This is the v2 that Artyom posted today.  I had reviewed the majority
>> of v1 earlier.  I re-read through the rebase and saw nothing amiss.
>> It passes my tests for sparc32, and does run the OpenSolaris image
>> to which Artyom links.
>>
>>
>> r~
>>
>>
>> The following changes since commit 41a0e54756a9ae6b60be34bb33302a7e085fdb07:
>>
>>   Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging 
>> (2017-01-10 10:46:21 +)
>>
>> are available in the git repository at:
>>
>>   git://github.com/rth7680/qemu.git tags/pull-sparc-20170111
>>
>> for you to fetch changes up to 224be7cc93a37ccd38342811a8925de889de1a49:
>>
>>   target-sparc: fix up niagara machine (2017-01-11 12:23:58 -0800)
>>
>> 
>> Sun4v support
>
> This hits clang's unused-function error;
>
> /home/petmay01/linaro/qemu-for-merges/target/sparc/ldst_helper.c:346:20:
> error: unused function 'do_check_asi' [-Werror,-Wunused-function]
> static inline void do_check_asi(CPUSPARCState *env, int asi, uintptr_t ra)
>^
> 1 error generated.
>

My bad. Will add an #ifdef and re-submit.

-- 
Regards,
Artyom Tarasenko

SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu

[Qemu-devel] [Bug 1578192] Re: GTK+ interface doesn't translate keycodes properly with Wayland backend

2017-01-16 Thread Daniel Berrange

This issue was fixed already in git master with:

commit a8ffb372a2202c65f42fdb69891ea68a2f274b55
Author: Daniel P. Berrange 
Date:   Thu Dec 1 09:41:17 2016 +

ui: use evdev keymap when running under wayland

Wayland always uses evdev as its input source, so QEMU
can use the existing evdev keymap data

Signed-off-by: Daniel P. Berrange 
Tested-by: Stefan Hajnoczi 
Message-id: 20161201094117.16407-1-berra...@redhat.com
Signed-off-by: Gerd Hoffmann 


** Changed in: qemu
   Status: New => Fix Committed

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

Title:
  GTK+ interface doesn't translate keycodes properly with Wayland
  backend

Status in QEMU:
  Fix Committed

Bug description:
  I already posted this on the mailing list
  (https://lists.nongnu.org/archive/html/qemu-
  devel/2016-05/msg00119.html) but I decided to do a formal bug report
  so it can be tracked and doesn't get lost.

  ... I'm no expert, but it looks like GTK+ key events come in at the
  ui/gtk.c:gd_key_event callback function, which calls
  ui/gtk.c:gd_map_keycode to translate the GTK+ keycode into the Qemu
  keycode before sending it on using qemu_input_event_send_key_number.
  The problem is that gd_map_keycode is incomplete when GTK+ is running
  on a backend other than X11.

  static int gd_map_keycode(GtkDisplayState *s, GdkDisplay *dpy, int 
gdk_keycode)
  {
  int qemu_keycode;

  #ifdef GDK_WINDOWING_WIN32
  if (GDK_IS_WIN32_DISPLAY(dpy)) {
  qemu_keycode = MapVirtualKey(gdk_keycode, MAPVK_VK_TO_VSC);
  switch (qemu_keycode) {
  case 103:   /* alt gr */
  qemu_keycode = 56 | SCANCODE_GREY;
  break;
  }
  return qemu_keycode;
  }
  #endif

  if (gdk_keycode < 9) {
  qemu_keycode = 0;
  } else if (gdk_keycode < 97) {
  qemu_keycode = gdk_keycode - 8;
  #ifdef GDK_WINDOWING_X11
  } else if (GDK_IS_X11_DISPLAY(dpy) && gdk_keycode < 158) {
  if (s->has_evdev) {
  qemu_keycode = translate_evdev_keycode(gdk_keycode - 97);
  } else {
  qemu_keycode = translate_xfree86_keycode(gdk_keycode - 97);
  }
  #endif
  } else if (gdk_keycode == 208) { /* Hiragana_Katakana */
  qemu_keycode = 0x70;
  } else if (gdk_keycode == 211) { /* backslash */
  qemu_keycode = 0x73;
  } else {
  qemu_keycode = 0;
  }

  return qemu_keycode;
  }

  In my case, I'm using GTK+'s Wayland backend, so keycodes 97 through
  157 (this includes KEY_HOME(102), KEY_PAGEUP(104), KEY_PAGEDOWN(109),
  KEY_END(107), etc.) are never translated into a qemu_keycode, and the
  final 'else' block is hit, causing gd_map_keycode to return 0, which
  is an invalid keycode and thus cannot be handled by xen-kbdfront. At
  least that's my best guess as to what is happening.

  The solution that comes to mind is provide an alternative to
  translate_{evdev,xfree86}_keycode that is compatable with
  Wayland/libinput, but I don't know exactly which API would provide
  this functionality, much less do I have a patch. Intuition tells me
  that translate_evdev_keycode would probably work under Wayland because
  Weston uses libinput which uses evdev as its backend, but I don't know
  this for a fact, and I don't know if it would be the Right Way (i.e.
  Wayland or libinput might provide an API for this purpose, but I don't
  know).

  I may try to do some testing with translate_evdev_keycode on Wayland
  and also look into any possible APIs for keycode translation, but I
  just wanted to put it out there and get some feedback awhile.

  Qemu 2.2.1 from Xen 4.6.1 (relevant code appears unchanged in Qemu master)
  GTK+ 3.18.7
  Wayland 1.9.0
  Weston 1.9.0
  libinput 1.2.3

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

Re: [Qemu-devel] [PATCH RFC v3 14/14] intel_iommu: enable vfio devices