date:20160107

On Tue, Nov 24, 2015 at 06:09:36PM +0100, Lluís Vilanova wrote:
> +/* Ensure 'tb_phys_idx' can encode event states as a bitmask */
> +bool too_many_tcg_vcpu_events[
> +TRACE_CPU_EVENT_COUNT > sizeof(unsigned int)*8 ? -1 : 0];

There is a limit of 32 vcpu tcg events?  That seems low but as long as
not too many users of this feature are merged it will work...

> @@ -227,6 +228,17 @@ void cpu_dump_statistics(CPUState *cpu, FILE *f, 
> fprintf_function cpu_fprintf,
>  void cpu_reset(CPUState *cpu)
>  {
>  CPUClass *klass = CPU_GET_CLASS(cpu);
> +TraceEvent *ev = NULL;
> +
> +if (!qemu_initialized) {

Is there a cleaner place to do this without introducing the
qemu_initialized global?

I guess the problem is that tracing itself is initialized before the
vcpus are set up.  Is qemu_add_machine_init_done_notifier() sufficient
for this purpose?

signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH v3 3/4] Add Error **errp for xen_pt_config_init()

2016-01-07 Thread Cao jin




On 01/07/2016 12:02 AM, Eric Blake wrote:

On 01/05/2016 07:39 PM, Cao jin wrote:

[...]

+static void xen_pt_config_reg_init(XenPCIPassthroughState *s,
+  XenPTRegGroup *reg_grp, XenPTRegInfo *reg,
+  Error **errp)


Indentation is now off.



Sharp eyes;)


@@ -1967,10 +1970,10 @@ static int 
xen_pt_config_reg_init(XenPCIPassthroughState *s,
  val = data;

  if (val & ~size_mask) {
-XEN_PT_ERR(&s->dev,"Offset 0x%04x:0x%04x expands past register 
size(%d)!\n",
-   offset, val, reg->size);
+error_setg(errp, "Offset 0x%04x:0x%04x expands past"
+" register size(%d)!", offset, val, reg->size);


Drop the trailing !.  Also, while touching this, it's better to have a
space before ( in English.



Ok




+void xen_pt_config_init(XenPCIPassthroughState *s, Error **errp)
  {
  int i, rc;
+Error *local_err = NULL;


Same comments as earlier in the series about using the shorter 'err'
instead of 'local_err'.



  QLIST_INIT(&s->reg_grps);

@@ -2039,11 +2041,12 @@ int xen_pt_config_init(XenPCIPassthroughState *s)
reg_grp_offset,
®_grp_entry->size);
  if (rc < 0) {
-XEN_PT_LOG(&s->dev, "Failed to initialize %d/%ld, type=0x%x, 
rc:%d\n",
-   i, ARRAY_SIZE(xen_pt_emu_reg_grps),
+error_setg(&local_err, "Failed to initialize %d/%ld, 
type=0x%x,"
+   " rc:%d", i, ARRAY_SIZE(xen_pt_emu_reg_grps),


This maps ARRAY_SIZE() (which is size_t) to %ld, which can fail to
compile on 32-bit platforms (where size_t is not necessarily long).  Fix
it to %zd while touching it.



a question:
1. Is %zu more suitable for size_t? since size_t is unsigned integer.

and a personal question after digging into size_t:
2. Does the size of size_t always equal to the word length[*] of computer

[*] https://en.wikipedia.org/wiki/Word_%28computer_architecture%29

--
Yours Sincerely,

Cao jin

Re: [Qemu-devel] [PATCH v2 4/7] device_tree: qemu_fdt_getprop converted to use the error API

Hi Peter,
On 01/07/2016 01:20 AM, Peter Crosthwaite wrote:
> On Wed, Jan 6, 2016 at 7:13 AM, Eric Auger  wrote:
>> Current qemu_fdt_getprop exits if the property is not found. It is
>> sometimes needed to read an optional property, in which case we do
>> not wish to exit but simply returns a null value.
>>
>> This patch converts qemu_fdt_getprop to accept an Error **, and existing
>> users are converted to pass &error_fatal. This preserves the existing
>> behaviour. Then to use the API with your optional semantic a null
>> parameter can be conveyed.
>>
>> Signed-off-by: Eric Auger 
>>
>> ---
>>
>> v1 -> v2:
>> - add a doc comment in the header file
>>
>> RFC -> v1:
>> - get rid of qemu_fdt_getprop_optional and implement Peter's suggestion
>>   that consists in using the error API
>>
>> Signed-off-by: Eric Auger 
>> ---
>>  device_tree.c| 11 ++-
>>  include/sysemu/device_tree.h | 15 ++-
>>  2 files changed, 20 insertions(+), 6 deletions(-)
>>
>> diff --git a/device_tree.c b/device_tree.c
>> index 8441e01..6ecc9da 100644
>> --- a/device_tree.c
>> +++ b/device_tree.c
>> @@ -321,18 +321,18 @@ int qemu_fdt_setprop_string(void *fdt, const char 
>> *node_path,
>>  }
>>
>>  const void *qemu_fdt_getprop(void *fdt, const char *node_path,
>> - const char *property, int *lenp)
>> + const char *property, int *lenp, Error **errp)
>>  {
>>  int len;
>>  const void *r;
>> +
>>  if (!lenp) {
>>  lenp = &len;
>>  }
>>  r = fdt_getprop(fdt, findnode_nofail(fdt, node_path), property, lenp);
>>  if (!r) {
>> -error_report("%s: Couldn't get %s/%s: %s", __func__,
>> - node_path, property, fdt_strerror(*lenp));
>> -exit(1);
>> +error_setg(errp, "%s: Couldn't get %s/%s: %s", __func__,
>> +  node_path, property, fdt_strerror(*lenp));
>>  }
>>  return r;
>>  }
>> @@ -341,7 +341,8 @@ uint32_t qemu_fdt_getprop_cell(void *fdt, const char 
>> *node_path,
>> const char *property)
>>  {
>>  int len;
>> -const uint32_t *p = qemu_fdt_getprop(fdt, node_path, property, &len);
>> +const uint32_t *p = qemu_fdt_getprop(fdt, node_path, property, &len,
>> + &error_fatal);
> 
> The _cell variant is now inconsistent with the regular _getprop. Can
> we convert them both together and fix the clients to error_fatal?
> (there are only 4 of them).

Yes sure

Best Regards

Eric
> 
> This would become the standard error_propagate pattern.
> 
>>  if (len != 4) {
>>  error_report("%s: %s/%s not 4 bytes long (not a cell?)",
>>   __func__, node_path, property);
> 
> And this would also convert to error_setg.
> 
> Regards,
> Peter
> 
>> diff --git a/include/sysemu/device_tree.h b/include/sysemu/device_tree.h
>> index 269cb1c..4d7cbb9 100644
>> --- a/include/sysemu/device_tree.h
>> +++ b/include/sysemu/device_tree.h
>> @@ -45,8 +45,21 @@ int qemu_fdt_setprop_string(void *fdt, const char 
>> *node_path,
>>  int qemu_fdt_setprop_phandle(void *fdt, const char *node_path,
>>   const char *property,
>>   const char *target_node_path);
>> +/**
>> + * qemu_fdt_getprop: retrieve the value of a given property
>> + * @fdt: pointer to the device tree blob
>> + * @node_path: node path
>> + * @property: name of the property to find
>> + * @lenp: fdt error if any or length of the property on success
>> + * @errp: handle to an error object
>> + *
>> + * returns a pointer to the property on success and NULL on failure
>> + * in case errp is set to &error_fatal, the function auto-asserts
>> + * on error (legacy behavior)
>> + */
>>  const void *qemu_fdt_getprop(void *fdt, const char *node_path,
>> - const char *property, int *lenp);
>> + const char *property, int *lenp,
>> + Error **errp);
>>  uint32_t qemu_fdt_getprop_cell(void *fdt, const char *node_path,
>> const char *property);
>>  uint32_t qemu_fdt_get_phandle(void *fdt, const char *path);
>> --
>> 1.9.1
>>

[Qemu-devel] [PULL 0/4] Tracing patches

The following changes since commit 38a762fec63fd5c035aae29ba9a77d357e21e4a7:

  Merge remote-tracking branch 
'remotes/berrange/tags/pull-crypto-fixes-2015-12-23-1' into staging (2015-12-23 
13:53:32 +)

are available in the git repository at:

  git://github.com/stefanha/qemu.git tags/tracing-pull-request

for you to fetch changes up to cef517ca4bf890ef5405aac1b95f75dcda043d6a:

  trace: add make dependencies on tracetool source (2016-01-07 16:59:56 +0800)





Mark Cave-Ayland (1):
  trace: fix PRIx64 constants in trace-events

Qinghua Jin (1):
  trace: reflect the file name change

Stefan Hajnoczi (2):
  trace: fix make foo-timestamp rules
  trace: add make dependencies on tracetool source

 trace-events| 14 --
 trace/Makefile.objs | 48 
 2 files changed, 36 insertions(+), 26 deletions(-)

-- 
2.5.0

[Qemu-devel] [PULL 3/4] trace: fix make foo-timestamp rules

The Makefile uses intermediate timestamp files to avoid rebuilding if
tracetool output is unchanged.

Timestamps are implemented incorrectly.  This was fixed for rules.mak in
commit 4b25966ab976f3a7fd9008193b2defcc82f8f04d ("rules.mak: cleanup
config generation rules") but never fixed in trace/Makefile.objs.

The problem with the old timestamp implementation was that make doesn't
notice the updated file modification time until the next time it is run.
It was necessary to run make twice in a row to achieve a full rebuild.

Signed-off-by: Stefan Hajnoczi 
---
 trace/Makefile.objs | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/trace/Makefile.objs b/trace/Makefile.objs
index 32f7a32..73bec38 100644
--- a/trace/Makefile.objs
+++ b/trace/Makefile.objs
@@ -5,20 +5,20 @@
 
 ifeq ($(findstring ust,$(TRACE_BACKENDS)),ust)
 $(obj)/generated-ust-provider.h: $(obj)/generated-ust-provider.h-timestamp
+   @cmp $< $@ >/dev/null 2>&1 || cp $< $@
 $(obj)/generated-ust-provider.h-timestamp: $(SRC_PATH)/trace-events
$(call quiet-command,$(TRACETOOL) \
--format=ust-events-h \
--backends=$(TRACE_BACKENDS) \
< $< > $@,"  GEN   $(patsubst %-timestamp,%,$@)")
-   @cmp -s $@ $(patsubst %-timestamp,%,$@) || cp $@ $(patsubst 
%-timestamp,%,$@)
 
 $(obj)/generated-ust.c: $(obj)/generated-ust.c-timestamp 
$(BUILD_DIR)/config-host.mak
+   @cmp $< $@ >/dev/null 2>&1 || cp $< $@
 $(obj)/generated-ust.c-timestamp: $(SRC_PATH)/trace-events
$(call quiet-command,$(TRACETOOL) \
--format=ust-events-c \
--backends=$(TRACE_BACKENDS) \
< $< > $@,"  GEN   $(patsubst %-timestamp,%,$@)")
-   @cmp -s $@ $(patsubst %-timestamp,%,$@) || cp $@ $(patsubst 
%-timestamp,%,$@)
 
 $(obj)/generated-events.h: $(obj)/generated-ust-provider.h
 $(obj)/generated-events.c: $(obj)/generated-ust.c
@@ -28,20 +28,20 @@ endif
 # Auto-generated event descriptions
 
 $(obj)/generated-events.h: $(obj)/generated-events.h-timestamp
+   @cmp $< $@ >/dev/null 2>&1 || cp $< $@
 $(obj)/generated-events.h-timestamp: $(SRC_PATH)/trace-events
$(call quiet-command,$(TRACETOOL) \
--format=events-h \
--backends=$(TRACE_BACKENDS) \
< $< > $@,"  GEN   $(patsubst %-timestamp,%,$@)")
-   @cmp -s $@ $(patsubst %-timestamp,%,$@) || cp $@ $(patsubst 
%-timestamp,%,$@)
 
 $(obj)/generated-events.c: $(obj)/generated-events.c-timestamp 
$(BUILD_DIR)/config-host.mak
+   @cmp $< $@ >/dev/null 2>&1 || cp $< $@
 $(obj)/generated-events.c-timestamp: $(SRC_PATH)/trace-events
$(call quiet-command,$(TRACETOOL) \
--format=events-c \
--backends=$(TRACE_BACKENDS) \
< $< > $@,"  GEN   $(patsubst %-timestamp,%,$@)")
-   @cmp -s $@ $(patsubst %-timestamp,%,$@) || cp $@ $(patsubst 
%-timestamp,%,$@)
 
 util-obj-y += generated-events.o
 
@@ -81,12 +81,12 @@ $(obj)/generated-tracers.o: $(obj)/generated-tracers.c 
$(obj)/generated-tracers.
 # rule file. So we use '.dtrace' instead
 ifeq ($(findstring dtrace,$(TRACE_BACKENDS)),dtrace)
 $(obj)/generated-tracers-dtrace.dtrace: 
$(obj)/generated-tracers-dtrace.dtrace-timestamp
+   @cmp $< $@ >/dev/null 2>&1 || cp $< $@
 $(obj)/generated-tracers-dtrace.dtrace-timestamp: $(SRC_PATH)/trace-events 
$(BUILD_DIR)/config-host.mak
$(call quiet-command,$(TRACETOOL) \
--format=d \
--backends=$(TRACE_BACKENDS) \
< $< > $@,"  GEN   $(patsubst %-timestamp,%,$@)")
-   @cmp -s $@ $(patsubst %-timestamp,%,$@) || cp $@ $(patsubst 
%-timestamp,%,$@)
 
 $(obj)/generated-tracers-dtrace.h: $(obj)/generated-tracers-dtrace.dtrace
$(call quiet-command,dtrace -o $@ -h -s $<, "  GEN   $@")
@@ -100,28 +100,28 @@ endif
 # Translation level
 
 $(obj)/generated-helpers-wrappers.h: 
$(obj)/generated-helpers-wrappers.h-timestamp
+   @cmp $< $@ >/dev/null 2>&1 || cp $< $@
 $(obj)/generated-helpers-wrappers.h-timestamp: $(SRC_PATH)/trace-events 
$(BUILD_DIR)/config-host.mak
$(call quiet-command,$(TRACETOOL) \
--format=tcg-helper-wrapper-h \
--backend=$(TRACE_BACKENDS) \
< $< > $@,"  GEN   $(patsubst %-timestamp,%,$@)")
-   @cmp -s $@ $(patsubst %-timestamp,%,$@) || cp $@ $(patsubst 
%-timestamp,%,$@)
 
 $(obj)/generated-helpers.h: $(obj)/generated-helpers.h-timestamp
+   @cmp $< $@ >/dev/null 2>&1 || cp $< $@
 $(obj)/generated-helpers.h-timestamp: $(SRC_PATH)/trace-events 
$(BUILD_DIR)/config-host.mak
$(call quiet-command,$(TRACETOOL) \
--format=tcg-helper-h \
--backend=$(TRACE_BACKENDS) \
< $< > $@,"  GEN   $(patsubst %-timestamp,%,$@)")
-   @cmp -s $@ $(patsubst %-timestamp,%,$@) || cp $@ $(patsubst 
%-timestamp,%,$@)
 
 $(obj)/generated-helpers.c: $(obj)/generated-helpers.c-timestamp
+   @cmp $< $@ >/dev/nu

Re: [Qemu-devel] 答复: What's the advantages of POSTCOPY over CPU-THROTTLE?

2016-01-07 Thread Dr. David Alan Gilbert

* Zhangbo (Oscar) (oscar.zhan...@huawei.com) wrote:
> Thank you David and Jason!
> 
> BTW, I noticed that Vmware did the same work alike us, but the situation is a 
> little different:
> they proposed postcopy(in the name of QuickResume) in vSphere4.1, but 
> they substituted it with SDPS(similar to CPU-THROTTLE) from vSphere5, do you 
> know the reason behind this?
> Reference: 
> https://qianr.wordpress.com/2013/10/14/vmware-vm-live-migration-vmotion/
> It's told that they've already introduced a shared storage to avoid losing 
> the guest when the network connection is lost. So what's their concern of 
> disposing QuickResume? 

Hmm that's a good summary; I'd not seen any detail of how vmware's systems 
worked before.
I'm not exactly sure; but I think that's saying that they store the
outstanding pages that haven't been transferred in a file on disk
so that they could be used to recover the VM later if the network failed.
It's not clear to me from that description if they do that only when the
network fails, or as part of a normal postcopy flow.

> Are there any other prices we need to pay to have postcopy?

The precopy phase in postcopy mode is slower than normal precopy migration,
but I think that's the only other penalty.

Dave

> 
> -邮件原件-
> 发件人: Jason J. Herne [mailto:jjhe...@linux.vnet.ibm.com] 
> 发送时间: 2016年1月7日 3:43
> 收件人: Dr. David Alan Gilbert; Zhangbo (Oscar)
> 抄送: zhouyimin Zhou(Yimin); Zhanghailiang; Yanqiangjun; Huangpeng (Peter); 
> qemu-devel@nongnu.org; Herongguang (Stephen); Linqiangmin; Huangzhichao; 
> Wangyufei (James)
> 主题: Re: [Qemu-devel] What's the advantages of POSTCOPY over CPU-THROTTLE?
> 
> On 01/06/2016 04:57 AM, Dr. David Alan Gilbert wrote:
> > * Zhangbo (Oscar) (oscar.zhan...@huawei.com) wrote:
> >> Hi all:
> >> 　　Postcopy is suitable for migrating guests which have large page change 
> >> rates. It
> >>  1 makes the guest run at the destination ASAP.
> >>  2 makes the downtime of the guest small enough.
> >>  If we don't take the 1st advantage into account, then, its benefit 
> >> seems similar with CPU-THROTTLE: both of them make the guest's downtime 
> >> small during migration.
> >>
> >>  CPU-THROTTLE would make the guest's dirtypage rate *smaller than the 
> >> network bandwidth*, in order to make the to_send_page_number in each 
> >> iteration convergent and achieve the small-enough downtime during the last 
> >> iteration.
> >>  If we adopt POST-COPY here, the guest's dirtypage rate would *become 
> >> equal to the bandwidth*, because we have to fetch its memory from the 
> >> source side, via the network.
> >>  Both of them would introduce performance degradations of the guest, 
> >> which may in turn cause downtime larger.
> >>
> >>  So, here comes the question: If we just compare POSTCOPY with 
> >> CPU-THROTTLE for their advantages in decreasing downtime, POSTCOPY seems 
> >> has no pos over CPU-THROTTLE, is that right?
> >>
> >>  Meanwhile, Are there any other benifits of POSTCOPY besides the 2 
> >> mentioned above?
> >
> > It's a good question and they do both try and help solve the same problem.
> > One problem with cpu-throttle is whether you can throttle the CPU 
> > enough to get the dirty-rate below the rate of the network, and the 
> > answer to that is very workload dependent.  On a large, many-core VM, 
> > even a little bit of CPU can dirty a lot of memory.  Postcopy is 
> > guaranteed to finish migration, irrespective of the workload.
> >
> > Postcopy is pretty fine-grained, in that only threads that are 
> > accessing pages that are still on the source are blocked, since it 
> > allows the use of async page faults, that means it's even finer 
> > grained than the vCPU level, so many threads come back up to full 
> > performance pretty quickly even if there are a few pages left.
> >
> 
> Good answer Dave. FWIW, I completely agree. Using cpu throttling can help the 
> situation depending on workload. Postcopy will *always* work. 
> One possible side effect of Postcopy is loss of the guest if the network 
> connection dies during the postcopy phase of migration. This should be a very 
> rare occurrence however. So both methods have their uses.
> 
> --
> -- Jason J. Herne (jjhe...@linux.vnet.ibm.com)
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [Qemu-devel] [PATCH 1/1] block/raw-posix: avoid bogus fixup for cylinders on DASD disks

2016-01-07 Thread Christian Borntraeger

On 12/14/2015 06:49 PM, Cornelia Huck wrote:
> On Mon, 14 Dec 2015 16:41:19 +0100
> Christian Borntraeger  wrote:
> 
>> large volume DASD that have > 64k cylinders do claim to have
>> 0xFFFE cylinders as special value in the old 16 bit field. We
>> want to pass this "token" along to the guest, instead of
>> calculating the real number. Otherwise qemu might fail with
>> "cyls must be between 1 and 65535"
>>
>> Acked-by: Cornelia Huck 
>> Signed-off-by: Christian Borntraeger 
>> ---
>>  block/raw-posix.c | 7 ---
>>  1 file changed, 7 deletions(-)
> 
> Maybe add cc:stable?

Yes.

Kevin, ping. I assume this goes via your tree?

Re: [Qemu-devel] [PATCH] sdhci: add quirk property for card insert interrupt status on Raspberry Pi

2016-01-07 Thread Peter Crosthwaite

On Tue, Jan 5, 2016 at 10:36 AM, Andrew Baumann
 wrote:
>> From: Peter Crosthwaite [mailto:crosthwaitepe...@gmail.com]
>> Sent: Monday, 4 January 2016 22:18
>> On Mon, Jan 4, 2016 at 2:12 PM, Andrew Baumann
>>  wrote:
>> >> From: Peter Crosthwaite [mailto:crosthwaitepe...@gmail.com]
>> >> Sent: Thursday, 31 December 2015 21:38
>> >> On Thu, Dec 31, 2015 at 1:40 PM, Andrew Baumann
>> >>  wrote:
>> >> > This quirk is a workaround for the following hardware behaviour, on
>> >> > which UEFI (specifically, the bootloader for Windows on Pi2) depends:
>> >> >
>> >> > 1. at boot with an SD card present, the interrupt status/enable
>> >> >registers are initially zero
>> >> > 2. upon enabling it in the interrupt enable register, the card insert
>> >> >bit in the interrupt status register is immediately set
>> >> > 3. after a subsequent controller reset, the card insert interrupt does
>> >> >not fire, even if enabled in the interrupt enable register
>> >> >
>> >>
>> >> This is a baffling symptom. Does prnsts card ejection state fully work
>> >> with physical card ejections and insertions both before and after the
>> >> subsequent controller reset?
>> >
>> > I just tested this, by polling prnsts and intsts in a tight loop at board 
>> > startup.
>> At power on with a card inserted, prnsts reads 1FFF. Subsequent
>> removal of the card, re-insertion etc. does not change its value.
>>
>> Does either the subsequent reset or the interrupt ack change it? I'm
>> assuming it is stuck permanently at 1fff.
>
> That's correct -- there's no change.
>
>> >After enabling interrupts, I reliably see a card insert interrupt in 
>> >intsts. If I
>> then write zero to the interrupt enable register, the pending card insert
>> interrupt remains, which seems to dispel the "mask on read" theory. Once
>> acked or reset, the card insert interrupt never recurs. I never saw a card
>> removal interrupt.
>> >
>>
>> So
>>
>> * interrupt status is initially 0
>> * writing one to enable triggers the ghost
>> * it can only be cleared with a status ack
> (or reset)
>> * you can never get a second ghost
>
> Correct.
>
> [...]
>> > but either way there is a reliable ghost of a card insertion interrupt 
>> > that is
>> signalled at power on, and remains pending until it is either acked or the
>> controller reset, after which point it never recurs. And I'd really like to 
>> model
>> that somehow without making a mess of sdhci.c :) Any ideas?
>> >
>>
>> Ok, I think it can be explained as a bad top-level connection as
>> follows. The pin is mis-connected in such a way that such that it sees
>> one edge on the POR reset and never sees any action again. The
>> controller considers this pin edge-triggered and has the penning quirk
>> as well, that is it saves edge interrupt until they are enabled and
>> then releases them singly to the status register.
>>
>> This doesn't explain why the controller doesn't see the interrupt on
>> the soft reset, but perhaps that is explained by the spec, as I don't
>> see anywhere that says that the interrupt has to retrigger for a
>> constantly inserted card over a controller reset. Might be
>> implementation specific.
>>
>> Looking at the set_cb stuff, I think the guard on your original quirk
>> implementation may be missing for the sd_set_cb() in sdhci_initfn().
>> If this guard were added that quirk would be more complete, as
>> currently it probably is seeing action on changes of state.
>>
>> I think the way to correct the original quirk is to:
>>
>> * make both sd_set_cb()'s conditional
>> * manually call insert_eject_cb() on the POR reset (call the CB
>> instead of register it).
>>
>> Note that sdhci has no device::reset callback. You could add this to
>> implement your POR reset.
>>
>> You then have the problem of the prnsts register, which I assume it
>> getting blasted by the reset memset. That can be managed by
>> specifically preserving those two bits of prnsts through the reset
>> (with an accompanying comment that this is needed for your quirk).
>
> Assuming the user doesn't eject/change the SD card at runtime then my 
> original patch isn't necessary at all. (I'm happy with that outcome, which is 
> why I submitted the revert patch.) Because the memset in reset clears 
> norintstsen, the sdhci_insert_eject_cb will never signal an insert interrupt. 
> If we wanted a quirk to disable insert/eject interrupts, then what you've 
> proposed seems like the right thing to do, although I think we'd need to 
> preserve more than two bits of prnsts; we'd also need the write protect bit, 
> and it's probably safe to just keep the upper half of the register.
>

Are there any issues with rPI WP bit?

>> Your patch as-is here doesn't seem to address the penning behaviour
>> (where the interrupt status remains clear until it is enabled), maybe
>> that can be added as a second quirk if needed later?
>
> My second patch does handle this in a way that's good enough to boot UEFI: a 
> card insert interrupt is pendin

Re: [Qemu-devel] [Qemu-block] Minutes from the "Stuttgart block Gipfele"

2016-01-07 Thread Fam Zheng

On Thu, 01/07 13:23, Stefan Hajnoczi wrote:
> On Mon, Jan 04, 2016 at 03:28:36PM +0800, Fam Zheng wrote:
> > On Mon, 01/04 13:16, Stefan Hajnoczi wrote:
> > > On Wed, Dec 23, 2015 at 06:15:20PM +0800, Fam Zheng wrote:
> > > > On Fri, 12/18 14:15, Markus Armbruster wrote:
> > > > In that theory, all other block job types, mirror/stream/commit, fit 
> > > > into a
> > > > "pull" model, which follows a specified dirty bitmap and copies data 
> > > > from a
> > > > specified src BDS. In this pull model,
> > > > 
> > > > mirror (device=d0 target=d1) becomes a pull fileter:
> > > > 
> > > > BB[d0]BB[d1]
> > > >| |
> > > > throttle[pull,src=d0]
> > > >| |
> > > >detect-zero   detect-zero
> > > >| |
> > > >   copy-on-read  copy-on-read
> > > >| |
> > > >   BDS   BDS
> > > > 
> > > > Note: the pull reuses most of the block/mirror.c code except the
> > > > s->dirty_bitmap will be initialized depending on the block job type. In 
> > > > the
> > > > case of mirror, it is trivially the same as now.
> > > 
> > > I don't understand the pull filter.  Is there also a mirror block job
> > > coroutine?
> > > 
> > > Does anything perform I/O to BB[d1]?
> > 
> > Yes, the filter will have a mirror block job coroutine, and it writes to the
> > BDS behind BB[d1]. This is conceptually different from the "block jobs have
> > their own BBs" design.
> 
> Are any of the pull filter's callbacks (.bdrv_co_readv(),
> .bdrv_co_writev()) being invoked?
> 
> I still don't understand your idea because it seems like the coroutine
> is doing all the work and the filter serves no purpose.
> 

OK, it's more of the mental model. My point is letting the dynamic filter
reconfiguration interface manage the block job in units of filters, the
internal mechanism should be the same between "pull" filter and "mirror" job
coroutine.

Fam

Re: [Qemu-devel] [PATCH] SCSI bus: fix to incomplete QOMify

2016-01-07 Thread Cao jin




On 01/07/2016 05:38 PM, Paolo Bonzini wrote:



On 06/01/2016 14:43, Cao jin wrote:

[...]


These functions are called in the data path; changes to use SCSI_BUS()
should come with performance data proving that it doesn't slow down I/O.

Paolo



I see. I am not familiar with the procedure of scsi i/o performance 
test, do have some guideline about it?


--
Yours Sincerely,

Cao jin

Re: [Qemu-devel] [PATCH] virtio serial port: fix to incomplete QOMify

2016-01-07 Thread Amit Shah

On (Wed) 06 Jan 2016 [16:22:55], Cao jin wrote:
> Signed-off-by: Cao jin 
> ---
>  hw/char/virtio-serial-bus.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
> index 497b0af..2d2a659 100644
> --- a/hw/char/virtio-serial-bus.c
> +++ b/hw/char/virtio-serial-bus.c
> @@ -798,7 +798,7 @@ static const TypeInfo virtser_bus_info = {
>  
>  static void virtser_bus_dev_print(Monitor *mon, DeviceState *qdev, int 
> indent)
>  {
> -VirtIOSerialPort *port = DO_UPCAST(VirtIOSerialPort, dev, qdev);
> +VirtIOSerialPort *port = VIRTIO_SERIAL_PORT(qdev);
>  
>  monitor_printf(mon, "%*sport %d, guest %s, host %s, throttle %s\n",
> indent, "", port->id,

Reviewed-by: Amit Shah 

Applied to my tree, thanks.

Amit

Re: [Qemu-devel] [PATCH v3 00/11] simplify usage of tracepoints, and connect them to logging

On Thu, Oct 29, 2015 at 11:44:06PM +0300, Denis V. Lunev wrote:
> This series does three things:
> 
> 1) add a "-trace [enable=]foo" option to enable one or more trace
> events, and a "-trace help" option to show the list of tracepoints
> (patches 4-5)
> 
> 2) change the stderr tracing backend so that it prints to the
> -D log file, and enable it by default.  "-trace file=..." is
> now a synonym of -D if the log backend is enabled (patches 7-8)
> 
> 3) add a "-d trace:foo" option that is a synonym for "-trace foo";
> this makes the new functionality more discoverable to people used
> to "-d", makes it available for user-mode emulation (which does
> not have -trace), and is somewhat nice if you want to enable both
> tracepoints and some other "-d" flag (patch 9).  When globbing
> it is also less susceptible to unwanted shell expansion.
> 
> For example, you can trace block device I/O and save the result
> to a file just by adding "-trace bdrv_aio_*,file=trace.txt", or
> correlate it to guest PCs with "-d exec,nochain,trace:bdrv_aio_*".
> 
> Opinions?  I would like to have this in 2.5 if there is agreement.
> 
> Signed-off-by: Paolo Bonzini 
> Signed-off-by: Denis V. Lunev 
> 
> Changes from v2:
> - compilation fix was extended to patch 2 and 3
> - replaced Reviewed-by with Acked-by by request from Christian
> 
> Changes from v1:
> - small cleanup to vl.c is added as patch (4)
> - compilation is fixed in patch (2)
> - moved qemu-log.c to util/log.c to fix linking of qemu-io/qemu-nbd
> 
> Denis V. Lunev (2):
>   trace: no need to call trace_backend_init in different branches now
>   log: move qemu-log.c into util/ directory
> 
> Paolo Bonzini (9):
>   trace: fix documentation
>   trace: split trace_init_events out of trace_init_backends
>   trace: split trace_init_file out of trace_init_backends
>   trace: add "-trace enable=..."
>   trace: add "-trace help"
>   log: do not unnecessarily include qom/cpu.h
>   trace: convert stderr backend to log
>   trace: switch default backend to "log"
>   log: add "-d trace:PATTERN"
> 
>  Makefile.objs   |  1 -
>  bsd-user/main.c |  1 +
>  configure   |  6 +-
>  cpu-exec.c  |  1 +
>  exec.c  |  1 +
>  hw/acpi/cpu_hotplug.c   |  1 +
>  hw/timer/a9gtimer.c |  1 +
>  include/exec/log.h  | 60 
>  include/qemu/log.h  | 60 +---
>  linux-user/main.c   |  1 +
>  qemu-io.c   |  2 +-
>  qemu-options.hx | 22 --
>  qom/cpu.c   |  1 +
>  scripts/tracetool/backend/{stderr.py => log.py} |  9 +--
>  target-alpha/translate.c|  1 +
>  target-arm/translate.c  |  1 +
>  target-cris/translate.c |  1 +
>  target-i386/seg_helper.c|  1 +
>  target-i386/smm_helper.c|  1 +
>  target-i386/translate.c |  1 +
>  target-lm32/helper.c|  1 +
>  target-lm32/translate.c |  1 +
>  target-m68k/translate.c |  1 +
>  target-microblaze/helper.c  |  1 +
>  target-microblaze/translate.c   |  1 +
>  target-mips/helper.c|  1 +
>  target-mips/translate.c |  1 +
>  target-moxie/translate.c|  1 +
>  target-openrisc/translate.c |  1 +
>  target-ppc/mmu-hash32.c |  1 +
>  target-ppc/mmu-hash64.c |  1 +
>  target-ppc/mmu_helper.c |  1 +
>  target-ppc/translate.c  |  1 +
>  target-s390x/translate.c|  1 +
>  target-sh4/helper.c |  1 +
>  target-sh4/translate.c  |  1 +
>  target-sparc/int32_helper.c |  1 +
>  target-sparc/int64_helper.c |  1 +
>  target-sparc/translate.c|  1 +
>  target-tilegx/translate.c   |  1 +
>  target-tricore/translate.c  |  1 +
>  target-unicore32/translate.c|  1 +
>  target-xtensa/translate.c   |  1 +
>  tcg/tcg.c   |  1 +
>  trace/control.c | 95 
> ++---
>  trace/control.h | 42 ++-
>  trace/simple.c  |  6 +-
>  trace/simple.h  |  4 +-
>  translate-all.c |  1 +
>  util/Makefile.objs

Re: [Qemu-devel] [Qemu-block] [PATCH] send readcapacity10 when readcapacity16 failed

On 06/01/2016 18:57, John Snow wrote:
> Ronnie: Thanks for the explanation!
> 
> Zhu: In light of this, can the patch be reworked slightly to explicitly
> check *why* READCAPACITY16 failed and only attempt the READCAPACITY10 as
> a fallback if it receives INVALID_OPCODE?
> 
> If it fails for any other reason it's probably best to report the error
> and let QEMU decide what to do about it.

Any other failure probably would happen for READ CAPACITY(10) as well, so
it's okay to ignore it for READ CAPACITY(16).

Zhu's patch matches what Linux does by default, it seems okay.  The only
change needed is to retry READ CAPACITY(16) if there is a UNIT ATTENTION
sense:

+if (task != NULL && task->status == SCSI_STATUS_CHECK_CONDITION
+&& task->sense.key == SCSI_SENSE_UNIT_ATTENTION) {
+break;
+}

Paolo

Re: [Qemu-devel] [RFC v6 00/14] Slow-path for atomic instruction translation

2016-01-07 Thread alvise rigo

Hi,

On Wed, Jan 6, 2016 at 7:00 PM, Andrew Baumann
 wrote:
>
> Hi,
>
> > From: qemu-devel-bounces+andrew.baumann=microsoft@nongnu.org
> > [mailto:qemu-devel-
> > bounces+andrew.baumann=microsoft@nongnu.org] On Behalf Of
> > Alvise Rigo
> > Sent: Monday, 14 December 2015 00:41
> >
> > This is the sixth iteration of the patch series which applies to the
> > upstream branch of QEMU (v2.5.0-rc3).
> >
> > Changes versus previous versions are at the bottom of this cover letter.
> >
> > The code is also available at following repository:
> > https://git.virtualopensystems.com/dev/qemu-mt.git
> > branch:
> > slowpath-for-atomic-v6-no-mttcg
> >
> > This patch series provides an infrastructure for atomic instruction
> > implementation in QEMU, thus offering a 'legacy' solution for
> > translating guest atomic instructions. Moreover, it can be considered as
> > a first step toward a multi-thread TCG.
> >
> > The underlying idea is to provide new TCG helpers (sort of softmmu
> > helpers) that guarantee atomicity to some memory accesses or in general
> > a way to define memory transactions.
> >
> > More specifically, the new softmmu helpers behave as LoadLink and
> > StoreConditional instructions, and are called from TCG code by means of
> > target specific helpers. This work includes the implementation for all
> > the ARM atomic instructions, see target-arm/op_helper.c.
>
> As a heads up, we just added support for alignment checks in LDREX:
> https://github.com/qemu/qemu/commit/30901475b91ef1f46304404ab4bfe89097f61b96

Thank you for the update.

>
> Hopefully it is an easy change to ensure that the same check happens for the 
> relevant loads when CONFIG_TCG_USE_LDST_EXCL is enabled?

It should be if we add an aligned variant for each of the exclusive helper.
BTW, why don't we make the check also for the STREX instruction?

Regards,
alvise

>
> Thanks,
> Andrew

Re: [Qemu-devel] [PATCH v3] bugfix: passing reference instead of value

2016-01-07 Thread Michael S. Tsirkin

On Mon, Jan 04, 2016 at 02:14:48PM +, Stefano Stabellini wrote:
> On Sat, 2 Jan 2016, Michael S. Tsirkin wrote:
> > On Sat, Jan 02, 2016 at 04:02:20PM +0800, Cao jin wrote:
> > > Fix the bug introduced by 595a4f07: function host_pci_config_read() 
> > > should be
> > > pass-by-reference, not value.
> > > 
> > > Signed-off-by: Cao jin 
> > > ---
> > > v3 changelog:
> > > 1. Remove cpu_to_le32() since the code only runs on X86.
> > 
> > It really should be le32_to_cpu and a separate patch,
> > but I think it's preferable to have it there
> > since people tend to copy code around.
> > 
> > But in any case, before merging any patches in this function I'd like to
> > hear a response from someone explaining why is this function necessary
> > at all, since it provably never did anything useful.
> 
> If Tiejun's email address bounces, then we are unlikely to get a reply.
> 
> I think that the pass-by-value bug was introduced in one of the
> rebase/resend versions, as the series is very old and originally looked
> very different. I would take the patch as is to fix the obvious bug.

Yes but with this bug in place, we know no one is using this
device. And if no one can be bothered to test it,
maybe we should rip out the code and be done with it.

OTOH Gerd has apparently been looking at making it
work for kvm, maybe this will bring in testers/users.

I'll apply the fix for now.


> This is how the original code looks like:
> 
> http://xenbits.xen.org/gitweb/?p=qemu-xen-traditional.git;a=blob_plain;f=hw/pt-graphics.c;hb=HEAD
> 
> See the function named igd_pci_read.
> 
> 
> 
> 
> 
> > > 
> > >  hw/pci-host/piix.c | 8 +---
> > >  1 file changed, 5 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
> > > index 715208b..924f0fa 100644
> > > --- a/hw/pci-host/piix.c
> > > +++ b/hw/pci-host/piix.c
> > > @@ -761,7 +761,7 @@ static const IGDHostInfo igd_host_bridge_infos[] = {
> > >  {0xa8, 4},  /* SNB: base of GTT stolen memory */
> > >  };
> > >  
> > > -static int host_pci_config_read(int pos, int len, uint32_t val)
> > > +static int host_pci_config_read(int pos, int len, uint32_t *val)
> > >  {
> > >  char path[PATH_MAX];
> > >  int config_fd;
> > > @@ -784,12 +784,14 @@ static int host_pci_config_read(int pos, int len, 
> > > uint32_t val)
> > >  ret = -errno;
> > >  goto out;
> > >  }
> > > +
> > >  do {
> > > -rc = read(config_fd, (uint8_t *)&val, len);
> > > +rc = read(config_fd, (uint8_t *)val, len);
> > >  } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
> > >  if (rc != len) {
> > >  ret = -errno;
> > >  }
> > > +
> > >  out:
> > >  close(config_fd);
> > >  return ret;
> > > @@ -805,7 +807,7 @@ static int igd_pt_i440fx_initfn(struct PCIDevice 
> > > *pci_dev)
> > >  for (i = 0; i < num; i++) {
> > >  pos = igd_host_bridge_infos[i].offset;
> > >  len = igd_host_bridge_infos[i].len;
> > > -rc = host_pci_config_read(pos, len, val);
> > > +rc = host_pci_config_read(pos, len, &val);
> > >  if (rc) {
> > >  return -ENODEV;
> > >  }
> > > -- 
> > > 2.1.0
> > > 
> > > 
> >

Re: [Qemu-devel] [PATCH v3] qemu-char: add logfile facility to all chardev backends



On 23/12/2015 14:27, Daniel P. Berrange wrote:
> -mon_chr = qemu_chr_alloc();
> +mon_chr = qemu_chr_alloc(&common, NULL);

Changed NULL to &error_abort, and queued.

Paolo

>  mon_chr->chr_write = gdb_monitor_write;

Re: [Qemu-devel] [RFC v6 00/14] Slow-path for atomic instruction translation

2016-01-07 Thread alvise rigo

On Thu, Jan 7, 2016 at 11:22 AM, Peter Maydell  wrote:
> On 7 January 2016 at 10:21, alvise rigo  wrote:
>> Hi,
>>
>> On Wed, Jan 6, 2016 at 7:00 PM, Andrew Baumann
>>  wrote:
>>> As a heads up, we just added support for alignment checks in LDREX:
>>> https://github.com/qemu/qemu/commit/30901475b91ef1f46304404ab4bfe89097f61b96
>
>> It should be if we add an aligned variant for each of the exclusive helper.
>> BTW, why don't we make the check also for the STREX instruction?
>
> Andrew's patch only changed the bits Windows cares about, I think.
> We should indeed extend this to cover also STREX and the A64 instructions
> as well, I think.

The alignment check is easily doable in general. The only tricky part
I found is the A64's STXP instruction that requires quadword alignment
for the 64bit paired access.
In that case, the translation of the instruction will rely on a
aarch64-only helper. The alternative solution would be to extend
softmmu_template.h to generate 128bit accesses, but I don't believe
this is the right way to go.

Regards,
alvise

>
> thanks
> -- PMM

Re: [Qemu-devel] [PATCH v5 0/6] i386: expose floppy-related objects in SSDT

2016-01-07 Thread Michael S. Tsirkin

On Wed, Jan 06, 2016 at 03:04:40PM +0100, Igor Mammedov wrote:
> On Wed, 30 Dec 2015 23:11:50 +0300
> Roman Kagan  wrote:
> 
> > Windows on UEFI systems is only capable of detecting the presence and
> > the type of floppy drives via corresponding ACPI objects.
> > 
> > Those objects are added in patch 5; the preceding ones pave the way to
> > it, by making the necessary data public and by moving the whole
> > floppy drive controller description into runtime-generated SSDT.
> > 
> > Note that the series conflicts with Igor's patchset for dynamic DSDT, in
> > particular, with "[PATCH v2 27/51] pc: acpi: move FDC0 device from DSDT
> > to SSDT"; I haven't managed to avoid that while trying to meet
> > maintainer's comments.
> 
> Tested with XPsp3 WS2008R2 WS2012R2, no regressions so far it boots fine and 
> can read floppy.
> 
> So for whole series:
> Reviewed-by: Igor Mammedov 
> 

Igor, could you pls rebase this on top of your patches?
I've merged them in my tree.

> > Roman Kagan (6):
> >   i386/pc: expose identifying the floppy controller
> >   i386/acpi: make floppy controller object dynamic
> >   tests/acpi: update test data
> >   expose floppy drive geometry and CMOS type
> >   i386: populate floppy drive information in SSDT
> >   tests/acpi: update test data
> > 
> > Signed-off-by: Roman Kagan 
> > Cc: "Michael S. Tsirkin" 
> > Cc: Eduardo Habkost 
> > Cc: Igor Mammedov 
> > Cc: John Snow 
> > Cc: Kevin Wolf 
> > Cc: Paolo Bonzini 
> > Cc: Richard Henderson 
> > Cc: qemu-bl...@nongnu.org
> > Cc: qemu-sta...@nongnu.org
> > ---
> > changes since v4:
> >  - re-split out code changes from test data updates
> > 
> > changes since v3:
> >  - make FDC object fully dynamic in a separate patch
> >  - split out support patches
> >  - include test data updates with the respective patches to maintain
> >bisectability
> > 
> > changes since v2:
> >  - explicit endianness for buffer data
> >  - reorder code to reduce conflicts with dynamic DSDT patchset
> >  - update test data
> > 
> >  hw/block/fdc.c  |  11 +
> >  hw/i386/acpi-build.c|  92 
> > 
> >  hw/i386/acpi-dsdt-isa.dsl   |  18 ---
> >  hw/i386/acpi-dsdt.dsl   |   1 -
> >  hw/i386/pc.c|  46 ++
> >  hw/i386/q35-acpi-dsdt.dsl   |   7 +--
> >  include/hw/block/fdc.h  |   2 +
> >  include/hw/i386/pc.h|   3 ++
> >  tests/acpi-test-data/pc/DSDT| Bin 3028 -> 2946 bytes
> >  tests/acpi-test-data/pc/SSDT| Bin 2486 -> 2635 bytes
> >  tests/acpi-test-data/pc/SSDT.bridge | Bin 4345 -> 4494 bytes
> >  tests/acpi-test-data/q35/DSDT   | Bin 7666 -> 7578 bytes
> >  12 files changed, 137 insertions(+), 43 deletions(-)
> >

Re: [Qemu-devel] [PATCH 3/6] nvdimm acpi: introduce patched dsm memory

On Wed, 6 Jan 2016 23:39:04 +0800
Xiao Guangrong  wrote:

> On 01/06/2016 11:23 PM, Igor Mammedov wrote:
> > On Tue,  5 Jan 2016 02:52:05 +0800
> > Xiao Guangrong  wrote:
> >  
> >> The dsm memory is used to save the input parameters and store
> >> the dsm result which is filled by QEMU.
> >>
> >> The address of dsm memory is decided by bios and patched into
> >> int64 object returned by "MEMA" method
> >>
> >> Signed-off-by: Xiao Guangrong 
> >> ---
> >>   hw/acpi/aml-build.c | 12 
> >>   hw/acpi/nvdimm.c| 24 ++--
> >>   include/hw/acpi/aml-build.h |  1 +
> >>   3 files changed, 35 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
> >> index 78e1290..83eadb3 100644
> >> --- a/hw/acpi/aml-build.c
> >> +++ b/hw/acpi/aml-build.c
> >> @@ -394,6 +394,18 @@ Aml *aml_int(const uint64_t val)
> >>   }
> >>
> >>   /*
> >> + * ACPI 1.0b: 16.2.3 Data Objects Encoding:
> >> + * encode: QWordConst
> >> + */
> >> +Aml *aml_int64(const uint64_t val)
> >> +{
> >> +Aml *var = aml_alloc();
> >> +build_append_byte(var->buf, 0x0E); /* QWordPrefix */
> >> +build_append_int_noprefix(var->buf, val, 8);
> >> +return var;
> >> +}
> >> +
> >> +/*
> >>* helper to construct NameString, which returns Aml object
> >>* for using with aml_append or other aml_* terms
> >>*/
> >> diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c
> >> index bc7cd8f..a72104c 100644
> >> --- a/hw/acpi/nvdimm.c
> >> +++ b/hw/acpi/nvdimm.c
> >> @@ -28,6 +28,7 @@
> >>
> >>   #include "hw/acpi/acpi.h"
> >>   #include "hw/acpi/aml-build.h"
> >> +#include "hw/acpi/bios-linker-loader.h"
> >>   #include "hw/nvram/fw_cfg.h"
> >>   #include "hw/mem/nvdimm.h"
> >>
> >> @@ -402,7 +403,8 @@ void nvdimm_init_acpi_state(AcpiNVDIMMState *state, 
> >> MemoryRegion *io,
> >>   state->dsm_mem->len);
> >>   }
> >>
> >> -#define NVDIMM_COMMON_DSM  "NCAL"
> >> +#define NVDIMM_GET_DSM_MEM  "MEMA"
> >> +#define NVDIMM_COMMON_DSM   "NCAL"
> >>
> >>   static void nvdimm_build_common_dsm(Aml *dev)
> >>   {
> >> @@ -468,7 +470,8 @@ static void nvdimm_build_ssdt(GSList *device_list, 
> >> GArray *table_offsets,
> >> GArray *table_data, GArray *linker,
> >> uint8_t revision)
> >>   {
> >> -Aml *ssdt, *sb_scope, *dev;
> >> +Aml *ssdt, *sb_scope, *dev, *method;
> >> +int offset;
> >>
> >>   acpi_add_table(table_offsets, table_data);
> >>
> >> @@ -499,9 +502,26 @@ static void nvdimm_build_ssdt(GSList *device_list, 
> >> GArray *table_offsets,
> >>
> >>   aml_append(sb_scope, dev);
> >>
> >> +/*
> >> + * leave it at the end of ssdt so that we can conveniently get the
> >> + * offset of int64 object returned by the function which will be
> >> + * patched with the real address of the dsm memory by BIOS.
> >> + */
> >> +method = aml_method(NVDIMM_GET_DSM_MEM, 0, AML_NOTSERIALIZED);
> >> +aml_append(method, aml_return(aml_int64(0x0)));  
> > there is no need in dedicated aml_int64(), you can use 
> > aml_int(0x64) trick  
> 
> We can not do this due to the trick in  bios_linker_loader_add_pointer() 
> which will
> issue a COMMAND_ADD_POINTER to BIOS, however, this request does:
>  /*
>   * COMMAND_ADD_POINTER - patch the table (originating from
>   * @dest_file) at @pointer.offset, by adding a pointer to the table
>   * originating from @src_file. 1,2,4 or 8 byte unsigned
>   * addition is used depending on @pointer.size.
>   */
> 
> that means the new-offset = old-offset + the address of the new table 
> allocated by BIOS.
> 
> So we expect 0 offset here.
perhaps I'm blind but I don't see bios_linker_loader_add_pointer() using
value stored in aml_int() in any way, see below.

> 
> >  
> >> +aml_append(sb_scope, method);
> >>   aml_append(ssdt, sb_scope);
> >>   /* copy AML table into ACPI tables blob and patch header there */
> >>   g_array_append_vals(table_data, ssdt->buf->data, ssdt->buf->len);
> >> +
> >> +offset = table_data->len - 8;
> >> +
> >> +bios_linker_loader_alloc(linker, NVDIMM_DSM_MEM_FILE, 
> >> TARGET_PAGE_SIZE,
> >> + false /* high memory */);
> >> +bios_linker_loader_add_pointer(linker, ACPI_BUILD_TABLE_FILE,
> >> +   NVDIMM_DSM_MEM_FILE, table_data,
> >> +   table_data->data + offset,
here table_data->data + offset is a pointer to the first byte of aml_int() 
value.

then bios_linker_loader_add_pointer(GArray *linker,
const char *dest_file,
const char *src_file,
GArray *table, void *pointer,
uint8_t pointer_size)
{
...
size_t offset = (gchar *)pointer - table->data; 
...
entry.pointe

Re: [Qemu-devel] [PATCH] hw/i386: fill in the CENTURY field of the FADT (FACP) ACPI table

2016-01-07 Thread Michael S. Tsirkin

On Thu, Jan 07, 2016 at 11:07:46AM +0100, Paolo Bonzini wrote:
> 
> 
> On 04/01/2016 18:19, Laszlo Ersek wrote:
> > On 12/10/15 19:53, Igor Mammedov wrote:
> >> On Thu, 10 Dec 2015 18:25:34 +0100
> >> Laszlo Ersek  wrote:
> >>
> >>> The ACPI specification (minimally versions 1.0b through 6.0) define
> >>> the FADT.CENTURY field as:
> >>>
> >>>   The RTC CMOS RAM index to the century of data value (hundred and
> >>>   thousand year decimals). If this field contains a zero, then the RTC
> >>>   centenary feature is not supported. If this field has a non-zero
> >>> value, then this field contains an index into RTC RAM space that OSPM
> >>> can use to program the centenary field.
> >>>
> >>> The x86 targets generate ACPI payload, emulate an RTC
> >>> (CONFIG_MC146818RTC), and that RTC supports the "centenary
> >>> feature" (see occurrences of RTC_CENTURY in cmos_ioport_write() and
> >>> cmos_ioport_read() in "hw/timer/mc146818rtc.c".)
> >>>
> >>> However, FADT.CENTURY is left at zero currently:
> >>>
> >>>   [06Ch 0108   1]RTC Century Index : 00
> >>>
> >>> which -- according to analysis done by Ruiyu Ni at Intel -- should
> >>> cause Linux and Windows 8+ to think the RTC centenary feature is
> >>> unavailable, and cause Windows 7 to (incorrectly) assume that the
> >>> offset to use is constant 0x32. (0x32 happens to be the right value
> >>> on QEMU, but Windows 7 is wrong to assume anything at all).
> >>>
> >>> Exposing the right nonzero offset in FADT.CENTURY informs Linux and
> >>> Windows 8+ about the right capabilities of the hardware, plus it
> >>> retrofits our FADT to Windows 7's behavior.
> >>>
> >>> Regression tested with the following guests (all UEFI installs):
> >>> - i386 Q35: Fedora 21 ("Fedlet" edition)
> >>> - x86_64:
> >>>   - i440fx:
> >>> - Fedora 21
> >>> - RHEL 6 and 7
> >>> - Windows 7 and 10
> >>> - Windows Server 2008 R2 and 2012 R2
> >>>   - Q35:
> >>> - Fedora 22
> >>> - Windows 8.1
> >>>
> >>> Cc: "Michael S. Tsirkin"  (supporter:ACPI/SMBIOS)
> >>> Cc: Igor Mammedov  (supporter:ACPI/SMBIOS)
> >>> Cc: Paolo Bonzini  (maintainer:X86)
> >>> Cc: Richard Henderson  (maintainer:X86)
> >>> Cc: Eduardo Habkost  (maintainer:X86)
> >>> Cc: Ruiyu Ni 
> >>> Signed-off-by: Laszlo Ersek 
> >>> ---
> >>>  hw/i386/acpi-build.c | 2 ++
> >>>  1 file changed, 2 insertions(+)
> >>>
> >>> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> >>> index 95e0c65..c5e6c4b 100644
> >>> --- a/hw/i386/acpi-build.c
> >>> +++ b/hw/i386/acpi-build.c
> >>> @@ -42,6 +42,7 @@
> >>>  #include "sysemu/tpm.h"
> >>>  #include "hw/acpi/tpm.h"
> >>>  #include "sysemu/tpm_backend.h"
> >>> +#include "hw/timer/mc146818rtc_regs.h"
> >>>  
> >>>  /* Supported chipsets: */
> >>>  #include "hw/acpi/piix4.h"
> >>> @@ -334,6 +335,7 @@ static void fadt_setup(AcpiFadtDescriptorRev1
> >>> *fadt, AcpiPmInfo *pm) if (max_cpus > 8) {
> >>>  fadt->flags |= cpu_to_le32(1 <<
> >>> ACPI_FADT_F_FORCE_APIC_CLUSTER_MODEL); }
> >>> +fadt->century = RTC_CENTURY;
> >>>  }
> >>>  
> >>>  
> >>
> >> Reviewed-by: Igor Mammedov 
> >>
> > 
> > Thanks.
> > 
> > Can someone please pick up this patch?
> 
> It should probably go in through Michael's tree, but I've queued it too
> so that it isn't forgotten.
> 
> Paolo

Yes - thanks!
I picked this up - should I add your Reviewed-by tag?

Re: [Qemu-devel] [PULL 0/4] Tracing patches

On 7 January 2016 at 09:13, Stefan Hajnoczi  wrote:
> The following changes since commit 38a762fec63fd5c035aae29ba9a77d357e21e4a7:
>
>   Merge remote-tracking branch 
> 'remotes/berrange/tags/pull-crypto-fixes-2015-12-23-1' into staging 
> (2015-12-23 13:53:32 +)
>
> are available in the git repository at:
>
>   git://github.com/stefanha/qemu.git tags/tracing-pull-request
>
> for you to fetch changes up to cef517ca4bf890ef5405aac1b95f75dcda043d6a:
>
>   trace: add make dependencies on tracetool source (2016-01-07 16:59:56 +0800)
>
> 
>
> 

Applied, thanks. (Hopefully this fixes the travis builds.)

-- PMM

Re: [Qemu-devel] [PATCH] hw/i386: fill in the CENTURY field of the FADT (FACP) ACPI table



On 07/01/2016 12:22, Michael S. Tsirkin wrote:
> On Thu, Jan 07, 2016 at 11:07:46AM +0100, Paolo Bonzini wrote:
>>
>>
>> On 04/01/2016 18:19, Laszlo Ersek wrote:
>>> On 12/10/15 19:53, Igor Mammedov wrote:
 On Thu, 10 Dec 2015 18:25:34 +0100
 Laszlo Ersek  wrote:

> The ACPI specification (minimally versions 1.0b through 6.0) define
> the FADT.CENTURY field as:
>
>   The RTC CMOS RAM index to the century of data value (hundred and
>   thousand year decimals). If this field contains a zero, then the RTC
>   centenary feature is not supported. If this field has a non-zero
> value, then this field contains an index into RTC RAM space that OSPM
> can use to program the centenary field.
>
> The x86 targets generate ACPI payload, emulate an RTC
> (CONFIG_MC146818RTC), and that RTC supports the "centenary
> feature" (see occurrences of RTC_CENTURY in cmos_ioport_write() and
> cmos_ioport_read() in "hw/timer/mc146818rtc.c".)
>
> However, FADT.CENTURY is left at zero currently:
>
>   [06Ch 0108   1]RTC Century Index : 00
>
> which -- according to analysis done by Ruiyu Ni at Intel -- should
> cause Linux and Windows 8+ to think the RTC centenary feature is
> unavailable, and cause Windows 7 to (incorrectly) assume that the
> offset to use is constant 0x32. (0x32 happens to be the right value
> on QEMU, but Windows 7 is wrong to assume anything at all).
>
> Exposing the right nonzero offset in FADT.CENTURY informs Linux and
> Windows 8+ about the right capabilities of the hardware, plus it
> retrofits our FADT to Windows 7's behavior.
>
> Regression tested with the following guests (all UEFI installs):
> - i386 Q35: Fedora 21 ("Fedlet" edition)
> - x86_64:
>   - i440fx:
> - Fedora 21
> - RHEL 6 and 7
> - Windows 7 and 10
> - Windows Server 2008 R2 and 2012 R2
>   - Q35:
> - Fedora 22
> - Windows 8.1
>
> Cc: "Michael S. Tsirkin"  (supporter:ACPI/SMBIOS)
> Cc: Igor Mammedov  (supporter:ACPI/SMBIOS)
> Cc: Paolo Bonzini  (maintainer:X86)
> Cc: Richard Henderson  (maintainer:X86)
> Cc: Eduardo Habkost  (maintainer:X86)
> Cc: Ruiyu Ni 
> Signed-off-by: Laszlo Ersek 
> ---
>  hw/i386/acpi-build.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index 95e0c65..c5e6c4b 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -42,6 +42,7 @@
>  #include "sysemu/tpm.h"
>  #include "hw/acpi/tpm.h"
>  #include "sysemu/tpm_backend.h"
> +#include "hw/timer/mc146818rtc_regs.h"
>  
>  /* Supported chipsets: */
>  #include "hw/acpi/piix4.h"
> @@ -334,6 +335,7 @@ static void fadt_setup(AcpiFadtDescriptorRev1
> *fadt, AcpiPmInfo *pm) if (max_cpus > 8) {
>  fadt->flags |= cpu_to_le32(1 <<
> ACPI_FADT_F_FORCE_APIC_CLUSTER_MODEL); }
> +fadt->century = RTC_CENTURY;
>  }
>  
>  

 Reviewed-by: Igor Mammedov 

>>>
>>> Thanks.
>>>
>>> Can someone please pick up this patch?
>>
>> It should probably go in through Michael's tree, but I've queued it too
>> so that it isn't forgotten.
>>
>> Paolo
> 
> Yes - thanks!
> I picked this up - should I add your Reviewed-by tag?

Sure!

Reviewed-by: Paolo Bonzini 

Paolo

[Qemu-devel] [PATCH 5/6] vhost: move virtio 1.0 check to cross-endian helper

Indeed vhost doesn't need to ask for vring endian fixing if the device is
virtio 1.0, since it is already handled by the in-kernel vhost driver. This
patch simply consolidates the logic into the existing helper.

Signed-off-by: Greg Kurz 
Reviewed-by: Cornelia Huck 
---
 hw/virtio/vhost.c |9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index 2e1e792d599e..aef750df22ad 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vhost.c
@@ -750,6 +750,9 @@ static void vhost_log_stop(MemoryListener *listener,
 
 static inline bool vhost_needs_vring_endian(VirtIODevice *vdev)
 {
+if (virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1)) {
+return false;
+}
 #ifdef TARGET_IS_BIENDIAN
 #ifdef HOST_WORDS_BIGENDIAN
 return !virtio_is_big_endian(vdev);
@@ -811,8 +814,7 @@ static int vhost_virtqueue_start(struct vhost_dev *dev,
 return -errno;
 }
 
-if (!virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1) &&
-vhost_needs_vring_endian(vdev)) {
+if (vhost_needs_vring_endian(vdev)) {
 r = vhost_virtqueue_set_vring_endian_legacy(dev,
 virtio_is_big_endian(vdev),
 vhost_vq_index);
@@ -908,8 +910,7 @@ static void vhost_virtqueue_stop(struct vhost_dev *dev,
 /* In the cross-endian case, we need to reset the vring endianness to
  * native as legacy devices expect so by default.
  */
-if (!virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1) &&
-vhost_needs_vring_endian(vdev)) {
+if (vhost_needs_vring_endian(vdev)) {
 r = vhost_virtqueue_set_vring_endian_legacy(dev,
 
!virtio_is_big_endian(vdev),
 vhost_vq_index);

[Qemu-devel] [PATCH 3/6] virtio: drop the virtio_needs_swap() helper

It is not used anymore.

Signed-off-by: Greg Kurz 
---
 include/hw/virtio/virtio-access.h |9 -
 1 file changed, 9 deletions(-)

diff --git a/include/hw/virtio/virtio-access.h 
b/include/hw/virtio/virtio-access.h
index 8aec843c8ff3..a01fff2e51d7 100644
--- a/include/hw/virtio/virtio-access.h
+++ b/include/hw/virtio/virtio-access.h
@@ -143,15 +143,6 @@ static inline uint64_t virtio_ldq_p(VirtIODevice *vdev, 
const void *ptr)
 }
 }
 
-static inline bool virtio_needs_swap(VirtIODevice *vdev)
-{
-#ifdef HOST_WORDS_BIGENDIAN
-return virtio_access_is_big_endian(vdev) ? false : true;
-#else
-return virtio_access_is_big_endian(vdev) ? true : false;
-#endif
-}
-
 static inline uint16_t virtio_tswap16(VirtIODevice *vdev, uint16_t s)
 {
 #ifdef HOST_WORDS_BIGENDIAN

[Qemu-devel] [PATCH 4/6] virtio: move cross-endian helper to vhost

If target is bi-endian (ppc64, arm), the virtio_legacy_is_cross_endian()
indeed returns the runtime state of the virtio device. However, it returns
false unconditionally in the general case. This sounds a bit strange
given the name of the function.

This helper is only useful for vhost actually, where indeed non bi-endian
targets don't have to deal with cross-endian issues.

This patch moves the helper to vhost.c and gives it a more appropriate name.

Signed-off-by: Greg Kurz 
Reviewed-by: Cornelia Huck 
---
 hw/virtio/vhost.c |   17 +++--
 include/hw/virtio/virtio-access.h |   13 -
 2 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index de29968a7945..2e1e792d599e 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vhost.c
@@ -748,6 +748,19 @@ static void vhost_log_stop(MemoryListener *listener,
 /* FIXME: implement */
 }
 
+static inline bool vhost_needs_vring_endian(VirtIODevice *vdev)
+{
+#ifdef TARGET_IS_BIENDIAN
+#ifdef HOST_WORDS_BIGENDIAN
+return !virtio_is_big_endian(vdev);
+#else
+return virtio_is_big_endian(vdev);
+#endif
+#else
+return false;
+#endif
+}
+
 static int vhost_virtqueue_set_vring_endian_legacy(struct vhost_dev *dev,
bool is_big_endian,
int vhost_vq_index)
@@ -799,7 +812,7 @@ static int vhost_virtqueue_start(struct vhost_dev *dev,
 }
 
 if (!virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1) &&
-virtio_legacy_is_cross_endian(vdev)) {
+vhost_needs_vring_endian(vdev)) {
 r = vhost_virtqueue_set_vring_endian_legacy(dev,
 virtio_is_big_endian(vdev),
 vhost_vq_index);
@@ -896,7 +909,7 @@ static void vhost_virtqueue_stop(struct vhost_dev *dev,
  * native as legacy devices expect so by default.
  */
 if (!virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1) &&
-virtio_legacy_is_cross_endian(vdev)) {
+vhost_needs_vring_endian(vdev)) {
 r = vhost_virtqueue_set_vring_endian_legacy(dev,
 
!virtio_is_big_endian(vdev),
 vhost_vq_index);
diff --git a/include/hw/virtio/virtio-access.h 
b/include/hw/virtio/virtio-access.h
index a01fff2e51d7..f1f12afe9089 100644
--- a/include/hw/virtio/virtio-access.h
+++ b/include/hw/virtio/virtio-access.h
@@ -32,19 +32,6 @@ static inline bool virtio_access_is_big_endian(VirtIODevice 
*vdev)
 #endif
 }
 
-static inline bool virtio_legacy_is_cross_endian(VirtIODevice *vdev)
-{
-#ifdef TARGET_IS_BIENDIAN
-#ifdef HOST_WORDS_BIGENDIAN
-return !virtio_is_big_endian(vdev);
-#else
-return virtio_is_big_endian(vdev);
-#endif
-#else
-return false;
-#endif
-}
-
 static inline uint16_t virtio_lduw_phys(VirtIODevice *vdev, hwaddr pa)
 {
 if (virtio_access_is_big_endian(vdev)) {

[Qemu-devel] [PATCH 6/6] virtio: optimize virtio_access_is_big_endian() for little-endian targets

When adding cross-endian support, we introduced the TARGET_IS_BIENDIAN macro
and the virtio_access_is_big_endian() helper to have a branchless fast path
in the virtio memory accessors for targets that don't switch endian.

This was considered as a strong requirement at the time.

Now we have added a runtime check for virtio 1.0, which ruins the benefit
of the virtio_access_is_big_endian() helper for always little-endian targets.

With this patch, always little-endian targets stop checking for virtio 1.0,
since the result is little-endian in all cases.

Signed-off-by: Greg Kurz 
---
 include/hw/virtio/virtio-access.h |3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/hw/virtio/virtio-access.h 
b/include/hw/virtio/virtio-access.h
index f1f12afe9089..fba4b4a4e1b2 100644
--- a/include/hw/virtio/virtio-access.h
+++ b/include/hw/virtio/virtio-access.h
@@ -19,10 +19,13 @@
 
 static inline bool virtio_access_is_big_endian(VirtIODevice *vdev)
 {
+#if defined(TARGET_IS_BIENDIAN) || defined(TARGET_WORDS_BIGENDIAN)
 if (virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1)) {
 /* Devices conforming to VIRTIO 1.0 or later are always LE. */
 return false;
 }
+#endif
+
 #if defined(TARGET_IS_BIENDIAN)
 return virtio_is_big_endian(vdev);
 #elif defined(TARGET_WORDS_BIGENDIAN)

Re: [Qemu-devel] [PATCH v6 5/5] i.MX: move i.MX31 CCM object to register array.

On 19 December 2015 at 21:27, pcrost  wrote:
> On Mon, Dec 07, 2015 at 11:53:42PM +0100, Jean-Christophe Dubois wrote:
>> With this i.MX25 and i.MX31 to have close implementation.
>>
>
> "will have closer implementations".
>
> Otherwise,
>
> Reviewed-by: Peter Crosthwaite 
>
> Peter, do you want to just amend the grammar in the queue?

Yes, I've just applied to target-arm.next with that tweak to
the commit message.

thanks
-- PMM

Re: [Qemu-devel] [PATCH] hw/dma/xilinx_axidma: remove dead code

On 6 January 2016 at 12:53, Andrew Jones  wrote:
> stream_desc_show() (and DEBUG_ENET) appear to be unused, as the
> function isn't compilable (there are broken PRI format strings).
>
> Signed-off-by: Andrew Jones 
> ---
>  hw/dma/xilinx_axidma.c | 10 --
>  1 file changed, 10 deletions(-)
>
> diff --git a/hw/dma/xilinx_axidma.c b/hw/dma/xilinx_axidma.c
> index b1cfa11356a26..f5ebc1f0e0734 100644
> --- a/hw/dma/xilinx_axidma.c
> +++ b/hw/dma/xilinx_axidma.c
> @@ -177,16 +177,6 @@ static inline int streamid_from_addr(hwaddr addr)
>  return sid;
>  }
>
> -#ifdef DEBUG_ENET
> -static void stream_desc_show(struct SDesc *d)
> -{
> -qemu_log("buffer_addr  = " PRIx64 "\n", d->buffer_address);
> -qemu_log("nxtdesc  = " PRIx64 "\n", d->nxtdesc);
> -qemu_log("control  = %x\n", d->control);
> -qemu_log("status   = %x\n", d->status);
> -}
> -#endif
> -
>  static void stream_desc_load(struct Stream *s, hwaddr addr)
>  {
>  struct SDesc *d = &s->desc;



Applied to target-arm.next, thanks.

-- PMM

Re: [Qemu-devel] [PULL 0/5] seabios: update to release 1.9.0

On 5 January 2016 at 12:11, Gerd Hoffmann  wrote:
>   Hi,
>
> This patch series updates seabios to version 1.9.0.
> Pull request is identical to the patch series sent
> to the list before xmas, except that I've dropped
> one patch which got merged through mst already.
>
> please pull,
>   Gerd
>
> The following changes since commit 38a762fec63fd5c035aae29ba9a77d357e21e4a7:
>
>   Merge remote-tracking branch 
> 'remotes/berrange/tags/pull-crypto-fixes-2015-12-23-1' into staging 
> (2015-12-23 13:53:32 +)
>
> are available in the git repository at:
>
>
>   git://git.kraxel.org/qemu tags/pull-seabios-20160105-1
>
> for you to fetch changes up to 4b9294c00e08011793f8869afd893e2fb49dacb3:
>
>   seabios: update binaries to release 1.9.0 (2016-01-05 13:04:15 +0100)
>
> 
> seabios: update to release 1.9.0
>

Applied, thanks.

-- PMM

Re: [Qemu-devel] [PATCH trivial] linux-user: enable sigaltstack for all architectures

On 29 December 2015 at 09:51, Michael Tokarev  wrote:
> There is no reason to limit sigaltstack syscall to just a few
> architectures and pretend it is not implemented for others.
>
> If some architecture is not ready for this, that architecture
> should be fixed instead.
>
> This fixes LP#1516408.
>
> Signed-off-by: Michael Tokarev 
> ---
> This patch depends on a previous patch I sent, "unicore32: convert
> get_sp_from_cpustate from macro to inline", or else unicore32-user
> wont build.
> ---
>  linux-user/syscall.c | 6 --
>  1 file changed, 6 deletions(-)
>
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index 6c64ba6..3ceb3e2 100644
> --- a/linux-user/syscall.c
> +++ b/linux-user/syscall.c
> @@ -8292,14 +8292,8 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
> arg1,
>  break;
>  }
>  case TARGET_NR_sigaltstack:
> -#if defined(TARGET_I386) || defined(TARGET_ARM) || defined(TARGET_MIPS) || \
> -defined(TARGET_SPARC) || defined(TARGET_PPC) || defined(TARGET_ALPHA) || 
> \
> -defined(TARGET_M68K) || defined(TARGET_S390X) || defined(TARGET_OPENRISC)
>  ret = do_sigaltstack(arg1, arg2, get_sp_from_cpustate((CPUArchState 
> *)cpu_env));
>  break;
> -#else
> -goto unimplemented;
> -#endif
>
>  #ifdef CONFIG_SENDFILE
>  case TARGET_NR_sendfile:

Reviewed-by: Peter Maydell 

thanks
-- PMM

Re: [Qemu-devel] [PATCH 00/22] 9pfs: disentangling virtio and generic code

2016-01-07 Thread Stefano Stabellini

On Tue, 5 Jan 2016, Wei Liu wrote:
> Hi all
> 
> Back in 2015 summer one of our OPW interns Linda Jacobson explored the
> possibility of making 9pfs work on Xen. It turned out lots of code in QEMU can
> be reused.
> 
> This series refactors 9pfs related code:
> 
> 1. Rename a bunch of files and functions to make clear they are generic.
> 2. Only export two functions (marshal and unmarshal) from transport to generic
>code.
> 3. disentangle virtio transport code and generic 9pfs code.
> 4. Some function name clean-up.

The series looks pretty good and it looks like a clean improvement over
the current code base.



> To make sure this series doesn't break compilation a rune is use to compile
> every commit.
> 
> $ git rebase -i origin/master --exec "make -j16 clean; ./configure 
> --target-list=x86_64-softmmu --enable-virtfs --enable-kvm; make -j16 && echo 
> ok."
> 
> Three use cases are tested:
> 
> 1. Local file system driver with passthrough security policy
> ./qemu-system-x86_64 -L .  -hda /dev/DATA/jessie   -vnc 0.0.0.0:0,to=99  
> -fsdev local,path=/root/qemu,security_model=passthrough,id=fs1  -device 
> virtio-9p-pci,fsdev=fs1,mount_tag=qemu  &
> 
> 2. Local file system driver with mapped security policy
> ./qemu-system-x86_64 -L . -hda /dev/DATA/jessie -vnc 0.0.0.0:0,to=99 -fsdev 
> local,path=/root/qemu,security_model=mapped,id=fs1 -device 
> virtio-9p-pci,fsdev=fs1,mount_tag=qemu &
> 
> 3. Proxy file system driver
> ./virtfs-proxy-helper -p /root/qemu -n -s virtfs-helper-sock -u 0 -g 0 &
> ./qemu-system-x86_64 -L .  -hda /dev/DATA/jessie   -vnc 0.0.0.0:0,to=99  
> -fsdev proxy,socket=virtfs-helper-sock,id=fs1  -device 
> virtio-9p-pci,fsdev=fs1,mount_tag=qemu &
> 
> During each of the tests, mounting, unmounting, read and write operations are
> performed. In "mapped" test, getfattr in host was used to inspect the
> attributes.
> 
> Let me know if you would like to see more tests.
> 
> Xen transport is still under development. I figure it would be better to post
> this series as soon as possible because rebasing such huge series from time to
> time is prone to error.
> 
> Comments are welcome. Thanks!
> 
> Wei.
> ---
> Cc: "Aneesh Kumar K.V" 
> Cc: Greg Kurz 
> Cc: "Michael S. Tsirkin" 
> Cc: Stefano Stabellini 
> ---
> 
> Wei Liu (22):
>   9pfs: rename virtio-9p-coth.{c,h} to coth.{c,h}
>   9pfs: rename virtio-9p-handle.c to 9p-handle.c
>   9pfs: rename virtio-9p-handle.c to 9p-handle.c
>   9pfs: rename virtio-9p-posix-acl.c to 9p-posix-acl.c
>   9pfs: rename virtio-9p-proxy.{c,h} to 9p-proxy.{c,h}
>   9pfs: rename virtio-9p-synth.{c,h} to 9p-synth.{c,h}
>   9pfs: rename virtio-9p-xattr{,-user}.{c,h} to 9p-xattr{,-user}.{c,h}
>   9pfs: merge hw/virtio/virtio-9p.h into hw/9pfs/virtio-9p.h
>   9pfs: remove dead code
>   fsdev: break out 9p-marshal.{c,h} from virtio-9p-marshal.{c,h}
>   fsdev: 9p-marshal: introduce V9fsBlob
>   9pfs: use V9fsBlob to transmit xattr
>   fsdev: rename virtio-9p-marshal.{c,h} to 9p-iov-marshal.{c,h}
>   9pfs: PDU processing functions don't need to take V9fsState as
> argument
>   9pfs: PDU processing functions should start pdu_ prefix
>   9pfs: make pdu_{,un}marshal proper functions
>   9pfs: factor out virtio_pdu_{,un}marshal
>   9pfs: factor out pdu_push_and_notify
>   9pfs: break out virtio_init_iov_from_pdu
>   9pfs: break out generic code from virtio-9p.{c,h}
>   9pfs: factor out v9fs_device_{,un}realize_common
>   9pfs: disentangle V9fsState
> 
>  Makefile   |   2 +-
>  fsdev/{virtio-9p-marshal.c => 9p-iov-marshal.c}| 205 ++-
>  fsdev/9p-iov-marshal.h |  15 +
>  fsdev/9p-marshal.c |  64 
>  fsdev/{virtio-9p-marshal.h => 9p-marshal.h}|  26 +-
>  fsdev/Makefile.objs|   2 +-
>  fsdev/virtfs-proxy-helper.c|   6 +-
>  hw/9pfs/{virtio-9p-handle.c => 9p-handle.c}|   7 +-
>  hw/9pfs/{virtio-9p-local.c => 9p-local.c}  |   7 +-
>  hw/9pfs/{virtio-9p-posix-acl.c => 9p-posix-acl.c}  |   7 +-
>  hw/9pfs/{virtio-9p-proxy.c => 9p-proxy.c}  |   7 +-
>  hw/9pfs/{virtio-9p-proxy.h => 9p-proxy.h}  |  10 +-
>  hw/9pfs/{virtio-9p-synth.c => 9p-synth.c}  |   6 +-
>  hw/9pfs/{virtio-9p-synth.h => 9p-synth.h}  |   6 +-
>  .../{virtio-9p-xattr-user.c => 9p-xattr-user.c}|   7 +-
>  hw/9pfs/{virtio-9p-xattr.c => 9p-xattr.c}  |   7 +-
>  hw/9pfs/{virtio-9p-xattr.h => 9p-xattr.h}  |   6 +-
>  hw/9pfs/{virtio-9p.c => 9p.c}  | 301 ++--
>  hw/9pfs/9p.h   | 335 ++
>  hw/9pfs/Makefile.objs  |  14 +-
>  hw/9pfs/codir.c|   2 +-
>  hw/9pfs/cofile.c   |   2 +-
>  hw/9pfs/cofs.c |   2 +-
>  hw/9pfs/{virtio-9p-coth.c => coth.c}

Re: [Qemu-devel] [PATCH] Add missing syscall nrs. This updates the QEMU syscall tables to more recent Linux kernels.

On 24 December 2015 at 22:31, Johan Ouwerkerk  wrote:
> This change covers arm, aarch64, mips. Others to follow?
>
> The change was prompted by QEMU warning about a syscall 384 (get_random()) 
> with Debian armhf binaries (ARMv7).

It would be nice if whoever applies this patch could fix
the overlong lines in the commit message.

> Signed-off-by: Johan Ouwerkerk 
> ---
>  linux-user/aarch64/syscall_nr.h | 13 +
>  linux-user/arm/syscall_nr.h | 12 
>  linux-user/mips/syscall_nr.h| 12 
>  3 files changed, 37 insertions(+)

No 64-bit mips to go with the 32-bit change?

Anyway, for the changes in this patch:

Reviewed-by: Peter Maydell 

thanks
-- PMM

Re: [Qemu-devel] [PATCH] SCSI bus: fix to incomplete QOMify

On 07/01/2016 10:53, Cao jin wrote:
> On 01/07/2016 05:38 PM, Paolo Bonzini wrote:
>> On 06/01/2016 14:43, Cao jin wrote:
>> These functions are called in the data path; changes to use SCSI_BUS()
>> should come with performance data proving that it doesn't slow down I/O.
>>
> 
> I see. I am not familiar with the procedure of scsi i/o performance
> test, do have some guideline about it?

Usually people test with FIO, but I think it's simpler to just keep
DO_UPCAST here.

Paolo

Re: [Qemu-devel] [PATCH trivial] linux-user: enable sigaltstack for all architectures

2016-01-07 Thread John Paul Adrian Glaubitz

Hi Peter!

On 01/07/2016 12:52 PM, Peter Maydell wrote:
> Reviewed-by: Peter Maydell 

Has this been committed yet? I can't see the change in cgit.

Cheers,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [Qemu-devel] [PATCH trivial] linux-user: enable sigaltstack for all architectures

On 7 January 2016 at 12:14, John Paul Adrian Glaubitz
 wrote:
> Hi Peter!
>
> On 01/07/2016 12:52 PM, Peter Maydell wrote:
>> Reviewed-by: Peter Maydell 
>
> Has this been committed yet? I can't see the change in cgit.

No. "Reviewed-by" means I just code reviewed it. At some point
it will be picked up by a subtree maintainer (either the
-trivial subtree or the linux-user one). That person will then
at some point send me a pull request for their subtree which
will result in the commit getting merged into master when I
apply that pull request.

thanks
-- PMM

[Qemu-devel] [RFC 01/13] postcopy/migration: Split fault related state into struct UserfaultState

Split fault related state from MigrationIncomingState struct, and put
them all into a new struct UserfaultState. We will add this state into
struct MigrationState in later patch.

We also fix some helper functions to use the new type.

Signed-off-by: zhanghailiang 
---
 include/migration/migration.h| 20 
 include/migration/postcopy-ram.h |  2 +-
 include/qemu/typedefs.h  |  1 +
 migration/postcopy-ram.c | 99 +++-
 migration/savevm.c   |  2 +-
 5 files changed, 72 insertions(+), 52 deletions(-)

diff --git a/include/migration/migration.h b/include/migration/migration.h
index d9494b8..4c80939 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -79,6 +79,16 @@ typedef enum {
 POSTCOPY_INCOMING_END
 } PostcopyState;
 
+struct UserfaultState {
+bool   have_fault_thread;
+QemuThread fault_thread;
+QemuSemaphore  fault_thread_sem;
+/* For the kernel to send us notifications */
+int   userfault_fd;
+/* To tell the fault_thread to quit */
+int   userfault_quit_fd;
+};
+
 /* State for the incoming migration */
 struct MigrationIncomingState {
 QEMUFile *from_src_file;
@@ -89,22 +99,16 @@ struct MigrationIncomingState {
  */
 QemuEvent main_thread_load_event;
 
-bool   have_fault_thread;
-QemuThread fault_thread;
-QemuSemaphore  fault_thread_sem;
-
 bool   have_listen_thread;
 QemuThread listen_thread;
 QemuSemaphore  listen_thread_sem;
 
-/* For the kernel to send us notifications */
-int   userfault_fd;
-/* To tell the fault_thread to quit */
-int   userfault_quit_fd;
 QEMUFile *to_src_file;
 QemuMutex rp_mutex;/* We send replies from multiple threads */
 void *postcopy_tmp_page;
 
+UserfaultState userfault_state;
+
 /* See savevm.c */
 LoadStateEntry_Head loadvm_handlers;
 };
diff --git a/include/migration/postcopy-ram.h b/include/migration/postcopy-ram.h
index b6a7491..e30978f 100644
--- a/include/migration/postcopy-ram.h
+++ b/include/migration/postcopy-ram.h
@@ -20,7 +20,7 @@ bool postcopy_ram_supported_by_host(void);
  * Make all of RAM sensitive to accesses to areas that haven't yet been written
  * and wire up anything necessary to deal with it.
  */
-int postcopy_ram_enable_notify(MigrationIncomingState *mis);
+int postcopy_ram_enable_notify(UserfaultState *us);
 
 /*
  * Initialise postcopy-ram, setting the RAM to a state where we can go into
diff --git a/include/qemu/typedefs.h b/include/qemu/typedefs.h
index 78fe6e8..eda3063 100644
--- a/include/qemu/typedefs.h
+++ b/include/qemu/typedefs.h
@@ -41,6 +41,7 @@ typedef struct MemoryListener MemoryListener;
 typedef struct MemoryMappingList MemoryMappingList;
 typedef struct MemoryRegion MemoryRegion;
 typedef struct MemoryRegionSection MemoryRegionSection;
+typedef struct UserfaultState UserfaultState;
 typedef struct MigrationIncomingState MigrationIncomingState;
 typedef struct MigrationParams MigrationParams;
 typedef struct MigrationState MigrationState;
diff --git a/migration/postcopy-ram.c b/migration/postcopy-ram.c
index 3946aa9..38245d4 100644
--- a/migration/postcopy-ram.c
+++ b/migration/postcopy-ram.c
@@ -233,7 +233,7 @@ static int init_range(const char *block_name, void 
*host_addr,
 static int cleanup_range(const char *block_name, void *host_addr,
 ram_addr_t offset, ram_addr_t length, void *opaque)
 {
-MigrationIncomingState *mis = opaque;
+UserfaultState *us = opaque;
 struct uffdio_range range_struct;
 trace_postcopy_cleanup_range(block_name, host_addr, offset, length);
 
@@ -251,7 +251,7 @@ static int cleanup_range(const char *block_name, void 
*host_addr,
 range_struct.start = (uintptr_t)host_addr;
 range_struct.len = length;
 
-if (ioctl(mis->userfault_fd, UFFDIO_UNREGISTER, &range_struct)) {
+if (ioctl(us->userfault_fd, UFFDIO_UNREGISTER, &range_struct)) {
 error_report("%s: userfault unregister %s", __func__, strerror(errno));
 
 return -1;
@@ -274,36 +274,47 @@ int postcopy_ram_incoming_init(MigrationIncomingState 
*mis, size_t ram_pages)
 return 0;
 }
 
-/*
- * At the end of a migration where postcopy_ram_incoming_init was called.
- */
-int postcopy_ram_incoming_cleanup(MigrationIncomingState *mis)
+static int postcopy_ram_disable_notify(UserfaultState *us)
 {
-trace_postcopy_ram_incoming_cleanup_entry();
-
-if (mis->have_fault_thread) {
+if (us->have_fault_thread) {
 uint64_t tmp64;
 
-if (qemu_ram_foreach_block(cleanup_range, mis)) {
+if (qemu_ram_foreach_block(cleanup_range, us)) {
 return -1;
 }
+
 /*
- * Tell the fault_thread to exit, it's an eventfd that should
- * currently be at 0, we're going to increment it to 1
- */
+* Tell the fault_thread to exit, it's an eventfd that should
+

[Qemu-devel] [RFC 02/13] migration: Allow the migrate command to work on file: urls

Usage:
(qemu) migrate file:/path/to/vm_statefile

Signed-off-by: zhanghailiang 
Signed-off-by: Benoit Canet 
---
- With this patch, we can easily test memory snapshot
- Rebase on qemu 2.5
---
 include/migration/migration.h |  6 +-
 migration/fd.c| 19 +--
 migration/migration.c |  4 +++-
 3 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/include/migration/migration.h b/include/migration/migration.h
index 4c80939..bf4f8e9 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -193,7 +193,11 @@ void unix_start_outgoing_migration(MigrationState *s, 
const char *path, Error **
 
 void fd_start_incoming_migration(const char *path, Error **errp);
 
-void fd_start_outgoing_migration(MigrationState *s, const char *fdname, Error 
**errp);
+void fd_start_outgoing_migration(MigrationState *s, const char *fdname,
+ int outfd, Error **errp);
+
+void file_start_outgoing_migration(MigrationState *s, const char *filename,
+   Error **errp);
 
 void rdma_start_outgoing_migration(void *opaque, const char *host_port, Error 
**errp);
 
diff --git a/migration/fd.c b/migration/fd.c
index 3e4bed0..b62161f 100644
--- a/migration/fd.c
+++ b/migration/fd.c
@@ -42,9 +42,10 @@ static bool fd_is_socket(int fd)
 return S_ISSOCK(stat.st_mode);
 }
 
-void fd_start_outgoing_migration(MigrationState *s, const char *fdname, Error 
**errp)
+void fd_start_outgoing_migration(MigrationState *s, const char *fdname,
+ int outfd, Error **errp)
 {
-int fd = monitor_get_fd(cur_mon, fdname, errp);
+int fd = fdname ? monitor_get_fd(cur_mon, fdname, errp) : outfd;
 if (fd == -1) {
 return;
 }
@@ -58,6 +59,20 @@ void fd_start_outgoing_migration(MigrationState *s, const 
char *fdname, Error **
 migrate_fd_connect(s);
 }
 
+void file_start_outgoing_migration(MigrationState *s, const char *filename,
+   Error **errp)
+{
+int fd;
+
+fd = qemu_open(filename, O_CREAT | O_TRUNC | O_WRONLY, S_IRUSR | S_IWUSR);
+if (fd < 0) {
+error_setg_errno(errp, errno, "Failed to open file: %s", filename);
+return;
+}
+fd_start_outgoing_migration(s, NULL, fd, errp);
+}
+
+
 static void fd_accept_incoming_migration(void *opaque)
 {
 QEMUFile *f = opaque;
diff --git a/migration/migration.c b/migration/migration.c
index c842499..3ec3b85 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -1021,7 +1021,9 @@ void qmp_migrate(const char *uri, bool has_blk, bool blk,
 } else if (strstart(uri, "unix:", &p)) {
 unix_start_outgoing_migration(s, p, &local_err);
 } else if (strstart(uri, "fd:", &p)) {
-fd_start_outgoing_migration(s, p, &local_err);
+fd_start_outgoing_migration(s, p, -1, &local_err);
+} else if (strstart(uri, "file:", &p)) {
+file_start_outgoing_migration(s, p,  &local_err);
 #endif
 } else {
 error_setg(errp, QERR_INVALID_PARAMETER_VALUE, "uri",
-- 
1.8.3.1

[Qemu-devel] [RFC 00/13] Live memory snapshot based on userfaultfd

For now, we still didn't support live memory snapshot, we have discussed
a scheme which based on userfaultfd long time ago.
You can find the discussion by the follow link:
https://lists.nongnu.org/archive/html/qemu-devel/2014-11/msg01779.html

The scheme is based on userfaultfd's write-protect capability.
The userfaultfd write protection feature is available here:
http://www.spinics.net/lists/linux-mm/msg97422.html

The process of this live memory scheme is like bellow:
1. Pause VM
2. Enable write-protect fault notification by using userfaultfd to
mark VM's memory to write-protect (readonly).
3. Save VM's static state (here is device state) to snapshot file
4. Resume VM, VM is going to run.
5. Snapshot thread begins to save VM's live state (here is RAM) into
snapshot file.
6. During this time, all the actions of writing VM's memory will be blocked
by kernel, and kernel will wakeup the fault treating thread in qemu to
process this write-protect fault. The fault treating thread will deliver this
page's address to snapshot thread.
7. snapshot thread gets this address, save this page into snasphot file,
and then remove the write-protect by using userfaultfd API, after that,
the actions of writing will be recovered.
8. Repeat step 5~7 until all VM's memory is saved to snapshot file

Compared with the feature of 'migrate VM's state to file',
the main difference for live memory snapshot is it has little time delay for
catching VM's state. It just captures the VM's state while got users snapshot
command, just like take a photo of VM's state.

For now, we only support tcg accelerator, since userfaultfd is not supporting
tracking write faults for KVM.

Usage:
1. Take a snapshot
#x86_64-softmmu/qemu-system-x86_64 -machine pc-i440fx-2.5,accel=tcg,usb=off
-drive
file=/mnt/windows/win7_install.qcow2.bak,if=none,id=drive-ide0-0-1,format=qcow2,cache=none
-device ide-hd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -vnc :7 -m
8192 -smp 1 -netdev tap,id=bn0 -device virtio-net-pci,id=net-pci0,netdev=bn0
--monitor stdio
Issue snapshot command:
(qemu)migrate -d file:/home/Snapshot
2. Revert to the snapshot
#x86_64-softmmu/qemu-system-x86_64 -machine pc-i440fx-2.5,accel=tcg,usb=off
-drive
file=/mnt/windows/win7_install.qcow2.bak,if=none,id=drive-ide0-0-1,format=qcow2,cache=none
-device ide-hd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -vnc :7 -m
8192 -smp 1 -netdev tap,id=bn0 -device virtio-net-pci,id=net-pci0,netdev=bn0
--monitor stdio -incoming file:/home/Snapshot

NOTE:
The userfaultfd write protection feature does not support THP for now,
Before taking snapshot, please disable THP by:
echo never > /sys/kernel/mm/transparent_hugepage/enabled

TODO:
- Reduce the influence for VM while taking snapshot

zhanghailiang (13):
postcopy/migration: Split fault related state into struct
UserfaultState
migration: Allow the migrate command to work on file: urls
migration: Allow -incoming to work on file: urls
migration: Create a snapshot thread to realize saving memory snapshot
migration: implement initialization work for snapshot
QEMUSizedBuffer: Introduce two help functions for qsb
savevm: Split qemu_savevm_state_complete_precopy() into two helper
functions
snapshot: Save VM's device state into snapshot file
migration/postcopy-ram: fix some helper functions to support
userfaultfd write-protect
snapshot: Enable the write-protect notification capability for VM's
RAM
snapshot/migration: Save VM's RAM into snapshot file
migration/ram: Fix some helper functions' parameter to use
PageSearchStatus
snapshot: Remove page's write-protect and copy the content during
setup stage

--
1.8.3.1

[Qemu-devel] [RFC 08/13] snapshot: Save VM's device state into snapshot file

For live memory snapshot, we want to catch VM's state at the
time of getting snapshot command. So we need to save the VM's
static state (here, it is VM's device state) at the beginning
of snapshot_thread(), but we can't do that while VM is running.
Besides, we can't save device's state into snapshot file directly,
because, we want to re-use the migration's incoming process with
snapshot, we need to keep the save sequence.

So here, we save the VM's device state into qsb temporarily in the
SETUP stage with VM is stopped, and save it into snapshot file after
finishing save VM's live state.

Signed-off-by: zhanghailiang 
---
 include/sysemu/sysemu.h |  3 +++
 migration/migration.c   | 14 --
 migration/savevm.c  | 44 
 3 files changed, 59 insertions(+), 2 deletions(-)

diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 3bb8897..3bc13b6 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -111,6 +111,9 @@ void qemu_savevm_state_begin(QEMUFile *f,
 void qemu_savevm_state_header(QEMUFile *f);
 int qemu_savevm_state_iterate(QEMUFile *f, bool postcopy);
 void qemu_savevm_state_cleanup(void);
+QEMUSizedBuffer *qemu_save_device_buffer(void);
+int qemu_save_buffer_file(MigrationState *s, QEMUSizedBuffer *buffer);
+
 void qemu_savevm_state_complete_postcopy(QEMUFile *f);
 void qemu_savevm_state_complete_precopy(QEMUFile *f, bool iterable_only);
 void qemu_savevm_state_pending(QEMUFile *f, uint64_t max_size,
diff --git a/migration/migration.c b/migration/migration.c
index 7413e0d..fd234eb 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -1742,6 +1742,7 @@ static void *snapshot_thread(void *opaque)
 {
 MigrationState *ms = opaque;;
 bool old_vm_running = false;
+QEMUSizedBuffer *buffer = NULL;
 int ret;
 
 rcu_register_thread();
@@ -1766,7 +1767,7 @@ static void *snapshot_thread(void *opaque)
 }
 }
 
-/* TODO: other setup work */
+buffer = qemu_save_device_buffer();
 
 if (old_vm_running) {
 vm_start();
@@ -1777,7 +1778,16 @@ static void *snapshot_thread(void *opaque)
 
 trace_snapshot_thread_setup_complete();
 
-/* Save VM's state */
+/* Save VM's Live state, such as RAM */
+
+qemu_save_buffer_file(ms, buffer);
+ret = qemu_file_get_error(ms->file);
+if (ret < 0) {
+migrate_set_state(ms, MIGRATION_STATUS_ACTIVE, 
MIGRATION_STATUS_FAILED);
+} else {
+migrate_set_state(ms, MIGRATION_STATUS_ACTIVE,
+  MIGRATION_STATUS_COMPLETED);
+}
 
 qemu_mutex_lock_iothread();
 qemu_savevm_state_cleanup();
diff --git a/migration/savevm.c b/migration/savevm.c
index 1b4e5bd..a59f216 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -59,6 +59,8 @@
 #define ARP_PTYPE_IP 0x0800
 #define ARP_OP_REQUEST_REV 0x3
 
+#define BUFFER_BASE_SIZE (4 * 1024 * 1024)
+
 const unsigned int postcopy_ram_discard_version = 0;
 
 static bool skip_section_footers;
@@ -2206,3 +2208,45 @@ void vmstate_register_ram_global(MemoryRegion *mr)
 {
 vmstate_register_ram(mr, NULL);
 }
+
+QEMUSizedBuffer *qemu_save_device_buffer(void)
+{
+QEMUSizedBuffer *buffer;
+QEMUFile *trans = NULL;
+
+buffer = qsb_create(NULL, BUFFER_BASE_SIZE);
+if (buffer == NULL) {
+error_report("Failed to allocate colo buffer!");
+return NULL;
+}
+
+qsb_set_length(buffer, 0);
+trans = qemu_bufopen("w", buffer);
+if (!trans) {
+error_report("Open qsb buffer for write failed");
+goto error;
+}
+cpu_synchronize_all_states();
+qemu_savevm_section_full(trans);
+qemu_fflush(trans);
+error_report("buffer address 0 :%p", buffer);
+return buffer;
+
+error:
+qsb_free(buffer);
+buffer = NULL;
+return NULL;
+}
+
+int qemu_save_buffer_file(MigrationState *s, QEMUSizedBuffer *buffer)
+{
+size_t size;
+
+size = qsb_get_length(buffer);
+
+qsb_put_buffer(s->file, buffer, size);
+qemu_fflush(s->file);
+qsb_free(buffer);
+buffer = NULL;
+return qemu_file_get_error(s->file);
+}
-- 
1.8.3.1

[Qemu-devel] [RFC 11/13] snapshot/migration: Save VM's RAM into snapshot file

For live memory snapshot, we should capture the VM's state
just at the time of getting snapshot command. For VM's RAM,
they may be dirtied during the process of creating snapshot,
Because VM is still running while we create snapshot.
To catch all the action of writing page, we have remove all pages'
write permission by using userfaultfd, and we also have a thread
to deal with the write-protect notification.

Here, we will read the address of page that will be dirtied, and
then save it into a queue. For snapshot thread, it will save the
page into snapshot file and then remove the write-protect.
In this way, we can ensure, the content of the page in snapshot file is
same with the time we got snapshot command.

Signed-off-by: zhanghailiang 
---
 include/migration/postcopy-ram.h |  4 
 migration/migration.c| 17 +++--
 migration/postcopy-ram.c | 19 +++
 migration/ram.c  | 24 +---
 4 files changed, 55 insertions(+), 9 deletions(-)

diff --git a/include/migration/postcopy-ram.h b/include/migration/postcopy-ram.h
index 978a8d7..bc9ce41 100644
--- a/include/migration/postcopy-ram.h
+++ b/include/migration/postcopy-ram.h
@@ -96,6 +96,10 @@ int postcopy_place_page_zero(MigrationIncomingState *mis, 
void *host);
  */
 void *postcopy_get_tmp_page(MigrationIncomingState *mis);
 
+int ram_set_pages_wp(uint64_t page_addr,
+ uint64_t size,
+ bool remove,
+ int uffd);
 int postcopy_ram_disable_notify(UserfaultState *us);
 
 void qemu_mlock_all_memory(void);
diff --git a/migration/migration.c b/migration/migration.c
index 2001490..3765c3b 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -34,6 +34,7 @@
 #include "exec/memory.h"
 #include "exec/address-spaces.h"
 #include "hw/boards.h" /* Fix me: Remove this if we support snapshot for KVM */
+#include 
 
 #define MAX_THROTTLE  (32 << 20)  /* Migration transfer speed throttling */
 
@@ -1780,7 +1781,19 @@ static void *snapshot_thread(void *opaque)
 
 trace_snapshot_thread_setup_complete();
 
-/* Save VM's Live state, such as RAM */
+while (qemu_file_get_error(ms->file) == 0) {
+if (qemu_savevm_state_iterate(ms->file, false) > 0) {
+break;
+}
+}
+
+ret = qemu_file_get_error(ms->file);
+if (ret == 0) {
+qemu_savevm_state_complete_precopy(ms->file, true);
+} else {
+migrate_set_state(ms, MIGRATION_STATUS_ACTIVE, 
MIGRATION_STATUS_FAILED);
+goto out;
+}
 
 qemu_save_buffer_file(ms, buffer);
 ret = qemu_file_get_error(ms->file);
@@ -1790,7 +1803,7 @@ static void *snapshot_thread(void *opaque)
 migrate_set_state(ms, MIGRATION_STATUS_ACTIVE,
   MIGRATION_STATUS_COMPLETED);
 }
-
+out:
 postcopy_ram_disable_notify(&ms->userfault_state);
 
 qemu_mutex_lock_iothread();
diff --git a/migration/postcopy-ram.c b/migration/postcopy-ram.c
index 9cd854b..61392d3 100644
--- a/migration/postcopy-ram.c
+++ b/migration/postcopy-ram.c
@@ -377,10 +377,10 @@ int postcopy_ram_prepare_discard(MigrationIncomingState 
*mis)
 return 0;
 }
 
-static int ram_set_pages_wp(uint64_t page_addr,
-uint64_t size,
-bool remove,
-int uffd)
+int ram_set_pages_wp(uint64_t page_addr,
+ uint64_t size,
+ bool remove,
+ int uffd)
 {
 struct uffdio_writeprotect wp_struct;
 
@@ -539,6 +539,17 @@ static void *postcopy_ram_fault_thread(void *opaque)
 migrate_send_rp_req_pages(mis, NULL,
   rb_offset, hostpagesize);
 }
+} else { /* UFFDIO_REGISTER_MODE_WP */
+MigrationState *ms = container_of(us, MigrationState,
+  userfault_state);
+ret = ram_save_queue_pages(ms, qemu_ram_get_idstr(rb), rb_offset,
+   hostpagesize);
+
+if (ret < 0) {
+error_report("%s: Save: %"PRIx64 " failed!",
+ __func__, (uint64_t)msg.arg.pagefault.address);
+break;
+}
 }
 }
 trace_postcopy_ram_fault_thread_exit();
diff --git a/migration/ram.c b/migration/ram.c
index c87663f..fc4c788 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -734,7 +734,11 @@ static int ram_save_page(QEMUFile *f, RAMBlock* block, 
ram_addr_t offset,
 ram_addr_t current_addr;
 uint8_t *p;
 int ret;
-bool send_async = true;
+/*
+* For snapshot, we should not be async, or the content of page may be
+* changed before it is really been saved.
+*/
+bool send_async = !migration_in_snapshot(migrate_get_current());
 
 p = block->host + offset;
 
@@ -1087,7 +1091,7 @@ static bool get_queued_page(MigrationState *ms, 
PageSearchS

[Qemu-devel] [RFC 13/13] snapshot: Remove page's write-protect and copy the content during setup stage

If we modify VM's RAM (pages) during setup stage after enable write-protect
notification in snapshot thread, the modification action will get stuck because
we only remove the page's write-protect in savevm process, it blocked by itself.

To fix this bug, we will remove page's write-protect in fault thread during
the setup stage. Besides, we should not try to get global lock after setup 
stage,
or there maybe an deadlock error.

Signed-off-by: zhanghailiang 
---
 include/migration/migration.h |  4 ++--
 migration/migration.c |  2 +-
 migration/postcopy-ram.c  | 17 -
 migration/ram.c   | 37 +++--
 4 files changed, 50 insertions(+), 10 deletions(-)

diff --git a/include/migration/migration.h b/include/migration/migration.h
index ef4c071..435de31 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -127,7 +127,7 @@ struct MigrationSrcPageRequest {
 RAMBlock *rb;
 hwaddroffset;
 hwaddrlen;
-
+uint8_t *pages_copy_addr;
 QSIMPLEQ_ENTRY(MigrationSrcPageRequest) next_req;
 };
 
@@ -333,7 +333,7 @@ void global_state_store_running(void);
 
 void flush_page_queue(MigrationState *ms);
 int ram_save_queue_pages(MigrationState *ms, const char *rbname,
- ram_addr_t start, ram_addr_t len);
+ ram_addr_t start, ram_addr_t len, bool copy_pages);
 
 PostcopyState postcopy_state_get(void);
 /* Set the state and return the old state */
diff --git a/migration/migration.c b/migration/migration.c
index 3765c3b..bf4c7a1 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -1248,7 +1248,7 @@ static void migrate_handle_rp_req_pages(MigrationState 
*ms, const char* rbname,
 return;
 }
 
-if (ram_save_queue_pages(ms, rbname, start, len)) {
+if (ram_save_queue_pages(ms, rbname, start, len, false)) {
 mark_source_rp_bad(ms);
 }
 }
diff --git a/migration/postcopy-ram.c b/migration/postcopy-ram.c
index 61392d3..2cf477d 100644
--- a/migration/postcopy-ram.c
+++ b/migration/postcopy-ram.c
@@ -543,13 +543,28 @@ static void *postcopy_ram_fault_thread(void *opaque)
 MigrationState *ms = container_of(us, MigrationState,
   userfault_state);
 ret = ram_save_queue_pages(ms, qemu_ram_get_idstr(rb), rb_offset,
-   hostpagesize);
+   hostpagesize, true);
 
 if (ret < 0) {
 error_report("%s: Save: %"PRIx64 " failed!",
  __func__, (uint64_t)msg.arg.pagefault.address);
 break;
 }
+
+/* Note: In the setup process, snapshot_thread may modify VM's
+* write-protected pages, we should not block it there, or there
+* will be an deadlock error.
+*/
+if (migration_in_setup(ms)) {
+uint64_t host = msg.arg.pagefault.address;
+
+host &= ~(hostpagesize - 1);
+ret = ram_set_pages_wp(host, getpagesize(), true,
+   us->userfault_fd);
+if (ret < 0) {
+error_report("Remove page's write-protect failed");
+}
+}
 }
 }
 trace_postcopy_ram_fault_thread_exit();
diff --git a/migration/ram.c b/migration/ram.c
index 8656719..747f9aa 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -233,6 +233,7 @@ struct PageSearchStatus {
 ram_addr_t   offset;
 /* Set once we wrap around */
 bool complete_round;
+uint8_t *pages_copy;
 };
 typedef struct PageSearchStatus PageSearchStatus;
 
@@ -742,7 +743,12 @@ static int ram_save_page(QEMUFile *f, PageSearchStatus 
*pss,
 RAMBlock *block = pss->block;
 ram_addr_t offset = pss->offset;
 
-p = block->host + offset;
+/* If we have a copy of this page, use the backup page first */
+if (pss->pages_copy) {
+p = pss->pages_copy;
+} else {
+p = block->host + offset;
+}
 
 /* In doubt sent page as normal */
 bytes_xmit = 0;
@@ -926,7 +932,12 @@ static int ram_save_compressed_page(QEMUFile *f, 
PageSearchStatus *pss,
 RAMBlock *block = pss->block;
 ram_addr_t offset = pss->offset;
 
-p = block->host + offset;
+/* If we have a copy of this page, use the backup first */
+if (pss->pages_copy) {
+p = pss->pages_copy;
+} else {
+p = block->host + offset;
+}
 
 bytes_xmit = 0;
 ret = ram_control_save_page(f, block->offset,
@@ -1043,7 +1054,7 @@ static bool find_dirty_block(QEMUFile *f, 
PageSearchStatus *pss,
  * Returns:  block (or NULL if none available)
  */
 static RAMBlock *unqueue_page(MigrationState *ms, ram_addr_t *offset,
-  ram_addr_t *ram_addr_abs)
+  ram_addr_t *ram_addr_abs, uint8 
**pages_copy_addr)

[Qemu-devel] [RFC 12/13] migration/ram: Fix some helper functions' parameter to use PageSearchStatus

Some helper functions use parameters 'RAMBlock *block' and 'ram_addr_t *offset',
We can use 'PageSearchStatus *pss' directly instead, with this change, we
can reduce the number of parameters for these helper function, also
it is easily to add new parameters for these helper functions.

Signed-off-by: zhanghailiang 
---
 migration/ram.c | 33 +++--
 1 file changed, 19 insertions(+), 14 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index fc4c788..8656719 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -726,7 +726,7 @@ static int save_zero_page(QEMUFile *f, RAMBlock *block, 
ram_addr_t offset,
  * @last_stage: if we are at the completion stage
  * @bytes_transferred: increase it with the number of transferred bytes
  */
-static int ram_save_page(QEMUFile *f, RAMBlock* block, ram_addr_t offset,
+static int ram_save_page(QEMUFile *f, PageSearchStatus *pss,
  bool last_stage, uint64_t *bytes_transferred)
 {
 int pages = -1;
@@ -739,6 +739,8 @@ static int ram_save_page(QEMUFile *f, RAMBlock* block, 
ram_addr_t offset,
 * changed before it is really been saved.
 */
 bool send_async = !migration_in_snapshot(migrate_get_current());
+RAMBlock *block = pss->block;
+ram_addr_t offset = pss->offset;
 
 p = block->host + offset;
 
@@ -913,14 +915,16 @@ static int compress_page_with_multi_thread(QEMUFile *f, 
RAMBlock *block,
  * @last_stage: if we are at the completion stage
  * @bytes_transferred: increase it with the number of transferred bytes
  */
-static int ram_save_compressed_page(QEMUFile *f, RAMBlock *block,
-ram_addr_t offset, bool last_stage,
+static int ram_save_compressed_page(QEMUFile *f, PageSearchStatus *pss,
+bool last_stage,
 uint64_t *bytes_transferred)
 {
 int pages = -1;
 uint64_t bytes_xmit;
 uint8_t *p;
 int ret;
+RAMBlock *block = pss->block;
+ram_addr_t offset = pss->offset;
 
 p = block->host + offset;
 
@@ -1230,7 +1234,7 @@ err:
  * Returns: Number of pages written.
  */
 static int ram_save_target_page(MigrationState *ms, QEMUFile *f,
-RAMBlock *block, ram_addr_t offset,
+PageSearchStatus *pss,
 bool last_stage,
 uint64_t *bytes_transferred,
 ram_addr_t dirty_ram_abs)
@@ -1241,11 +1245,11 @@ static int ram_save_target_page(MigrationState *ms, 
QEMUFile *f,
 if (migration_bitmap_clear_dirty(dirty_ram_abs)) {
 unsigned long *unsentmap;
 if (compression_switch && migrate_use_compression()) {
-res = ram_save_compressed_page(f, block, offset,
+res = ram_save_compressed_page(f, pss,
last_stage,
bytes_transferred);
 } else {
-res = ram_save_page(f, block, offset, last_stage,
+res = ram_save_page(f, pss, last_stage,
 bytes_transferred);
 }
 
@@ -1261,7 +1265,7 @@ static int ram_save_target_page(MigrationState *ms, 
QEMUFile *f,
  * to the stream.
  */
 if (res > 0) {
-last_sent_block = block;
+last_sent_block = pss->block;
 }
 }
 
@@ -1285,26 +1289,27 @@ static int ram_save_target_page(MigrationState *ms, 
QEMUFile *f,
  * @bytes_transferred: increase it with the number of transferred bytes
  * @dirty_ram_abs: Address of the start of the dirty page in ram_addr_t space
  */
-static int ram_save_host_page(MigrationState *ms, QEMUFile *f, RAMBlock *block,
-  ram_addr_t *offset, bool last_stage,
+static int ram_save_host_page(MigrationState *ms, QEMUFile *f,
+  PageSearchStatus *pss,
+  bool last_stage,
   uint64_t *bytes_transferred,
   ram_addr_t dirty_ram_abs)
 {
 int tmppages, pages = 0;
 do {
-tmppages = ram_save_target_page(ms, f, block, *offset, last_stage,
+tmppages = ram_save_target_page(ms, f, pss, last_stage,
 bytes_transferred, dirty_ram_abs);
 if (tmppages < 0) {
 return tmppages;
 }
 
 pages += tmppages;
-*offset += TARGET_PAGE_SIZE;
+pss->offset += TARGET_PAGE_SIZE;
 dirty_ram_abs += TARGET_PAGE_SIZE;
-} while (*offset & (qemu_host_page_size - 1));
+} while (pss->offset & (qemu_host_page_size - 1));
 
 /* The offset we leave with is the last one we looked at */
-*offset -= TARGET_PAGE_SIZE;
+pss->offset -= TARGET_PAGE_SIZE;
 return pages;
 }
 
@@ -1352,7 +1357,7 @@ static int ram_find_and_save_block(QEMUFile *f, bool 
last_stage,
 }
 
 if (foun

Re: [Qemu-devel] [PATCH trivial] linux-user: enable sigaltstack for all architectures

2016-01-07 Thread John Paul Adrian Glaubitz

On 01/07/2016 01:18 PM, Peter Maydell wrote:
> No. "Reviewed-by" means I just code reviewed it.

Yeah, that is clear :-).

> it will be picked up by a subtree maintainer (either the
> -trivial subtree or the linux-user one). That person will then
> at some point send me a pull request for their subtree which
> will result in the commit getting merged into master when I
> apply that pull request.

Ok, I didn't know qemu has subtrees as well as the kernel. I
thought it would be easier to send in drive-by patches as
in systemd, for example.

PS: In order to make qemu-sh4 actually usable again, it would
be great if the setup_frame changes by Laurent Vivier [1]
could be merged as well. Without the fix, qemu-user reproducibly
segfaults when emulating sh4 [2].

> [1] https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg04883.html
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805827

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [Qemu-devel] [PATCH] i386: avoid null pointer dereference



On 04/01/2016 16:49, P J P wrote:
> +-- On Fri, 18 Dec 2015, P J P wrote --+
> | A null pointer dereference issue was reported by Mr Ling Liu, CC'd here. It
> | occurs while doing I/O port write operations via hmp interface. In that,
> | 'current_cpu' remains null as it is not called from cpu_exec loop, which
> | results in the said issue.
> 
> Ping..! -> https://patchwork.ozlabs.org/patch/558748/

I was on vacation until today.  I'll send a pull request some time next
week.

Paolo

Re: [Qemu-devel] [PATCH v2 0/3] qemu-nbd.texi formatting, grammar and completeness fixes



On 05/01/2016 08:33, Sitsofe Wheeler wrote:
> Bring the qemu-nbd man page up to date with options and fix some styling and
> grammar issues along the way.
> 
> Changes from v1:
> - Add disconnect usage to synopsis.
> - Add styling to synopsis usage.
> - Fix up the grammar in the description.
> - Move filename variable description out of the option table.
> - Add a description of the NBD dev variable.
> - Add reference to qemu man page to see also section.
> - Fix sentence capitalisation in options section.
> 
> Sitsofe Wheeler (3):
>   qemu-nbd: Fix unintended texi verbatim formatting
>   qemu-nbd: Minor texi updates
>   qemu-nbd: Fix texi sentence capitalisation
> 
>  qemu-nbd.texi | 80 
> +--
>  1 file changed, 45 insertions(+), 35 deletions(-)
> 

Thanks, queued.  Will send a pull request some time next week.

Paolo

Re: [Qemu-devel] [PULL] qemu-sparc update

2016-01-07 Thread Mark Cave-Ayland

On 07/01/16 12:24, Mark Cave-Ayland wrote:

> Hi Peter,
> 
> Happy New Year! Here is the series from last year containing the sun4u timer 
> updates, please pull.
> 
> 
> Many thanks,
> 
> Mark.

Ah wait please ignore this - I accidentally ran the script to push to
the OpenBIOS branch by accident :(

Will resend shortly.


ATB,

Mark.

[Qemu-devel] [PULLv2] qemu-sparc update

2016-01-07 Thread Mark Cave-Ayland

Hi Peter,

Happy New Year! Here is the series from last year containing the sun4u timer 
updates, please pull (this time with correct tag).


Many thanks,

Mark.


The following changes since commit ac93a067868453c3b3bcef830f336e8107afdc9e:

  Merge remote-tracking branch 'remotes/kraxel/tags/pull-seabios-20160105-1' 
into staging (2016-01-07 11:22:18 +)

are available in the git repository at:


  https://github.com/mcayland/qemu.git tags/qemu-sparc-signed

for you to fetch changes up to c9a464420d7eb67dace1f630554245360b4c7c5b:

  target-sparc: implement NPT timer bit (2016-01-07 12:21:06 +)


qemu-sparc update


Mark Cave-Ayland (3):
  sun4u: split out NPT and INT_DIS into separate CPUTimer fields
  sun4u: split NPT and INT_DIS accesses between timer and compare registers
  target-sparc: implement NPT timer bit

 hw/sparc64/sun4u.c   |   36 +++-
 target-sparc/cpu.h   |2 ++
 target-sparc/helper.c|   10 --
 target-sparc/helper.h|2 +-
 target-sparc/translate.c |   18 +++---
 5 files changed, 49 insertions(+), 19 deletions(-)

Re: [Qemu-devel] [PATCH] s390: Introduce CCW_COMPAT_2_5

On Wed, 23 Dec 2015 21:42:11 +0200
Shmulik Ladkani  wrote:

> In 240240d5 'pc: Add pc-*-2.6 machine classes' HW_COMPAT_2_5 and
> PC_COMPAT_2_5 were introduced.
> 
> Accordingly, introduce CCW_COMPAT_2_5 that uses HW_COMPAT_2_5.
> 
> Signed-off-by: Shmulik Ladkani 
> ---
>  hw/s390x/s390-virtio-ccw.c | 9 +
>  1 file changed, 9 insertions(+)

Thanks, applied to my s390-next branch (after fixing up a trivial
conflict).

[Qemu-devel] [PATCH v2 3/9] s390x: remove s390-virtio devices

From: Pierre Morel 

The s390-virtio machine has been removed; remove the associated devices
as well.

hw/s390x/s390-virtio-bus.c and hw/s390x/s390-virtio-bus.h
have been deleted and removed from hw/s390x/Makefile.objs

virtio-size has no more meaning for the modern machine
and has been removed from helper.c and cpu.h

virtio-serial-s390 belonging to the old machine is
being removed from vl.c

Signed-off-by: Pierre Morel 
Acked-by: Cornelia Huck 
Signed-off-by: Cornelia Huck 
---
 hw/s390x/Makefile.objs |   2 +-
 hw/s390x/s390-virtio-bus.c | 758 -
 hw/s390x/s390-virtio-bus.h | 186 ---
 hw/s390x/s390-virtio.c |   1 -
 target-s390x/cpu.h |   3 -
 target-s390x/helper.c  |   2 +-
 vl.c   |   7 +-
 7 files changed, 3 insertions(+), 956 deletions(-)
 delete mode 100644 hw/s390x/s390-virtio-bus.c
 delete mode 100644 hw/s390x/s390-virtio-bus.h

diff --git a/hw/s390x/Makefile.objs b/hw/s390x/Makefile.objs
index 527d754..2203617 100644
--- a/hw/s390x/Makefile.objs
+++ b/hw/s390x/Makefile.objs
@@ -1,4 +1,4 @@
-obj-y = s390-virtio-bus.o s390-virtio.o
+obj-y += s390-virtio.o
 obj-y += s390-virtio-hcall.o
 obj-y += sclp.o
 obj-y += event-facility.o
diff --git a/hw/s390x/s390-virtio-bus.c b/hw/s390x/s390-virtio-bus.c
deleted file mode 100644
index 98cb129..000
--- a/hw/s390x/s390-virtio-bus.c
+++ /dev/null
@@ -1,758 +0,0 @@
-/*
- * QEMU S390 virtio target
- *
- * Copyright (c) 2009 Alexander Graf 
- *
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2 of the License, or (at your option) any later version.
- *
- * 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 .
- */
-
-#include "hw/hw.h"
-#include "sysemu/block-backend.h"
-#include "sysemu/sysemu.h"
-#include "hw/boards.h"
-#include "hw/loader.h"
-#include "elf.h"
-#include "hw/virtio/virtio.h"
-#include "hw/virtio/virtio-rng.h"
-#include "hw/virtio/virtio-serial.h"
-#include "hw/virtio/virtio-net.h"
-#include "hw/virtio/vhost-scsi.h"
-#include "hw/sysbus.h"
-#include "sysemu/kvm.h"
-
-#include "hw/s390x/s390-virtio-bus.h"
-#include "hw/virtio/virtio-bus.h"
-
-/* #define DEBUG_S390 */
-
-#ifdef DEBUG_S390
-#define DPRINTF(fmt, ...) \
-do { fprintf(stderr, fmt, ## __VA_ARGS__); } while (0)
-#else
-#define DPRINTF(fmt, ...) \
-do { } while (0)
-#endif
-
-#define VIRTIO_S390_QUEUE_MAX 64
-
-static void virtio_s390_bus_new(VirtioBusState *bus, size_t bus_size,
-VirtIOS390Device *dev);
-
-static const TypeInfo s390_virtio_bus_info = {
-.name = TYPE_S390_VIRTIO_BUS,
-.parent = TYPE_BUS,
-.instance_size = sizeof(VirtIOS390Bus),
-};
-
-static ram_addr_t s390_virtio_device_num_vq(VirtIOS390Device *dev);
-
-/* length of VirtIO device pages */
-const hwaddr virtio_size = S390_DEVICE_PAGES * TARGET_PAGE_SIZE;
-
-static void s390_virtio_bus_reset(void *opaque)
-{
-VirtIOS390Bus *bus = opaque;
-bus->next_ring = bus->dev_page + TARGET_PAGE_SIZE;
-}
-
-void s390_virtio_reset_idx(VirtIOS390Device *dev)
-{
-int i;
-hwaddr idx_addr;
-uint8_t num_vq;
-
-num_vq = s390_virtio_device_num_vq(dev);
-for (i = 0; i < num_vq; i++) {
-idx_addr = virtio_queue_get_avail_addr(dev->vdev, i) +
-VIRTIO_VRING_AVAIL_IDX_OFFS;
-address_space_stw(&address_space_memory, idx_addr, 0,
-  MEMTXATTRS_UNSPECIFIED, NULL);
-idx_addr = virtio_queue_get_avail_addr(dev->vdev, i) +
-virtio_queue_get_avail_size(dev->vdev, i);
-address_space_stw(&address_space_memory, idx_addr, 0,
-  MEMTXATTRS_UNSPECIFIED, NULL);
-idx_addr = virtio_queue_get_used_addr(dev->vdev, i) +
-VIRTIO_VRING_USED_IDX_OFFS;
-address_space_stw(&address_space_memory, idx_addr, 0,
-  MEMTXATTRS_UNSPECIFIED, NULL);
-idx_addr = virtio_queue_get_used_addr(dev->vdev, i) +
-virtio_queue_get_used_size(dev->vdev, i);
-address_space_stw(&address_space_memory, idx_addr, 0,
-  MEMTXATTRS_UNSPECIFIED, NULL);
-}
-}
-
-VirtIOS390Bus *s390_virtio_bus_init(ram_addr_t *ram_size)
-{
-VirtIOS390Bus *bus;
-BusState *_bus;
-DeviceState *dev;
-
-/* Create bridge device */
-dev = qdev_create(NULL, "s390-virtio-bridge");
-qdev_init_nofail(dev);
-
-/* Create bus on bridge device */
-
-_bus = qbus_create(TYPE_S390_VIRTIO_BUS, dev, "s390-virtio");
-bus = DO_

[Qemu-devel] [PATCH v2 0/9] First set of s390x patches for 2.6

Added three more patches to the patchset I sent before Christmas
and rebased to current master.

This first round of s390x patches includes:
- new compat machine
- remove the old s390-virtio machine (would like an ack from Alex
  on this)
- fixes and some cleanup

Cornelia Huck (2):
  s390x: add 2.6 compat machine
  s390x/virtio: use qemu_check_nic_model()

Halil Pasic (1):
  virtio-ccw: fix sanity check for vector

Pierre Morel (2):
  s390x: remove s390-virtio machine
  s390x: remove s390-virtio devices

Shmulik Ladkani (1):
  s390: Introduce CCW_COMPAT_2_5

Yi Min Zhao (3):
  s390x/pci: reject some operations to disabled PCI function
  s390x/pci: code cleanup
  s390x/pci: return real state during listing PCI

 hw/s390x/Makefile.objs |   2 +-
 hw/s390x/s390-pci-bus.c|   6 +-
 hw/s390x/s390-pci-bus.h|   1 +
 hw/s390x/s390-pci-inst.c   |  20 +-
 hw/s390x/s390-virtio-bus.c | 758 -
 hw/s390x/s390-virtio-bus.h | 186 ---
 hw/s390x/s390-virtio-ccw.c |  27 +-
 hw/s390x/s390-virtio.c | 168 +-
 hw/s390x/virtio-ccw.c  |   3 +-
 target-s390x/cpu.h |   3 -
 target-s390x/helper.c  |   2 +-
 vl.c   |   7 +-
 12 files changed, 47 insertions(+), 1136 deletions(-)
 delete mode 100644 hw/s390x/s390-virtio-bus.c
 delete mode 100644 hw/s390x/s390-virtio-bus.h

-- 
2.6.4

[Qemu-devel] [PATCH v2 5/9] s390x/pci: code cleanup

From: Yi Min Zhao 

Make use of the new FH_ENABLED define in existing code.

Signed-off-by: Yi Min Zhao 
Reviewed-by: Cornelia Huck 
Signed-off-by: Cornelia Huck 
---
 hw/s390x/s390-pci-inst.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/hw/s390x/s390-pci-inst.c b/hw/s390x/s390-pci-inst.c
index df57a7d..d521b2b 100644
--- a/hw/s390x/s390-pci-inst.c
+++ b/hw/s390x/s390-pci-inst.c
@@ -208,12 +208,12 @@ int clp_service_call(S390CPU *cpu, uint8_t r2)
 
 switch (reqsetpci->oc) {
 case CLP_SET_ENABLE_PCI_FN:
-pbdev->fh = pbdev->fh | 1 << ENABLE_BIT_OFFSET;
+pbdev->fh = pbdev->fh | FH_ENABLED;
 stl_p(&ressetpci->fh, pbdev->fh);
 stw_p(&ressetpci->hdr.rsp, CLP_RC_OK);
 break;
 case CLP_SET_DISABLE_PCI_FN:
-pbdev->fh = pbdev->fh & ~(1 << ENABLE_BIT_OFFSET);
+pbdev->fh = pbdev->fh & ~FH_ENABLED;
 pbdev->error_state = false;
 pbdev->lgstg_blocked = false;
 stl_p(&ressetpci->fh, pbdev->fh);
@@ -818,7 +818,7 @@ int stpcifc_service_call(S390CPU *cpu, uint8_t r1, uint64_t 
fiba, uint8_t ar)
((uint32_t)pbdev->sum << 7) | pbdev->routes.adapter.summary_offset;
 stl_p(&fib.data, data);
 
-if (pbdev->fh >> ENABLE_BIT_OFFSET) {
+if (pbdev->fh & FH_ENABLED) {
 fib.fc |= 0x80;
 }
 
-- 
2.6.4

[Qemu-devel] [PATCH v2 1/9] s390x: add 2.6 compat machine

New qemu version, new machine.

Signed-off-by: Cornelia Huck 
---
 hw/s390x/s390-virtio-ccw.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index 5a52ff2..8d7d04b 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -297,9 +297,7 @@ static void ccw_machine_2_5_class_init(ObjectClass *oc, 
void *data)
 {
 MachineClass *mc = MACHINE_CLASS(oc);
 
-mc->alias = "s390-ccw-virtio";
 mc->desc = "VirtIO-ccw based S390 machine v2.5";
-mc->is_default = 1;
 }
 
 static const TypeInfo ccw_machine_2_5_info = {
@@ -308,11 +306,27 @@ static const TypeInfo ccw_machine_2_5_info = {
 .class_init= ccw_machine_2_5_class_init,
 };
 
+static void ccw_machine_2_6_class_init(ObjectClass *oc, void *data)
+{
+MachineClass *mc = MACHINE_CLASS(oc);
+
+mc->alias = "s390-ccw-virtio";
+mc->desc = "VirtIO-ccw based S390 machine v2.6";
+mc->is_default = 1;
+}
+
+static const TypeInfo ccw_machine_2_6_info = {
+.name  = MACHINE_TYPE_NAME("s390-ccw-virtio-2.6"),
+.parent= TYPE_S390_CCW_MACHINE,
+.class_init= ccw_machine_2_6_class_init,
+};
+
 static void ccw_machine_register_types(void)
 {
 type_register_static(&ccw_machine_info);
 type_register_static(&ccw_machine_2_4_info);
 type_register_static(&ccw_machine_2_5_info);
+type_register_static(&ccw_machine_2_6_info);
 }
 
 type_init(ccw_machine_register_types)
-- 
2.6.4

[Qemu-devel] [PATCH v2 9/9] s390x/pci: return real state during listing PCI

From: Yi Min Zhao 

At present, list_pci() shows all PCI devices as being in configured
state. As devices can be deconfigured by the guest, we need to show
the real configuration status instead.

Signed-off-by: Yi Min Zhao 
Reviewed-by: Cornelia Huck 
Signed-off-by: Cornelia Huck 
---
 hw/s390x/s390-pci-inst.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/s390x/s390-pci-inst.c b/hw/s390x/s390-pci-inst.c
index d521b2b..1a6a3e7 100644
--- a/hw/s390x/s390-pci-inst.c
+++ b/hw/s390x/s390-pci-inst.c
@@ -105,7 +105,8 @@ static int list_pci(ClpReqRspListPci *rrb, uint8_t *cc)
 pci_get_word(pbdev->pdev->config + PCI_DEVICE_ID));
 stw_p(&rrb->response.fh_list[idx - resume_token].vendor_id,
 pci_get_word(pbdev->pdev->config + PCI_VENDOR_ID));
-stl_p(&rrb->response.fh_list[idx - resume_token].config, 0x8000);
+stl_p(&rrb->response.fh_list[idx - resume_token].config,
+pbdev->configured << 31);
 stl_p(&rrb->response.fh_list[idx - resume_token].fid, pbdev->fid);
 stl_p(&rrb->response.fh_list[idx - resume_token].fh, pbdev->fh);
 
-- 
2.6.4

[Qemu-devel] [PATCH v2 2/9] s390x: remove s390-virtio machine

From: Pierre Morel 

Remove machine code for the s390-virtio machine, but keep functions
useful for the ccw machine.

Signed-off-by: Pierre Morel 
Acked-by: Cornelia Huck 
Signed-off-by: Cornelia Huck 
---
 hw/s390x/s390-virtio.c | 162 -
 1 file changed, 162 deletions(-)

diff --git a/hw/s390x/s390-virtio.c b/hw/s390x/s390-virtio.c
index ae55760..e4ecf0d 100644
--- a/hw/s390x/s390-virtio.c
+++ b/hw/s390x/s390-virtio.c
@@ -61,7 +61,6 @@
 #define S390_TOD_CLOCK_VALUE_MISSING0x00
 #define S390_TOD_CLOCK_VALUE_PRESENT0x01
 
-static VirtIOS390Bus *s390_bus;
 static S390CPU **ipi_states;
 
 S390CPU *s390_cpu_addr2state(uint16_t cpu_addr)
@@ -73,78 +72,6 @@ S390CPU *s390_cpu_addr2state(uint16_t cpu_addr)
 return ipi_states[cpu_addr];
 }
 
-static int s390_virtio_hcall_notify(const uint64_t *args)
-{
-uint64_t mem = args[0];
-int r = 0, i;
-
-if (mem > ram_size) {
-VirtIOS390Device *dev = s390_virtio_bus_find_vring(s390_bus, mem, &i);
-if (dev) {
-/*
- * Older kernels will use the virtqueue before setting DRIVER_OK.
- * In this case the feature bits are not yet up to date, meaning
- * that several funny things can happen, e.g. the guest thinks
- * EVENT_IDX is on and QEMU thinks it is off. Let's force a feature
- * and status sync.
- */
-if (!(dev->vdev->status & VIRTIO_CONFIG_S_DRIVER_OK)) {
-s390_virtio_device_update_status(dev);
-}
-virtio_queue_notify(dev->vdev, i);
-} else {
-r = -EINVAL;
-}
-} else {
-/* Early printk */
-}
-return r;
-}
-
-static int s390_virtio_hcall_reset(const uint64_t *args)
-{
-uint64_t mem = args[0];
-VirtIOS390Device *dev;
-
-dev = s390_virtio_bus_find_mem(s390_bus, mem);
-if (dev == NULL) {
-return -EINVAL;
-}
-virtio_reset(dev->vdev);
-address_space_stb(&address_space_memory,
-  dev->dev_offs + VIRTIO_DEV_OFFS_STATUS, 0,
-  MEMTXATTRS_UNSPECIFIED, NULL);
-s390_virtio_device_sync(dev);
-s390_virtio_reset_idx(dev);
-
-return 0;
-}
-
-static int s390_virtio_hcall_set_status(const uint64_t *args)
-{
-uint64_t mem = args[0];
-int r = 0;
-VirtIOS390Device *dev;
-
-dev = s390_virtio_bus_find_mem(s390_bus, mem);
-if (dev) {
-s390_virtio_device_update_status(dev);
-} else {
-r = -EINVAL;
-}
-return r;
-}
-
-static void s390_virtio_register_hcalls(void)
-{
-s390_register_virtio_hypercall(KVM_S390_VIRTIO_NOTIFY,
-   s390_virtio_hcall_notify);
-s390_register_virtio_hypercall(KVM_S390_VIRTIO_RESET,
-   s390_virtio_hcall_reset);
-s390_register_virtio_hypercall(KVM_S390_VIRTIO_SET_STATUS,
-   s390_virtio_hcall_set_status);
-}
-
 void s390_init_ipl_dev(const char *kernel_filename,
const char *kernel_cmdline,
const char *initrd_filename,
@@ -261,58 +188,6 @@ int gtod_load(QEMUFile *f, void *opaque, int version_id)
 return 0;
 }
 
-/* PC hardware initialisation */
-static void s390_init(MachineState *machine)
-{
-ram_addr_t my_ram_size;
-void *virtio_region;
-hwaddr virtio_region_len;
-hwaddr virtio_region_start;
-
-if (!qtest_enabled()) {
-error_printf("WARNING\n"
- "The s390-virtio machine (non-ccw) is deprecated.\n"
- "It will be removed in 2.6. Please use 
s390-ccw-virtio\n");
-}
-
-if (machine->ram_slots) {
-error_report("Memory hotplug not supported by the selected machine.");
-exit(EXIT_FAILURE);
-}
-s390_sclp_init();
-my_ram_size = machine->ram_size;
-
-/* get a BUS */
-s390_bus = s390_virtio_bus_init(&my_ram_size);
-s390_init_ipl_dev(machine->kernel_filename, machine->kernel_cmdline,
-  machine->initrd_filename, ZIPL_FILENAME, false);
-s390_flic_init();
-
-/* register hypercalls */
-s390_virtio_register_hcalls();
-
-/* allocate RAM */
-s390_memory_init(my_ram_size);
-
-/* clear virtio region */
-virtio_region_len = my_ram_size - ram_size;
-virtio_region_start = ram_size;
-virtio_region = cpu_physical_memory_map(virtio_region_start,
-&virtio_region_len, true);
-memset(virtio_region, 0, virtio_region_len);
-cpu_physical_memory_unmap(virtio_region, virtio_region_len, 1,
-  virtio_region_len);
-
-/* init CPUs */
-s390_init_cpus(machine->cpu_model);
-
-/* Create VirtIO network adapters */
-s390_create_virtio_net((BusState *)s390_bus, "virtio-net-s390");
-
-/* Register savevm handler for guest TOD clock */
-register_savevm(NULL, "todclock", 0, 1, gtod_save, gtod_load, N

[Qemu-devel] [PATCH v2 6/9] s390x/virtio: use qemu_check_nic_model()

Switching to the generally used interface changes the output of

s390x-softmmu/qemu-system-s390x -net nic,model=?

from

S390 only supports VirtIO nics

to the rather more useful

qemu: Supported NIC models: virtio

while still giving us a sensible error message for unsupported
models:

s390x-softmmu/qemu-system-s390x -net nic,model=foo
qemu-system-s390x: Unsupported NIC model: foo

Acked-by: David Hildenbrand 
Acked-by: Christian Borntraeger 
Signed-off-by: Cornelia Huck 
---
 hw/s390x/s390-virtio.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/hw/s390x/s390-virtio.c b/hw/s390x/s390-virtio.c
index 5dbb815..946325f 100644
--- a/hw/s390x/s390-virtio.c
+++ b/hw/s390x/s390-virtio.c
@@ -131,10 +131,7 @@ void s390_create_virtio_net(BusState *bus, const char 
*name)
 nd->model = g_strdup("virtio");
 }
 
-if (strcmp(nd->model, "virtio")) {
-fprintf(stderr, "S390 only supports VirtIO nics\n");
-exit(1);
-}
+qemu_check_nic_model(nd, "virtio");
 
 dev = qdev_create(bus, name);
 qdev_set_nic_properties(dev, nd);
-- 
2.6.4

Re: [Qemu-devel] [PATCH 00/34] kvm_stat: Cleanup and fixup

On Tue, 15 Dec 2015 10:56:35 +0100
Cornelia Huck  wrote:

> On Thu, 10 Dec 2015 13:12:30 +0100
> Janosch Frank  wrote:
> 
> > Kvm_stat is a very helpful script for checking the state of VMs, but
> > when I tried to introduce new features it broke every few lines.
> > 
> > This patch series aims to make the script more readable and durable,
> > so future additions to it will break it less likely. It also fixes
> > input/output problems for all of its interface modes.
> > 
> > Testing was done rarely on X86_64 RHEL 6.7 and mostly on s390. Tests
> > on other architectures would be beneficial.
> 
> The cleanup and fixes look good to me, but I'm most certainly not a
> python expert :)
> 
> Paolo, would you take these through the kvm tree?

Anybody interested in these? I can't really comment on python stuff,
but it would be a shame if these patches were left out in the cold...

> 
> > 
> > Janosch Frank (34):
> >   scripts/kvm/kvm_stat: Cleanup of multiple imports
> >   scripts/kvm/kvm_stat: Replaced os.listdir with os.walk
> >   scripts/kvm/kvm_stat: Make constants uppercase
> >   scripts/kvm/kvm_stat: Removed unneeded PERF constants
> >   scripts/kvm/kvm_stat: Mark globals in functions
> >   scripts/kvm/kvm_stat: Invert dictionaries
> >   scripts/kvm/kvm_stat: Cleanup of path variables
> >   scripts/kvm/kvm_stat: Improve debugfs access checking
> >   scripts/kvm/kvm_stat: Introduce main function
> >   scripts/kvm/kvm_stat: Fix spaces around keyword assignments
> >   scripts/kvm/kvm_stat: Rename variables that redefine globals
> >   scripts/kvm/kvm_stat: Moved DebugfsProvider
> >   scripts/kvm/kvm_stat: Fixup syscall error reporting
> >   scripts/kvm/kvm_stat: Set sensible no. files rlimit
> >   scripts/kvm/kvm_stat: Cleanup of platform detection
> >   scripts/kvm/kvm_stat: Make cpu detection a function
> >   scripts/kvm/kvm_stat: Rename _perf_event_open
> >   scripts/kvm/kvm_stat: Introduce properties for providers
> >   scripts/kvm/kvm_stat: Cleanup of TracepointProvider
> >   scripts/kvm/kvm_stat: Cleanup cpu list retrieval
> >   scripts/kvm/kvm_stat: Encapsulate filters variable
> >   scripts/kvm/kvm_stat: Cleanup of Stats class
> >   scripts/kvm/kvm_stat: Cleanup of Groups class
> >   scripts/kvm/kvm_stat: Cleanup of Event class
> >   scripts/kvm/kvm_stat: Group arch specific data
> >   scripts/kvm/kvm_stat: Remove unneeded X86_EXIT_REASONS
> >   scripts/kvm/kvm_stat: Make tui function a class
> >   scripts/kvm/kvm_stat: Fix output formatting
> >   scripts/kvm/kvm_stat: Move to argparse and add description
> >   scripts/kvm/kvm_stat: Cleanup and pre-init perf_event_attr
> >   scripts/kvm/kvm_stat: Read event values as u64
> >   scripts/kvm/kvm_stat: Fix rlimit for unprivileged users
> >   scripts/kvm/kvm_stat: Fixup filtering
> >   scripts/kvm/kvm_stat: Add interactive filtering
> > 
> >  scripts/kvm/kvm_stat | 1129 
> > --
> >  1 file changed, 626 insertions(+), 503 deletions(-)
> > 
>

Re: [Qemu-devel] [PATCH v5 0/6] i386: expose floppy-related objects in SSDT

On Thu, 7 Jan 2016 12:56:58 +0200
"Michael S. Tsirkin"  wrote:

> On Thu, Jan 07, 2016 at 12:56:09PM +0200, Michael S. Tsirkin wrote:
> > On Wed, Jan 06, 2016 at 03:04:40PM +0100, Igor Mammedov wrote:  
> > > On Wed, 30 Dec 2015 23:11:50 +0300
> > > Roman Kagan  wrote:
> > >   
> > > > Windows on UEFI systems is only capable of detecting the presence and
> > > > the type of floppy drives via corresponding ACPI objects.
> > > > 
> > > > Those objects are added in patch 5; the preceding ones pave the way to
> > > > it, by making the necessary data public and by moving the whole
> > > > floppy drive controller description into runtime-generated SSDT.
> > > > 
> > > > Note that the series conflicts with Igor's patchset for dynamic DSDT, in
> > > > particular, with "[PATCH v2 27/51] pc: acpi: move FDC0 device from DSDT
> > > > to SSDT"; I haven't managed to avoid that while trying to meet
> > > > maintainer's comments.  
> > > 
> > > Tested with XPsp3 WS2008R2 WS2012R2, no regressions so far it boots fine 
> > > and can read floppy.
> > > 
> > > So for whole series:
> > > Reviewed-by: Igor Mammedov 
> > >   
> > 
> > Igor, could you pls rebase this on top of your patches?
> > I've merged them in my tree.  
> 
> Pls remember to keep the author information intact though.
Sure,
I'll usually do it or when in doubt I just ask original
authors before changing it.

> 
> > > > Roman Kagan (6):
> > > >   i386/pc: expose identifying the floppy controller
> > > >   i386/acpi: make floppy controller object dynamic
> > > >   tests/acpi: update test data
> > > >   expose floppy drive geometry and CMOS type
> > > >   i386: populate floppy drive information in SSDT
> > > >   tests/acpi: update test data
> > > > 
> > > > Signed-off-by: Roman Kagan 
> > > > Cc: "Michael S. Tsirkin" 
> > > > Cc: Eduardo Habkost 
> > > > Cc: Igor Mammedov 
> > > > Cc: John Snow 
> > > > Cc: Kevin Wolf 
> > > > Cc: Paolo Bonzini 
> > > > Cc: Richard Henderson 
> > > > Cc: qemu-bl...@nongnu.org
> > > > Cc: qemu-sta...@nongnu.org
> > > > ---
> > > > changes since v4:
> > > >  - re-split out code changes from test data updates
> > > > 
> > > > changes since v3:
> > > >  - make FDC object fully dynamic in a separate patch
> > > >  - split out support patches
> > > >  - include test data updates with the respective patches to maintain
> > > >bisectability
> > > > 
> > > > changes since v2:
> > > >  - explicit endianness for buffer data
> > > >  - reorder code to reduce conflicts with dynamic DSDT patchset
> > > >  - update test data
> > > > 
> > > >  hw/block/fdc.c  |  11 +
> > > >  hw/i386/acpi-build.c|  92 
> > > > 
> > > >  hw/i386/acpi-dsdt-isa.dsl   |  18 ---
> > > >  hw/i386/acpi-dsdt.dsl   |   1 -
> > > >  hw/i386/pc.c|  46 ++
> > > >  hw/i386/q35-acpi-dsdt.dsl   |   7 +--
> > > >  include/hw/block/fdc.h  |   2 +
> > > >  include/hw/i386/pc.h|   3 ++
> > > >  tests/acpi-test-data/pc/DSDT| Bin 3028 -> 2946 bytes
> > > >  tests/acpi-test-data/pc/SSDT| Bin 2486 -> 2635 bytes
> > > >  tests/acpi-test-data/pc/SSDT.bridge | Bin 4345 -> 4494 bytes
> > > >  tests/acpi-test-data/q35/DSDT   | Bin 7666 -> 7578 bytes
> > > >  12 files changed, 137 insertions(+), 43 deletions(-)
> > > >

[Qemu-devel] [PATCH 01/11] trace: fix documentation

From: Paolo Bonzini 

Mention the ftrace backend too.

Signed-off-by: Paolo Bonzini 
Signed-off-by: Denis V. Lunev 
Acked-by: Christian Borntraeger 
---
 qemu-options.hx | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index 215d00d..1ce89db 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -3545,13 +3545,13 @@ Specify tracing options.
 @table @option
 @item events=@var{file}
 Immediately enable events listed in @var{file}.
-The file must contain one event name (as listed in the @var{trace-events} file)
-per line.
-This option is only available if QEMU has been compiled with
-either @var{simple} or @var{stderr} tracing backend.
+The file must contain one event name (as listed in the @file{trace-events} 
file)
+per line; globbing patterns are accepted too.  This option is only
+available if QEMU has been compiled with the @var{simple}, @var{stderr} or
+@var{ftrace} tracing backend.
+
 @item file=@var{file}
 Log output traces to @var{file}.
-
 This option is only available if QEMU has been compiled with
 the @var{simple} tracing backend.
 @end table
-- 
2.5.0

[Qemu-devel] [PATCH 06/11] trace: add "-trace help"

From: Paolo Bonzini 

Print a list of trace points

Signed-off-by: Paolo Bonzini 
Signed-off-by: Denis V. Lunev 
Acked-by: Christian Borntraeger 
---
 qemu-options.hx |  2 ++
 trace/control.c | 21 -
 trace/control.h |  7 +++
 3 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index e5d03c9..aa3707d 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -3551,6 +3551,8 @@ available if QEMU has been compiled with the 
@var{simple}, @var{stderr}
 or @var{ftrace} tracing backend.  To specify multiple events or patterns,
 specify the @option{-trace} option multiple times.
 
+Use @code{-trace help} to print a list of names of trace points.
+
 @item events=@var{file}
 Immediately enable events listed in @var{file}.
 The file must contain one event name (as listed in the @file{trace-events} 
file)
diff --git a/trace/control.c b/trace/control.c
index 715b5b7..7c84795 100644
--- a/trace/control.c
+++ b/trace/control.c
@@ -85,7 +85,16 @@ TraceEvent *trace_event_pattern(const char *pat, TraceEvent 
*ev)
 return NULL;
 }
 
-void trace_enable_events(const char *line_buf)
+void trace_list_events(void)
+{
+int i;
+for (i = 0; i < trace_event_count(); i++) {
+TraceEvent *res = trace_event_id(i);
+fprintf(stderr, "%s\n", trace_event_get_name(res));
+}
+}
+
+static void do_trace_enable_events(const char *line_buf)
 {
 const bool enable = ('-' != line_buf[0]);
 const char *line_ptr = enable ? line_buf : line_buf + 1;
@@ -111,6 +120,16 @@ void trace_enable_events(const char *line_buf)
 }
 }
 
+void trace_enable_events(const char *line_buf)
+{
+if (is_help_option(line_buf)) {
+trace_list_events();
+exit(0);
+} else {
+do_trace_enable_events(line_buf);
+}
+}
+
 void trace_init_events(const char *fname)
 {
 Location loc;
diff --git a/trace/control.h b/trace/control.h
index 32a66ce..3707b3b 100644
--- a/trace/control.h
+++ b/trace/control.h
@@ -182,6 +182,13 @@ void trace_init_events(const char *file);
 void trace_init_file(const char *file);
 
 /**
+ * trace_list_events:
+ *
+ * List all available events.
+ */
+void trace_list_events(void);
+
+/**
  * trace_enable_events:
  * @line_buf: A string with a glob pattern of events to be enabled or,
  *if the string starts with '-', disabled.
-- 
2.5.0

[Qemu-devel] [PATCH 03/11] trace: split trace_init_file out of trace_init_backends

From: Paolo Bonzini 

This is cleaner, and improves error reporting with -daemonize.

Signed-off-by: Paolo Bonzini 
Signed-off-by: Denis V. Lunev 
Acked-by: Christian Borntraeger 
---
 qemu-io.c   |  2 +-
 trace/control.c | 17 -
 trace/control.h | 13 -
 trace/simple.c  |  6 ++
 trace/simple.h  |  4 ++--
 vl.c| 13 +
 6 files changed, 38 insertions(+), 17 deletions(-)

diff --git a/qemu-io.c b/qemu-io.c
index d6fa11b..fbddf82 100644
--- a/qemu-io.c
+++ b/qemu-io.c
@@ -440,7 +440,7 @@ int main(int argc, char **argv)
 }
 break;
 case 'T':
-if (!trace_init_backends(optarg)) {
+if (!trace_init_backends()) {
 exit(1); /* error message will have been printed */
 }
 break;
diff --git a/trace/control.c b/trace/control.c
index ee5fbca..3e33d03 100644
--- a/trace/control.c
+++ b/trace/control.c
@@ -142,17 +142,24 @@ void trace_init_events(const char *fname)
 loc_pop(&loc);
 }
 
-bool trace_init_backends(const char *file)
+void trace_init_file(const char *file)
 {
 #ifdef CONFIG_TRACE_SIMPLE
-if (!st_init(file)) {
-fprintf(stderr, "failed to initialize simple tracing backend.\n");
-return false;
-}
+st_set_trace_file(file);
 #else
 if (file) {
 fprintf(stderr, "error: -trace file=...: "
 "option not supported by the selected tracing backends\n");
+exit(1);
+}
+#endif
+}
+
+bool trace_init_backends(void)
+{
+#ifdef CONFIG_TRACE_SIMPLE
+if (!st_init()) {
+fprintf(stderr, "failed to initialize simple tracing backend.\n");
 return false;
 }
 #endif
diff --git a/trace/control.h b/trace/control.h
index bfbe560..d2506d4 100644
--- a/trace/control.h
+++ b/trace/control.h
@@ -157,7 +157,7 @@ static void trace_event_set_state_dynamic(TraceEvent *ev, 
bool state);
  *
  * Returns: Whether the backends could be successfully initialized.
  */
-bool trace_init_backends(const char *file);
+bool trace_init_backends(void);
 
 /**
  * trace_init_events:
@@ -170,6 +170,17 @@ bool trace_init_backends(const char *file);
  */
 void trace_init_events(const char *file);
 
+/**
+ * trace_init_file:
+ * @file:   Name of trace output file; may be NULL.
+ *  Corresponds to commandline option "-trace file=...".
+ *
+ * Record the name of the output file for the tracing backend.
+ * Exits if no selected backend does not support specifying the
+ * output file, and a non-NULL file was passed.
+ */
+void trace_init_file(const char *file);
+
 
 #include "trace/control-internal.h"
 
diff --git a/trace/simple.c b/trace/simple.c
index 56a624c..e8594cd 100644
--- a/trace/simple.c
+++ b/trace/simple.c
@@ -322,7 +322,7 @@ void st_set_trace_file_enabled(bool enable)
  * @fileThe trace file name or NULL for the default name- set at
  *  config time
  */
-bool st_set_trace_file(const char *file)
+void st_set_trace_file(const char *file)
 {
 st_set_trace_file_enabled(false);
 
@@ -336,7 +336,6 @@ bool st_set_trace_file(const char *file)
 }
 
 st_set_trace_file_enabled(true);
-return true;
 }
 
 void st_print_trace_file_status(FILE *stream, int (*stream_printf)(FILE 
*stream, const char *fmt, ...))
@@ -374,7 +373,7 @@ static GThread *trace_thread_create(GThreadFunc fn)
 return thread;
 }
 
-bool st_init(const char *file)
+bool st_init(void)
 {
 GThread *thread;
 
@@ -387,6 +386,5 @@ bool st_init(const char *file)
 }
 
 atexit(st_flush_trace_buffer);
-st_set_trace_file(file);
 return true;
 }
diff --git a/trace/simple.h b/trace/simple.h
index 6997996..8d1a32e 100644
--- a/trace/simple.h
+++ b/trace/simple.h
@@ -20,8 +20,8 @@
 
 void st_print_trace_file_status(FILE *stream, fprintf_function stream_printf);
 void st_set_trace_file_enabled(bool enable);
-bool st_set_trace_file(const char *file);
-bool st_init(const char *file);
+void st_set_trace_file(const char *file);
+bool st_init(void);
 void st_flush_trace_buffer(void);
 
 typedef struct {
diff --git a/vl.c b/vl.c
index 2aa368b..210db41 100644
--- a/vl.c
+++ b/vl.c
@@ -2994,7 +2994,7 @@ int main(int argc, char **argv, char **envp)
 bool userconfig = true;
 const char *log_mask = NULL;
 const char *log_file = NULL;
-const char *trace_file = NULL;
+char *trace_file = NULL;
 ram_addr_t maxram_size;
 uint64_t ram_slots = 0;
 FILE *vmstate_dump_file = NULL;
@@ -3911,7 +3911,10 @@ int main(int argc, char **argv, char **envp)
 exit(1);
 }
 trace_init_events(qemu_opt_get(opts, "events"));
-trace_file = qemu_opt_get(opts, "file");
+if (trace_file) {
+g_free(trace_file);
+}
+trace_file = g_strdup(qemu_opt_get(opts, "file"));
 qemu_opts_del(opts);
 break;
 }
@@ -4095,6 +4098,8 @@ int main(int argc, ch

[Qemu-devel] [PATCH 09/11] trace: convert stderr backend to log

From: Paolo Bonzini 

Signed-off-by: Paolo Bonzini 
Signed-off-by: Denis V. Lunev 
Acked-by: Christian Borntraeger 
---
 configure   |  4 ++--
 include/qemu/log.h  |  1 +
 scripts/tracetool/backend/{stderr.py => log.py} |  9 +
 trace/control.c | 10 ++
 util/log.c  |  3 +++
 vl.c|  2 ++
 6 files changed, 23 insertions(+), 6 deletions(-)
 rename scripts/tracetool/backend/{stderr.py => log.py} (78%)

diff --git a/configure b/configure
index 83b40fc..76d9ae6 100755
--- a/configure
+++ b/configure
@@ -5375,8 +5375,8 @@ if have_backend "simple"; then
   # Set the appropriate trace file.
   trace_file="\"$trace_file-\" FMT_pid"
 fi
-if have_backend "stderr"; then
-  echo "CONFIG_TRACE_STDERR=y" >> $config_host_mak
+if have_backend "log"; then
+  echo "CONFIG_TRACE_LOG=y" >> $config_host_mak
 fi
 if have_backend "ust"; then
   echo "CONFIG_TRACE_UST=y" >> $config_host_mak
diff --git a/include/qemu/log.h b/include/qemu/log.h
index 09722e3..30817f7 100644
--- a/include/qemu/log.h
+++ b/include/qemu/log.h
@@ -45,6 +45,7 @@ static inline bool qemu_log_separate(void)
 #define CPU_LOG_MMU(1 << 12)
 #define CPU_LOG_TB_NOCHAIN (1 << 13)
 #define CPU_LOG_PAGE   (1 << 14)
+#define LOG_TRACE  (1 << 15)
 
 /* Returns true if a bit is set in the current loglevel mask
  */
diff --git a/scripts/tracetool/backend/stderr.py 
b/scripts/tracetool/backend/log.py
similarity index 78%
rename from scripts/tracetool/backend/stderr.py
rename to scripts/tracetool/backend/log.py
index ca58054..a62c310 100644
--- a/scripts/tracetool/backend/stderr.py
+++ b/scripts/tracetool/backend/log.py
@@ -25,6 +25,7 @@ def generate_h_begin(events):
 '#include ',
 '#include ',
 '#include "trace/control.h"',
+'#include "qemu/log.h"',
 '')
 
 
@@ -36,10 +37,10 @@ def generate_h(event):
 out('if (trace_event_get_state(%(event_id)s)) {',
 'struct timeval _now;',
 'gettimeofday(&_now, NULL);',
-'fprintf(stderr, "%%d@%%zd.%%06zd:%(name)s " %(fmt)s "\\n",',
-'getpid(),',
-'(size_t)_now.tv_sec, (size_t)_now.tv_usec',
-'%(argnames)s);',
+'qemu_log_mask(LOG_TRACE, "%%d@%%zd.%%06zd:%(name)s " %(fmt)s 
"\\n",',
+'  getpid(),',
+'  (size_t)_now.tv_sec, (size_t)_now.tv_usec',
+'  %(argnames)s);',
 '}',
 event_id="TRACE_" + event.name.upper(),
 name=event.name,
diff --git a/trace/control.c b/trace/control.c
index 7c84795..9a1e381 100644
--- a/trace/control.c
+++ b/trace/control.c
@@ -14,6 +14,9 @@
 #ifdef CONFIG_TRACE_FTRACE
 #include "trace/ftrace.h"
 #endif
+#ifdef CONFIG_TRACE_LOG
+#include "qemu/log.h"
+#endif
 #include "qemu/error-report.h"
 
 TraceEvent *trace_event_name(const char *name)
@@ -171,6 +174,13 @@ void trace_init_file(const char *file)
 {
 #ifdef CONFIG_TRACE_SIMPLE
 st_set_trace_file(file);
+#elif defined CONFIG_TRACE_LOG
+/* If both the simple and the log backends are enabled, "-trace file"
+ * only applies to the simple backend; use "-D" for the log backend.
+ */
+if (file) {
+qemu_set_log_filename(file);
+}
 #else
 if (file) {
 fprintf(stderr, "error: -trace file=...: "
diff --git a/util/log.c b/util/log.c
index 901b930..37185a5 100644
--- a/util/log.c
+++ b/util/log.c
@@ -51,6 +51,9 @@ void qemu_log_mask(int mask, const char *fmt, ...)
 void do_qemu_set_log(int log_flags, bool use_own_buffers)
 {
 qemu_loglevel = log_flags;
+#ifdef CONFIG_TRACE_LOG
+qemu_loglevel |= LOG_TRACE;
+#endif
 if (qemu_loglevel && !qemu_logfile) {
 if (logfilename) {
 qemu_logfile = fopen(logfilename, log_append ? "a" : "w");
diff --git a/vl.c b/vl.c
index 01b39d4..6720839 100644
--- a/vl.c
+++ b/vl.c
@@ -4121,6 +4121,8 @@ int main(int argc, char **argv, char **envp)
 exit(1);
 }
 qemu_set_log(mask);
+} else {
+qemu_set_log(0);
 }
 
 if (!trace_init_backends()) {
-- 
2.5.0

[Qemu-devel] [PATCH 11/11] log: add "-d trace:PATTERN"

From: Paolo Bonzini 

This is a bit easier to use than "-trace" if you are also enabling
other kinds of logging.  It is also more discoverable for experienced
QEMU users, and accessible from user-mode emulators.

Signed-off-by: Paolo Bonzini 
Signed-off-by: Denis V. Lunev 
Acked-by: Christian Borntraeger 
---
 util/log.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/util/log.c b/util/log.c
index 37185a5..46c88c9 100644
--- a/util/log.c
+++ b/util/log.c
@@ -19,6 +19,7 @@
 
 #include "qemu-common.h"
 #include "qemu/log.h"
+#include "trace/control.h"
 
 static char *logfilename;
 FILE *qemu_logfile;
@@ -154,6 +155,11 @@ int qemu_str_to_log_mask(const char *str)
 for (item = qemu_log_items; item->mask != 0; item++) {
 mask |= item->mask;
 }
+#ifdef CONFIG_TRACE_LOG
+} else if (strncmp(p, "trace:", 6) == 0 && p + 6 != p1) {
+trace_enable_events(p + 6);
+mask |= LOG_TRACE;
+#endif
 } else {
 for (item = qemu_log_items; item->mask != 0; item++) {
 if (cmp1(p, p1 - p, item->name)) {
@@ -161,9 +167,9 @@ int qemu_str_to_log_mask(const char *str)
 }
 }
 return 0;
+found:
+mask |= item->mask;
 }
-found:
-mask |= item->mask;
 if (*p1 != ',') {
 break;
 }
@@ -177,6 +183,10 @@ void qemu_print_log_usage(FILE *f)
 const QEMULogItem *item;
 fprintf(f, "Log items (comma separated):\n");
 for (item = qemu_log_items; item->mask != 0; item++) {
-fprintf(f, "%-10s %s\n", item->name, item->help);
+fprintf(f, "%-15s %s\n", item->name, item->help);
 }
+#ifdef CONFIG_TRACE_LOG
+fprintf(f, "trace:PATTERN   enable trace events\n");
+fprintf(f, "\nUse \"-d trace:help\" to get a list of trace events.\n\n");
+#endif
 }
-- 
2.5.0

Re: [Qemu-devel] [PATCH v1 0/2] hw/microblaze: Set MicroBlaze CPU version

2016-01-07 Thread Edgar E. Iglesias

On Fri, Nov 13, 2015 at 06:00:02PM +0100, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias" 
> 
> Hi,
> 
> This series avoids runtime warnings when using the
> petalogix s3adsp1800 and ml605 microblaze boards by
> explicitly selecting the MicroBlaze CPU versions.
> 
> The versions match the DTBs we ship.


I've applied this series.

Cheers,
Edgar


> 
> Cheers,
> Edgar
> 
> Edgar E. Iglesias (2):
>   s3adsp1800: Set the MicroBlaze CPU version to 7.10.d
>   petalogix-ml605: Set the MicroBlaze CPU version to 8.10.a
> 
>  hw/microblaze/petalogix_ml605_mmu.c  | 1 +
>  hw/microblaze/petalogix_s3adsp1800_mmu.c | 1 +
>  2 files changed, 2 insertions(+)
> 
> -- 
> 1.9.1
>

Re: [Qemu-devel] [PATCH 0/6] NVDIMM ACPI: introduce the framework of QEMU emulated DSM

On Tue,  5 Jan 2016 02:52:02 +0800
Xiao Guangrong  wrote:

> This patchset is against commit 5530427f0ca (acpi: extend aml_and() to
> accept target argument) on pci branch of Michael's git tree
> and can be found at:
>   https://github.com/xiaogr/qemu.git nvdimm-acpi-v1
> 
> This is the second part of vNVDIMM implementation which implements the
> BIOS patched dsm memory and introduces the framework that allows QEMU
> to emulate DSM method
> 
> Thanks to Michael's idea, we do not reserve any memory for NVDIMM ACPI,
> instead we let BIOS allocate the memory and patch the address to the
> offset we want
> 
> IO port is still enabled as it plays as the way to notify QEMU and pass
> the patched dsm memory address, so that IO port region, 0x0a18 - 0xa20,
> is reserved and it is divided into two 32 bits ports and used to pass
> the low 32 bits and high 32 bits of dsm memory address to QEMU
> 
> Thanks Igor's idea, this patchset also extends DSDT/SSDT to revision 2
> to apply 64 bit operations, in order to keeping compatibility, old
> version (<= 2.5) still uses revision 1. Since 64 bit operations breaks
> old guests (such as windows XP), we should keep the 64 bits stuff in
> the private place where common ACPI operation does not touch it
> 

general notes:
1. could you split out AML API additions/changes into separate patches?
   even if series nvdims patches couldn't be accepted on next respin,
   AML API patches could be good and we could pick them up just
   for API completeness. That also would make them easier to review
   and reduces count of patches you'd need to respin.
2. add test case for NVDIMM table blob, see tests/bios-tables-test.c
   at the beginning of series.
3. make V=1 check would show you ASL diff your patches are introducing,
   it will save you from booting real guest and dumping/decompiling
   tables manually.
4. at the end of series add NVDIMM table test blob with new table.
   you can use tests/acpi-test-data/rebuild-expected-aml.sh to make it
5. if make check by some miracle passes with these patches,
   dump NVDIMM table in guest and try to decompile and then compile it
   back with IASL, it will show you what needs to be fixed.

PS:
 under NVDIMM table I mean SSDT NVMDIM table.

> Igor Mammedov (1):
>   pc: acpi: bump DSDT/SSDT compliance revision to v2
> 
> Xiao Guangrong (5):
>   nvdimm acpi: initialize the resource used by NVDIMM ACPI
>   nvdimm acpi: introduce patched dsm memory
>   acpi: allow using acpi named offset for OperationRegion
>   nvdimm acpi: let qemu handle _DSM method
>   nvdimm acpi: emulate dsm method
> 
>  hw/acpi/Makefile.objs   |   2 +-
>  hw/acpi/aml-build.c |  45 +++-
>  hw/acpi/ich9.c  |  32 +
>  hw/acpi/nvdimm.c| 276 
> ++--
>  hw/acpi/piix4.c |   3 +
>  hw/i386/acpi-build.c|  41 ---
>  hw/i386/pc.c|   8 +-
>  hw/i386/pc_piix.c   |   5 +
>  hw/i386/pc_q35.c|   8 +-
>  include/hw/acpi/aml-build.h |   6 +-
>  include/hw/acpi/ich9.h  |   2 +
>  include/hw/i386/pc.h|  19 ++-
>  include/hw/mem/nvdimm.h |  44 ++-
>  13 files changed, 449 insertions(+), 42 deletions(-)
>

Re: [Qemu-devel] [PATCH 5/6] nvdimm acpi: let qemu handle _DSM method

On Tue,  5 Jan 2016 02:52:07 +0800
Xiao Guangrong  wrote:

> If dsm memory is successfully patched, we let qemu fully emulate
> the dsm method
> 
> This patch saves _DSM input parameters into dsm memory, tell dsm
> memory address to QEMU, then fetch the result from the dsm memory
you also need to add NVDR._CRS method that would report
resources used by operation regions.

NVDIMM_COMMON_DSM - probably should be serialized, otherwise
there is a race risk, when several callers would write to
control region.


> 
> Signed-off-by: Xiao Guangrong 
> ---
>  hw/acpi/aml-build.c |  27 ++
>  hw/acpi/nvdimm.c| 124 
> ++--
>  include/hw/acpi/aml-build.h |   2 +
>  3 files changed, 150 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
> index 677c1a6..e65171f 100644
> --- a/hw/acpi/aml-build.c
> +++ b/hw/acpi/aml-build.c
> @@ -1013,6 +1013,19 @@ Aml *create_field_common(int opcode, Aml *srcbuf, Aml 
> *index, const char *name)
>  return var;
>  }
>  
> +/* ACPI 1.0b: 16.2.5.2 Named Objects Encoding: DefCreateField */
> +Aml *aml_create_field(Aml *srcbuf, Aml *index, Aml *len, const char *name)
> +{
> +Aml *var = aml_alloc();
> +build_append_byte(var->buf, 0x5B); /* ExtOpPrefix */
> +build_append_byte(var->buf, 0x13); /* CreateFieldOp */
> +aml_append(var, srcbuf);
> +aml_append(var, index);
> +aml_append(var, len);
> +build_append_namestring(var->buf, "%s", name);
> +return var;
> +}
> +
>  /* ACPI 1.0b: 16.2.5.2 Named Objects Encoding: DefCreateDWordField */
>  Aml *aml_create_dword_field(Aml *srcbuf, Aml *index, const char *name)
>  {
> @@ -1439,6 +1452,20 @@ Aml *aml_alias(const char *source_object, const char 
> *alias_object)
>  return var;
>  }
>  
> +/* ACPI 1.0b: 16.2.5.4 Type 2 Opcodes Encoding: DefConcat */
> +Aml *aml_concatenate(Aml *source1, Aml *source2, Aml *target)
> +{
> +Aml *var = aml_opcode(0x73 /* ConcatOp */);
> +aml_append(var, source1);
> +aml_append(var, source2);
> +
> +if (target) {
> +aml_append(var, target);
> +}
> +
> +return var;
> +}
> +
>  void
>  build_header(GArray *linker, GArray *table_data,
>   AcpiTableHeader *h, const char *sig, int len, uint8_t rev,
> diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c
> index a72104c..dfccbc0 100644
> --- a/hw/acpi/nvdimm.c
> +++ b/hw/acpi/nvdimm.c
> @@ -369,6 +369,24 @@ static void nvdimm_build_nfit(GSList *device_list, 
> GArray *table_offsets,
>  g_array_free(structures, true);
>  }
>  
> +struct NvdimmDsmIn {
> +uint32_t handle;
> +uint32_t revision;
> +uint32_t function;
> +   /* the remaining size in the page is used by arg3. */
> +union {
> +uint8_t arg3[0];
> +};
> +} QEMU_PACKED;
> +typedef struct NvdimmDsmIn NvdimmDsmIn;
> +
> +struct NvdimmDsmOut {
> +/* the size of buffer filled by QEMU. */
> +uint32_t len;
> +uint8_t data[0];
> +} QEMU_PACKED;
> +typedef struct NvdimmDsmOut NvdimmDsmOut;
> +
>  static uint64_t
>  nvdimm_dsm_read(void *opaque, hwaddr addr, unsigned size)
>  {
> @@ -408,11 +426,21 @@ void nvdimm_init_acpi_state(AcpiNVDIMMState *state, 
> MemoryRegion *io,
>  
>  static void nvdimm_build_common_dsm(Aml *dev)
>  {
> -Aml *method, *ifctx, *function;
> +Aml *method, *ifctx, *function, *unpatched, *field, *high_dsm_mem;
> +Aml *result_size, *dsm_mem;
>  uint8_t byte_list[1];
>  
>  method = aml_method(NVDIMM_COMMON_DSM, 4, AML_NOTSERIALIZED);
>  function = aml_arg(2);
> +dsm_mem = aml_arg(3);
> +
> +aml_append(method, aml_store(aml_call0(NVDIMM_GET_DSM_MEM), dsm_mem));
> +
> +/*
> + * do not support any method if DSM memory address has not been
> + * patched.
> + */
> +unpatched = aml_if(aml_equal(dsm_mem, aml_int64(0x0)));
>  
>  /*
>   * function 0 is called to inquire what functions are supported by
> @@ -421,12 +449,102 @@ static void nvdimm_build_common_dsm(Aml *dev)
>  ifctx = aml_if(aml_equal(function, aml_int(0)));
>  byte_list[0] = 0 /* No function Supported */;
>  aml_append(ifctx, aml_return(aml_buffer(1, byte_list)));
> -aml_append(method, ifctx);
> +aml_append(unpatched, ifctx);
>  
>  /* No function is supported yet. */
>  byte_list[0] = 1 /* Not Supported */;
> -aml_append(method, aml_return(aml_buffer(1, byte_list)));
> +aml_append(unpatched, aml_return(aml_buffer(1, byte_list)));
> +aml_append(method, unpatched);
> +
> +/* map DSM memory and IO into ACPI namespace. */
> +aml_append(method, aml_operation_region("NPIO", AML_SYSTEM_IO,
> +   aml_int(NVDIMM_ACPI_IO_BASE), NVDIMM_ACPI_IO_LEN));
> +aml_append(method, aml_operation_region("NRAM", AML_SYSTEM_MEMORY,
> +dsm_mem, TARGET_PAGE_SIZE));
> +
> +/*
> + * DSM notifier:
> + * LNTF: write the low 32 bits of DSM memory.
> + * HNTF: write the high 32

Re: [Qemu-devel] [PATCH v8 4/4] arm_mptimer: Convert to use ptimer

2016-01-07 Thread Dmitry Osipenko


06.01.2016 16:17, Peter Crosthwaite пишет:

On Tue, Jan 05, 2016 at 05:33:29AM +0300, Dmitry Osipenko wrote:

Current ARM MPTimer implementation uses QEMUTimer for the actual timer,
this implementation isn't complete and mostly tries to duplicate of what
generic ptimer is already doing fine.

Conversion to ptimer brings the following benefits and fixes:
- Simple timer pausing implementation
- Fixes counter value preservation after stopping the timer
- Code simplification and reduction

Bump VMSD to version 3, since VMState is changed and is not compatible
with the previous implementation.

Signed-off-by: Dmitry Osipenko 
---
  hw/timer/arm_mptimer.c | 110 ++---
  include/hw/timer/arm_mptimer.h |   4 +-
  2 files changed, 49 insertions(+), 65 deletions(-)

diff --git a/hw/timer/arm_mptimer.c b/hw/timer/arm_mptimer.c
index 3e59c2a..c06da5e 100644
--- a/hw/timer/arm_mptimer.c
+++ b/hw/timer/arm_mptimer.c
@@ -19,8 +19,9 @@
   * with this program; if not, see .
   */

+#include "hw/ptimer.h"
  #include "hw/timer/arm_mptimer.h"
-#include "qemu/timer.h"
+#include "qemu/main-loop.h"
  #include "qom/cpu.h"

  /* This device implements the per-cpu private timer and watchdog block
@@ -47,28 +48,10 @@ static inline uint32_t timerblock_scale(TimerBlock *tb)
  return (((tb->control >> 8) & 0xff) + 1) * 10;
  }

-static void timerblock_reload(TimerBlock *tb, int restart)
-{
-if (tb->count == 0) {
-return;
-}
-if (restart) {
-tb->tick = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
-}
-tb->tick += (int64_t)tb->count * timerblock_scale(tb);
-timer_mod(tb->timer, tb->tick);
-}
-
  static void timerblock_tick(void *opaque)
  {
  TimerBlock *tb = (TimerBlock *)opaque;
  tb->status = 1;
-if (tb->control & 2) {
-tb->count = tb->load;
-timerblock_reload(tb, 0);
-} else {
-tb->count = 0;
-}
  timerblock_update_irq(tb);
  }

@@ -76,21 +59,11 @@ static uint64_t timerblock_read(void *opaque, hwaddr addr,
  unsigned size)
  {
  TimerBlock *tb = (TimerBlock *)opaque;
-int64_t val;
  switch (addr) {
  case 0: /* Load */
  return tb->load;
  case 4: /* Counter.  */
-if (((tb->control & 1) == 0) || (tb->count == 0)) {
-return 0;
-}
-/* Slow and ugly, but hopefully won't happen too often.  */
-val = tb->tick - qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
-val /= timerblock_scale(tb);
-if (val < 0) {
-val = 0;
-}
-return val;
+return ptimer_get_count(tb->timer);
  case 8: /* Control.  */
  return tb->control;
  case 12: /* Interrupt status.  */
@@ -100,6 +73,19 @@ static uint64_t timerblock_read(void *opaque, hwaddr addr,
  }
  }

+static void timerblock_run(TimerBlock *tb, uint64_t count, int set_count)
+{
+if (set_count) {
+if (((tb->control & 3) == 3) && (count == 0)) {


Parentheses around == expressions should not be needed.


+count = tb->load;
+}
+ptimer_set_count(tb->timer, count);
+}
+if ((tb->control & 1) && (count != 0)) {


This can check against tb->load instead of count to avoid dummy
pass of tb->load to this fn ...


+ptimer_run(tb->timer, !(tb->control & 2));
+}
+}
+
  static void timerblock_write(void *opaque, hwaddr addr,
   uint64_t value, unsigned size)
  {
@@ -108,32 +94,34 @@ static void timerblock_write(void *opaque, hwaddr addr,
  switch (addr) {
  case 0: /* Load */
  tb->load = value;
-/* Fall through.  */
-case 4: /* Counter.  */
-if ((tb->control & 1) && tb->count) {
-/* Cancel the previous timer.  */
-timer_del(tb->timer);
+/* Setting load to 0 stops the timer.  */
+if (tb->load == 0) {
+ptimer_stop(tb->timer);
  }
-tb->count = value;
-if (tb->control & 1) {
-timerblock_reload(tb, 1);
+ptimer_set_limit(tb->timer, tb->load, 1);
+timerblock_run(tb, tb->load, 0);
+break;
+case 4: /* Counter.  */
+/* Setting counter to 0 stops the one-shot timer.  */
+if (!(tb->control & 2) && (value == 0)) {
+ptimer_stop(tb->timer);
  }
+timerblock_run(tb, value, 1);


... then this would just need to be elsed.


  break;
  case 8: /* Control.  */
  old = tb->control;
  tb->control = value;
-if (value & 1) {
-if ((old & 1) && (tb->count != 0)) {
-/* Do nothing if timer is ticking right now.  */
-break;
-}
-if (tb->control & 2) {
-tb->count = tb->load;
-}
-timerblock_reload(tb, 1);
-} else if (old & 1) {
-/* Shutdown the timer.  */
-

Re: [Qemu-devel] [PATCH] hw/arm/virt: Initialize NICs configured in PCI bus

On 7 January 2016 at 05:53, Ashok Kumar  wrote:
> On Wed, Jan 06, 2016 at 06:10:15PM +, Peter Maydell wrote:
>> I guess from the patch that this is adding support for
>> the legacy '-net' way of configuring networking, but do
>> we need that if we never supported it in the first place?
>> (If virt is the only PCI machine which doesn't support
>> -net syntax that would probably be a strong argument for
>> supporting it.)
> Fine with me. But there are some documentation for e.g [1] which says "-net" 
> is
> still supported.
>
> [1] http://www.linux-kvm.org/page/Networking#Compatibility

I've cc'd the networking maintainer and some other people
who might have an opinion. Basically the question is
"should we support the legacy -net syntax for new board models
which didn't exist back when -net was the only option and
have never supported -net" ?

The argument for "don't support it" is that -net is legacy and
if there aren't any legacy command lines to support then we
should avoid extending the scope of legacy behaviour.

The argument for "do support it" is consistency -- we don't
document that -net is only for certain boards, and users
will expect that network config options that work on some machines
(including x86 PC and many of the ARM embedded board models)
will also work on the ARM virt board.

I think my current inclination is to say that virt should
support -net, because I would prefer to avoid having yet
another speedbump in the path of people trying to move to
using KVM-on-ARM based on their previous experience with
KVM-on-x86.

thanks
-- PMM

Re: [Qemu-devel] 答复: What's the advantages of POSTCOPY over CPU-THROTTLE?

2016-01-07 Thread Dr. David Alan Gilbert

* Dr. David Alan Gilbert (dgilb...@redhat.com) wrote:
> * Zhangbo (Oscar) (oscar.zhan...@huawei.com) wrote:
> > Thank you David and Jason!
> > 
> > BTW, I noticed that Vmware did the same work alike us, but the situation is 
> > a little different:
> > they proposed postcopy(in the name of QuickResume) in vSphere4.1, but 
> > they substituted it with SDPS(similar to CPU-THROTTLE) from vSphere5, do 
> > you know the reason behind this?
> > Reference: 
> > https://qianr.wordpress.com/2013/10/14/vmware-vm-live-migration-vmotion/
> > It's told that they've already introduced a shared storage to avoid losing 
> > the guest when the network connection is lost. So what's their concern of 
> > disposing QuickResume? 
> 
> Hmm that's a good summary; I'd not seen any detail of how vmware's systems 
> worked before.
> I'm not exactly sure; but I think that's saying that they store the
> outstanding pages that haven't been transferred in a file on disk
> so that they could be used to recover the VM later if the network failed.
> It's not clear to me from that description if they do that only when the
> network fails, or as part of a normal postcopy flow.

I was thinking about this a bit more; recovering from a failed network
connection for postcopy might be doable, I can kind of see how to do it
*without* using a disk intermediate, but with a disk it's a bit trickier.

Assuming the network connection is lost after we enter postcopy mode,
we've also lost a bit of state - because the source doesn't know exactly
which pages the destination has already received.  This is also something
that we don't actually keep track of on the destination, we leave it up
to the source to tell us when we're finished.

What we could do is:
  a) When the network connection fails make sure we dont kill the destination,
and go into some form of paused mode
  b) Also make sure the source doesn't lose the migration state.
  c) Now, get the destination to listen for a connection (something like
 migrate_incoming but we don't want to reset the state, but we do need
 the ability to specify a different network setup)
  d) Tell the source to connect to the destination again
  e) The source does *not* carry on any background transfer - it only transfers
 pages that the destination asks for.
  f) We start a recovery thread on the destination that just walks all of memory
 reading one byte from each page; it should get stuck on any outstanding 
pages
 and cause the page to be requested.
  g) The source must send a requested page, even if it had previously sent it
 because it might have been lost in network buffers.
  h) Once that recovery thread finishes we know we've received all pages, so
 we're good.

  That all sounds doable; the tricky bit is making sure the destination copes
with the failure enough to be able to recover; it mustn't cause an exit or
a cleanup of the migration state when the network errors.  Also, if a device
tries to access a page of memory, it had better not block the monitor, since
we'll need that to recover.

Could we do it to file, like that description of VMWare? Again the tricky
bit is to do with the pages that may or may not have been lost in the packet
buffer.  If we did a migrate-to-file/snapshot then that would have all of
memory, rather than the nice small chunk that article describes, but we
could recover from a whole migrate-to-file if we did something special
to make the postcopy load from that (like the userfault driven loadvm
work people have done).
To keep the file small we would have to be smarter.
We'd have to include all the pages that we *know* we haven't sent, but
we'd also have to include pages that might not have been received;
e.g. resend say the last ~20MByte (enough for a few packet buffers)
into that file.
Then the destination would have to do the recovery thread like above,
and also only load pages it was asked for.
One trick to make this easier, would be to have something that loaded
this recovery file and pretended to be a source-vm, then we could use
the sequence above on the destination side without any changes.

Dave

> > Are there any other prices we need to pay to have postcopy?
> 
> The precopy phase in postcopy mode is slower than normal precopy migration,
> but I think that's the only other penalty.

> 
> Dave
> 
> > 
> > -邮件原件-
> > 发件人: Jason J. Herne [mailto:jjhe...@linux.vnet.ibm.com] 
> > 发送时间: 2016年1月7日 3:43
> > 收件人: Dr. David Alan Gilbert; Zhangbo (Oscar)
> > 抄送: zhouyimin Zhou(Yimin); Zhanghailiang; Yanqiangjun; Huangpeng (Peter); 
> > qemu-devel@nongnu.org; Herongguang (Stephen); Linqiangmin; Huangzhichao; 
> > Wangyufei (James)
> > 主题: Re: [Qemu-devel] What's the advantages of POSTCOPY over CPU-THROTTLE?
> > 
> > On 01/06/2016 04:57 AM, Dr. David Alan Gilbert wrote:
> > > * Zhangbo (Oscar) (oscar.zhan...@huawei.com) wrote:
> > >> Hi all:
> > >> 　　Postcopy is suitable for migrating guests which have large page change 
> > >> rates

Re: [Qemu-devel] [PATCH 07/34] scripts/kvm/kvm_stat: Cleanup of path variables



On 10/12/2015 13:12, Janosch Frank wrote:
>  if not os.access('/sys/kernel/debug', os.F_OK):

PATH_DEBUGFS should be /sys/kernel/debug, while...

>  print 'Please enable CONFIG_DEBUG_FS in your kernel'
>  sys.exit(1)
> -if not os.access('/sys/kernel/debug/kvm', os.F_OK):
> +if not os.access(PATH_DEBUGFS, os.F_OK):

... this should be PATH_DEBUGFS_KVM.

Paolo

Re: [Qemu-devel] [RFC v6 10/14] softmmu: Simplify helper_*_st_name, wrap unaligned code

2016-01-07 Thread alvise rigo

On Thu, Jan 7, 2016 at 3:46 PM, Alex Bennée  wrote:
>
> Alvise Rigo  writes:
>
>> Attempting to simplify the helper_*_st_name, wrap the
>> do_unaligned_access code into an inline function.
>> Remove also the goto statement.
>
> As I said in the other thread I think these sort of clean-ups can come
> before the ll/sc implementations and potentially get merged ahead of the
> rest of it.
>
>>
>> Suggested-by: Jani Kokkonen 
>> Suggested-by: Claudio Fontana 
>> Signed-off-by: Alvise Rigo 
>> ---
>>  softmmu_template.h | 96 
>> ++
>>  1 file changed, 60 insertions(+), 36 deletions(-)
>>
>> diff --git a/softmmu_template.h b/softmmu_template.h
>> index d3d5902..92f92b1 100644
>> --- a/softmmu_template.h
>> +++ b/softmmu_template.h
>> @@ -370,6 +370,32 @@ static inline void glue(io_write, SUFFIX)(CPUArchState 
>> *env,
>>   iotlbentry->attrs);
>>  }
>>
>> +static inline void glue(helper_le_st_name, _do_unl_access)(CPUArchState 
>> *env,
>> +   DATA_TYPE val,
>> +   target_ulong 
>> addr,
>> +   TCGMemOpIdx oi,
>> +   unsigned mmu_idx,
>> +   uintptr_t 
>> retaddr)
>> +{
>> +int i;
>> +
>> +if ((get_memop(oi) & MO_AMASK) == MO_ALIGN) {
>> +cpu_unaligned_access(ENV_GET_CPU(env), addr, MMU_DATA_STORE,
>> + mmu_idx, retaddr);
>> +}
>> +/* XXX: not efficient, but simple */
>> +/* Note: relies on the fact that tlb_fill() does not remove the
>> + * previous page from the TLB cache.  */
>> +for (i = DATA_SIZE - 1; i >= 0; i--) {
>> +/* Little-endian extract.  */
>> +uint8_t val8 = val >> (i * 8);
>> +/* Note the adjustment at the beginning of the function.
>> +   Undo that for the recursion.  */
>> +glue(helper_ret_stb, MMUSUFFIX)(env, addr + i, val8,
>> +oi, retaddr + GETPC_ADJ);
>> +}
>> +}
>
> There is still duplication of 99% of the code here which is silly given

Then why should we keep this template-like design in the first place?
I tried to keep the code duplication for performance reasons
(otherwise how can we justify the two almost identical versions of the
helper?), while making the code more compact and readable.

> the compiler inlines the code anyway. If we gave the helper a more
> generic name and passed the endianess in via args I would hope the
> compiler did the sensible thing and constant fold the code. Something
> like:
>
> static inline void glue(helper_generic_st_name, _do_unl_access)
> (CPUArchState *env,
> bool little_endian,
> DATA_TYPE val,
> target_ulong addr,
> TCGMemOpIdx oi,
> unsigned mmu_idx,
> uintptr_t retaddr)
> {
> int i;
>
> if ((get_memop(oi) & MO_AMASK) == MO_ALIGN) {
> cpu_unaligned_access(ENV_GET_CPU(env), addr, MMU_DATA_STORE,
>  mmu_idx, retaddr);
> }
> /* Note: relies on the fact that tlb_fill() does not remove the
>  * previous page from the TLB cache.  */
> for (i = DATA_SIZE - 1; i >= 0; i--) {
> if (little_endian) {

little_endian will have >99% of the time the same value, does it make
sense to have a branch here?

Thank you,
alvise

> /* Little-endian extract.  */
> uint8_t val8 = val >> (i * 8);
> } else {
> /* Big-endian extract.  */
> uint8_t val8 = val >> (((DATA_SIZE - 1) * 8) - (i * 8));
> }
> /* Note the adjustment at the beginning of the function.
>Undo that for the recursion.  */
> glue(helper_ret_stb, MMUSUFFIX)(env, addr + i, val8,
> oi, retaddr + GETPC_ADJ);
> }
> }
>
>
>> +
>>  void helper_le_st_name(CPUArchState *env, target_ulong addr, DATA_TYPE val,
>> TCGMemOpIdx oi, uintptr_t retaddr)
>>  {
>> @@ -433,7 +459,8 @@ void helper_le_st_name(CPUArchState *env, target_ulong 
>> addr, DATA_TYPE val,
>>  return;
>>  } else {
>>  if ((addr & (DATA_SIZE - 1)) != 0) {
>> -goto do_unaligned_access;
>> +glue(helper_le_st_name, _do_unl_access)(env, val, addr, 
>> mmu_idx,
>> +oi, retaddr);
>>  }
>>  iotlbentry = &env->iotlb[mmu_idx][index];
>>
>> @@ -449,23 +476,8 @@ void helper_le_st_name(CPUArchState *env, target_ulong 
>> addr, DATA_TYPE val,
>>  if (DATA_SIZE > 1
>>  && unlikely((addr & ~TARGET_PAGE_MASK) + D

[Qemu-devel] [PATCH] softmmu_template: POC simpler do_unl_access inline

2016-01-07 Thread Alex Bennée

As any constant arguments will be folded by the compiler when a function
is in-lined we can squash the be/le handlers together and let the
compiler figure it out.
---
 softmmu_template.h | 68 --
 1 file changed, 25 insertions(+), 43 deletions(-)

diff --git a/softmmu_template.h b/softmmu_template.h
index 65cce0a..6d86a21 100644
--- a/softmmu_template.h
+++ b/softmmu_template.h
@@ -108,6 +108,8 @@
 # define helper_be_st_name  glue(glue(helper_be_st, SUFFIX), MMUSUFFIX)
 #endif
 
+#define helper_generic_st_name glue(glue(helper_generic_st, SUFFIX), MMUSUFFIX)
+
 #ifdef TARGET_WORDS_BIGENDIAN
 # define helper_te_ld_name  helper_be_ld_name
 # define helper_te_st_name  helper_be_st_name
@@ -378,12 +380,13 @@ static inline void glue(io_write, SUFFIX)(CPUArchState 
*env,
  iotlbentry->attrs);
 }
 
-static inline void glue(helper_le_st_name, _do_unl_access)(CPUArchState *env,
-   DATA_TYPE val,
-   target_ulong addr,
-   TCGMemOpIdx oi,
-   unsigned mmu_idx,
-   uintptr_t retaddr)
+static inline void glue(helper_generic_st_name, _do_unl_access)(CPUArchState 
*env,
+bool 
little_endian,
+DATA_TYPE val,
+target_ulong 
addr,
+TCGMemOpIdx oi,
+unsigned 
mmu_idx,
+uintptr_t 
retaddr)
 {
 int i;
 
@@ -391,12 +394,17 @@ static inline void glue(helper_le_st_name, 
_do_unl_access)(CPUArchState *env,
 cpu_unaligned_access(ENV_GET_CPU(env), addr, MMU_DATA_STORE,
  mmu_idx, retaddr);
 }
-/* XXX: not efficient, but simple */
 /* Note: relies on the fact that tlb_fill() does not remove the
  * previous page from the TLB cache.  */
 for (i = DATA_SIZE - 1; i >= 0; i--) {
-/* Little-endian extract.  */
-uint8_t val8 = val >> (i * 8);
+uint8_t val8;
+if (little_endian) {
+/* Little-endian extract.  */
+val8 = val >> (i * 8);
+} else {
+/* Big-endian extract.  */
+val8 = val >> (((DATA_SIZE - 1) * 8) - (i * 8));
+}
 /* Note the adjustment at the beginning of the function.
Undo that for the recursion.  */
 glue(helper_ret_stb, MMUSUFFIX)(env, addr + i, val8,
@@ -415,8 +423,8 @@ static inline void glue(helper_le_st_name, 
_do_mmio_access)(CPUArchState *env,
 CPUIOTLBEntry *iotlbentry = &env->iotlb[mmu_idx][index];
 
 if ((addr & (DATA_SIZE - 1)) != 0) {
-glue(helper_le_st_name, _do_unl_access)(env, val, addr, mmu_idx,
-oi, retaddr);
+glue(helper_generic_st_name, _do_unl_access)(env, true, val, addr,
+ mmu_idx, oi, retaddr);
 }
 /* ??? Note that the io helpers always read data in the target
byte ordering.  We should push the LE/BE request down into io.  */
@@ -438,8 +446,8 @@ static inline void glue(helper_le_st_name, 
_do_ram_access)(CPUArchState *env,
 if (DATA_SIZE > 1
 && unlikely((addr & ~TARGET_PAGE_MASK) + DATA_SIZE - 1
  >= TARGET_PAGE_SIZE)) {
-glue(helper_le_st_name, _do_unl_access)(env, val, addr, oi, mmu_idx,
-retaddr);
+glue(helper_generic_st_name, _do_unl_access)(env, true, val, addr, oi, 
mmu_idx,
+ retaddr);
 return;
 }
 
@@ -538,32 +546,6 @@ void helper_le_st_name(CPUArchState *env, target_ulong 
addr, DATA_TYPE val,
 }
 
 #if DATA_SIZE > 1
-static inline void glue(helper_be_st_name, _do_unl_access)(CPUArchState *env,
-   DATA_TYPE val,
-   target_ulong addr,
-   TCGMemOpIdx oi,
-   unsigned mmu_idx,
-   uintptr_t retaddr)
-{
-int i;
-
-if ((get_memop(oi) & MO_AMASK) == MO_ALIGN) {
-cpu_unaligned_access(ENV_GET_CPU(env), addr, MMU_DATA_STORE,
- mmu_idx, retaddr);
-}
-/* XXX: not efficient, but simple */
-/* Note: relies on the fact that tlb_fill() does not remove the
- * previ

Re: [Qemu-devel] [PATCH] hw/arm/virt: Initialize NICs configured in PCI bus



On 07/01/2016 15:47, Peter Maydell wrote:
> I think my current inclination is to say that virt should
> support -net, because I would prefer to avoid having yet
> another speedbump in the path of people trying to move to
> using KVM-on-ARM based on their previous experience with
> KVM-on-x86.

I agree.

Paolo

Re: [Qemu-devel] [PATCH 29/34] scripts/kvm/kvm_stat: Move to argparse and add description



On 10/12/2015 13:12, Janosch Frank wrote:
> The OptionParser is deprecated since the introduction of the
> ArgumentParser in 2.7.
> 
> Additionally added a description text for the script, so new users
> don't have to guess its purpose and inner workings.

QEMU still supports 2.6, so this cannot be done.

Paolo

Re: [Qemu-devel] [PATCH 00/34] kvm_stat: Cleanup and fixup



On 07/01/2016 14:41, Cornelia Huck wrote:
> On Tue, 15 Dec 2015 10:56:35 +0100
> Cornelia Huck  wrote:
> 
>> On Thu, 10 Dec 2015 13:12:30 +0100
>> Janosch Frank  wrote:
>>
>>> Kvm_stat is a very helpful script for checking the state of VMs, but
>>> when I tried to introduce new features it broke every few lines.
>>>
>>> This patch series aims to make the script more readable and durable,
>>> so future additions to it will break it less likely. It also fixes
>>> input/output problems for all of its interface modes.
>>>
>>> Testing was done rarely on X86_64 RHEL 6.7 and mostly on s390. Tests
>>> on other architectures would be beneficial.
>>
>> The cleanup and fixes look good to me, but I'm most certainly not a
>> python expert :)
>>
>> Paolo, would you take these through the kvm tree?
> 
> Anybody interested in these? I can't really comment on python stuff,
> but it would be a shame if these patches were left out in the cold...

Ok, I've now reviewed it.  I didn't have many comments, but the
Signed-off-by was missing so I prefer to have a v2 instead of follow-up
patches.

Paolo

[Qemu-devel] [PATCH v3 6/8] hw/arm/sysbus-fdt: helpers for clock node generation

Some passthrough'ed devices depend on clock nodes. Those need to be
generated in the guest device tree. This patch introduces some helpers
to build a clock node from information retrieved in the host device tree.

- inherit_properties copies properties from a host device tree node to
  a guest device tree node
- fdt_build_clock_node builds a guest clock node and checks the host
  fellow clock is a fixed one.

fdt_build_clock_node will become static as soon as it gets used. A
dummy pre-declaration is needed for compilation of this patch.

Signed-off-by: Eric Auger 

---

v1 -> v2:
- inherit properties now outputs an error message in case
  qemu_fdt_getprop fails for an existing optional property
- no hardcoded fixed buffer length
- fdt_build_clock_node becomes void and auto-asserts on error
- use boolean values when defining the clock properties

RFC -> v1:
- use the new proto of qemu_fdt_getprop
- remove newline in error_report
- fix some style issues
---
 hw/arm/sysbus-fdt.c | 120 
 1 file changed, 120 insertions(+)

diff --git a/hw/arm/sysbus-fdt.c b/hw/arm/sysbus-fdt.c
index 9d28797..a1cf57b 100644
--- a/hw/arm/sysbus-fdt.c
+++ b/hw/arm/sysbus-fdt.c
@@ -21,6 +21,7 @@
  *
  */
 
+#include 
 #include "hw/arm/sysbus-fdt.h"
 #include "qemu/error-report.h"
 #include "sysemu/device_tree.h"
@@ -56,6 +57,125 @@ typedef struct NodeCreationPair {
 int (*add_fdt_node_fn)(SysBusDevice *sbdev, void *opaque);
 } NodeCreationPair;
 
+/* helpers */
+
+typedef struct HostProperty {
+const char *name;
+bool optional;
+} HostProperty;
+
+/**
+ * inherit_properties
+ *
+ * copies properties listed in an array from host device tree to
+ * guest device tree. If a non optional property is not found, the
+ * function self-asserts. An optional property is ignored if not found
+ * in the host device tree.
+ * @props: array of HostProperty to copy
+ * @nb_props: number of properties in the array
+ * @host_dt: host device tree blob
+ * @guest_dt: guest device tree blob
+ * @node_path: host dt node path where the property is supposed to be
+  found
+ * @nodename: guest node name the properties should be added to
+ */
+static void inherit_properties(HostProperty *props, int nb_props,
+   void *host_fdt, void *guest_fdt,
+   char *node_path, char *nodename)
+{
+int i, prop_len;
+const void *r;
+Error *err = NULL;
+
+for (i = 0; i < nb_props; i++) {
+r = qemu_fdt_getprop(host_fdt, node_path,
+ props[i].name,
+ &prop_len,
+ props[i].optional ? &err : &error_fatal);
+if (r) {
+qemu_fdt_setprop(guest_fdt, nodename,
+ props[i].name, r, prop_len);
+} else {
+if (prop_len != -FDT_ERR_NOTFOUND) {
+/* optional property not returned although property exists */
+error_report_err(err);
+} else {
+error_free(err);
+}
+}
+}
+}
+
+/* clock properties whose values are copied/pasted from host */
+static HostProperty clock_inherited_properties[] = {
+{"compatible", false},
+{"#clock-cells", false},
+{"clock-frequency", true},
+{"clock-output-names", true},
+};
+
+/**
+ * fdt_build_clock_node
+ *
+ * Build a guest clock node, used as a dependency from a passthrough'ed
+ * device. Most information are retrieved from the host clock node.
+ * Also check the host clock is a fixed one.
+ *
+ * @host_fdt: host device tree blob from which info are retrieved
+ * @guest_fdt: guest device tree blob where the clock node is added
+ * @host_phandle: phandle of the clock in host device tree
+ * @guest_phandle: phandle to assign to the guest node
+ */
+void fdt_build_clock_node(void *host_fdt, void *guest_fdt,
+ uint32_t host_phandle,
+ uint32_t guest_phandle);
+void fdt_build_clock_node(void *host_fdt, void *guest_fdt,
+ uint32_t host_phandle,
+ uint32_t guest_phandle)
+{
+char *node_path = NULL;
+char *nodename;
+const void *r;
+int ret, node_offset, prop_len, path_len = 16;
+
+node_offset = fdt_node_offset_by_phandle(host_fdt, host_phandle);
+if (node_offset <= 0) {
+error_setg(&error_fatal,
+   "not able to locate clock handle %d in host device tree",
+   host_phandle);
+}
+node_path = g_malloc(path_len);
+while ((ret = fdt_get_path(host_fdt, node_offset, node_path, path_len))
+== -FDT_ERR_NOSPACE) {
+path_len += 16;
+node_path = g_realloc(node_path, path_len);
+}
+if (ret < 0) {
+error_setg(&error_fatal,
+   "not able to retrieve node path for clock handle %d",
+   host_phandle);
+}
+
+r = qemu_fdt_getprop(host

[Qemu-devel] [PATCH v3 4/8] device_tree: qemu_fdt_getprop converted to use the error API

Current qemu_fdt_getprop exits if the property is not found. It is
sometimes needed to read an optional property, in which case we do
not wish to exit but simply returns a null value.

This patch converts qemu_fdt_getprop to accept an Error **, and existing
users are converted to pass &error_fatal. This preserves the existing
behaviour. Then to use the API with your optional semantic a null
parameter can be conveyed.

Signed-off-by: Eric Auger 

---

v1 -> v2:
- add a doc comment in the header file

RFC -> v1:
- get rid of qemu_fdt_getprop_optional and implement Peter's suggestion
  that consists in using the error API

Signed-off-by: Eric Auger 
---
 device_tree.c| 11 ++-
 include/sysemu/device_tree.h | 15 ++-
 2 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/device_tree.c b/device_tree.c
index 8441e01..6ecc9da 100644
--- a/device_tree.c
+++ b/device_tree.c
@@ -321,18 +321,18 @@ int qemu_fdt_setprop_string(void *fdt, const char 
*node_path,
 }
 
 const void *qemu_fdt_getprop(void *fdt, const char *node_path,
- const char *property, int *lenp)
+ const char *property, int *lenp, Error **errp)
 {
 int len;
 const void *r;
+
 if (!lenp) {
 lenp = &len;
 }
 r = fdt_getprop(fdt, findnode_nofail(fdt, node_path), property, lenp);
 if (!r) {
-error_report("%s: Couldn't get %s/%s: %s", __func__,
- node_path, property, fdt_strerror(*lenp));
-exit(1);
+error_setg(errp, "%s: Couldn't get %s/%s: %s", __func__,
+  node_path, property, fdt_strerror(*lenp));
 }
 return r;
 }
@@ -341,7 +341,8 @@ uint32_t qemu_fdt_getprop_cell(void *fdt, const char 
*node_path,
const char *property)
 {
 int len;
-const uint32_t *p = qemu_fdt_getprop(fdt, node_path, property, &len);
+const uint32_t *p = qemu_fdt_getprop(fdt, node_path, property, &len,
+ &error_fatal);
 if (len != 4) {
 error_report("%s: %s/%s not 4 bytes long (not a cell?)",
  __func__, node_path, property);
diff --git a/include/sysemu/device_tree.h b/include/sysemu/device_tree.h
index 269cb1c..4d7cbb9 100644
--- a/include/sysemu/device_tree.h
+++ b/include/sysemu/device_tree.h
@@ -45,8 +45,21 @@ int qemu_fdt_setprop_string(void *fdt, const char *node_path,
 int qemu_fdt_setprop_phandle(void *fdt, const char *node_path,
  const char *property,
  const char *target_node_path);
+/**
+ * qemu_fdt_getprop: retrieve the value of a given property
+ * @fdt: pointer to the device tree blob
+ * @node_path: node path
+ * @property: name of the property to find
+ * @lenp: fdt error if any or length of the property on success
+ * @errp: handle to an error object
+ *
+ * returns a pointer to the property on success and NULL on failure
+ * in case errp is set to &error_fatal, the function auto-asserts
+ * on error (legacy behavior)
+ */
 const void *qemu_fdt_getprop(void *fdt, const char *node_path,
- const char *property, int *lenp);
+ const char *property, int *lenp,
+ Error **errp);
 uint32_t qemu_fdt_getprop_cell(void *fdt, const char *node_path,
const char *property);
 uint32_t qemu_fdt_get_phandle(void *fdt, const char *path);
-- 
1.9.1

Re: [Qemu-devel] [PATCH 0/8] ivshmem: test msi=off, remove CharDriver

2016-01-07 Thread Marc-André Lureau

Hi

On Mon, Dec 21, 2015 at 12:30 PM,   wrote:
> From: Marc-André Lureau 
>
> This is a ivshmem series with various bits:
> - add a test for a recently introduced regression
> - the fix is included in the series but was sent separatly to cc -stable
> - fix some test leaks
> - get rid of CharDriver usage for eventfd
> - simplify event callback
>

Adding a few people in CC who might help with reviewing.

thanks

> Marc-André Lureau (8):
>   ivshmem: no need for opaque argument
>   ivshmem: remove redundant assignment, fix crash with msi=off
>   ivshmem-test: leak fixes
>   libqos: remove some leaks
>   ivshmem-test: test both msi & irq cases
>   ivshmem: generalize ivshmem_setup_interrupts
>   ivshmem: use a single eventfd callback, get rid of CharDriver
>   char: remove qemu_chr_open_eventfd
>
>  hw/misc/ivshmem.c | 85 
> +--
>  include/sysemu/char.h |  3 --
>  qemu-char.c   | 13 
>  tests/ivshmem-test.c  | 81 
>  tests/libqos/pci.c|  2 ++
>  5 files changed, 91 insertions(+), 93 deletions(-)
>
> --
> 2.5.0
>
>



-- 
Marc-André Lureau

[Qemu-devel] [PATCH v3 7/8] hw/arm/sysbus-fdt: enable amd-xgbe dynamic instantiation

This patch allows the instantiation of the vfio-amd-xgbe device
from the QEMU command line (-device vfio-amd-xgbe,host="").

The guest is exposed with a device tree node that combines the description
of both XGBE and PHY (representation supported from 4.2 onwards kernel):
Documentation/devicetree/bindings/net/amd-xgbe.txt.

There are 5 register regions, 6 interrupts including 4 optional
edge-sensitive per-channel interrupts.

Some property values are inherited from host device tree. Host device tree
must feature a combined XGBE/PHY representation (>= 4.2 host kernel).

2 clock nodes (dma and ptp) also are created. It is checked those clocks
are fixed on host side.

AMD XGBE node creation function has a dependency on vfio Linux header and
more generally node creation function for VFIO platform devices only make
sense with CONFIG_LINUX so let's protect this code with #ifdef CONFIG_LINUX.

Signed-off-by: Eric Auger 

---
v1 -> v2:
- add CONFIG_LINUX protection
- improves robustness in sysfs_to_dt_name
- output messages to end-user on misc failures and self-exits:
  error management becomes more violent than before assuming if
  the end-user wants passthrough we must exit if the device cannot
  be instantiated
- fix misc style issues
- remove qemu_fdt_setprop returned value check since it self-asserts

RFC -> v1:
- use qemu_fdt_getprop with Error **
- free substrings in sysfs_to_dt_name
- add some comments related to endianess in add_amd_xgbe_fdt_node
- reword commit message (dtc binary dependency has disappeared)
- check the host device has 5 regions meaning this is a combined
  XGBE/PHY device
---
 hw/arm/sysbus-fdt.c | 187 ++--
 1 file changed, 181 insertions(+), 6 deletions(-)

diff --git a/hw/arm/sysbus-fdt.c b/hw/arm/sysbus-fdt.c
index a1cf57b..66fa766 100644
--- a/hw/arm/sysbus-fdt.c
+++ b/hw/arm/sysbus-fdt.c
@@ -22,6 +22,10 @@
  */
 
 #include 
+#include "qemu-common.h"
+#ifdef CONFIG_LINUX
+#include 
+#endif
 #include "hw/arm/sysbus-fdt.h"
 #include "qemu/error-report.h"
 #include "sysemu/device_tree.h"
@@ -29,6 +33,7 @@
 #include "sysemu/sysemu.h"
 #include "hw/vfio/vfio-platform.h"
 #include "hw/vfio/vfio-calxeda-xgmac.h"
+#include "hw/vfio/vfio-amd-xgbe.h"
 #include "hw/arm/fdt.h"
 
 /*
@@ -64,6 +69,8 @@ typedef struct HostProperty {
 bool optional;
 } HostProperty;
 
+#ifdef CONFIG_LINUX
+
 /**
  * inherit_properties
  *
@@ -126,12 +133,9 @@ static HostProperty clock_inherited_properties[] = {
  * @host_phandle: phandle of the clock in host device tree
  * @guest_phandle: phandle to assign to the guest node
  */
-void fdt_build_clock_node(void *host_fdt, void *guest_fdt,
- uint32_t host_phandle,
- uint32_t guest_phandle);
-void fdt_build_clock_node(void *host_fdt, void *guest_fdt,
- uint32_t host_phandle,
- uint32_t guest_phandle)
+static void fdt_build_clock_node(void *host_fdt, void *guest_fdt,
+uint32_t host_phandle,
+uint32_t guest_phandle)
 {
 char *node_path = NULL;
 char *nodename;
@@ -176,6 +180,28 @@ void fdt_build_clock_node(void *host_fdt, void *guest_fdt,
 g_free(node_path);
 }
 
+/**
+ * sysfs_to_dt_name: convert the name found in sysfs into the node name
+ * for instance e090.xgmac is converted into xgmac@e090
+ * @sysfs_name: directory name in sysfs
+ *
+ * returns the device tree name upon success or NULL in case the sysfs name
+ * does not match the expected format
+ */
+static char *sysfs_to_dt_name(const char *sysfs_name)
+{
+gchar **substrings =  g_strsplit(sysfs_name, ".", 2);
+char *dt_name = NULL;
+
+if (!substrings || !substrings[1] || !substrings[0]) {
+goto out;
+}
+dt_name = g_strdup_printf("%s@%s", substrings[1], substrings[0]);
+out:
+g_strfreev(substrings);
+return dt_name;
+}
+
 /* Device Specific Code */
 
 /**
@@ -243,9 +269,158 @@ fail_reg:
 return ret;
 }
 
+
+/* AMD xgbe properties whose values are copied/pasted from host */
+static HostProperty amd_xgbe_inherited_properties[] = {
+{"compatible", false},
+{"dma-coherent", true},
+{"amd,per-channel-interrupt", true},
+{"phy-mode", false},
+{"mac-address", true},
+{"amd,speed-set", false},
+{"amd,serdes-blwc", true},
+{"amd,serdes-cdr-rate", true},
+{"amd,serdes-pq-skew", true},
+{"amd,serdes-tx-amp", true},
+{"amd,serdes-dfe-tap-config", true},
+{"amd,serdes-dfe-tap-enable", true},
+{"clock-names", false},
+};
+
+/**
+ * add_amd_xgbe_fdt_node
+ *
+ * Generates the combined xgbe/phy node following kernel >=4.2
+ * binding documentation:
+ * Documentation/devicetree/bindings/net/amd-xgbe.txt:
+ * Also 2 clock nodes are created (dma and ptp)
+ */
+static int add_amd_xgbe_fdt_node(SysBusDevice *sbdev, void *opaque)
+{
+PlatformBusFDTData *data = opaque;
+PlatformBusDevice *pbus = data->pbus;

Re: [Qemu-devel] arm64 qemu tests failing in linux-next since 'arm64: kernel: enforce pmuserenr_el0 initialization and restore'

2016-01-07 Thread Lorenzo Pieralisi

On Thu, Jan 07, 2016 at 01:25:35PM +, Peter Maydell wrote:
> On 24 December 2015 at 00:52, Guenter Roeck  wrote:
> > Hi all,
> >
> > since commit 60792ad349f3 ("arm64: kernel: enforce pmuserenr_el0
> > initialization
> > and restore"), my arm64 qemu tests of linux-next are failing. After this
> > commit,
> > qemu does not display any output.
> >
> > Qemu version is 2.5.0. Linux kernel configuration is arm64:defconfig.
> >
> > qemu command line is as follows:
> >
> > qemu-system-aarch64 -machine virt -cpu cortex-a57 -machine type=virt
> > -nographic -smp 1 \
> > -m 512 -kernel arch/arm64/boot/Image -initrd
> > rootfs.arm64.cpio -no-reboot \
> > -append "console=ttyAMA0"
> >
> > Any idea what might cause this problem and how to fix it (presumably in
> > qemu) ?
> 
> This turns out to be because QEMU doesn't currently implement
> PMUSERENR_EL0 for AArch64 (we do have an AArch32 implementation),
> so you get an immediate UNDEF when the kernel touches it, followed
> by an infinite loop of UNDEF exceptions because the instruction
> at the UNDEF vector entrypoint is unallocated at this point in
> execution.
> 
> We had previously been relying on the kernel not attempting to
> touch the PMU if the ID_AA64DFR0_EL1 PMUVer bits read 
> ("Performance Monitors extension System registers not implemented").

Ok, thanks for looking into this. I wonder why reading pmcr_el0 does
not suffer from the same problem though.

> Since the v8 ARM ARM states that the Performance Monitors Extension is
> an optional feature of an implementation, this seems like a kernel
> bug to me. (QEMU should probably get round to implementing the PMU
> at some point for feature parity with v7, but this has not been
> a priority for us since they're not actually very useful in a
> fully emulated setup.)

Fixup patch coming, thanks.

Lorenzo

Re: [Qemu-devel] arm64 qemu tests failing in linux-next since 'arm64: kernel: enforce pmuserenr_el0 initialization and restore'

On 7 January 2016 at 15:53, Lorenzo Pieralisi  wrote:
> On Thu, Jan 07, 2016 at 01:25:35PM +, Peter Maydell wrote:
>> We had previously been relying on the kernel not attempting to
>> touch the PMU if the ID_AA64DFR0_EL1 PMUVer bits read 
>> ("Performance Monitors extension System registers not implemented").
>
> Ok, thanks for looking into this. I wonder why reading pmcr_el0 does
> not suffer from the same problem though.

Just a pragmatic thing on QEMU's end, I expect -- the kernel already
touched PMCR_EL0 and we wanted to be able to boot it, so we have an
implementation of it.

thanks
-- PMM

[Qemu-devel] [PATCH v3 8/8] hw/arm/sysbus-fdt: remove qemu_fdt_setprop returned value check

qemu_fdt_setprop self-exists in case of error hence no need to check
the returned value.

Signed-off-by: Eric Auger 
---
 hw/arm/sysbus-fdt.c | 15 +++
 1 file changed, 3 insertions(+), 12 deletions(-)

diff --git a/hw/arm/sysbus-fdt.c b/hw/arm/sysbus-fdt.c
index 66fa766..68d7e53 100644
--- a/hw/arm/sysbus-fdt.c
+++ b/hw/arm/sysbus-fdt.c
@@ -241,12 +241,8 @@ static int add_calxeda_midway_xgmac_fdt_node(SysBusDevice 
*sbdev, void *opaque)
 reg_attr[2 * i + 1] = cpu_to_be32(
 memory_region_size(&vdev->regions[i]->mem));
 }
-ret = qemu_fdt_setprop(fdt, nodename, "reg", reg_attr,
-   vbasedev->num_regions * 2 * sizeof(uint32_t));
-if (ret) {
-error_report("could not set reg property of node %s", nodename);
-goto fail_reg;
-}
+qemu_fdt_setprop(fdt, nodename, "reg", reg_attr,
+ vbasedev->num_regions * 2 * sizeof(uint32_t));
 
 irq_attr = g_new(uint32_t, vbasedev->num_irqs * 3);
 for (i = 0; i < vbasedev->num_irqs; i++) {
@@ -256,14 +252,9 @@ static int add_calxeda_midway_xgmac_fdt_node(SysBusDevice 
*sbdev, void *opaque)
 irq_attr[3 * i + 1] = cpu_to_be32(irq_number);
 irq_attr[3 * i + 2] = cpu_to_be32(GIC_FDT_IRQ_FLAGS_LEVEL_HI);
 }
-ret = qemu_fdt_setprop(fdt, nodename, "interrupts",
+qemu_fdt_setprop(fdt, nodename, "interrupts",
  irq_attr, vbasedev->num_irqs * 3 * sizeof(uint32_t));
-if (ret) {
-error_report("could not set interrupts property of node %s",
- nodename);
-}
 g_free(irq_attr);
-fail_reg:
 g_free(reg_attr);
 g_free(nodename);
 return ret;
-- 
1.9.1

Re: [Qemu-devel] [PATCH v3 11/11] igd: move igd-passthrough-isa-bridge creation to machine init

2016-01-07 Thread Gerd Hoffmann

On Do, 2016-01-07 at 13:10 +, Stefano Stabellini wrote:
> CC'ing the Xen x86 maintainers
> 
> On Thu, 7 Jan 2016, Gerd Hoffmann wrote:
> >   Hi,
> > 
> > > One thing I don't like about this is that it is going to skip the checks
> > > done in xen_pt_initfn.
> > 
> > Hmm?  Those checks are still done when you assign a igd ...
> 
> Their failure doesn't affect the creation of the bridge.

Doesn't their failure makes qemu throw a fatal error and exit?
So the guest isn't going to run either way?

> > > For example it is going to create the isa bridge,
> > > even if there is going to be an error loading the vga bios or if the
> > > device specified is not even an Intel graphic card.
> > 
> > Creating the special igd-isa-bridge is no longer tied to actually
> > assigning a igd, but to the igd-passthru=on machine option being present
> > (and machine type being 'pc').
> 
> and machine type 'xenfv', unless I am mistaken?

Yes, xenfv too (uses i440fx too and thus is a 'pc' derivate).

> > xen_pt_initfn checks that igd-passthru=on is set in case it finds a igd
> > device is assigned, that will make sure the igd-isa-bridge is present.
> > 
> > But, yes, you can create a igd-isa-bridge now even when not assigning a
> > igd device, either by specifying igd-passthru=on or using -device.  I
> > fail to see why this is a problem though, care to explain?
> 
> It is going to change the PCI layout of any virtual machines with a
> config file containing
> 
> gfx_passthru="igd"
> 
> and no pci config line. A Xen 4.7 user could add gfx_passthru="igd" to
> all her VM config files, because actually it does nothing unless an
> Intel graphic card is assigned to the VM.

No.  It changes the host bridge even when not passing through a igd,
because that is linked to igd-passthru=on only.

So making both host bridge tweak and isa bridge tweak triggered by
igd-passthru=on brings more consistency to the whole thing.

> > Also note that moving this to machine init nicely handles the fact that
> > the igd-isa-bridge is needed on 'pc' only, not on 'q35'.  If you don't
> > want create the igd-isa-bridge in machine init, what is your alternative
> > suggestion to handle this?
> 
> Maybe we could retain the check whether an Intel graphic card has been
> assigned? 

Should be possible, but is not that easy due to initialization order
issues.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH 29/34] scripts/kvm/kvm_stat: Move to argparse and add description

On 07/01/2016 16:54, Janosch Frank wrote:
> On 01/07/2016 04:41 PM, Paolo Bonzini wrote:
>>
>>
>> On 10/12/2015 13:12, Janosch Frank wrote:
>>> The OptionParser is deprecated since the introduction of the
>>> ArgumentParser in 2.7.
>>>
>>> Additionally added a description text for the script, so new users
>>> don't have to guess its purpose and inner workings.
>>
>> QEMU still supports 2.6, so this cannot be done.
>>
>> Paolo
>>
> 
> I guess you don't want to have the dependency on the python-argparse
> package which is provided down to 2.3?

I would at least make it a separate patch, because unlike other patches
in this series it would require a mention in the release notes.  One
would also have to check whether the supported Linux distributions
include it (for example, RHEL6 only includes it since RHEL6.4; I don't
know about SLES-11).

Paolo

Re: [Qemu-devel] [PATCH v6 1/6] qdev: get_child_bus(): Use QOM lookup if available

On 20 December 2015 at 05:43, Peter Crosthwaite
 wrote:
> qbus_realize() adds busses as a QOM child of the device in addition to
> adding it to the qdev bus list. Change get_child_bus() to use the QOM
> child if it is available. This takes priority over the bus-list, but
> the child object is checked for type correctness.
>
> This prepares support for aliasing of buses. The use case is SoCs,
> where a SoC container needs to present buses to the board level, but
> the buses are implemented by controller IP we already model as self
> contained qbus-containing devices.
>
> Signed-off-by: Peter Crosthwaite 
> ---
> Currently qbus_realize() ignores errors from object_property_add_child,
> so it is hard to guarantee that the QOM linkage is reliable. If it were
> the case that that object_property_add_child was supposed to be error
> asserting, we could remove the old bus-list strcmp iterator altogether.
>
>  hw/core/qdev.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/hw/core/qdev.c b/hw/core/qdev.c
> index b3ad467..c96c464 100644
> --- a/hw/core/qdev.c
> +++ b/hw/core/qdev.c
> @@ -581,6 +581,12 @@ void qdev_pass_gpios(DeviceState *dev, DeviceState 
> *container,
>  BusState *qdev_get_child_bus(DeviceState *dev, const char *name)
>  {
>  BusState *bus;
> +Object *child = object_resolve_path_component(OBJECT(dev), name);
> +
> +bus = (BusState *)object_dynamic_cast(child, TYPE_BUS);
> +if (bus) {
> +return bus;
> +}
>
>  QLIST_FOREACH(bus, &dev->child_bus, sibling) {
>  if (strcmp(name, bus->name) == 0) {

This looks OK to me (and I like the effective API you get for
devices using things), but I don't know enough QOM/qdev internals
to be completely confident giving it a reviewed-by.

thanks
-- PMM

Re: [Qemu-devel] arm64 qemu tests failing in linux-next since 'arm64: kernel: enforce pmuserenr_el0 initialization and restore'

2016-01-07 Thread Guenter Roeck


On 01/07/2016 07:53 AM, Lorenzo Pieralisi wrote:

On Thu, Jan 07, 2016 at 01:25:35PM +, Peter Maydell wrote:

On 24 December 2015 at 00:52, Guenter Roeck  wrote:

Hi all,

since commit 60792ad349f3 ("arm64: kernel: enforce pmuserenr_el0
initialization
and restore"), my arm64 qemu tests of linux-next are failing. After this
commit,
qemu does not display any output.

Qemu version is 2.5.0. Linux kernel configuration is arm64:defconfig.

qemu command line is as follows:

 qemu-system-aarch64 -machine virt -cpu cortex-a57 -machine type=virt
-nographic -smp 1 \
 -m 512 -kernel arch/arm64/boot/Image -initrd
rootfs.arm64.cpio -no-reboot \
 -append "console=ttyAMA0"

Any idea what might cause this problem and how to fix it (presumably in
qemu) ?


This turns out to be because QEMU doesn't currently implement
PMUSERENR_EL0 for AArch64 (we do have an AArch32 implementation),
so you get an immediate UNDEF when the kernel touches it, followed
by an infinite loop of UNDEF exceptions because the instruction
at the UNDEF vector entrypoint is unallocated at this point in
execution.

We had previously been relying on the kernel not attempting to
touch the PMU if the ID_AA64DFR0_EL1 PMUVer bits read 
("Performance Monitors extension System registers not implemented").


Ok, thanks for looking into this. I wonder why reading pmcr_el0 does
not suffer from the same problem though.


Since the v8 ARM ARM states that the Performance Monitors Extension is
an optional feature of an implementation, this seems like a kernel
bug to me. (QEMU should probably get round to implementing the PMU
at some point for feature parity with v7, but this has not been
a priority for us since they're not actually very useful in a
fully emulated setup.)


Fixup patch coming, thanks.



The following code around the register accesses fixes the problem for me.
+   mrs x0, ID_AA64DFR0_EL1
+   tst x0, #0xf00
+   b.eq1f
msr pmuserenr_el0, xzr  // Disable PMU access from EL0
+1:

I don't have a real system, so I can not verify if the register is correctly
set there. Plus, of course, I don't really know aarch64 assembler, so the above
code may be plain wrong ;-).

Guenter

Re: [Qemu-devel] [PATCH 1/2] compat: Introduce HW_COMPAT_2_5



On 23/12/2015 20:21, Shmulik Ladkani wrote:
> Hi,
> 
> On Fri, 18 Dec 2015 09:30:02 +0200 Shmulik Ladkani 
>  wrote:
>> Introduce the place-holder for 2.5 back-compat properties, and the
>> accompanying PC_COMPAT_2_5, CCW_COMPAT_2_5, SPAPR_COMPAT_2_5.
> 
> Please ignore this series, it'll clash.
> 
> Recent pull has already introduced HW_COMPAT_2_5 and PC_COMPAT_2_5
> (240240d pc: Add pc-*-2.6 machine classes).
> 
> I'll send patches introducing only CCW_COMPAT_2_5 and SPAPR_COMPAT_2_5

Can you send these now?

Thanks,

Paolo

Re: [Qemu-devel] [PATCH v1 2/6] kvm/x86: Hyper-V unify stimer_start() and stimer_restart()



On 23/12/2015 12:28, Andrey Smetanin wrote:
> This will be used in future to start Hyper-V SynIC timer
> in several places by one logic in one function.
> 
> Signed-off-by: Andrey Smetanin 
> Reviewed-by: Roman Kagan 
> CC: Gleb Natapov 
> CC: Paolo Bonzini 
> CC: Roman Kagan 
> CC: Denis V. Lunev 
> CC: qemu-devel@nongnu.org
> ---
>  arch/x86/kvm/hyperv.c | 37 -
>  1 file changed, 16 insertions(+), 21 deletions(-)
> 
> diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
> index ec3a900..8623aa6 100644
> --- a/arch/x86/kvm/hyperv.c
> +++ b/arch/x86/kvm/hyperv.c
> @@ -408,6 +408,7 @@ static void stimer_cleanup(struct kvm_vcpu_hv_stimer 
> *stimer)
>   clear_bit(stimer->index,
> vcpu_to_hv_vcpu(vcpu)->stimer_pending_bitmap);
>   stimer->msg_pending = false;
> + stimer->exp_time = 0;
>  }
>  
>  static enum hrtimer_restart stimer_timer_callback(struct hrtimer *timer)
> @@ -420,24 +421,6 @@ static enum hrtimer_restart stimer_timer_callback(struct 
> hrtimer *timer)
>   return HRTIMER_NORESTART;
>  }
>  
> -static void stimer_restart(struct kvm_vcpu_hv_stimer *stimer)
> -{
> - u64 time_now;
> - ktime_t ktime_now;
> - u64 remainder;
> -
> - time_now = get_time_ref_counter(stimer_to_vcpu(stimer)->kvm);
> - ktime_now = ktime_get();
> -
> - div64_u64_rem(time_now - stimer->exp_time, stimer->count, &remainder);
> - stimer->exp_time = time_now + (stimer->count - remainder);
> -
> - hrtimer_start(&stimer->timer,
> -   ktime_add_ns(ktime_now,
> -100 * (stimer->exp_time - time_now)),
> -   HRTIMER_MODE_ABS);
> -}
> -
>  static int stimer_start(struct kvm_vcpu_hv_stimer *stimer)
>  {
>   u64 time_now;
> @@ -450,9 +433,21 @@ static int stimer_start(struct kvm_vcpu_hv_stimer 
> *stimer)
>   if (stimer->count == 0)
>   return -EINVAL;
>  
> - stimer->exp_time = time_now + stimer->count;
> + if (stimer->exp_time) {
> + if (time_now >= stimer->exp_time) {

Just for my education, is it possible to have this function called with
stimer->exp_time != 0 && time_now < stimer->exp_time?

Paolo

> + u64 remainder;
> +
> + div64_u64_rem(time_now - stimer->exp_time,
> +   stimer->count, &remainder);
> + stimer->exp_time =
> + time_now + (stimer->count - remainder);
> + }
> + } else
> + stimer->exp_time = time_now + stimer->count;
> +
>   hrtimer_start(&stimer->timer,
> -   ktime_add_ns(ktime_now, 100 * stimer->count),
> +   ktime_add_ns(ktime_now,
> +100 * (stimer->exp_time - time_now)),
> HRTIMER_MODE_ABS);
>   return 0;
>   }
> @@ -580,7 +575,7 @@ static void stimer_expiration(struct kvm_vcpu_hv_stimer 
> *stimer)
>   if (!(stimer->config & HV_STIMER_PERIODIC))
>   stimer->config |= ~HV_STIMER_ENABLE;
>   else
> - stimer_restart(stimer);
> + stimer_start(stimer);
>  }
>  
>  void kvm_hv_process_stimers(struct kvm_vcpu *vcpu)
>

Re: [Qemu-devel] [PATCH 1/2] compat: Introduce HW_COMPAT_2_5

On Thu, 7 Jan 2016 17:30:20 +0100
Paolo Bonzini  wrote:

> On 23/12/2015 20:21, Shmulik Ladkani wrote:
> > Hi,
> > 
> > On Fri, 18 Dec 2015 09:30:02 +0200 Shmulik Ladkani 
> >  wrote:
> >> Introduce the place-holder for 2.5 back-compat properties, and the
> >> accompanying PC_COMPAT_2_5, CCW_COMPAT_2_5, SPAPR_COMPAT_2_5.
> > 
> > Please ignore this series, it'll clash.
> > 
> > Recent pull has already introduced HW_COMPAT_2_5 and PC_COMPAT_2_5
> > (240240d pc: Add pc-*-2.6 machine classes).
> > 
> > I'll send patches introducing only CCW_COMPAT_2_5 and SPAPR_COMPAT_2_5
> 
> Can you send these now?

I've already added the CCW_COMPAT_2_5 patch to my queue.

Re: [Qemu-devel] [PATCH v1 3/6] kvm/x86: Reorg stimer_expiration() to better control timer restart



On 23/12/2015 12:28, Andrey Smetanin wrote:
> - stimer_send_msg(stimer);
> - if (!(stimer->config & HV_STIMER_PERIODIC))
> - stimer->config |= ~HV_STIMER_ENABLE;
> - else
> - stimer_start(stimer);
> + stimer->msg_pending = true;
> + if (!stimer_send_msg(stimer)) {
> + stimer->msg_pending = false;
> + if (!(stimer->config & HV_STIMER_PERIODIC))
> + stimer->config |= ~HV_STIMER_ENABLE;

Just because this is curious: sure it shouldn't be "&="?

Paolo

> + }

Re: [Qemu-devel] arm64 qemu tests failing in linux-next since 'arm64: kernel: enforce pmuserenr_el0 initialization and restore'

2016-01-07 Thread Lorenzo Pieralisi

On Thu, Jan 07, 2016 at 03:58:15PM +, Peter Maydell wrote:
> On 7 January 2016 at 15:53, Lorenzo Pieralisi  
> wrote:
> > On Thu, Jan 07, 2016 at 01:25:35PM +, Peter Maydell wrote:
> >> We had previously been relying on the kernel not attempting to
> >> touch the PMU if the ID_AA64DFR0_EL1 PMUVer bits read 
> >> ("Performance Monitors extension System registers not implemented").
> >
> > Ok, thanks for looking into this. I wonder why reading pmcr_el0 does
> > not suffer from the same problem though.
> 
> Just a pragmatic thing on QEMU's end, I expect -- the kernel already
> touched PMCR_EL0 and we wanted to be able to boot it, so we have an
> implementation of it.

If that's the case, that was the wrong approach IMHO. QEMU has to comply
with the Aarch64 architecture which means that either the CPU it models
has a Performance Monitors extension or it does not. If reading pmcr_el0
does not fault I could tell you this is a QEMU regression because currently
it _does_ model pmcr_el0 while (hopefully) ID_AA64DFR0_EL1 PMUVer reports
it should not.

I will add code that guards both register accesses to fix both bugs at
once.

Thanks,
Lorenzo

Re: [Qemu-devel] [PATCH v1 0/6] KVM: Hyper-V SynIC timers migration fixes



On 23/12/2015 12:28, Andrey Smetanin wrote:
> During testing of Windows 2012R2 guest migration with
> Hyper-V SynIC timers enabled we found several bugs
> which lead to restoring guest in a hung state.
> 
> This patch series provides several fixes to make the
> migration of guest with Hyper-V SynIC timers enabled
> succeed.
> 
> The series applies on top of
> 'kvm/x86: Remove Hyper-V SynIC timer stopping'
> previously sent.
> 
> Signed-off-by: Andrey Smetanin 
> Reviewed-by: Roman Kagan 
> CC: Gleb Natapov 
> CC: Paolo Bonzini 
> CC: Roman Kagan 
> CC: Denis V. Lunev 
> CC: qemu-devel@nongnu.org
> 
> Andrey Smetanin (6):
>   kvm/x86: Drop stimer_stop() function
>   kvm/x86: Hyper-V unify stimer_start() and stimer_restart()
>   kvm/x86: Reorg stimer_expiration() to better control timer restart
>   kvm/x86: Hyper-V fix SynIC timer disabling condition
>   kvm/x86: Skip SynIC vector check for QEMU side
>   kvm/x86: Update SynIC timers on guest entry only
> 
>  arch/x86/kvm/hyperv.c | 112 
> +++---
>  arch/x86/kvm/x86.c|   6 +++
>  2 files changed, 58 insertions(+), 60 deletions(-)
> 

Applied, let me know if I should fix up patch 3 (the bug is preexisting
anyway, if it is a bug as I suspect).

Paolo

Re: [Qemu-devel] [PATCH v2 3/7] kvm/x86: Hyper-V unify stimer_start() and stimer_restart()



On 28/12/2015 16:27, Andrey Smetanin wrote:
> This will be used in future to start Hyper-V SynIC timer
> in several places by one logic in one function.
> 
> Changes v2:
> * drop stimer->count == 0 check inside stimer_start()
> * comment stimer_start() assumptions

Can you replace comments with WARN_ON_ONCE?

Paolo

Re: [Qemu-devel] [PATCH 09/22] 9pfs: remove dead code

2016-01-07 Thread Aneesh Kumar K.V

Wei Liu  writes:

> Some structures virtio-9p.h have been unused since 2011 when relevant
> functions switched to use coroutines.
>
> The declaration of pdu_packunpack and function do_pdu_unpack are
> useless.
>
> The function virtio_9p_set_fd_limit is unused.
>
> Signed-off-by: Wei Liu 
> ---
>  hw/9pfs/virtio-9p.c | 11 -
>  hw/9pfs/virtio-9p.h | 68 
> -
>  2 files changed, 79 deletions(-)
>
> diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
> index 30ff828..084fa6a 100644
> --- a/hw/9pfs/virtio-9p.c
> +++ b/hw/9pfs/virtio-9p.c
> @@ -3287,14 +3287,3 @@ void handle_9p_output(VirtIODevice *vdev, VirtQueue 
> *vq)
>  }
>  free_pdu(s, pdu);
>  }
> -
> -static void __attribute__((__constructor__)) virtio_9p_set_fd_limit(void)
> -{
> -struct rlimit rlim;
> -if (getrlimit(RLIMIT_NOFILE, &rlim) < 0) {
> -fprintf(stderr, "Failed to get the resource limit\n");
> -exit(1);
> -}
> -open_fd_hw = rlim.rlim_cur - MIN(400, rlim.rlim_cur/3);
> -open_fd_rc = rlim.rlim_cur/2;
> -}

I am looking at when we stopped using that. We still do file descriptor
reclaim. If we do that we need to set the open_fd_hw/rc.



> diff --git a/hw/9pfs/virtio-9p.h b/hw/9pfs/virtio-9p.h
> index ac4cb00..3c78d3c 100644
> --- a/hw/9pfs/virtio-9p.h
> +++ b/hw/9pfs/virtio-9p.h
> @@ -227,65 +227,6 @@ typedef struct V9fsState
>  V9fsConf fsconf;
>2.1.4

-aneesh

Re: [Qemu-devel] [PATCH 1/2] compat: Introduce HW_COMPAT_2_5



On 07/01/2016 17:33, Cornelia Huck wrote:
> On Thu, 7 Jan 2016 17:30:20 +0100
> Paolo Bonzini  wrote:
> 
>> On 23/12/2015 20:21, Shmulik Ladkani wrote:
>>> Hi,
>>>
>>> On Fri, 18 Dec 2015 09:30:02 +0200 Shmulik Ladkani 
>>>  wrote:
 Introduce the place-holder for 2.5 back-compat properties, and the
 accompanying PC_COMPAT_2_5, CCW_COMPAT_2_5, SPAPR_COMPAT_2_5.
>>>
>>> Please ignore this series, it'll clash.
>>>
>>> Recent pull has already introduced HW_COMPAT_2_5 and PC_COMPAT_2_5
>>> (240240d pc: Add pc-*-2.6 machine classes).
>>>
>>> I'll send patches introducing only CCW_COMPAT_2_5 and SPAPR_COMPAT_2_5
>>
>> Can you send these now?
> 
> I've already added the CCW_COMPAT_2_5 patch to my queue.
> 

Ok, so I can send Shmulik's patch doing

@@ -2,14 +2,7 @@
 #define HW_COMPAT_H

 #define HW_COMPAT_2_5 \
-/* empty */
-
-#define HW_COMPAT_2_4 \
 {\
-.driver   = "virtio-blk-device",\
-.property = "scsi",\
-.value= "true",\
-},{\
 .driver   = "pvscsi",\
 .property = "x-old-pci-configuration",\
 .value= "on",\
@@ -17,6 +10,13 @@
 .driver   = "pvscsi",\
 .property = "x-disable-pcie",\
 .value= "on",\
+},
+
+#define HW_COMPAT_2_4 \
+{\
+.driver   = "virtio-blk-device",\
+.property = "scsi",\
+.value= "true",\
 },{\
 .driver   = "e1000",\
 .property = "extra_mac_registers",\


in my next pull request.

Paolo

Re: [Qemu-devel] [PATCH v3 3/4] Add Error **errp for xen_pt_config_init()

2016-01-07 Thread Eric Blake

On 01/07/2016 01:12 AM, Cao jin wrote:

>>>   if (rc < 0) {
>>> -XEN_PT_LOG(&s->dev, "Failed to initialize %d/%ld,
>>> type=0x%x, rc:%d\n",
>>> -   i, ARRAY_SIZE(xen_pt_emu_reg_grps),
>>> +error_setg(&local_err, "Failed to initialize %d/%ld,
>>> type=0x%x,"
>>> +   " rc:%d", i,
>>> ARRAY_SIZE(xen_pt_emu_reg_grps),
>>
>> This maps ARRAY_SIZE() (which is size_t) to %ld, which can fail to
>> compile on 32-bit platforms (where size_t is not necessarily long).  Fix
>> it to %zd while touching it.
>>
> 
> a question:
> 1. Is %zu more suitable for size_t? since size_t is unsigned integer.

Yes, you're right on that one.

> 
> and a personal question after digging into size_t:
> 2. Does the size of size_t always equal to the word length[*] of computer

No.  It equals the maximum size the program can use.  But the x32 ABI
project is a good example of a 32-bit size_t while still taking full
advantage of the 64-bit word size registers, in the name of memory
efficiencies.  See https://en.wikipedia.org/wiki/X32_ABI.

-- 
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 07/34] scripts/kvm/kvm_stat: Cleanup of path variables

2016-01-07 Thread Janosch Frank

On 01/07/2016 03:56 PM, Paolo Bonzini wrote:
> 
> 
> On 10/12/2015 13:12, Janosch Frank wrote:
>>  if not os.access('/sys/kernel/debug', os.F_OK):
> 
> PATH_DEBUGFS should be /sys/kernel/debug, while...
> 
>>  print 'Please enable CONFIG_DEBUG_FS in your kernel'
>>  sys.exit(1)
>> -if not os.access('/sys/kernel/debug/kvm', os.F_OK):
>> +if not os.access(PATH_DEBUGFS, os.F_OK):
> 
> ... this should be PATH_DEBUGFS_KVM.
> 
> Paolo
> 
Sure, when I'm at it I'll also change PATH_TRACING to
PATH_DEBUGFS_TRACING so they are consistent.

Re: [Qemu-devel] [PATCH 20/34] scripts/kvm/kvm_stat: Cleanup cpu list retrieval