Re: [Qemu-devel] Regression with floppy drive controller

[Gerd Hoffmann]

  Hi,

> Using the default QEMU config, we build SeaBIOS to use the TSC timer:
> 
> builds/seabios-128k/.config:CONFIG_TSC_TIMER=y
> builds/seabios-256k/.config:CONFIG_TSC_TIMER=y

> Do we need a cpu with TSC support to run SeaBIOS?

Hmm.  seabios uses pmtimer if available.  isapc has no pmtimer though,
so it uses TSC instead.

> So we should use '-cpu Conroe' or '-cpu core2duo' minimum?

-cpu Conroe for -M isapc is kida silly though ...

Maybe we should simply build seabios with CONFIG_TSC_TIMER=n ?

Using the TSC in a virtual machine is problematic anyway, the
calibration can be _way_ off on a loaded host, this is why seabios
prefers the (fixed frequency) pmtimer. 

cheers,
  Gerd

Re: [Qemu-devel] [PATCH v2 0/3] colo: Add support for continious replication

[Zhang, Chen]

> -Original Message-
> From: Lukas Straub [mailto:lukasstra...@web.de]
> Sent: Saturday, August 17, 2019 2:20 AM
> To: Zhang, Chen 
> Cc: Dr. David Alan Gilbert ; qemu-devel  de...@nongnu.org>; Jason Wang ; Xie Changlong
> ; Wen Congyang 
> Subject: Re: [Qemu-devel] [PATCH v2 0/3] colo: Add support for continious
> replication
> 
> On Fri, 16 Aug 2019 01:51:20 +
> "Zhang, Chen"  wrote:
> 
> > > -Original Message-
> > > From: Lukas Straub [mailto:lukasstra...@web.de]
> > > Sent: Friday, August 16, 2019 3:48 AM
> > > To: Dr. David Alan Gilbert 
> > > Cc: qemu-devel ; Zhang, Chen
> > > ; Jason Wang ; Xie
> > > Changlong ; Wen Congyang
> > > 
> > > Subject: Re: [Qemu-devel] [PATCH v2 0/3] colo: Add support for
> > > continious replication
> > >
> > > On Thu, 15 Aug 2019 19:57:37 +0100
> > > "Dr. David Alan Gilbert"  wrote:
> > >
> > > > * Lukas Straub (lukasstra...@web.de) wrote:
> > > > > Hello Everyone,
> > > > > These Patches add support for continious replication to colo.
> > > > > Please review.
> > > >
> > > >
> > > > OK, for those who haven't followed COLO for so long; 'continuous
> > > > replication' is when after the first primary fails, you can
> > > > promote the original secondary to a new primary and start
> > > > replicating again;
> > > >
> > > > i.e. current COLO gives you
> > > >
> > > > p<->s
> > > > 
> > > > s
> > > >
> > > > with your patches you can do
> > > >
> > > > s becomes p2
> > > > p2<->s2
> > > >
> > > > and you're back to being resilient again.
> > > >
> > > > Which is great; because that was always an important missing piece.
> > > >
> > > > Do you have some test scripts/setup for this - it would be great
> > > > to automate some testing.
> > >
> > > My Plan is to write a Pacemaker Resource Agent[1] for qemu-colo and
> > > then do some long-term testing in my small cluster here. Writing
> > > standalone tests using that Resource Agent should be easy, it just
> > > needs to be provided with the right arguments and environment Variables.
> >
> > Thanks Dave's explanation.
> > It looks good for me and I will test this series in my side.
> >
> > Another question: Is "Pacemaker Resource Agent[1] "  like a heartbeat
> module?
> 
> It's a bit more than that. Pacemaker itself is an Cluster Resource Manager, 
> you
> can think of it like sysvinit but for clusters. It controls where in the 
> cluster
> Resources run, what state (master/slave) and what to do in case of a Node or
> Resource failure. Now Resources can be anything like SQL-Server, Webserver,
> VM, etc. and Pacemaker itself doesn't directly control them, that's the Job of
> the Resource Agents. So a Resource Agent is like an init-script, but cluster-
> aware with more actions like start, stop, monitor, promote (to master) or
> migrate-to.
> 
> > I have wrote an internal heartbeat module running on Qemu, it make COLO
> can detect fail and trigger failover automatically, no need external APP to 
> call
> the QMP command "x-colo-lost-heartbeat". If you need it, I can send a RFC
> version recently.
> 
> Cool, this should be faster to failover than with Pacemaker.
> What is the plan with cases like Primary-failover, which need to issue 
> multiple
> commands?

Yes, currently we need input some net filter delete command after 
primary-failover.
We need make a way to remove related net-filter and chardev automatically.
But for Pacemaker it isn't a problem, you can send related qmp command after 
the "x-lost-heart-beat". 

Thanks
Zhang Chen

> 
> > Thanks
> > Zhang Chen
> > >
> > > Regards,
> > > Lukas Straub
> > >
> > > [1]
> > > https://github.com/ClusterLabs/resource-agents/blob/master/doc/dev-g
> > > uides/ra-dev-guide.asc#what-is-a-resource-agent

Re: [Qemu-devel] [RFC PATCH v3 02/46] target/i386: Push rex_w into DisasContext

[Jan Bobek]

On 8/15/19 6:19 AM, Aleksandar Markovic wrote:
> 
> 15.08.2019. 11.55, "Richard Henderson"  > је написао/ла:
>>
>> On 8/15/19 8:30 AM, Aleksandar Markovic wrote:
>> >
>> > 15.08.2019. 04.13, "Jan Bobek" > > 
>> > >> је написао/ла:
>> >>
>> >> From: Richard Henderson mailto:r...@twiddle.net> 
>> >> >>
>> >>
>> >> Treat this the same as we already do for other rex bits.
>> >>
>> >> Signed-off-by: Richard Henderson > >>  > >> >>
>> >> ---
>> >>  target/i386/translate.c | 19 +++
>> >>  1 file changed, 11 insertions(+), 8 deletions(-)
>> >>
>> >> diff --git a/target/i386/translate.c b/target/i386/translate.c
>> >> index d74dbfd585..c0866c2797 100644
>> >> --- a/target/i386/translate.c
>> >> +++ b/target/i386/translate.c
>> >> @@ -44,11 +44,13 @@
>> >>  #define REX_X(s) ((s)->rex_x)
>> >>  #define REX_B(s) ((s)->rex_b)
>> >>  #define REX_R(s) ((s)->rex_r)
>> >> +#define REX_W(s) ((s)->rex_w)
>> >>  #else
>> >>  #define CODE64(s) 0
>> >>  #define REX_X(s) 0
>> >>  #define REX_B(s) 0
>> >>  #define REX_R(s) 0
>> >> +#define REX_W(s) -1
>> >
>> > The commit message says "treat rex_w the same as other rex bits". Why is 
>> > then
>> > REX_W() treated differently here?
>>
>> "Treated the same" in terms of being referenced by a macro instead of a local
>> variable.  As for the -1, if you look at the rest of the patch you can 
>> clearly
>> see it preserves existing behaviour.
>>
> 
> That is exactly what I dislike about your commit messages: they often 
> introduce ambiguity, without any real need, and with really bad consequences 
> to the reader. Is adding "in terms of being referenced by a macro instead of 
> a local
> variable" to the commit message that hard?
> 
> When writing commit messages, you need to try to put yourself in the shoes of 
> the reader.

FWIW, personally I don't find it confusing. I think even just the
first couple of lines of the patch make it quite clear what's
going on. Just my 2 cents.

-Jan



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [RFC PATCH v3 15/46] target/i386: introduce function ck_cpuid

[Jan Bobek]

On 8/15/19 11:01 AM, Aleksandar Markovic wrote:
> 
> 15.08.2019. 04.23, "Jan Bobek"  > је написао/ла:
>>
>> Introduce a helper function to take care of instruction CPUID checks.
>>
>> Signed-off-by: Jan Bobek mailto:jan.bo...@gmail.com>>
>> ---
> 
> Jan, what is the origin of "CK"? If it is a QEMU internal thing, perhaps use 
> "CHECK".
> 
> The function should be called check_cpuid(), imho. I know, Richard would like 
> c_ci(), or simpler cc(), better.

It was completely my initiative to name it like that. I'll rename
it to check_cpuid().

-Jan



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [RFC PATCH v3 46/46] target/i386: introduce SSE3 instructions to sse-opcode.inc.h

[Jan Bobek]

On 8/15/19 6:07 AM, Aleksandar Markovic wrote:
> 
> 15.08.2019. 11.55, "Richard Henderson"  > је написао/ла:
>>
>> On 8/15/19 8:02 AM, Aleksandar Markovic wrote:
>> > A question for you: What about FISTTP, MONITOR, MWAIT, that belong to 
>> > SSE3, but
>> > are not mentioned in this patch?
>> >
>>
>> They are also not vector instructions, which is the subject of this patch 
>> set.
>>
> 
> The subject of the patch and the patch set says "SSE3", not "vector", read it 
> again.

Richard is right, I will clarify the series' subject and the
commit message.

-Jan



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH RFC 0/4] intel_iommu: Do sanity check of vfio-pci earlier

[Peter Xu]

On Tue, Aug 20, 2019 at 08:24:49AM +0200, Paolo Bonzini wrote:
> On 20/08/19 07:22, Peter Xu wrote:
> > On Mon, Aug 12, 2019 at 09:45:27AM +0200, Peter Xu wrote:
> >> This is a RFC series.
> >>
> >> The VT-d code has some defects, one of them is that we cannot detect
> >> the misuse of vIOMMU and vfio-pci early enough.
> >>
> >> For example, logically this is not allowed:
> >>
> >>   -device intel-iommu,caching-mode=off \
> >>   -device vfio-pci,host=05:00.0
> >>
> >> Because the caching mode is required to make vfio-pci devices
> >> functional.
> >>
> >> Previously we did this sanity check in vtd_iommu_notify_flag_changed()
> >> as when the memory regions change their attributes.  However that's
> >> too late in most cases!  Because the memory region layouts will only
> >> change after IOMMU is enabled, and that's in most cases during the
> >> guest OS boots.  So when the configuration is wrong, we will only bail
> >> out during the guest boots rather than simply telling the user before
> >> QEMU starts.
> >>
> >> The same problem happens on device hotplug, say, when we have this:
> >>
> >>   -device intel-iommu,caching-mode=off
> >>
> >> Then we do something like:
> >>
> >>   (HMP) device_add vfio-pci,host=05:00.0,bus=pcie.1
> >>
> >> If at that time the vIOMMU is enabled in the guest then the QEMU
> >> process will simply quit directly due to this hotplug event.  This is
> >> a bit insane...
> >>
> >> This series tries to solve above two problems by introducing two
> >> sanity checks upon these places separately:
> >>
> >>   - machine done
> >>   - hotplug device
> >>
> >> This is a bit awkward but I hope this could be better than before.
> >> There is of course other solutions like hard-code the check into
> >> vfio-pci but I feel it even more unpretty.  I didn't think out any
> >> better way to do this, if there is please kindly shout out.
> >>
> >> Please have a look to see whether this would be acceptable, thanks.
> > 
> > Any more comment on this?
> 
> No problem from me, but I wouldn't mind if someone else merged it. :)

Can I read this as an "acked-by"? :)

Michael, should this be for your tree?  What do you think about the
series?  Please let me know what I need to do to move this forward.  I
can repost a non-rfc series if needed, but it'll be exactly the same
content.

Regards,

-- 
Peter Xu

[Qemu-devel] [Bug 1819289] Re: Windows 95 and Windows 98 will not install or run

[Brad Parker]

Just finished a bisect between cfcca36 (working) and current master (not
working), here is the result:

$ git bisect bad
cd1bfd5ef336166b275a09dc9842542bf5e63ae3 is the first bad commit
commit cd1bfd5ef336166b275a09dc9842542bf5e63ae3
Author: Gerd Hoffmann 
Date:   Wed Jun 20 12:17:34 2018 +0200

seabios: update bios and vgabios binaries

Adds two new vgabios binaries, for ramfb and bochs-display.

Signed-off-by: Gerd Hoffmann 

 pc-bios/bios-256k.bin | Bin 262144 -> 262144 bytes
 pc-bios/bios.bin  | Bin 131072 -> 131072 bytes
 pc-bios/vgabios-bochs-display.bin | Bin 0 -> 27648 bytes
 pc-bios/vgabios-cirrus.bin| Bin 38400 -> 38400 bytes
 pc-bios/vgabios-qxl.bin   | Bin 38912 -> 38912 bytes
 pc-bios/vgabios-ramfb.bin | Bin 0 -> 28160 bytes
 pc-bios/vgabios-stdvga.bin| Bin 38912 -> 38912 bytes
 pc-bios/vgabios-virtio.bin| Bin 38912 -> 38912 bytes
 pc-bios/vgabios-vmware.bin| Bin 38912 -> 38912 bytes
 pc-bios/vgabios.bin   | Bin 38400 -> 38400 bytes
 10 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 pc-bios/vgabios-bochs-display.bin
 create mode 100644 pc-bios/vgabios-ramfb.bin

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

Title:
  Windows 95 and Windows 98 will not install or run

Status in QEMU:
  New

Bug description:
  The last version of QEMU I have been able to run Windows 95 or Windows
  98 on was 2.7 or 2.8. Recent versions since then even up to 3.1 will
  either not install or will not run 95 or 98 at all. I have tried every
  combination of options like isapc or no isapc, cpu pentium  or cpu as
  486. Tried different memory configurations, but they just don't work
  anymore.

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

Re: [Qemu-devel] [Qemu-riscv] RISCV: when will the CLIC be ready?

[liuzhiwei]

On 2019/8/20 上午12:38, Chih-Min Chao wrote:



On Mon, Aug 19, 2019 at 9:47 PM liuzhiwei > wrote:



On 2019/8/17 上午1:29, Alistair Francis wrote:
> On Thu, Aug 15, 2019 at 8:39 PM liuzhiweimailto:zhiwei_...@c-sky.com>> wrote:
>> Hi, Palmer
>>
>> When Michael Clark still was the maintainer of RISCV QEMU, he
wrote in the mail list, "the CLIC interrupt controller is under
testing,
>> and will be included in QEMU 3.1 or 3.2". It is pity that the
CLIC is not in
>> included even in QEMU 4.1.0.
> I see that there is a CLIC branch available here:
> https://github.com/riscv/riscv-qemu/pull/157
>
> It looks like all of the work is in a single commit
>

(https://github.com/riscv/riscv-qemu/pull/157/commits/206d9ac339feb9ef2c325402a00f0f45f453d019)
> and that most of the other commits in the PR have already made
it into
> master.
>
> Although the CLIC commit is very large it doesn't seem impossible to
> manually pull out the CLIC bits and apply it onto master.
>
> Do you know the state of the CLIC model? If it's working it
shouldn't
> be too hard to rebase the work and get the code into mainline.
>
> Alistair
>
Hi,  Alistair

In my opinion, the CLIC code almost works.

Last year when my workmate ported an RTOS, I once read the CLIC
specification and used the CLIC model code. It worked through  all
the tests after fixed two bugs. I also had sent the patch to
Michael, but without response(maybe a wrong email address).

diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index 7bf6cbc..95d80ab 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -505,6 +505,9 @@ static target_ulong
riscv_intr_pc(CPURISCVState *env,
      if (!(async || clic)) {
          return tvec & ~0b11;
      }
+    if (clic) {
+        cause &= 0x3ff;
+    }

      /* bits [1:0] encode mode; 0 = direct, 1 = vectored, 2 >=
reserved */
      switch (mode1) {
@@ -645,6 +648,9 @@ void riscv_cpu_do_interrupt(CPUState *cs)
          riscv_cpu_set_mode(env, PRV_M);
      }

+    if (clic) {
+        env->exccode = 0;
+    }
      /* NOTE: it is not necessary to yield load reservations
here. It is only
         necessary for an SC from "another hart" to cause a load
reservation
         to be yielded. Refer to the memory consistency model
section of the

After that, the specification has updated and the code may
changed. I didn't pull new code again.

If the CLIC model may merged into the mainline, and no body
maintain the code, I'd like to work on it, fixing the bugs and
updating the code according to latest specification.

Best Regards,
Zhiwei

>> As we have cpus using CLIC, I have to use the out of tree qemu
code in SIFIVE
>> a long time. Could you tell me when it will be upstreamed?
>>
>> Best Regards
>> Zhiwei
>>


Hi Zhiwei,

I think what Alistair point out is the latest clic version (or 
https://github.com/riscv/riscv-qemu/tree/riscv-qemu-3.1). The two 
versions, on pull request and 3.1 branch, should be similar.

As far as I know, there is no concrete plan on CLIC patch in short term.
It is good to know that the clic patch has been run with real RTOS.
It is also great if you could update the implementation to latest spec 
and send the patch again.


chihmin


Hi chihmin,

Thanks for your reminding and approval. I will pull the latest clic 
version code and send the patch about two or three weeks later.


The RTOS is Rhino,  which is the kernel of 
AliOS-Things(https://github.com/alibaba/AliOS-Things).


It is also the kernel of YOC(https://cop.c-sky.com).

Best Regards
Zhiwei

Re: [Qemu-devel] [PATCH for 4.1] aspeed/timer: Provide back-pressure information for short periods

[Joel Stanley]

On Tue, 16 Jul 2019 at 07:02, Philippe Mathieu-Daudé  wrote:
> On 7/16/19 9:00 AM, Joel Stanley wrote:
> > On Tue, 16 Jul 2019 at 06:54, Joel Stanley  wrote:
> >> On Thu, 4 Jul 2019 at 12:26, Paolo Bonzini  wrote:
> >>> On 04/07/19 12:13, Stefan Hajnoczi wrote:
>  On Thu, Jul 04, 2019 at 11:26:53AM +0200, Philippe Mathieu-Daudé wrote:
> > CC'ing Stefan & Paolo for a non-ARM view on this...
> 
>  I'm not familiar with the various clock smoothing techniques implemented
>  in QEMU and KVM, but this looks okay given that Linux guests expect
>  this.
> >>>
> >>> Yeah, even KVM applies a minimum period of 200us to the x86 LAPIC timer.
> >>
> >> Can we please merge this so guests can boot on 4.1?
> >
> > Cédric pointed out this lacks my reviewed by. I had not provided it in
> > the past as I wondered if we could come up with a better fix. However,
> > I consider this a good fix for 4.1, and if sometime finds time to
> > further rework the timer model in the future then we can do that work
> > later.
>
> Agreed.
>
> >
> > Reviewed-by: Joel Stanley 
> > Tested-by: Joel Stanley 
>
> Reviewed-by: Philippe Mathieu-Daudé 

HI Peter,

Is this one still in your queue?

Cheers,

Joel

[Qemu-devel] [PATCH v2] ppc/pnv: Set default ram size to 1.75GB

[Joel Stanley]

This makes the powernv machine easier for end users as the default
initrd address (1.5GB) is now within RAM.

This uses less than 2GB of RAM to ensure 32 bit Qemu still works.

Signed-off-by: Joel Stanley 
--
v2: Use INITRD defines, whcih come out to 1.75, instead of 2GB
---
 hw/ppc/pnv.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index d95086fbbd1e..5000db5faab5 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -1361,7 +1361,9 @@ static void pnv_machine_class_init(ObjectClass *oc, void 
*data)
   * storage */
 mc->no_parallel = 1;
 mc->default_boot_order = NULL;
-mc->default_ram_size = 1 * GiB;
+/* RAM defaults to less than 2048 for 32-bit hosts, and large
+ * enough to fit the maximum initrd size at it's load address */
+mc->default_ram_size = INITRD_LOAD_ADDR + INITRD_MAX_SIZE;
 xic->icp_get = pnv_icp_get;
 xic->ics_get = pnv_ics_get;
 xic->ics_resend = pnv_ics_resend;
-- 
2.23.0.rc1

Re: [Qemu-devel] RISCV: when will the CLIC be ready?

[liuzhiwei]

On 2019/8/20 上午2:56, Alistair Francis wrote:

On Mon, Aug 19, 2019 at 6:44 AM liuzhiwei  wrote:


On 2019/8/17 上午1:29, Alistair Francis wrote:

On Thu, Aug 15, 2019 at 8:39 PM liuzhiwei  wrote:

Hi, Palmer

When Michael Clark still was the maintainer of RISCV QEMU, he wrote in the mail 
list, "the CLIC interrupt controller is under testing,
and will be included in QEMU 3.1 or 3.2". It is pity that the CLIC is not in
included even in QEMU 4.1.0.

I see that there is a CLIC branch available here:
https://github.com/riscv/riscv-qemu/pull/157

It looks like all of the work is in a single commit
(https://github.com/riscv/riscv-qemu/pull/157/commits/206d9ac339feb9ef2c325402a00f0f45f453d019)
and that most of the other commits in the PR have already made it into
master.

Although the CLIC commit is very large it doesn't seem impossible to
manually pull out the CLIC bits and apply it onto master.

Do you know the state of the CLIC model? If it's working it shouldn't
be too hard to rebase the work and get the code into mainline.

Alistair


Hi,  Alistair

In my opinion, the CLIC code almost works.

Last year when my workmate ported an RTOS, I once read the CLIC specification 
and used the CLIC model code. It worked through  all the tests after fixed two 
bugs. I also had sent the patch to Michael, but without response(maybe a wrong 
email address).

diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index 7bf6cbc..95d80ab 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -505,6 +505,9 @@ static target_ulong riscv_intr_pc(CPURISCVState *env,
   if (!(async || clic)) {
   return tvec & ~0b11;
   }
+if (clic) {
+cause &= 0x3ff;
+}

   /* bits [1:0] encode mode; 0 = direct, 1 = vectored, 2 >= reserved */
   switch (mode1) {
@@ -645,6 +648,9 @@ void riscv_cpu_do_interrupt(CPUState *cs)
   riscv_cpu_set_mode(env, PRV_M);
   }

+if (clic) {
+env->exccode = 0;
+}
   /* NOTE: it is not necessary to yield load reservations here. It is only
  necessary for an SC from "another hart" to cause a load reservation
  to be yielded. Refer to the memory consistency model section of the

After that, the specification has updated and the code may changed. I didn't 
pull new code again.

If the CLIC model may merged into the mainline, and no body maintain the code, 
I'd like to work on it, fixing the bugs and updating the code according to 
latest specification.

Yes please! We will be happy to merge it!

If you would like to it would be great if you could update the code,
fix the bugs and then send patches to this list.

Alistair

OK,  I'd like to. As the vector extension patch has already been under 
data  disclosure  review,


I will forward move on to this work and send the patch about two or 
three weeks later.


Best Regards,
Zhiwei


Best Regards,
Zhiwei


As we have cpus using CLIC, I have to use the out of tree qemu code in SIFIVE
a long time. Could you tell me when it will be upstreamed?

Best Regards
Zhiwei

Re: [Qemu-devel] [PATCH] Revert "i386: correct cpu_x86_cpuid(0xd)"

[owen...@ucloud.cn]

Thanks for you reply, we have some hosts running with legacy kernel, difficult 
to upgrade, and i want to run the latest qemu.
Does QEMU support running with legacy kernel(kvm) in design?



owen...@ucloud.cn
 
From: Eduardo Habkost
Date: 2019-08-21 05:23
To: Bingsong Si
CC: qemu-devel
Subject: Re: [Qemu-devel] [PATCH] Revert "i386: correct cpu_x86_cpuid(0xd)"
On Mon, Aug 19, 2019 at 06:09:24PM +0800, Bingsong Si wrote:
> This reverts commit de2e68c902f7b6e438b0fa3cfedd74a06a20704f.
> 
> Initial value of env->xcr0 == 0, then CPUID(EAX=0xd,ECX=0).EBX == 0, after kvm
> upstream commit 412a3c41, It is ok.
> On host before commit 412a3c41, some legacy guest, i.e. CentOS 6, get
> xstate_size == 0, will crash the guest.
> 
> Signed-off-by: Bingsong Si 
 
cpu_x86_cpuid() is also used by TCG, and needs to return the
correct data depending on xcr0.  If you want to work around a KVM
bug by ignoring xcr0, it needs to be conditional on
kvm_enabled().
 
But even if we you make this conditional on kvm_enabled(), I
don't understand why QEMU would need a workaround for a KVM bug
that was fixed more than 4 years ago.
 
> ---
>  target/i386/cpu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index ff65e11008..69562e21ed 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -4416,7 +4416,7 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, 
> uint32_t count,
>  *ecx = xsave_area_size(x86_cpu_xsave_components(cpu));
>  *eax = env->features[FEAT_XSAVE_COMP_LO];
>  *edx = env->features[FEAT_XSAVE_COMP_HI];
> -*ebx = xsave_area_size(env->xcr0);
> +*ebx = *ecx;
>  } else if (count == 1) {
>  *eax = env->features[FEAT_XSAVE];
>  } else if (count < ARRAY_SIZE(x86_ext_save_areas)) {
> -- 
> 2.22.0
> 
> 
 
-- 
Eduardo

[Qemu-devel] [Bug 1840865] [NEW] qemu crashes when doing iotest on virtio-9p filesystem

[fangying]

Public bug reported:

Qemu crashes when doing avocado-vt test on virtio-9p filesystem.
This bug can be reproduced running 
https://github.com/autotest/tp-qemu/blob/master/qemu/tests/9p.py.
The crash stack goes like:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  v9fs_mark_fids_unreclaim (pdu=pdu@entry=0xaaab00046868, 
path=path@entry=0x851e2fa8)
at hw/9pfs/9p.c:505
#1  0xe3585acc in v9fs_unlinkat (opaque=0xaaab00046868) at 
hw/9pfs/9p.c:2590
#2  0xe3811c10 in coroutine_trampoline (i0=, 
i1=)
at util/coroutine-ucontext.c:116
#3  0xa13ddb20 in ?? () from /lib64/libc.so.6
Backtrace stopped: not enough registers or memory available to unwind further

A segment fault is triggered at hw/9pfs/9p.c line 505

for (fidp = s->fid_list; fidp; fidp = fidp->next) {
if (fidp->path.size != path->size) { # fidp is invalid 
continue;
}

(gdb) p path
$10 = (V9fsPath *) 0x851e2fa8
(gdb) p *path
$11 = {size = 21, data = 0xfed6f420 "./9p_test/p2a1/d0/f1"}
(gdb) p *fidp
Cannot access memory at address 0x101010101010101
(gdb) p *pdu
$12 = {size = 19, tag = 54, id = 76 'L', cancelled = 0 '\000', complete = 
{entries = {
  sqh_first = 0x0, sqh_last = 0xaaab00046870}}, s = 0xaaab000454b8, next = {
le_next = 0xaaab000467c0, le_prev = 0xaaab00046f88}, idx = 88}
(gdb) 

Address Sanitizer shows error and saying that there is a heap-use-after-
free on *fidp*.

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  qemu crashes when doing iotest on  virtio-9p filesystem

Status in QEMU:
  New

Bug description:
  Qemu crashes when doing avocado-vt test on virtio-9p filesystem.
  This bug can be reproduced running 
https://github.com/autotest/tp-qemu/blob/master/qemu/tests/9p.py.
  The crash stack goes like:

  Program terminated with signal SIGSEGV, Segmentation fault.
  #0  v9fs_mark_fids_unreclaim (pdu=pdu@entry=0xaaab00046868, 
path=path@entry=0x851e2fa8)
  at hw/9pfs/9p.c:505
  #1  0xe3585acc in v9fs_unlinkat (opaque=0xaaab00046868) at 
hw/9pfs/9p.c:2590
  #2  0xe3811c10 in coroutine_trampoline (i0=, 
i1=)
  at util/coroutine-ucontext.c:116
  #3  0xa13ddb20 in ?? () from /lib64/libc.so.6
  Backtrace stopped: not enough registers or memory available to unwind further

  A segment fault is triggered at hw/9pfs/9p.c line 505

  for (fidp = s->fid_list; fidp; fidp = fidp->next) {
  if (fidp->path.size != path->size) { # fidp is invalid 
  continue;
  }

  (gdb) p path
  $10 = (V9fsPath *) 0x851e2fa8
  (gdb) p *path
  $11 = {size = 21, data = 0xfed6f420 "./9p_test/p2a1/d0/f1"}
  (gdb) p *fidp
  Cannot access memory at address 0x101010101010101
  (gdb) p *pdu
  $12 = {size = 19, tag = 54, id = 76 'L', cancelled = 0 '\000', complete = 
{entries = {
sqh_first = 0x0, sqh_last = 0xaaab00046870}}, s = 0xaaab000454b8, next 
= {
  le_next = 0xaaab000467c0, le_prev = 0xaaab00046f88}, idx = 88}
  (gdb) 

  Address Sanitizer shows error and saying that there is a heap-use-
  after-free on *fidp*.

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

Re: [Qemu-devel] [PATCH v3 0/4] iotests: use python logging

[no-reply]

Patchew URL: https://patchew.org/QEMU/20190820235243.26092-1-js...@redhat.com/



Hi,

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

Type: series
Subject: [Qemu-devel] [PATCH v3 0/4] iotests: use python logging
Message-id: 20190820235243.26092-1-js...@redhat.com

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] patchew/20190820235243.26092-1-js...@redhat.com -> 
patchew/20190820235243.26092-1-js...@redhat.com
Submodule 'capstone' (https://git.qemu.org/git/capstone.git) registered for 
path 'capstone'
Submodule 'dtc' (https://git.qemu.org/git/dtc.git) registered for path 'dtc'
Submodule 'roms/QemuMacDrivers' (https://git.qemu.org/git/QemuMacDrivers.git) 
registered for path 'roms/QemuMacDrivers'
Submodule 'roms/SLOF' (https://git.qemu.org/git/SLOF.git) registered for path 
'roms/SLOF'
Submodule 'roms/edk2' (https://git.qemu.org/git/edk2.git) registered for path 
'roms/edk2'
Submodule 'roms/ipxe' (https://git.qemu.org/git/ipxe.git) registered for path 
'roms/ipxe'
Submodule 'roms/openbios' (https://git.qemu.org/git/openbios.git) registered 
for path 'roms/openbios'
Submodule 'roms/openhackware' (https://git.qemu.org/git/openhackware.git) 
registered for path 'roms/openhackware'
Submodule 'roms/opensbi' (https://git.qemu.org/git/opensbi.git) registered for 
path 'roms/opensbi'
Submodule 'roms/qemu-palcode' (https://git.qemu.org/git/qemu-palcode.git) 
registered for path 'roms/qemu-palcode'
Submodule 'roms/seabios' (https://git.qemu.org/git/seabios.git/) registered for 
path 'roms/seabios'
Submodule 'roms/seabios-hppa' (https://git.qemu.org/git/seabios-hppa.git) 
registered for path 'roms/seabios-hppa'
Submodule 'roms/sgabios' (https://git.qemu.org/git/sgabios.git) registered for 
path 'roms/sgabios'
Submodule 'roms/skiboot' (https://git.qemu.org/git/skiboot.git) registered for 
path 'roms/skiboot'
Submodule 'roms/u-boot' (https://git.qemu.org/git/u-boot.git) registered for 
path 'roms/u-boot'
Submodule 'roms/u-boot-sam460ex' (https://git.qemu.org/git/u-boot-sam460ex.git) 
registered for path 'roms/u-boot-sam460ex'
Submodule 'slirp' (https://git.qemu.org/git/libslirp.git) registered for path 
'slirp'
Submodule 'tests/fp/berkeley-softfloat-3' 
(https://git.qemu.org/git/berkeley-softfloat-3.git) registered for path 
'tests/fp/berkeley-softfloat-3'
Submodule 'tests/fp/berkeley-testfloat-3' 
(https://git.qemu.org/git/berkeley-testfloat-3.git) registered for path 
'tests/fp/berkeley-testfloat-3'
Submodule 'ui/keycodemapdb' (https://git.qemu.org/git/keycodemapdb.git) 
registered for path 'ui/keycodemapdb'
Cloning into 'capstone'...
Submodule path 'capstone': checked out 
'22ead3e0bfdb87516656453336160e0a37b066bf'
Cloning into 'dtc'...
Submodule path 'dtc': checked out '88f18909db731a627456f26d779445f84e449536'
Cloning into 'roms/QemuMacDrivers'...
Submodule path 'roms/QemuMacDrivers': checked out 
'90c488d5f4a407342247b9ea869df1c2d9c8e266'
Cloning into 'roms/SLOF'...
Submodule path 'roms/SLOF': checked out 
'ba1ab360eebe6338bb8d7d83a9220ccf7e213af3'
Cloning into 'roms/edk2'...
Submodule path 'roms/edk2': checked out 
'20d2e5a125e34fc8501026613a71549b2a1a3e54'
Submodule 'SoftFloat' (https://github.com/ucb-bar/berkeley-softfloat-3.git) 
registered for path 'ArmPkg/Library/ArmSoftFloatLib/berkeley-softfloat-3'
Submodule 'CryptoPkg/Library/OpensslLib/openssl' 
(https://github.com/openssl/openssl) registered for path 
'CryptoPkg/Library/OpensslLib/openssl'
Cloning into 'ArmPkg/Library/ArmSoftFloatLib/berkeley-softfloat-3'...
Submodule path 'roms/edk2/ArmPkg/Library/ArmSoftFloatLib/berkeley-softfloat-3': 
checked out 'b64af41c3276f97f0e181920400ee056b9c88037'
Cloning into 'CryptoPkg/Library/OpensslLib/openssl'...
Submodule path 'roms/edk2/CryptoPkg/Library/OpensslLib/openssl': checked out 
'50eaac9f3337667259de725451f201e784599687'
Submodule 'boringssl' (https://boringssl.googlesource.com/boringssl) registered 
for path 'boringssl'
Submodule 'krb5' (https://github.com/krb5/krb5) registered for path 'krb5'
Submodule 'pyca.cryptography' (https://github.com/pyca/cryptography.git) 
registered for path 'pyca-cryptography'
Cloning into 'boringssl'...
Submodule path 'roms/edk2/CryptoPkg/Library/OpensslLib/openssl/boringssl': 
checked out '2070f8ad9151dc8f3a73bffaa146b5e6937a583f'
Cloning into 'krb5'...
Submodule path 'roms/edk2/CryptoPkg/Library/OpensslLib/openssl/krb5': checked 
out 'b9ad6c49505c96a088326b62a52568e3484f2168'
Cloning into 'pyca-cryptography'...
Submodule path 
'roms/edk2/CryptoPkg/Library/OpensslLib/openssl/pyca-cryptography': checked out 
'09403100de2f6f1cdd0d484dcb8e620f1c335c8f'
Cloning into 'roms/ipxe'...
Submodule path 'roms/ipxe': ch

[Qemu-devel] [PATCH v3 4/4] iotests: use python logging for iotests.log()

[John Snow]

We can turn logging on/off globally instead of per-function.

Remove use_log from run_job, and use python logging to turn on
diffable output when we run through a script entry point.

iotest 245 changes output order due to buffering reasons.
---
 tests/qemu-iotests/030|  4 +--
 tests/qemu-iotests/245|  1 +
 tests/qemu-iotests/245.out| 24 +-
 tests/qemu-iotests/iotests.py | 47 +--
 4 files changed, 43 insertions(+), 33 deletions(-)

diff --git a/tests/qemu-iotests/030 b/tests/qemu-iotests/030
index 1b69f318c6..a382cb430b 100755
--- a/tests/qemu-iotests/030
+++ b/tests/qemu-iotests/030
@@ -411,8 +411,8 @@ class TestParallelOps(iotests.QMPTestCase):
 result = self.vm.qmp('block-job-set-speed', device='drive0', speed=0)
 self.assert_qmp(result, 'return', {})
 
-self.vm.run_job(job='drive0', auto_dismiss=True, use_log=False)
-self.vm.run_job(job='node4', auto_dismiss=True, use_log=False)
+self.vm.run_job(job='drive0', auto_dismiss=True)
+self.vm.run_job(job='node4', auto_dismiss=True)
 self.assert_no_active_block_jobs()
 
 # Test a block-stream and a block-commit job in parallel
diff --git a/tests/qemu-iotests/245 b/tests/qemu-iotests/245
index bc1ceb9792..3bc29acb33 100644
--- a/tests/qemu-iotests/245
+++ b/tests/qemu-iotests/245
@@ -1000,4 +1000,5 @@ class TestBlockdevReopen(iotests.QMPTestCase):
 self.reopen(opts, {'backing': 'hd2'})
 
 if __name__ == '__main__':
+iotests.activate_logging()
 iotests.main(supported_fmts=["qcow2"])
diff --git a/tests/qemu-iotests/245.out b/tests/qemu-iotests/245.out
index a19de5214d..15c3630e92 100644
--- a/tests/qemu-iotests/245.out
+++ b/tests/qemu-iotests/245.out
@@ -1,17 +1,17 @@
+{"execute": "job-finalize", "arguments": {"id": "commit0"}}
+{"return": {}}
+{"data": {"id": "commit0", "type": "commit"}, "event": "BLOCK_JOB_PENDING", 
"timestamp": {"microseconds": "USECS", "seconds": "SECS"}}
+{"data": {"device": "commit0", "len": 3145728, "offset": 3145728, "speed": 0, 
"type": "commit"}, "event": "BLOCK_JOB_COMPLETED", "timestamp": 
{"microseconds": "USECS", "seconds": "SECS"}}
+{"execute": "job-finalize", "arguments": {"id": "stream0"}}
+{"return": {}}
+{"data": {"id": "stream0", "type": "stream"}, "event": "BLOCK_JOB_PENDING", 
"timestamp": {"microseconds": "USECS", "seconds": "SECS"}}
+{"data": {"device": "stream0", "len": 3145728, "offset": 3145728, "speed": 0, 
"type": "stream"}, "event": "BLOCK_JOB_COMPLETED", "timestamp": 
{"microseconds": "USECS", "seconds": "SECS"}}
+{"execute": "job-finalize", "arguments": {"id": "stream0"}}
+{"return": {}}
+{"data": {"id": "stream0", "type": "stream"}, "event": "BLOCK_JOB_PENDING", 
"timestamp": {"microseconds": "USECS", "seconds": "SECS"}}
+{"data": {"device": "stream0", "len": 3145728, "offset": 3145728, "speed": 0, 
"type": "stream"}, "event": "BLOCK_JOB_COMPLETED", "timestamp": 
{"microseconds": "USECS", "seconds": "SECS"}}
 ..
 --
 Ran 18 tests
 
 OK
-{"execute": "job-finalize", "arguments": {"id": "commit0"}}
-{"return": {}}
-{"data": {"id": "commit0", "type": "commit"}, "event": "BLOCK_JOB_PENDING", 
"timestamp": {"microseconds": "USECS", "seconds": "SECS"}}
-{"data": {"device": "commit0", "len": 3145728, "offset": 3145728, "speed": 0, 
"type": "commit"}, "event": "BLOCK_JOB_COMPLETED", "timestamp": 
{"microseconds": "USECS", "seconds": "SECS"}}
-{"execute": "job-finalize", "arguments": {"id": "stream0"}}
-{"return": {}}
-{"data": {"id": "stream0", "type": "stream"}, "event": "BLOCK_JOB_PENDING", 
"timestamp": {"microseconds": "USECS", "seconds": "SECS"}}
-{"data": {"device": "stream0", "len": 3145728, "offset": 3145728, "speed": 0, 
"type": "stream"}, "event": "BLOCK_JOB_COMPLETED", "timestamp": 
{"microseconds": "USECS", "seconds": "SECS"}}
-{"execute": "job-finalize", "arguments": {"id": "stream0"}}
-{"return": {}}
-{"data": {"id": "stream0", "type": "stream"}, "event": "BLOCK_JOB_PENDING", 
"timestamp": {"microseconds": "USECS", "seconds": "SECS"}}
-{"data": {"device": "stream0", "len": 3145728, "offset": 3145728, "speed": 0, 
"type": "stream"}, "event": "BLOCK_JOB_COMPLETED", "timestamp": 
{"microseconds": "USECS", "seconds": "SECS"}}
diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
index 661d7f93bf..b97cc2fab2 100644
--- a/tests/qemu-iotests/iotests.py
+++ b/tests/qemu-iotests/iotests.py
@@ -35,6 +35,13 @@ from collections import OrderedDict
 sys.path.append(os.path.join(os.path.dirname(__file__), '..', '..', 'python'))
 from qemu import qtest
 
+# Use this logger for logging messages directly from the iotests module
+logger = logging.getLogger(__name__)
+logger.addHandler(logging.NullHandler())
+
+# Use this logger for messages that ought to be used for diff output.
+test_logger = logging.getLogger('.'.join((__name__, 'iotest')))
+test_logger.addHandler(logging.NullH

Re: [Qemu-devel] [PATCH v5 00/17] target/arm: Reduce overhead of cpu_get_tb_cpu_state

[Richard Henderson]

On 8/20/19 2:07 PM, Richard Henderson wrote:
> Changes since v4:
>   * Split patch 1 into 15 smaller patches.
>   * Cache the new DEBUG_TARGET_EL field.
>   * Split out m-profile hflags separately from a-profile 32-bit.
>   * Move around non-cached tb flags as well, avoiding repetitive
> checks for m-profile or other mutually exclusive conditions.

Just after I posted this, I started rebasing my VHE patch set on top, and I
found that the new DEBUG_TARGET_EL field has used The Last Bit, so that I could
not add the one bit that I need for VHE.

However, while working on this patch set, I noticed that we have a lot of
unnecessary overlap between A- and M- profile in the TBFLAGs.  Thus point 4
above and the completely separate rebuild_hflags_m32().

If we rearrange things like the appended, then we recover 4 bits.

Thoughts?


r~
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 91a54662c3..0c2803baa1 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -3183,38 +3183,50 @@ FIELD(TBFLAG_ANY, BE_DATA, 23, 1)
  */
 FIELD(TBFLAG_ANY, DEBUG_TARGET_EL, 21, 2)
 
-/* Bit usage when in AArch32 state: */
-FIELD(TBFLAG_A32, THUMB, 0, 1)  /* Not cached. */
-FIELD(TBFLAG_A32, VECLEN, 1, 3) /* Not cached. */
-FIELD(TBFLAG_A32, VECSTRIDE, 4, 2)  /* Not cached. */
+/*
+ * Bit usage when in AArch32 state, both A- and M-profile.
+ */
+FIELD(TBFLAG_AM32, CONDEXEC, 0, 8)  /* Not cached. */
+
+/*
+ * Bit usage when in AArch32 state, for A-profile only.
+ */
+FIELD(TBFLAG_A32, THUMB, 8, 1)  /* Not cached. */
+FIELD(TBFLAG_A32, VECLEN, 9, 3) /* Not cached. */
+FIELD(TBFLAG_A32, VECSTRIDE, 12, 2) /* Not cached. */
 /*
  * We store the bottom two bits of the CPAR as TB flags and handle
  * checks on the other bits at runtime. This shares the same bits as
  * VECSTRIDE, which is OK as no XScale CPU has VFP.
  * Not cached, because VECLEN+VECSTRIDE are not cached.
  */
-FIELD(TBFLAG_A32, XSCALE_CPAR, 4, 2)
+FIELD(TBFLAG_A32, XSCALE_CPAR, 12, 2)
+FIELD(TBFLAG_A32, VFPEN, 14, 1) /* Partially cached, minus FPEXC. */
+FIELD(TBFLAG_A32, SCTLR_B, 15, 1)
 /*
  * Indicates whether cp register reads and writes by guest code should access
  * the secure or nonsecure bank of banked registers; note that this is not
  * the same thing as the current security state of the processor!
  */
-FIELD(TBFLAG_A32, NS, 6, 1)
-FIELD(TBFLAG_A32, VFPEN, 7, 1)  /* Partially cached, minus FPEXC. */
-FIELD(TBFLAG_A32, CONDEXEC, 8, 8)   /* Not cached. */
-FIELD(TBFLAG_A32, SCTLR_B, 16, 1)
-/* For M profile only, set if FPCCR.LSPACT is set */
-FIELD(TBFLAG_A32, LSPACT, 18, 1)/* Not cached. */
-/* For M profile only, set if we must create a new FP context */
-FIELD(TBFLAG_A32, NEW_FP_CTXT_NEEDED, 19, 1) /* Not cached. */
-/* For M profile only, set if FPCCR.S does not match current security state */
-FIELD(TBFLAG_A32, FPCCR_S_WRONG, 20, 1) /* Not cached. */
-/* For M profile only, Handler (ie not Thread) mode */
-FIELD(TBFLAG_A32, HANDLER, 21, 1)
-/* For M profile only, whether we should generate stack-limit checks */
-FIELD(TBFLAG_A32, STACKCHECK, 22, 1)
+FIELD(TBFLAG_A32, NS, 16, 1)
 
-/* Bit usage when in AArch64 state */
+/*
+ * Bit usage when in AArch32 state, for M-profile only.
+ */
+/* Set if FPCCR.LSPACT is set */
+FIELD(TBFLAG_M32, LSPACT, 8, 1)  /* Not cached. */
+/* Set if we must create a new FP context */
+FIELD(TBFLAG_M32, NEW_FP_CTXT_NEEDED, 9, 1)  /* Not cached. */
+/* Set if FPCCR.S does not match current security state */
+FIELD(TBFLAG_M32, FPCCR_S_WRONG, 10, 1)  /* Not cached. */
+/* Handler (ie not Thread) mode */
+FIELD(TBFLAG_A32, HANDLER, 11, 1)
+/* Whether we should generate stack-limit checks */
+FIELD(TBFLAG_A32, STACKCHECK, 12, 1)
+
+/*
+ * Bit usage when in AArch64 state
+ */
 FIELD(TBFLAG_A64, TBII, 0, 2)
 FIELD(TBFLAG_A64, SVEEXC_EL, 2, 2)
 FIELD(TBFLAG_A64, ZCR_LEN, 4, 4)

[Qemu-devel] [PATCH v3 0/4] iotests: use python logging

[John Snow]

This series uses python logging to enable output conditionally on
iotests.log(). We unify an initialization call (which also enables
debugging output for those tests with -d) and then make the switch
inside of iotests.

It will help alleviate the need to create logged/unlogged versions
of all the various helpers we have made.

V3:
 - Rebased for 4.1+; now based on main branch.

V2:
 - Added all of the other python tests I missed to use script_initialize
 - Refactored the common setup as per Ehabkost's suggestion
 - Added protocol arguments to common initialization,
   but this isn't strictly required.

John Snow (4):
  iotests: add script_initialize
  iotest 258: use script_main
  iotests: add protocol support to initialization info
  iotests: use python logging for iotests.log()

 tests/qemu-iotests/030|   4 +-
 tests/qemu-iotests/149|   3 +-
 tests/qemu-iotests/194|   3 +-
 tests/qemu-iotests/202|   3 +-
 tests/qemu-iotests/203|   3 +-
 tests/qemu-iotests/206|   2 +-
 tests/qemu-iotests/207|   4 +-
 tests/qemu-iotests/208|   2 +-
 tests/qemu-iotests/209|   2 +-
 tests/qemu-iotests/210|   4 +-
 tests/qemu-iotests/211|   4 +-
 tests/qemu-iotests/212|   4 +-
 tests/qemu-iotests/213|   4 +-
 tests/qemu-iotests/216|   3 +-
 tests/qemu-iotests/218|   2 +-
 tests/qemu-iotests/219|   2 +-
 tests/qemu-iotests/222|   5 +-
 tests/qemu-iotests/224|   3 +-
 tests/qemu-iotests/228|   3 +-
 tests/qemu-iotests/234|   3 +-
 tests/qemu-iotests/235|   4 +-
 tests/qemu-iotests/236|   2 +-
 tests/qemu-iotests/237|   2 +-
 tests/qemu-iotests/238|   2 +
 tests/qemu-iotests/242|   2 +-
 tests/qemu-iotests/245|   1 +
 tests/qemu-iotests/245.out|  24 
 tests/qemu-iotests/246|   2 +-
 tests/qemu-iotests/248|   2 +-
 tests/qemu-iotests/254|   2 +-
 tests/qemu-iotests/255|   2 +-
 tests/qemu-iotests/256|   2 +-
 tests/qemu-iotests/258|   8 +--
 tests/qemu-iotests/262|   3 +-
 tests/qemu-iotests/iotests.py | 108 ++
 35 files changed, 124 insertions(+), 105 deletions(-)

-- 
2.21.0

[Qemu-devel] [PATCH v3 2/4] iotest 258: use script_main

[John Snow]

Since this one is nicely factored to use a single entry point,
use script_main to run the tests.
---
 tests/qemu-iotests/258 | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/tests/qemu-iotests/258 b/tests/qemu-iotests/258
index b84cf02254..1372522c7a 100755
--- a/tests/qemu-iotests/258
+++ b/tests/qemu-iotests/258
@@ -23,11 +23,6 @@ import iotests
 from iotests import log, qemu_img, qemu_io_silent, \
 filter_qmp_testfiles, filter_qmp_imgfmt
 
-# Need backing file and change-backing-file support
-iotests.verify_image_format(supported_fmts=['qcow2', 'qed'])
-iotests.verify_platform(['linux'])
-
-
 # Returns a node for blockdev-add
 def node(node_name, path, backing=None, fmt=None, throttle=None):
 if fmt is None:
@@ -160,4 +155,5 @@ def main():
 test_concurrent_finish(False)
 
 if __name__ == '__main__':
-main()
+# Need backing file and change-backing-file support
+iotests.script_main(main, supported_fmts=['qcow2', 'qed'])
-- 
2.21.0

[Qemu-devel] [PATCH v3 3/4] iotests: add protocol support to initialization info

[John Snow]

This will add supported_protocols and unsupported_protocols to all of
iotests.main, iotests.script_main, and iotests.script_initialize.
---
 tests/qemu-iotests/207| 4 ++--
 tests/qemu-iotests/210| 4 ++--
 tests/qemu-iotests/211| 4 ++--
 tests/qemu-iotests/212| 4 ++--
 tests/qemu-iotests/213| 4 ++--
 tests/qemu-iotests/iotests.py | 5 -
 6 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/tests/qemu-iotests/207 b/tests/qemu-iotests/207
index ab9e3b6747..35d98f2736 100755
--- a/tests/qemu-iotests/207
+++ b/tests/qemu-iotests/207
@@ -24,8 +24,8 @@ import iotests
 import subprocess
 import re
 
-iotests.script_initialize(supported_fmts=['raw'])
-iotests.verify_protocol(supported=['ssh'])
+iotests.script_initialize(supported_fmts=['raw'],
+  supported_protocols=['ssh'])
 
 def filter_hash(qmsg):
 def _filter(key, value):
diff --git a/tests/qemu-iotests/210 b/tests/qemu-iotests/210
index 5a7013cd34..d9fe780c07 100755
--- a/tests/qemu-iotests/210
+++ b/tests/qemu-iotests/210
@@ -23,8 +23,8 @@
 import iotests
 from iotests import imgfmt
 
-iotests.script_initialize(supported_fmts=['luks'])
-iotests.verify_protocol(supported=['file'])
+iotests.script_initialize(supported_fmts=['luks'],
+  supported_protocols=['file'])
 
 def blockdev_create(vm, options):
 result = vm.qmp_log('blockdev-create', job_id='job0', options=options,
diff --git a/tests/qemu-iotests/211 b/tests/qemu-iotests/211
index 4d6aac497f..155fac4e87 100755
--- a/tests/qemu-iotests/211
+++ b/tests/qemu-iotests/211
@@ -23,8 +23,8 @@
 import iotests
 from iotests import imgfmt
 
-iotests.script_initialize(supported_fmts=['vdi'])
-iotests.verify_protocol(supported=['file'])
+iotests.script_initialize(supported_fmts=['vdi'],
+  supported_protocols=['file'])
 
 def blockdev_create(vm, options):
 result = vm.qmp_log('blockdev-create', job_id='job0', options=options,
diff --git a/tests/qemu-iotests/212 b/tests/qemu-iotests/212
index ec35bceb11..67e5a1dbb5 100755
--- a/tests/qemu-iotests/212
+++ b/tests/qemu-iotests/212
@@ -23,8 +23,8 @@
 import iotests
 from iotests import imgfmt
 
-iotests.script_initialize(supported_fmts=['parallels'])
-iotests.verify_protocol(supported=['file'])
+iotests.script_initialize(supported_fmts=['parallels'],
+  supported_protocols=['file'])
 
 def blockdev_create(vm, options):
 result = vm.qmp_log('blockdev-create', job_id='job0', options=options,
diff --git a/tests/qemu-iotests/213 b/tests/qemu-iotests/213
index 3d2c024375..23f387ab63 100755
--- a/tests/qemu-iotests/213
+++ b/tests/qemu-iotests/213
@@ -23,8 +23,8 @@
 import iotests
 from iotests import imgfmt
 
-iotests.script_initialize(supported_fmts=['vhdx'])
-iotests.verify_protocol(supported=['file'])
+iotests.script_initialize(supported_fmts=['vhdx'],
+  supported_protocols=['file'])
 
 def blockdev_create(vm, options):
 result = vm.qmp_log('blockdev-create', job_id='job0', options=options,
diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
index 2970d7304a..661d7f93bf 100644
--- a/tests/qemu-iotests/iotests.py
+++ b/tests/qemu-iotests/iotests.py
@@ -925,7 +925,9 @@ def execute_unittest(debug=False):
 def execute_setup_common(supported_fmts=[],
  supported_oses=['linux'],
  supported_cache_modes=[],
- unsupported_fmts=[]):
+ unsupported_fmts=[],
+ supported_protocols=[],
+ unsupported_protocols=[]):
 """
 Perform necessary setup for either script-style or unittest-style tests.
 """
@@ -941,6 +943,7 @@ def execute_setup_common(supported_fmts=[],
 verify_image_format(supported_fmts, unsupported_fmts)
 verify_platform(supported_oses)
 verify_cache_mode(supported_cache_modes)
+verify_protocol(supported_protocols, unsupported_protocols)
 
 debug = '-d' in sys.argv
 if debug:
-- 
2.21.0

[Qemu-devel] [PATCH v3 1/4] iotests: add script_initialize

[John Snow]

Like script_main, but doesn't require a single point of entry.
Replace all existing initialization sections with this drop-in replacement.

This brings debug support to all existing script-style iotests.

Note: supported_oses=['linux'] was omitted, as it is a default argument.
---
 tests/qemu-iotests/149|  3 +-
 tests/qemu-iotests/194|  3 +-
 tests/qemu-iotests/202|  3 +-
 tests/qemu-iotests/203|  3 +-
 tests/qemu-iotests/206|  2 +-
 tests/qemu-iotests/207|  2 +-
 tests/qemu-iotests/208|  2 +-
 tests/qemu-iotests/209|  2 +-
 tests/qemu-iotests/210|  2 +-
 tests/qemu-iotests/211|  2 +-
 tests/qemu-iotests/212|  2 +-
 tests/qemu-iotests/213|  2 +-
 tests/qemu-iotests/216|  3 +-
 tests/qemu-iotests/218|  2 +-
 tests/qemu-iotests/219|  2 +-
 tests/qemu-iotests/222|  5 ++-
 tests/qemu-iotests/224|  3 +-
 tests/qemu-iotests/228|  3 +-
 tests/qemu-iotests/234|  3 +-
 tests/qemu-iotests/235|  4 +--
 tests/qemu-iotests/236|  2 +-
 tests/qemu-iotests/237|  2 +-
 tests/qemu-iotests/238|  2 ++
 tests/qemu-iotests/242|  2 +-
 tests/qemu-iotests/246|  2 +-
 tests/qemu-iotests/248|  2 +-
 tests/qemu-iotests/254|  2 +-
 tests/qemu-iotests/255|  2 +-
 tests/qemu-iotests/256|  2 +-
 tests/qemu-iotests/262|  3 +-
 tests/qemu-iotests/iotests.py | 58 +++
 31 files changed, 71 insertions(+), 61 deletions(-)

diff --git a/tests/qemu-iotests/149 b/tests/qemu-iotests/149
index 4f363f295f..9fa97966c5 100755
--- a/tests/qemu-iotests/149
+++ b/tests/qemu-iotests/149
@@ -383,8 +383,7 @@ def test_once(config, qemu_img=False):
 
 
 # Obviously we only work with the luks image format
-iotests.verify_image_format(supported_fmts=['luks'])
-iotests.verify_platform()
+iotests.script_initialize(supported_fmts=['luks'])
 
 # We need sudo in order to run cryptsetup to create
 # dm-crypt devices. This is safe to use on any
diff --git a/tests/qemu-iotests/194 b/tests/qemu-iotests/194
index d746ab1e21..c8aeb6d0e4 100755
--- a/tests/qemu-iotests/194
+++ b/tests/qemu-iotests/194
@@ -21,8 +21,7 @@
 
 import iotests
 
-iotests.verify_image_format(supported_fmts=['qcow2', 'qed', 'raw'])
-iotests.verify_platform(['linux'])
+iotests.script_initialize(supported_fmts=['qcow2', 'qed', 'raw'])
 
 with iotests.FilePath('source.img') as source_img_path, \
  iotests.FilePath('dest.img') as dest_img_path, \
diff --git a/tests/qemu-iotests/202 b/tests/qemu-iotests/202
index 581ca34d79..1271ac9459 100755
--- a/tests/qemu-iotests/202
+++ b/tests/qemu-iotests/202
@@ -24,8 +24,7 @@
 
 import iotests
 
-iotests.verify_image_format(supported_fmts=['qcow2'])
-iotests.verify_platform(['linux'])
+iotests.script_initialize(supported_fmts=['qcow2'])
 
 with iotests.FilePath('disk0.img') as disk0_img_path, \
  iotests.FilePath('disk1.img') as disk1_img_path, \
diff --git a/tests/qemu-iotests/203 b/tests/qemu-iotests/203
index 4874a1a0d8..c40fe231ea 100755
--- a/tests/qemu-iotests/203
+++ b/tests/qemu-iotests/203
@@ -24,8 +24,7 @@
 
 import iotests
 
-iotests.verify_image_format(supported_fmts=['qcow2'])
-iotests.verify_platform(['linux'])
+iotests.script_initialize(supported_fmts=['qcow2'])
 
 with iotests.FilePath('disk0.img') as disk0_img_path, \
  iotests.FilePath('disk1.img') as disk1_img_path, \
diff --git a/tests/qemu-iotests/206 b/tests/qemu-iotests/206
index 5bb738bf23..23ff2f624b 100755
--- a/tests/qemu-iotests/206
+++ b/tests/qemu-iotests/206
@@ -23,7 +23,7 @@
 import iotests
 from iotests import imgfmt
 
-iotests.verify_image_format(supported_fmts=['qcow2'])
+iotests.script_initialize(supported_fmts=['qcow2'])
 
 def blockdev_create(vm, options):
 result = vm.qmp_log('blockdev-create',
diff --git a/tests/qemu-iotests/207 b/tests/qemu-iotests/207
index ec8c1d06f0..ab9e3b6747 100755
--- a/tests/qemu-iotests/207
+++ b/tests/qemu-iotests/207
@@ -24,7 +24,7 @@ import iotests
 import subprocess
 import re
 
-iotests.verify_image_format(supported_fmts=['raw'])
+iotests.script_initialize(supported_fmts=['raw'])
 iotests.verify_protocol(supported=['ssh'])
 
 def filter_hash(qmsg):
diff --git a/tests/qemu-iotests/208 b/tests/qemu-iotests/208
index 1e202388dc..dfce6f9fe4 100755
--- a/tests/qemu-iotests/208
+++ b/tests/qemu-iotests/208
@@ -22,7 +22,7 @@
 
 import iotests
 
-iotests.verify_image_format(supported_fmts=['generic'])
+iotests.script_initialize(supported_fmts=['generic'])
 
 with iotests.FilePath('disk.img') as disk_img_path, \
  iotests.FilePath('disk-snapshot.img') as disk_snapshot_img_path, \
diff --git a/tests/qemu-iotests/209 b/tests/qemu-iotests/209
index 259e991ec6..a77f884166 100755
--- a/tests/qemu-iotests/209
+++ b/tests/qemu-iotests/209
@@ -22,7 +22,7 @@ import iotests
 from iotests import qemu_img_create, qemu_io, qemu_img_verbose, qemu_nbd, \
 fi

Re: [Qemu-devel] [PULL 00/36] QEMU patches for 2018-08-20

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/1566284395-30287-1-git-send-email-pbonz...@redhat.com/



Hi,

This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-fedora V=1 NETWORK=1
time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 NETWORK=1
=== TEST SCRIPT END ===

  CC  hw/display/xenfb.o
  CC  hw/display/vga-pci.o
  CC  hw/display/vga-isa.o
/tmp/qemu-test/src/hw/core/loader.c:1123:9: error: implicit declaration of 
function 'runstate_check' is invalid in C99 
[-Werror,-Wimplicit-function-declaration]
if (runstate_check(RUN_STATE_INMIGRATE))
^
/tmp/qemu-test/src/hw/core/loader.c:1123:9: error: this function declaration is 
not a prototype [-Werror,-Wstrict-prototypes]
2 errors generated.
make: *** [/tmp/qemu-test/src/rules.mak:69: hw/core/loader.o] Error 1
make: *** Waiting for unfinished jobs


The full log is available at
http://patchew.org/logs/1566284395-30287-1-git-send-email-pbonz...@redhat.com/testing.asan/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [Qemu-devel] [PATCH] block/backup: install notifier during creation

[John Snow]

ping, y'all

On 8/9/19 4:13 PM, John Snow wrote:
> Backup jobs may yield prior to installing their handler, because of the
> job_co_entry shim which guarantees that a job won't begin work until
> we are ready to start an entire transaction.
> 
> Unfortunately, this makes proving correctness about transactional
> points-in-time for backup hard to reason about. Make it explicitly clear
> by moving the handler registration to creation time, and changing the
> write notifier to a no-op until the job is started.
> 
> Reported-by: Vladimir Sementsov-Ogievskiy 
> Signed-off-by: John Snow 
> ---
>  block/backup.c | 32 +++-
>  include/qemu/job.h |  5 +
>  job.c  |  2 +-
>  3 files changed, 29 insertions(+), 10 deletions(-)
> 
> diff --git a/block/backup.c b/block/backup.c
> index 07d751aea4..4df5b95415 100644
> --- a/block/backup.c
> +++ b/block/backup.c
> @@ -344,6 +344,13 @@ static int coroutine_fn backup_before_write_notify(
>  assert(QEMU_IS_ALIGNED(req->offset, BDRV_SECTOR_SIZE));
>  assert(QEMU_IS_ALIGNED(req->bytes, BDRV_SECTOR_SIZE));
>  
> +/* The handler is installed at creation time; the actual point-in-time
> + * starts at job_start(). Transactions guarantee those two points are
> + * the same point in time. */
> +if (!job_started(&job->common.job)) {
> +return 0;
> +}
> +
>  return backup_do_cow(job, req->offset, req->bytes, NULL, true);
>  }
>  
> @@ -398,6 +405,12 @@ static void backup_clean(Job *job)
>  BackupBlockJob *s = container_of(job, BackupBlockJob, common.job);
>  BlockDriverState *bs = blk_bs(s->common.blk);
>  
> +/* cancelled before job_start: remove write_notifier */
> +if (s->before_write.notify) {
> +notifier_with_return_remove(&s->before_write);
> +s->before_write.notify = NULL;
> +}
> +
>  if (s->copy_bitmap) {
>  bdrv_release_dirty_bitmap(bs, s->copy_bitmap);
>  s->copy_bitmap = NULL;
> @@ -527,17 +540,8 @@ static void backup_init_copy_bitmap(BackupBlockJob *job)
>  static int coroutine_fn backup_run(Job *job, Error **errp)
>  {
>  BackupBlockJob *s = container_of(job, BackupBlockJob, common.job);
> -BlockDriverState *bs = blk_bs(s->common.blk);
>  int ret = 0;
>  
> -QLIST_INIT(&s->inflight_reqs);
> -qemu_co_rwlock_init(&s->flush_rwlock);
> -
> -backup_init_copy_bitmap(s);
> -
> -s->before_write.notify = backup_before_write_notify;
> -bdrv_add_before_write_notifier(bs, &s->before_write);
> -
>  if (s->sync_mode == MIRROR_SYNC_MODE_TOP) {
>  int64_t offset = 0;
>  int64_t count;
> @@ -572,6 +576,7 @@ static int coroutine_fn backup_run(Job *job, Error **errp)
>  
>   out:
>  notifier_with_return_remove(&s->before_write);
> +s->before_write.notify = NULL;
>  
>  /* wait until pending backup_do_cow() calls have completed */
>  qemu_co_rwlock_wrlock(&s->flush_rwlock);
> @@ -767,6 +772,15 @@ BlockJob *backup_job_create(const char *job_id, 
> BlockDriverState *bs,
> &error_abort);
>  job->len = len;
>  
> +/* Finally, install a write notifier that takes effect after job_start() 
> */
> +backup_init_copy_bitmap(job);
> +
> +QLIST_INIT(&job->inflight_reqs);
> +qemu_co_rwlock_init(&job->flush_rwlock);
> +
> +job->before_write.notify = backup_before_write_notify;
> +bdrv_add_before_write_notifier(bs, &job->before_write);
> +
>  return &job->common;
>  
>   error:
> diff --git a/include/qemu/job.h b/include/qemu/job.h
> index 9e7cd1e4a0..733afb696b 100644
> --- a/include/qemu/job.h
> +++ b/include/qemu/job.h
> @@ -394,6 +394,11 @@ void job_enter_cond(Job *job, bool(*fn)(Job *job));
>   */
>  void job_start(Job *job);
>  
> +/**
> + * job_started returns true if the @job has started.
> + */
> +bool job_started(Job *job);
> +
>  /**
>   * @job: The job to enter.
>   *
> diff --git a/job.c b/job.c
> index 28dd48f8a5..745af659ff 100644
> --- a/job.c
> +++ b/job.c
> @@ -243,7 +243,7 @@ bool job_is_completed(Job *job)
>  return false;
>  }
>  
> -static bool job_started(Job *job)
> +bool job_started(Job *job)
>  {
>  return job->co;
>  }
> 

Re: [Qemu-devel] [Bug 1819289] Re: Windows 95 and Windows 98 will not install or run

[Aleksandar Markovic]

20.08.2019. 23.56, "Brad Parker" <1819...@bugs.launchpad.net> је написао/ла:
>
> So it looks like even though that commit fixed it, it seems to break
> again (differently) in 3.0.0, so I'll need to do another bisect between
> cfcca36 and v3.0.0 then I guess. And keep working my way up to master as
> well.
>
> --

At least you will have an interesting debugging story to tell afterwards. I
wish you luck!

Aleksandar

> You received this bug notification because you are a member of qemu-
> devel-ml, which is subscribed to QEMU.
> https://bugs.launchpad.net/bugs/1819289
>
> Title:
>   Windows 95 and Windows 98 will not install or run
>
> Status in QEMU:
>   New
>
> Bug description:
>   The last version of QEMU I have been able to run Windows 95 or Windows
>   98 on was 2.7 or 2.8. Recent versions since then even up to 3.1 will
>   either not install or will not run 95 or 98 at all. I have tried every
>   combination of options like isapc or no isapc, cpu pentium  or cpu as
>   486. Tried different memory configurations, but they just don't work
>   anymore.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1819289/+subscriptions
>

[Qemu-devel] QEMU bitmap backup usability FAQ

[John Snow]

Hi, downstream here at Red Hat I've been fielding some questions about
the usability and feature readiness of Bitmaps (and related features) in
QEMU.

Here are some questions I answered internally that I am copying to the
list for two reasons:

(1) To make sure my answers are actually correct, and
(2) To share this pseudo-reference with the community at large.

This is long, and mostly for reference. There's a summary at the bottom
with some todo items and observations about the usability of the feature
as it exists in QEMU.

Before too long, I intend to send a more summarized "roadmap" mail which
details all of the current and remaining work to be done in and around
the bitmaps feature in QEMU.


Questions:

> "What format(s) is/are required for this functionality?"

>From the QEMU API, any format can be used to create and author
incremental backups. The only known format limitations are:

1. Persistent bitmaps cannot be created on any format except qcow2,
although there are hooks to add support to other formats at a later date
if desired.

DANGER CAVEAT #1: Adding bitmaps to QEMU by default creates transient
bitmaps instead of persistent ones.

Possible TODO: Allow users to 'upgrade' transient bitmaps to persistent
ones in case they made a mistake.


2. When using push backups (blockdev-backup, drive-backup), you may use
any format as a target format.

DANGER CAVEAT #2: without backing file and/or filesystem-less sparse
support, these images will be unusable.

EXAMPLE: Backing up to a raw file loses allocation information, so we
can no longer distinguish between zeroes and unallocated regions. The
cluster size is also lost. This file will not be usable without
additional metadata recorded elsewhere.*

(* This is complicated, but it is in theory possible to do a push backup
to e.g. an NBD target with custom server code that saves allocation
information to a metadata file, which would allow you to reconstruct
backups. For instance, recording in a .json file which extents were
written out would allow you to -- with a custom binary -- write this
information on top of a base file to reconstruct a backup.)


3. Any format can be used for either shared storage or live storage
migrations. There are TWO distinct mechanisms for migrating bitmaps:

A) The bitmap is flushed to storage and re-opened on the destination.
This is only supported for qcow2 and shared-storage migrations.

B) The bitmap is live-migrated to the destination. This is supported for
any format and can be used for either shared storage or live storage
migrations.

DANGER CAVEAT #3: The second bitmap migration technique there is an
optional migration capability that must be enabled explicitly.
Otherwise, some migration combinations may drop bitmaps.

Matrix:

> migrate = migrate_capability or (persistent and shared_storage)

Enumerated:

live storage + raw : transient + no-capability: Dropped
live-storage + raw : transient + bm-capability: Migrated
live-storage + qcow2 : transient + no-capability: Dropped
live-storage + qcow2 : transient + bm-capability: Migrated
live-storage + qcow2 : persistent + no-capability: Dropped (!)
live-storage + qcow2 : persistent + bm-capability: Migrated

shared-storage + raw : transient - no-capability: Dropped
shared-storage + raw : transient + bm-capability: Migrated
shared-storage + qcow2 : transient + no-capability: Migrated
shared-storage + qcow2 : transient + bm-capability: Migrated
shared-storage + qcow2 : persistent + no-capability: Migrated
shared-storage + qcow2 : persistent + bm-capability: Migrated

Enabling the bitmap migration capability will ALWAYS migrate the bitmap.
If it's disabled, we will only migrate the bitmaps for shared storage
migrations where the bitmap is persistent, which is a qcow2-only case.

There is no warning or error if you attempt to migrate in a manner that
loses your bitmaps.

(I might be persuaded to add a case for when you are doing a live
storage migration of qcow2 with persistent bitmaps, which is somewhat a
conflicting case: you've asked for the bitmap to be persistent, but it
seems likely that if this ever happens in practice, it's because you
have neglected to ask for it to be migrated to the new host.)

See iotest 169 for more details on this.

At present, these are the only format limitations I am consciously aware
of. From a management API/GUI perspective, it makes sense to restrict
the feature set to "qcow2 only" to minimize edge cases.


> "Is libvirt aware of these 'gotcha' cases?"

>From talks I've had with Eric Blake and Peter Krempa, they certainly are
now.


> "Is it possible to make persistent the default?"

Not quickly.

In QEMU, not without a deprecation period or some other incompatibility.
Default values are not (yet?) introspectable via the schema. We need
(possibly) up to two QAPI extensions:

I) The ability to return deprecation warnings when issuing a command
that will cease to work in the future.

This has been being discussed somewhat on-list recently. 

[Qemu-devel] [Bug 1819289] Re: Windows 95 and Windows 98 will not install or run

[Brad Parker]

So it looks like even though that commit fixed it, it seems to break
again (differently) in 3.0.0, so I'll need to do another bisect between
cfcca36 and v3.0.0 then I guess. And keep working my way up to master as
well.

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

Title:
  Windows 95 and Windows 98 will not install or run

Status in QEMU:
  New

Bug description:
  The last version of QEMU I have been able to run Windows 95 or Windows
  98 on was 2.7 or 2.8. Recent versions since then even up to 3.1 will
  either not install or will not run 95 or 98 at all. I have tried every
  combination of options like isapc or no isapc, cpu pentium  or cpu as
  486. Tried different memory configurations, but they just don't work
  anymore.

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

Re: [Qemu-devel] [PATCH v3 3/8] iotests: Allow skipping test cases

[John Snow]

On 8/19/19 4:18 PM, Max Reitz wrote:
> case_notrun() does not actually skip the current test case.  It just
> adds a "notrun" note and then returns to the caller, who manually has to
> skip the test.  Generally, skipping a test case is as simple as
> returning from the current function, but not always: For example, this
> model does not allow skipping tests already in the setUp() function.
> 
> Thus, add a QMPTestCase.case_skip() function that invokes case_notrun()
> and then self.skipTest().  To make this work, we need to filter the
> information on how many test cases were skipped from the unittest
> output.
> 
> Signed-off-by: Max Reitz 

Hm, didn't someone else send a patch like this recently?

Ah, yes:
[Qemu-block] [PATCH v5 3/6] iotests: Add casenotrun report to bash tests

Oh, theirs is for bash. Moving along.

> ---
>  tests/qemu-iotests/iotests.py | 21 ++---
>  1 file changed, 18 insertions(+), 3 deletions(-)
> 
> diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
> index 84438e837c..2f53baf633 100644
> --- a/tests/qemu-iotests/iotests.py
> +++ b/tests/qemu-iotests/iotests.py
> @@ -802,6 +802,11 @@ class QMPTestCase(unittest.TestCase):
>  return self.pause_wait(job_id)
>  return result
>  
> +def case_skip(self, reason):
> +'''Skip this test case'''
> +case_notrun(reason)
> +self.skipTest(reason)
> +
>  
>  def notrun(reason):
>  '''Skip this test suite'''
> @@ -813,7 +818,10 @@ def notrun(reason):
>  sys.exit(0)
>  
>  def case_notrun(reason):
> -'''Skip this test case'''
> +'''Mark this test case as not having been run, but do not actually
> +skip it; that is left to the caller.  See QMPTestCase.case_skip()
> +for a variant that actually skips the current test case.'''
> +
>  # Each test in qemu-iotests has a number ("seq")
>  seq = os.path.basename(sys.argv[0])
>  
> @@ -904,8 +912,15 @@ def execute_unittest(output, verbosity, debug):
>  unittest.main(testRunner=runner)
>  finally:
>  if not debug:
> -sys.stderr.write(re.sub(r'Ran (\d+) tests? in [\d.]+s',
> -r'Ran \1 tests', output.getvalue()))
> +out = output.getvalue()
> +out = re.sub(r'Ran (\d+) tests? in [\d.]+s', r'Ran \1 tests', 
> out)
> +
> +# Hide skipped tests from the reference output
> +out = re.sub(r'OK \(skipped=\d+\)', 'OK', out)
> +out_first_line, out_rest = out.split('\n', 1)
> +out = out_first_line.replace('s', '.') + '\n' + out_rest
> +
> +sys.stderr.write(out)
>  
>  def execute_test(test_function=None,
>   supported_fmts=[], supported_oses=['linux'],
> 

okey dokey.

Reviewed-by: John Snow 

Re: [Qemu-devel] [PATCH] Revert "i386: correct cpu_x86_cpuid(0xd)"

[Eduardo Habkost]

On Mon, Aug 19, 2019 at 06:09:24PM +0800, Bingsong Si wrote:
> This reverts commit de2e68c902f7b6e438b0fa3cfedd74a06a20704f.
> 
> Initial value of env->xcr0 == 0, then CPUID(EAX=0xd,ECX=0).EBX == 0, after kvm
> upstream commit 412a3c41, It is ok.
> On host before commit 412a3c41, some legacy guest, i.e. CentOS 6, get
> xstate_size == 0, will crash the guest.
> 
> Signed-off-by: Bingsong Si 

cpu_x86_cpuid() is also used by TCG, and needs to return the
correct data depending on xcr0.  If you want to work around a KVM
bug by ignoring xcr0, it needs to be conditional on
kvm_enabled().

But even if we you make this conditional on kvm_enabled(), I
don't understand why QEMU would need a workaround for a KVM bug
that was fixed more than 4 years ago.

> ---
>  target/i386/cpu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index ff65e11008..69562e21ed 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -4416,7 +4416,7 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, 
> uint32_t count,
>  *ecx = xsave_area_size(x86_cpu_xsave_components(cpu));
>  *eax = env->features[FEAT_XSAVE_COMP_LO];
>  *edx = env->features[FEAT_XSAVE_COMP_HI];
> -*ebx = xsave_area_size(env->xcr0);
> +*ebx = *ecx;
>  } else if (count == 1) {
>  *eax = env->features[FEAT_XSAVE];
>  } else if (count < ARRAY_SIZE(x86_ext_save_areas)) {
> -- 
> 2.22.0
> 
> 

-- 
Eduardo

[Qemu-devel] [Bug 1819289] Re: Windows 95 and Windows 98 will not install or run

[Brad Parker]

e3af7c788b73a6495 was indeed one of the bad commits I tested during the
bisect. If I apply cfcca361d77142f25f on top of it, Windows starts up
normally instead of giving me a BSOD on bootup.

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

Title:
  Windows 95 and Windows 98 will not install or run

Status in QEMU:
  New

Bug description:
  The last version of QEMU I have been able to run Windows 95 or Windows
  98 on was 2.7 or 2.8. Recent versions since then even up to 3.1 will
  either not install or will not run 95 or 98 at all. I have tried every
  combination of options like isapc or no isapc, cpu pentium  or cpu as
  486. Tried different memory configurations, but they just don't work
  anymore.

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

Re: [Qemu-devel] [Qemu-block] [PATCH] nbd: Advertise multi-conn for shared read-only connections

[Nir Soffer]

On Mon, Aug 19, 2019 at 9:04 PM Eric Blake  wrote:

> On 8/17/19 8:31 PM, Nir Soffer wrote:
> >>> Also, for qemu-nbd, shouldn't we allow -e only together with -r ?
> >>
> >> I'm reluctant to; it might break whatever existing user is okay exposing
> >> it (although such users are questionable, so maybe we can argue they
> >> were already broken).  Maybe it's time to start a deprecation cycle?
> >>
> >
> > man qemu-nbd (on Centos 7.6) says:
> >
> >-e, --shared=num
> >Allow up to num clients to share the device (default 1)
> >
> > I see that in qemu-img 4.1 there is a note about consistency with
> writers:
> >
> >-e, --shared=num
> >Allow up to num clients to share the device (default 1). Safe
> > for readers, but for now, consistency is not guaranteed between multiple
> > writers.
> > But it is not clear what are the consistency guarantees.
> >
> > Supporting multiple writers is important. oVirt is giving the user a URL
> > (since 4.3), and the user
> > can use multiple connections using the same URL, each having a connection
> > to the same qemu-nbd
> > socket. I know that some backup vendors tried to use multiple connections
> > to speed up backups, and
> > they may try to do this also for restore.
> >
> > An interesting use case would be using multiple connections on client
> side
> > to write in parallel to
> > same image, when every client is writing different ranges.
>
> Good to know.
>
> >
> > Do we have real issue in qemu-nbd serving multiple clients writing to
> > different parts of
> > the same image?
>
> If a server advertises multi-conn on a writable image, then clients have
> stronger guarantees about behavior on what happens with flush on one
> client vs. write in another, to the point that you can make some better
> assumptions about image consistency, including what one client will read
> after another has written.  But as long as multiple clients only ever
> access distinct portions of the disk, then multi-conn is not important
> to that client (whether for reading or for writing).
>

Thanks for making this clear. I think we need to document this in oVirt,
so users will be careful about using multiple connections.



>
> So it sounds like I have no reason to deprecate qemu-nbd -e 2, even for
> writable images.
>
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.   +1-919-301-3226
> Virtualization:  qemu.org | libvirt.org
>
>

Re: [Qemu-devel] [PATCH v3 5/8] iotests: Let skip_if_unsupported() accept a method

[John Snow]

On 8/19/19 4:18 PM, Max Reitz wrote:
> This lets tests use skip_if_unsupported() with a potentially variable
> list of required formats.
> 
> Suggested-by: Kevin Wolf 
> Signed-off-by: Max Reitz 
> ---
>  tests/qemu-iotests/iotests.py | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
> index 726f904f50..8f315538e9 100644
> --- a/tests/qemu-iotests/iotests.py
> +++ b/tests/qemu-iotests/iotests.py
> @@ -893,8 +893,12 @@ def skip_if_unsupported(required_formats=[], 
> read_only=False):
> Runs the test if all the required formats are whitelisted'''
>  def skip_test_decorator(func):
>  def func_wrapper(*args, **kwargs):
> -usf_list = list(set(required_formats) -
> -set(supported_formats(read_only)))
> +if callable(required_formats):
> +fmts = required_formats(args[0])
> +else:
> +fmts = required_formats
> +
> +usf_list = list(set(fmts) - set(supported_formats(read_only)))
>  if usf_list:
>  args[0].case_skip('{}: formats {} are not 
> whitelisted'.format(
>  args[0], usf_list))
> 

I am required to inform you that this is in direct violation of the
pythonista treaty of 2007; which mandates that you try to call and fail
instead of attempting to gracefully check ahead of time.

Luckily, I am not fond of such rules.

Reviewed-by: John Snow 

Re: [Qemu-devel] [PATCH v3 6/8] iotests: Test driver whitelisting in 093

[John Snow]

On 8/19/19 4:18 PM, Max Reitz wrote:
> null-aio may not be whitelisted.  Skip all test cases that require it.
> 
> Signed-off-by: Max Reitz 
> ---
>  tests/qemu-iotests/093 | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/tests/qemu-iotests/093 b/tests/qemu-iotests/093
> index 50c1e7f2ec..f03fa24a07 100755
> --- a/tests/qemu-iotests/093
> +++ b/tests/qemu-iotests/093
> @@ -24,7 +24,7 @@ import iotests
>  nsec_per_sec = 10
>  
>  class ThrottleTestCase(iotests.QMPTestCase):
> -test_img = "null-aio://"
> +test_driver = "null-aio"
>  max_drives = 3
>  
>  def blockstats(self, device):
> @@ -35,10 +35,14 @@ class ThrottleTestCase(iotests.QMPTestCase):
>  return stat['rd_bytes'], stat['rd_operations'], 
> stat['wr_bytes'], stat['wr_operations']
>  raise Exception("Device not found for blockstats: %s" % device)
>  
> +def required_drivers(self):
> +return [self.test_driver]
> +
> +@iotests.skip_if_unsupported(required_drivers)

Oh, I see why you're passing args[0] back to the callback now. Why not
just pass self.required_drivers and call it with no arguments instead?

You can get a bound version that way that doesn't need additional
arguments, and then the callback is free to take generic callables of
any kind.

>  def setUp(self):
>  self.vm = iotests.VM()
>  for i in range(0, self.max_drives):
> -self.vm.add_drive(self.test_img, "file.read-zeroes=on")
> +self.vm.add_drive(self.test_driver + "://", 
> "file.read-zeroes=on")
>  self.vm.launch()
>  
>  def tearDown(self):
> @@ -264,7 +268,7 @@ class ThrottleTestCase(iotests.QMPTestCase):
>  self.assertEqual(self.blockstats('drive1')[0], 4096)
>  
>  class ThrottleTestCoroutine(ThrottleTestCase):
> -test_img = "null-co://"
> +test_driver = "null-co"
>  
>  class ThrottleTestGroupNames(iotests.QMPTestCase):
>  max_drives = 3
> @@ -425,4 +429,6 @@ class ThrottleTestRemovableMedia(iotests.QMPTestCase):
>  
>  
>  if __name__ == '__main__':
> +if 'null-co' not in iotests.supported_formats():
> +iotests.notrun('null-co driver support missing')
>  iotests.main(supported_fmts=["raw"])
> 

Re: [Qemu-devel] [PATCH v3 8/8] iotests: Cache supported_formats()

[John Snow]

Any particular reason? I guess an "itch."

On 8/19/19 4:18 PM, Max Reitz wrote:
> Signed-off-by: Max Reitz 
> ---
>  tests/qemu-iotests/iotests.py | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
> index 8f315538e9..f6492b355f 100644
> --- a/tests/qemu-iotests/iotests.py
> +++ b/tests/qemu-iotests/iotests.py
> @@ -884,9 +884,17 @@ def qemu_pipe(*args):
>  def supported_formats(read_only=False):
>  '''Set 'read_only' to True to check ro-whitelist
> Otherwise, rw-whitelist is checked'''
> -format_message = qemu_pipe("-drive", "format=help")
> -line = 1 if read_only else 0
> -return format_message.splitlines()[line].split(":")[1].split()
> +
> +if not hasattr(supported_formats, "formats"):
> +supported_formats.formats = {}
> +
> +if read_only not in supported_formats.formats:
> +format_message = qemu_pipe("-drive", "format=help")
> +line = 1 if read_only else 0
> +supported_formats.formats[read_only] = \
> +format_message.splitlines()[line].split(":")[1].split()
> +

Seems a little odd to use a boolean as a dict key, but I guess it works
and is fine.

> +return supported_formats.formats[read_only]
>  
>  def skip_if_unsupported(required_formats=[], read_only=False):
>  '''Skip Test Decorator
> 

Eh, why not.

Reviewed-by: John Snow 

Re: [Qemu-devel] [PATCH v3 4/8] iotests: Use case_skip() in skip_if_unsupported()

[John Snow]

On 8/19/19 4:18 PM, Max Reitz wrote:
> skip_if_unsupported() should use the stronger variant case_skip(),
> because this allows it to be used even with setUp() (in a meaningful
> way).
> 
> Signed-off-by: Max Reitz 
> ---
>  tests/qemu-iotests/iotests.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
> index 2f53baf633..726f904f50 100644
> --- a/tests/qemu-iotests/iotests.py
> +++ b/tests/qemu-iotests/iotests.py
> @@ -896,7 +896,7 @@ def skip_if_unsupported(required_formats=[], 
> read_only=False):
>  usf_list = list(set(required_formats) -
>  set(supported_formats(read_only)))
>  if usf_list:
> -case_notrun('{}: formats {} are not whitelisted'.format(
> +args[0].case_skip('{}: formats {} are not 
> whitelisted'.format(
>  args[0], usf_list))
>  else:
>  return func(*args, **kwargs)
> 

Should we promote args[0] to a named argument here, because we depend on
it having a specific type? It's not truly as polymorphic as we're making
it appear.

That type here is iotests.QMPTestCase because we're relying on case_skip
being present.

def test_wrapper(test_case, *args, **kwargs):
...
return func(test_case, *args, **kwargs)

--js

[Qemu-devel] [PATCH v5 12/17] target/arm: Add arm_rebuild_hflags

[Richard Henderson]

This function assumes nothing about the current state of the cpu,
and writes the computed value to env->hflags.

Signed-off-by: Richard Henderson 
---
 target/arm/cpu.h|  6 ++
 target/arm/helper.c | 30 ++
 2 files changed, 28 insertions(+), 8 deletions(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 9606222942..602c879395 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -3293,6 +3293,12 @@ void arm_register_pre_el_change_hook(ARMCPU *cpu, 
ARMELChangeHookFn *hook,
 void arm_register_el_change_hook(ARMCPU *cpu, ARMELChangeHookFn *hook, void
 *opaque);
 
+/**
+ * arm_rebuild_hflags:
+ * Rebuild the cached TBFLAGS for arbitrary changed processor state.
+ */
+void arm_rebuild_hflags(CPUARMState *env);
+
 /**
  * aa32_vfp_dreg:
  * Return a pointer to the Dn register within env in 32-bit mode.
diff --git a/target/arm/helper.c b/target/arm/helper.c
index b905d61898..83ae33dae5 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -11160,17 +11160,35 @@ static uint32_t rebuild_hflags_a64(CPUARMState *env, 
int el, int fp_el,
 return rebuild_hflags_common(env, fp_el, mmu_idx, flags);
 }
 
+static uint32_t rebuild_hflags_internal(CPUARMState *env)
+{
+int el = arm_current_el(env);
+int fp_el = fp_exception_el(env, el);
+ARMMMUIdx mmu_idx = arm_mmu_idx(env);
+
+if (is_a64(env)) {
+return rebuild_hflags_a64(env, el, fp_el, mmu_idx);
+} else if (arm_feature(env, ARM_FEATURE_M)) {
+return rebuild_hflags_m32(env, fp_el, mmu_idx);
+} else {
+return rebuild_hflags_a32(env, fp_el, mmu_idx);
+}
+}
+
+void arm_rebuild_hflags(CPUARMState *env)
+{
+env->hflags = rebuild_hflags_internal(env);
+}
+
 void cpu_get_tb_cpu_state(CPUARMState *env, target_ulong *pc,
   target_ulong *cs_base, uint32_t *pflags)
 {
-ARMMMUIdx mmu_idx = arm_mmu_idx(env);
-int current_el = arm_current_el(env);
-int fp_el = fp_exception_el(env, current_el);
 uint32_t flags, pstate_for_ss;
 
+flags = rebuild_hflags_internal(env);
+
 if (is_a64(env)) {
 *pc = env->pc;
-flags = rebuild_hflags_a64(env, current_el, fp_el, mmu_idx);
 if (cpu_isar_feature(aa64_bti, env_archcpu(env))) {
 flags = FIELD_DP32(flags, TBFLAG_A64, BTYPE, env->btype);
 }
@@ -11179,8 +11197,6 @@ void cpu_get_tb_cpu_state(CPUARMState *env, 
target_ulong *pc,
 *pc = env->regs[15];
 
 if (arm_feature(env, ARM_FEATURE_M)) {
-flags = rebuild_hflags_m32(env, fp_el, mmu_idx);
-
 if (arm_feature(env, ARM_FEATURE_M_SECURITY) &&
 FIELD_EX32(env->v7m.fpccr[M_REG_S], V7M_FPCCR, S)
 != env->v7m.secure) {
@@ -11204,8 +11220,6 @@ void cpu_get_tb_cpu_state(CPUARMState *env, 
target_ulong *pc,
 flags = FIELD_DP32(flags, TBFLAG_A32, LSPACT, 1);
 }
 } else {
-flags = rebuild_hflags_a32(env, fp_el, mmu_idx);
-
 /*
  * Note that XSCALE_CPAR shares bits with VECSTRIDE.
  * Note that VECLEN+VECSTRIDE are RES0 for M-profile.
-- 
2.17.1

[Qemu-devel] [PATCH v5 17/17] target/arm: Rely on hflags correct in cpu_get_tb_cpu_state

[Richard Henderson]

This is the payoff.

>From perf record -g data of ubuntu 18 boot and shutdown:

BEFORE:

-   23.02% 2.82%  qemu-system-aar  [.] helper_lookup_tb_ptr
   - 20.22% helper_lookup_tb_ptr
  + 10.05% tb_htable_lookup
  - 9.13% cpu_get_tb_cpu_state
   3.20% aa64_va_parameters_both
   0.55% fp_exception_el

-   11.66% 4.74%  qemu-system-aar  [.] cpu_get_tb_cpu_state
   - 6.96% cpu_get_tb_cpu_state
3.63% aa64_va_parameters_both
0.60% fp_exception_el
0.53% sve_exception_el

AFTER:

-   16.40% 3.40%  qemu-system-aar  [.] helper_lookup_tb_ptr
   - 13.03% helper_lookup_tb_ptr
  + 11.19% tb_htable_lookup
0.55% cpu_get_tb_cpu_state

 0.98% 0.71%  qemu-system-aar  [.] cpu_get_tb_cpu_state

 0.87% 0.24%  qemu-system-aar  [.] rebuild_hflags_a64

Before, helper_lookup_tb_ptr is the second hottest function in the
application, consuming almost a quarter of the runtime.  Within the
entire execution, cpu_get_tb_cpu_state consumes about 12%.

After, helper_lookup_tb_ptr has dropped to the fourth hottest function,
with consumption dropping to a sixth of the runtime.  Within the
entire execution, cpu_get_tb_cpu_state has dropped below 1%, and the
supporting function to rebuild hflags also consumes about 1%.

Assertions are retained for --enable-debug-tcg.

Tested-by: Alex Bennée 
Reviewed-by: Alex Bennée 
Signed-off-by: Richard Henderson 
---
v2: Retain asserts for future debugging.
---
 target/arm/helper.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index d1bf71a260..5e4f996882 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -11211,12 +11211,15 @@ void HELPER(rebuild_hflags_a64)(CPUARMState *env, int 
el)
 void cpu_get_tb_cpu_state(CPUARMState *env, target_ulong *pc,
   target_ulong *cs_base, uint32_t *pflags)
 {
-uint32_t flags, pstate_for_ss;
+uint32_t flags = env->hflags;
+uint32_t pstate_for_ss;
 
 *cs_base = 0;
-flags = rebuild_hflags_internal(env);
+#ifdef CONFIG_TCG_DEBUG
+assert(flags == rebuild_hflags_internal(env));
+#endif
 
-if (is_a64(env)) {
+if (FIELD_EX32(flags, TBFLAG_ANY, AARCH64_STATE)) {
 *pc = env->pc;
 if (cpu_isar_feature(aa64_bti, env_archcpu(env))) {
 flags = FIELD_DP32(flags, TBFLAG_A64, BTYPE, env->btype);
-- 
2.17.1

[Qemu-devel] [PATCH v5 08/17] target/arm: Split out rebuild_hflags_aprofile

[Richard Henderson]

Create a function to compute the values of the TBFLAG_ANY bits
that will be cached, and are used by A-profile.

Signed-off-by: Richard Henderson 
---
 target/arm/helper.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index 0fea62dc12..fc071f95db 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -11068,18 +11068,28 @@ static uint32_t rebuild_hflags_m32(CPUARMState *env, 
int fp_el,
 return rebuild_hflags_common_32(env, fp_el, mmu_idx, flags);
 }
 
+static uint32_t rebuild_hflags_aprofile(CPUARMState *env)
+{
+int flags = 0;
+
+flags = FIELD_DP32(flags, TBFLAG_ANY, DEBUG_TARGET_EL,
+   arm_debug_target_el(env));
+return flags;
+}
+
 static uint32_t rebuild_hflags_a32(CPUARMState *env, int fp_el,
ARMMMUIdx mmu_idx)
 {
-return rebuild_hflags_common_32(env, fp_el, mmu_idx, 0);
+uint32_t flags = rebuild_hflags_aprofile(env);
+return rebuild_hflags_common_32(env, fp_el, mmu_idx, flags);
 }
 
 static uint32_t rebuild_hflags_a64(CPUARMState *env, int el, int fp_el,
ARMMMUIdx mmu_idx)
 {
+uint32_t flags = rebuild_hflags_aprofile(env);
 ARMMMUIdx stage1 = stage_1_mmu_idx(mmu_idx);
 ARMVAParameters p0 = aa64_va_parameters_both(env, 0, stage1);
-uint32_t flags = 0;
 uint64_t sctlr;
 int tbii, tbid;
 
@@ -11224,12 +11234,6 @@ void cpu_get_tb_cpu_state(CPUARMState *env, 
target_ulong *pc,
 }
 }
 
-if (!arm_feature(env, ARM_FEATURE_M)) {
-int target_el = arm_debug_target_el(env);
-
-flags = FIELD_DP32(flags, TBFLAG_ANY, DEBUG_TARGET_EL, target_el);
-}
-
 *pflags = flags;
 *cs_base = 0;
 }
-- 
2.17.1

[Qemu-devel] [PATCH v5 14/17] target/arm: Hoist store to cs_base in cpu_get_tb_cpu_state

[Richard Henderson]

By performing this store early, we avoid having to save and restore
the register holding the address around any function calls.

Signed-off-by: Richard Henderson 
---
 target/arm/helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index 19bdb9b9d6..7a94495788 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -11187,6 +11187,7 @@ void cpu_get_tb_cpu_state(CPUARMState *env, 
target_ulong *pc,
 {
 uint32_t flags, pstate_for_ss;
 
+*cs_base = 0;
 flags = rebuild_hflags_internal(env);
 
 if (is_a64(env)) {
@@ -11260,7 +11261,6 @@ void cpu_get_tb_cpu_state(CPUARMState *env, 
target_ulong *pc,
 }
 
 *pflags = flags;
-*cs_base = 0;
 }
 
 #ifdef TARGET_AARCH64
-- 
2.17.1

[Qemu-devel] [PATCH v5 13/17] target/arm: Split out arm_mmu_idx_el

[Richard Henderson]

Avoid calling arm_current_el() twice.

Signed-off-by: Richard Henderson 
---
 target/arm/internals.h |  9 +
 target/arm/helper.c| 12 +++-
 2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/target/arm/internals.h b/target/arm/internals.h
index 232d963875..f5313dd3d4 100644
--- a/target/arm/internals.h
+++ b/target/arm/internals.h
@@ -949,6 +949,15 @@ void arm_cpu_update_virq(ARMCPU *cpu);
  */
 void arm_cpu_update_vfiq(ARMCPU *cpu);
 
+/**
+ * arm_mmu_idx_el:
+ * @env: The cpu environment
+ * @el: The EL to use.
+ *
+ * Return the full ARMMMUIdx for the translation regime for EL.
+ */
+ARMMMUIdx arm_mmu_idx_el(CPUARMState *env, int el);
+
 /**
  * arm_mmu_idx:
  * @env: The cpu environment
diff --git a/target/arm/helper.c b/target/arm/helper.c
index 83ae33dae5..19bdb9b9d6 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -10988,15 +10988,12 @@ ARMMMUIdx arm_v7m_mmu_idx_for_secstate(CPUARMState 
*env, bool secstate)
 }
 #endif
 
-ARMMMUIdx arm_mmu_idx(CPUARMState *env)
+ARMMMUIdx arm_mmu_idx_el(CPUARMState *env, int el)
 {
-int el;
-
 if (arm_feature(env, ARM_FEATURE_M)) {
 return arm_v7m_mmu_idx_for_secstate(env, env->v7m.secure);
 }
 
-el = arm_current_el(env);
 if (el < 2 && arm_is_secure_below_el3(env)) {
 return ARMMMUIdx_S1SE0 + el;
 } else {
@@ -11004,6 +11001,11 @@ ARMMMUIdx arm_mmu_idx(CPUARMState *env)
 }
 }
 
+ARMMMUIdx arm_mmu_idx(CPUARMState *env)
+{
+return arm_mmu_idx_el(env, arm_current_el(env));
+}
+
 int cpu_mmu_index(CPUARMState *env, bool ifetch)
 {
 return arm_to_core_mmu_idx(arm_mmu_idx(env));
@@ -11164,7 +11166,7 @@ static uint32_t rebuild_hflags_internal(CPUARMState 
*env)
 {
 int el = arm_current_el(env);
 int fp_el = fp_exception_el(env, el);
-ARMMMUIdx mmu_idx = arm_mmu_idx(env);
+ARMMMUIdx mmu_idx = arm_mmu_idx_el(env, el);
 
 if (is_a64(env)) {
 return rebuild_hflags_a64(env, el, fp_el, mmu_idx);
-- 
2.17.1

[Qemu-devel] [PATCH v5 11/17] target/arm: Hoist computation of TBFLAG_A32.VFPEN

[Richard Henderson]

There are 3 conditions that each enable this flag.  M-profile always
enables; A-profile with EL1 as AA64 always enables.  Both of these
conditions can easily be cached.  The final condition relies on the
FPEXC register which we are not prepared to cache.

Signed-off-by: Richard Henderson 
---
 target/arm/cpu.h|  2 +-
 target/arm/helper.c | 14 ++
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 5dec4d3b3a..9606222942 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -3188,7 +3188,7 @@ FIELD(TBFLAG_A32, XSCALE_CPAR, 4, 2)
  * the same thing as the current security state of the processor!
  */
 FIELD(TBFLAG_A32, NS, 6, 1)
-FIELD(TBFLAG_A32, VFPEN, 7, 1)  /* Not cached. */
+FIELD(TBFLAG_A32, VFPEN, 7, 1)  /* Partially cached, minus FPEXC. */
 FIELD(TBFLAG_A32, CONDEXEC, 8, 8)   /* Not cached. */
 FIELD(TBFLAG_A32, SCTLR_B, 16, 1)
 /* For M profile only, set if FPCCR.LSPACT is set */
diff --git a/target/arm/helper.c b/target/arm/helper.c
index c01b3027e0..b905d61898 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -11050,6 +11050,9 @@ static uint32_t rebuild_hflags_m32(CPUARMState *env, 
int fp_el,
 {
 uint32_t flags = 0;
 
+/* v8M always enables the fpu.  */
+flags = FIELD_DP32(flags, TBFLAG_A32, VFPEN, 1);
+
 if (arm_v7m_is_handler_mode(env)) {
 flags = FIELD_DP32(flags, TBFLAG_A32, HANDLER, 1);
 }
@@ -11081,6 +11084,10 @@ static uint32_t rebuild_hflags_a32(CPUARMState *env, 
int fp_el,
ARMMMUIdx mmu_idx)
 {
 uint32_t flags = rebuild_hflags_aprofile(env);
+
+if (arm_el_is_aa64(env, 1)) {
+flags = FIELD_DP32(flags, TBFLAG_A32, VFPEN, 1);
+}
 return rebuild_hflags_common_32(env, fp_el, mmu_idx, flags);
 }
 
@@ -11212,14 +11219,13 @@ void cpu_get_tb_cpu_state(CPUARMState *env, 
target_ulong *pc,
 flags = FIELD_DP32(flags, TBFLAG_A32, VECSTRIDE,
env->vfp.vec_stride);
 }
+if (env->vfp.xregs[ARM_VFP_FPEXC] & (1 << 30)) {
+flags = FIELD_DP32(flags, TBFLAG_A32, VFPEN, 1);
+}
 }
 
 flags = FIELD_DP32(flags, TBFLAG_A32, THUMB, env->thumb);
 flags = FIELD_DP32(flags, TBFLAG_A32, CONDEXEC, env->condexec_bits);
-if (env->vfp.xregs[ARM_VFP_FPEXC] & (1 << 30)
-|| arm_el_is_aa64(env, 1) || arm_feature(env, ARM_FEATURE_M)) {
-flags = FIELD_DP32(flags, TBFLAG_A32, VFPEN, 1);
-}
 pstate_for_ss = env->uncached_cpsr;
 }
 
-- 
2.17.1

[Qemu-devel] [PATCH v5 03/17] target/arm: Split out rebuild_hflags_common_32

[Richard Henderson]

Create a function to compute the values of the TBFLAG_A32 bits
that will be cached, and are used by all profiles.

Signed-off-by: Richard Henderson 
---
 target/arm/helper.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index 02cb43cf58..1844c13a19 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -11032,6 +11032,15 @@ static uint32_t rebuild_hflags_common(CPUARMState 
*env, int fp_el,
 return flags;
 }
 
+static uint32_t rebuild_hflags_common_32(CPUARMState *env, int fp_el,
+ ARMMMUIdx mmu_idx, uint32_t flags)
+{
+flags = FIELD_DP32(flags, TBFLAG_A32, SCTLR_B, arm_sctlr_b(env));
+flags = FIELD_DP32(flags, TBFLAG_A32, NS, !access_secure_reg(env));
+
+return rebuild_hflags_common(env, fp_el, mmu_idx, flags);
+}
+
 static uint32_t rebuild_hflags_a64(CPUARMState *env, int el, int fp_el,
ARMMMUIdx mmu_idx)
 {
@@ -11103,7 +2,7 @@ void cpu_get_tb_cpu_state(CPUARMState *env, 
target_ulong *pc,
 ARMMMUIdx mmu_idx = arm_mmu_idx(env);
 int current_el = arm_current_el(env);
 int fp_el = fp_exception_el(env, current_el);
-uint32_t flags = 0;
+uint32_t flags;
 
 if (is_a64(env)) {
 *pc = env->pc;
@@ -3,12 +11122,11 @@ void cpu_get_tb_cpu_state(CPUARMState *env, 
target_ulong *pc,
 }
 } else {
 *pc = env->regs[15];
+flags = rebuild_hflags_common_32(env, fp_el, mmu_idx, 0);
 flags = FIELD_DP32(flags, TBFLAG_A32, THUMB, env->thumb);
 flags = FIELD_DP32(flags, TBFLAG_A32, VECLEN, env->vfp.vec_len);
 flags = FIELD_DP32(flags, TBFLAG_A32, VECSTRIDE, env->vfp.vec_stride);
 flags = FIELD_DP32(flags, TBFLAG_A32, CONDEXEC, env->condexec_bits);
-flags = FIELD_DP32(flags, TBFLAG_A32, SCTLR_B, arm_sctlr_b(env));
-flags = FIELD_DP32(flags, TBFLAG_A32, NS, !access_secure_reg(env));
 if (env->vfp.xregs[ARM_VFP_FPEXC] & (1 << 30)
 || arm_el_is_aa64(env, 1) || arm_feature(env, ARM_FEATURE_M)) {
 flags = FIELD_DP32(flags, TBFLAG_A32, VFPEN, 1);
@@ -11128,8 +11136,6 @@ void cpu_get_tb_cpu_state(CPUARMState *env, 
target_ulong *pc,
 flags = FIELD_DP32(flags, TBFLAG_A32,
XSCALE_CPAR, env->cp15.c15_cpar);
 }
-
-flags = rebuild_hflags_common(env, fp_el, mmu_idx, flags);
 }
 
 /* The SS_ACTIVE and PSTATE_SS bits correspond to the state machine
-- 
2.17.1

[Qemu-devel] [PATCH v5 16/17] target/arm: Rebuild hflags at EL changes and MSR writes

[Richard Henderson]

Now setting, but not relying upon, env->hflags.

Signed-off-by: Richard Henderson 
---
 linux-user/syscall.c   |  1 +
 target/arm/cpu.c   |  1 +
 target/arm/helper-a64.c|  3 +++
 target/arm/helper.c|  2 ++
 target/arm/machine.c   |  1 +
 target/arm/op_helper.c |  1 +
 target/arm/translate-a64.c |  6 +-
 target/arm/translate.c | 18 --
 8 files changed, 30 insertions(+), 3 deletions(-)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 8b41a03901..be01c33759 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -9980,6 +9980,7 @@ static abi_long do_syscall1(void *cpu_env, int num, 
abi_long arg1,
 aarch64_sve_narrow_vq(env, vq);
 }
 env->vfp.zcr_el[1] = vq - 1;
+arm_rebuild_hflags(env);
 ret = vq * 16;
 }
 return ret;
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 2399c14471..d043e75166 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -406,6 +406,7 @@ static void arm_cpu_reset(CPUState *s)
 
 hw_breakpoint_update_all(cpu);
 hw_watchpoint_update_all(cpu);
+arm_rebuild_hflags(env);
 }
 
 bool arm_cpu_exec_interrupt(CPUState *cs, int interrupt_request)
diff --git a/target/arm/helper-a64.c b/target/arm/helper-a64.c
index bca80bdc38..b4cd680fc4 100644
--- a/target/arm/helper-a64.c
+++ b/target/arm/helper-a64.c
@@ -1025,6 +1025,7 @@ void HELPER(exception_return)(CPUARMState *env, uint64_t 
new_pc)
 } else {
 env->regs[15] = new_pc & ~0x3;
 }
+helper_rebuild_hflags_a32(env, new_el);
 qemu_log_mask(CPU_LOG_INT, "Exception return from AArch64 EL%d to "
   "AArch32 EL%d PC 0x%" PRIx32 "\n",
   cur_el, new_el, env->regs[15]);
@@ -1036,10 +1037,12 @@ void HELPER(exception_return)(CPUARMState *env, 
uint64_t new_pc)
 }
 aarch64_restore_sp(env, new_el);
 env->pc = new_pc;
+helper_rebuild_hflags_a64(env, new_el);
 qemu_log_mask(CPU_LOG_INT, "Exception return from AArch64 EL%d to "
   "AArch64 EL%d PC 0x%" PRIx64 "\n",
   cur_el, new_el, env->pc);
 }
+
 /*
  * Note that cur_el can never be 0.  If new_el is 0, then
  * el0_a64 is return_to_aa64, else el0_a64 is ignored.
diff --git a/target/arm/helper.c b/target/arm/helper.c
index 53a7bd796b..d1bf71a260 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -7908,6 +7908,7 @@ static void take_aarch32_exception(CPUARMState *env, int 
new_mode,
 env->regs[14] = env->regs[15] + offset;
 }
 env->regs[15] = newpc;
+arm_rebuild_hflags(env);
 }
 
 static void arm_cpu_do_interrupt_aarch32_hyp(CPUState *cs)
@@ -8255,6 +8256,7 @@ static void arm_cpu_do_interrupt_aarch64(CPUState *cs)
 pstate_write(env, PSTATE_DAIF | new_mode);
 env->aarch64 = 1;
 aarch64_restore_sp(env, new_el);
+helper_rebuild_hflags_a64(env, new_el);
 
 env->pc = addr;
 
diff --git a/target/arm/machine.c b/target/arm/machine.c
index 5c36707a7c..eb28b2381b 100644
--- a/target/arm/machine.c
+++ b/target/arm/machine.c
@@ -756,6 +756,7 @@ static int cpu_post_load(void *opaque, int version_id)
 if (!kvm_enabled()) {
 pmu_op_finish(&cpu->env);
 }
+arm_rebuild_hflags(&cpu->env);
 
 return 0;
 }
diff --git a/target/arm/op_helper.c b/target/arm/op_helper.c
index 0fd4bd0238..ccc2cecb46 100644
--- a/target/arm/op_helper.c
+++ b/target/arm/op_helper.c
@@ -404,6 +404,7 @@ void HELPER(cpsr_write_eret)(CPUARMState *env, uint32_t val)
  * state. Do the masking now.
  */
 env->regs[15] &= (env->thumb ? ~1 : ~3);
+arm_rebuild_hflags(env);
 
 qemu_mutex_lock_iothread();
 arm_call_el_change_hook(env_archcpu(env));
diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index fc3e5f5c38..4412c60383 100644
--- a/target/arm/translate-a64.c
+++ b/target/arm/translate-a64.c
@@ -1777,11 +1777,15 @@ static void handle_sys(DisasContext *s, uint32_t insn, 
bool isread,
 /* I/O operations must end the TB here (whether read or write) */
 gen_io_end();
 s->base.is_jmp = DISAS_UPDATE;
-} else if (!isread && !(ri->type & ARM_CP_SUPPRESS_TB_END)) {
+}
+if (!isread && !(ri->type & ARM_CP_SUPPRESS_TB_END)) {
 /* We default to ending the TB on a coprocessor register write,
  * but allow this to be suppressed by the register definition
  * (usually only necessary to work around guest bugs).
  */
+TCGv_i32 tcg_el = tcg_const_i32(s->current_el);
+gen_helper_rebuild_hflags_a64(cpu_env, tcg_el);
+tcg_temp_free_i32(tcg_el);
 s->base.is_jmp = DISAS_UPDATE;
 }
 }
diff --git a/target/arm/translate.c b/target/arm/translate.c
index d948757131..2f7beca065 100644
--- a/target/arm/translate.c
+++ b/target/arm/translate.c
@@ -7130,6 +7130,8 @@ static int disas_coproc_insn(Di

[Qemu-devel] [PATCH v5 15/17] target/arm: Add HELPER(rebuild_hflags_{a32, a64, m32})

[Richard Henderson]

This functions are given the mode and el state of the cpu
and writes the computed value to env->hflags.

Signed-off-by: Richard Henderson 
---
 target/arm/helper.h |  4 
 target/arm/helper.c | 24 
 2 files changed, 28 insertions(+)

diff --git a/target/arm/helper.h b/target/arm/helper.h
index 1fb2cb5a77..3d4ec267a2 100644
--- a/target/arm/helper.h
+++ b/target/arm/helper.h
@@ -90,6 +90,10 @@ DEF_HELPER_4(msr_banked, void, env, i32, i32, i32)
 DEF_HELPER_2(get_user_reg, i32, env, i32)
 DEF_HELPER_3(set_user_reg, void, env, i32, i32)
 
+DEF_HELPER_FLAGS_2(rebuild_hflags_m32, TCG_CALL_NO_RWG, void, env, int)
+DEF_HELPER_FLAGS_2(rebuild_hflags_a32, TCG_CALL_NO_RWG, void, env, int)
+DEF_HELPER_FLAGS_2(rebuild_hflags_a64, TCG_CALL_NO_RWG, void, env, int)
+
 DEF_HELPER_1(vfp_get_fpscr, i32, env)
 DEF_HELPER_2(vfp_set_fpscr, void, env, i32)
 
diff --git a/target/arm/helper.c b/target/arm/helper.c
index 7a94495788..53a7bd796b 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -11182,6 +11182,30 @@ void arm_rebuild_hflags(CPUARMState *env)
 env->hflags = rebuild_hflags_internal(env);
 }
 
+void HELPER(rebuild_hflags_m32)(CPUARMState *env, int el)
+{
+int fp_el = fp_exception_el(env, el);
+ARMMMUIdx mmu_idx = arm_mmu_idx_el(env, el);
+
+env->hflags = rebuild_hflags_m32(env, fp_el, mmu_idx);
+}
+
+void HELPER(rebuild_hflags_a32)(CPUARMState *env, int el)
+{
+int fp_el = fp_exception_el(env, el);
+ARMMMUIdx mmu_idx = arm_mmu_idx_el(env, el);
+
+env->hflags = rebuild_hflags_a32(env, fp_el, mmu_idx);
+}
+
+void HELPER(rebuild_hflags_a64)(CPUARMState *env, int el)
+{
+int fp_el = fp_exception_el(env, el);
+ARMMMUIdx mmu_idx = arm_mmu_idx_el(env, el);
+
+env->hflags = rebuild_hflags_a64(env, el, fp_el, mmu_idx);
+}
+
 void cpu_get_tb_cpu_state(CPUARMState *env, target_ulong *pc,
   target_ulong *cs_base, uint32_t *pflags)
 {
-- 
2.17.1

[Qemu-devel] [PATCH v5 09/17] target/arm: Hoist XSCALE_CPAR, VECLEN, VECSTRIDE in cpu_get_tb_cpu_state

[Richard Henderson]

We do not need to compute any of these values for M-profile.
Further, XSCALE_CPAR overlaps VECSTRIDE so obviously the two
sets must be mutually exclusive.

Signed-off-by: Richard Henderson 
---
 target/arm/helper.c | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index fc071f95db..3889b9295a 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -11197,21 +11197,28 @@ void cpu_get_tb_cpu_state(CPUARMState *env, 
target_ulong *pc,
 }
 } else {
 flags = rebuild_hflags_a32(env, fp_el, mmu_idx);
+
+/*
+ * Note that XSCALE_CPAR shares bits with VECSTRIDE.
+ * Note that VECLEN+VECSTRIDE are RES0 for M-profile.
+ */
+if (arm_feature(env, ARM_FEATURE_XSCALE)) {
+flags = FIELD_DP32(flags, TBFLAG_A32,
+   XSCALE_CPAR, env->cp15.c15_cpar);
+} else {
+flags = FIELD_DP32(flags, TBFLAG_A32, VECLEN,
+   env->vfp.vec_len);
+flags = FIELD_DP32(flags, TBFLAG_A32, VECSTRIDE,
+   env->vfp.vec_stride);
+}
 }
 
 flags = FIELD_DP32(flags, TBFLAG_A32, THUMB, env->thumb);
-flags = FIELD_DP32(flags, TBFLAG_A32, VECLEN, env->vfp.vec_len);
-flags = FIELD_DP32(flags, TBFLAG_A32, VECSTRIDE, env->vfp.vec_stride);
 flags = FIELD_DP32(flags, TBFLAG_A32, CONDEXEC, env->condexec_bits);
 if (env->vfp.xregs[ARM_VFP_FPEXC] & (1 << 30)
 || arm_el_is_aa64(env, 1) || arm_feature(env, ARM_FEATURE_M)) {
 flags = FIELD_DP32(flags, TBFLAG_A32, VFPEN, 1);
 }
-/* Note that XSCALE_CPAR shares bits with VECSTRIDE */
-if (arm_feature(env, ARM_FEATURE_XSCALE)) {
-flags = FIELD_DP32(flags, TBFLAG_A32,
-   XSCALE_CPAR, env->cp15.c15_cpar);
-}
 }
 
 /* The SS_ACTIVE and PSTATE_SS bits correspond to the state machine
-- 
2.17.1

[Qemu-devel] [PATCH v5 02/17] target/arm: Split out rebuild_hflags_a64

[Richard Henderson]

Create a function to compute the values of the TBFLAG_A64 bits
that will be cached.  For now, the env->hflags variable is not
used, and the results are fed back to cpu_get_tb_cpu_state.

Signed-off-by: Richard Henderson 
---
 target/arm/helper.c | 131 +++-
 1 file changed, 69 insertions(+), 62 deletions(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index f2c6419369..02cb43cf58 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -11032,6 +11032,71 @@ static uint32_t rebuild_hflags_common(CPUARMState 
*env, int fp_el,
 return flags;
 }
 
+static uint32_t rebuild_hflags_a64(CPUARMState *env, int el, int fp_el,
+   ARMMMUIdx mmu_idx)
+{
+ARMMMUIdx stage1 = stage_1_mmu_idx(mmu_idx);
+ARMVAParameters p0 = aa64_va_parameters_both(env, 0, stage1);
+uint32_t flags = 0;
+uint64_t sctlr;
+int tbii, tbid;
+
+flags = FIELD_DP32(flags, TBFLAG_ANY, AARCH64_STATE, 1);
+
+/* FIXME: ARMv8.1-VHE S2 translation regime.  */
+if (regime_el(env, stage1) < 2) {
+ARMVAParameters p1 = aa64_va_parameters_both(env, -1, stage1);
+tbid = (p1.tbi << 1) | p0.tbi;
+tbii = tbid & ~((p1.tbid << 1) | p0.tbid);
+} else {
+tbid = p0.tbi;
+tbii = tbid & !p0.tbid;
+}
+
+flags = FIELD_DP32(flags, TBFLAG_A64, TBII, tbii);
+flags = FIELD_DP32(flags, TBFLAG_A64, TBID, tbid);
+
+if (cpu_isar_feature(aa64_sve, env_archcpu(env))) {
+int sve_el = sve_exception_el(env, el);
+uint32_t zcr_len;
+
+/*
+ * If SVE is disabled, but FP is enabled,
+ * then the effective len is 0.
+ */
+if (sve_el != 0 && fp_el == 0) {
+zcr_len = 0;
+} else {
+zcr_len = sve_zcr_len_for_el(env, el);
+}
+flags = FIELD_DP32(flags, TBFLAG_A64, SVEEXC_EL, sve_el);
+flags = FIELD_DP32(flags, TBFLAG_A64, ZCR_LEN, zcr_len);
+}
+
+sctlr = arm_sctlr(env, el);
+
+if (cpu_isar_feature(aa64_pauth, env_archcpu(env))) {
+/*
+ * In order to save space in flags, we record only whether
+ * pauth is "inactive", meaning all insns are implemented as
+ * a nop, or "active" when some action must be performed.
+ * The decision of which action to take is left to a helper.
+ */
+if (sctlr & (SCTLR_EnIA | SCTLR_EnIB | SCTLR_EnDA | SCTLR_EnDB)) {
+flags = FIELD_DP32(flags, TBFLAG_A64, PAUTH_ACTIVE, 1);
+}
+}
+
+if (cpu_isar_feature(aa64_bti, env_archcpu(env))) {
+/* Note that SCTLR_EL[23].BT == SCTLR_BT1.  */
+if (sctlr & (el == 0 ? SCTLR_BT0 : SCTLR_BT1)) {
+flags = FIELD_DP32(flags, TBFLAG_A64, BT, 1);
+}
+}
+
+return rebuild_hflags_common(env, fp_el, mmu_idx, flags);
+}
+
 void cpu_get_tb_cpu_state(CPUARMState *env, target_ulong *pc,
   target_ulong *cs_base, uint32_t *pflags)
 {
@@ -11041,67 +11106,9 @@ void cpu_get_tb_cpu_state(CPUARMState *env, 
target_ulong *pc,
 uint32_t flags = 0;
 
 if (is_a64(env)) {
-ARMCPU *cpu = env_archcpu(env);
-uint64_t sctlr;
-
 *pc = env->pc;
-flags = FIELD_DP32(flags, TBFLAG_ANY, AARCH64_STATE, 1);
-
-/* Get control bits for tagged addresses.  */
-{
-ARMMMUIdx stage1 = stage_1_mmu_idx(mmu_idx);
-ARMVAParameters p0 = aa64_va_parameters_both(env, 0, stage1);
-int tbii, tbid;
-
-/* FIXME: ARMv8.1-VHE S2 translation regime.  */
-if (regime_el(env, stage1) < 2) {
-ARMVAParameters p1 = aa64_va_parameters_both(env, -1, stage1);
-tbid = (p1.tbi << 1) | p0.tbi;
-tbii = tbid & ~((p1.tbid << 1) | p0.tbid);
-} else {
-tbid = p0.tbi;
-tbii = tbid & !p0.tbid;
-}
-
-flags = FIELD_DP32(flags, TBFLAG_A64, TBII, tbii);
-flags = FIELD_DP32(flags, TBFLAG_A64, TBID, tbid);
-}
-
-if (cpu_isar_feature(aa64_sve, cpu)) {
-int sve_el = sve_exception_el(env, current_el);
-uint32_t zcr_len;
-
-/* If SVE is disabled, but FP is enabled,
- * then the effective len is 0.
- */
-if (sve_el != 0 && fp_el == 0) {
-zcr_len = 0;
-} else {
-zcr_len = sve_zcr_len_for_el(env, current_el);
-}
-flags = FIELD_DP32(flags, TBFLAG_A64, SVEEXC_EL, sve_el);
-flags = FIELD_DP32(flags, TBFLAG_A64, ZCR_LEN, zcr_len);
-}
-
-sctlr = arm_sctlr(env, current_el);
-
-if (cpu_isar_feature(aa64_pauth, cpu)) {
-/*
- * In order to save space in flags, we record only whether
- * pauth is "inactive", meaning all insns are implemented as
- * a nop, or "active" when some action must be performed.
-

[Qemu-devel] [PATCH v5 10/17] target/arm: Simplify set of PSTATE_SS in cpu_get_tb_cpu_state

[Richard Henderson]

Hoist the variable load for PSTATE into the existing test vs is_a64.

Signed-off-by: Richard Henderson 
---
 target/arm/helper.c | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index 3889b9295a..c01b3027e0 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -11159,7 +11159,7 @@ void cpu_get_tb_cpu_state(CPUARMState *env, 
target_ulong *pc,
 ARMMMUIdx mmu_idx = arm_mmu_idx(env);
 int current_el = arm_current_el(env);
 int fp_el = fp_exception_el(env, current_el);
-uint32_t flags;
+uint32_t flags, pstate_for_ss;
 
 if (is_a64(env)) {
 *pc = env->pc;
@@ -11167,6 +11167,7 @@ void cpu_get_tb_cpu_state(CPUARMState *env, 
target_ulong *pc,
 if (cpu_isar_feature(aa64_bti, env_archcpu(env))) {
 flags = FIELD_DP32(flags, TBFLAG_A64, BTYPE, env->btype);
 }
+pstate_for_ss = env->pstate;
 } else {
 *pc = env->regs[15];
 
@@ -11219,9 +11220,11 @@ void cpu_get_tb_cpu_state(CPUARMState *env, 
target_ulong *pc,
 || arm_el_is_aa64(env, 1) || arm_feature(env, ARM_FEATURE_M)) {
 flags = FIELD_DP32(flags, TBFLAG_A32, VFPEN, 1);
 }
+pstate_for_ss = env->uncached_cpsr;
 }
 
-/* The SS_ACTIVE and PSTATE_SS bits correspond to the state machine
+/*
+ * The SS_ACTIVE and PSTATE_SS bits correspond to the state machine
  * states defined in the ARM ARM for software singlestep:
  *  SS_ACTIVE   PSTATE.SS   State
  * 0x   Inactive (the TB flag for SS is always 0)
@@ -11229,16 +11232,9 @@ void cpu_get_tb_cpu_state(CPUARMState *env, 
target_ulong *pc,
  * 11   Active-not-pending
  * SS_ACTIVE is set in hflags; PSTATE_SS is computed every TB.
  */
-if (FIELD_EX32(flags, TBFLAG_ANY, SS_ACTIVE)) {
-if (is_a64(env)) {
-if (env->pstate & PSTATE_SS) {
-flags = FIELD_DP32(flags, TBFLAG_ANY, PSTATE_SS, 1);
-}
-} else {
-if (env->uncached_cpsr & PSTATE_SS) {
-flags = FIELD_DP32(flags, TBFLAG_ANY, PSTATE_SS, 1);
-}
-}
+if (FIELD_EX32(flags, TBFLAG_ANY, SS_ACTIVE) &&
+(pstate_for_ss & PSTATE_SS)) {
+flags = FIELD_DP32(flags, TBFLAG_ANY, PSTATE_SS, 1);
 }
 
 *pflags = flags;
-- 
2.17.1

[Qemu-devel] [PATCH v5 05/17] target/arm: Split out rebuild_hflags_m32

[Richard Henderson]

Create a function to compute the values of the TBFLAG_A32 bits
that will be cached, and are used by M-profile.

Signed-off-by: Richard Henderson 
---
 target/arm/helper.c | 45 ++---
 1 file changed, 30 insertions(+), 15 deletions(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index 6570d7e195..c36ec6c530 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -11045,6 +11045,29 @@ static uint32_t rebuild_hflags_common_32(CPUARMState 
*env, int fp_el,
 return rebuild_hflags_common(env, fp_el, mmu_idx, flags);
 }
 
+static uint32_t rebuild_hflags_m32(CPUARMState *env, int fp_el,
+   ARMMMUIdx mmu_idx)
+{
+uint32_t flags = 0;
+
+if (arm_v7m_is_handler_mode(env)) {
+flags = FIELD_DP32(flags, TBFLAG_A32, HANDLER, 1);
+}
+
+/*
+ * v8M always applies stack limit checks unless CCR.STKOFHFNMIGN
+ * is suppressing them because the requested execution priority
+ * is less than 0.
+ */
+if (arm_feature(env, ARM_FEATURE_V8) &&
+!((mmu_idx & ARM_MMU_IDX_M_NEGPRI) &&
+  (env->v7m.ccr[env->v7m.secure] & R_V7M_CCR_STKOFHFNMIGN_MASK))) {
+flags = FIELD_DP32(flags, TBFLAG_A32, STACKCHECK, 1);
+}
+
+return rebuild_hflags_common_32(env, fp_el, mmu_idx, flags);
+}
+
 static uint32_t rebuild_hflags_a64(CPUARMState *env, int el, int fp_el,
ARMMMUIdx mmu_idx)
 {
@@ -11130,7 +11153,13 @@ void cpu_get_tb_cpu_state(CPUARMState *env, 
target_ulong *pc,
 }
 } else {
 *pc = env->regs[15];
-flags = rebuild_hflags_common_32(env, fp_el, mmu_idx, 0);
+
+if (arm_feature(env, ARM_FEATURE_M)) {
+flags = rebuild_hflags_m32(env, fp_el, mmu_idx);
+} else {
+flags = rebuild_hflags_common_32(env, fp_el, mmu_idx, 0);
+}
+
 flags = FIELD_DP32(flags, TBFLAG_A32, THUMB, env->thumb);
 flags = FIELD_DP32(flags, TBFLAG_A32, VECLEN, env->vfp.vec_len);
 flags = FIELD_DP32(flags, TBFLAG_A32, VECSTRIDE, env->vfp.vec_stride);
@@ -11166,20 +11195,6 @@ void cpu_get_tb_cpu_state(CPUARMState *env, 
target_ulong *pc,
 }
 }
 
-if (arm_v7m_is_handler_mode(env)) {
-flags = FIELD_DP32(flags, TBFLAG_A32, HANDLER, 1);
-}
-
-/* v8M always applies stack limit checks unless CCR.STKOFHFNMIGN is
- * suppressing them because the requested execution priority is less than 
0.
- */
-if (arm_feature(env, ARM_FEATURE_V8) &&
-arm_feature(env, ARM_FEATURE_M) &&
-!((mmu_idx  & ARM_MMU_IDX_M_NEGPRI) &&
-  (env->v7m.ccr[env->v7m.secure] & R_V7M_CCR_STKOFHFNMIGN_MASK))) {
-flags = FIELD_DP32(flags, TBFLAG_A32, STACKCHECK, 1);
-}
-
 if (arm_feature(env, ARM_FEATURE_M_SECURITY) &&
 FIELD_EX32(env->v7m.fpccr[M_REG_S], V7M_FPCCR, S) != env->v7m.secure) {
 flags = FIELD_DP32(flags, TBFLAG_A32, FPCCR_S_WRONG, 1);
-- 
2.17.1

[Qemu-devel] [PATCH v5 07/17] target/arm: Split out rebuild_hflags_a32

[Richard Henderson]

Currently a trivial wrapper for rebuild_hflags_common_32.

Signed-off-by: Richard Henderson 
---
 target/arm/helper.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index 570f2dcc98..0fea62dc12 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -11068,6 +11068,12 @@ static uint32_t rebuild_hflags_m32(CPUARMState *env, 
int fp_el,
 return rebuild_hflags_common_32(env, fp_el, mmu_idx, flags);
 }
 
+static uint32_t rebuild_hflags_a32(CPUARMState *env, int fp_el,
+   ARMMMUIdx mmu_idx)
+{
+return rebuild_hflags_common_32(env, fp_el, mmu_idx, 0);
+}
+
 static uint32_t rebuild_hflags_a64(CPUARMState *env, int el, int fp_el,
ARMMMUIdx mmu_idx)
 {
@@ -11180,7 +11186,7 @@ void cpu_get_tb_cpu_state(CPUARMState *env, 
target_ulong *pc,
 flags = FIELD_DP32(flags, TBFLAG_A32, LSPACT, 1);
 }
 } else {
-flags = rebuild_hflags_common_32(env, fp_el, mmu_idx, 0);
+flags = rebuild_hflags_a32(env, fp_el, mmu_idx);
 }
 
 flags = FIELD_DP32(flags, TBFLAG_A32, THUMB, env->thumb);
-- 
2.17.1

[Qemu-devel] [PATCH v5 00/17] target/arm: Reduce overhead of cpu_get_tb_cpu_state

[Richard Henderson]

Changes since v4:
  * Split patch 1 into 15 smaller patches.
  * Cache the new DEBUG_TARGET_EL field.
  * Split out m-profile hflags separately from a-profile 32-bit.
  * Move around non-cached tb flags as well, avoiding repetitive
checks for m-profile or other mutually exclusive conditions.

  I haven't officially re-run the performance test quoted in the
  last patch, but I have eyeballed "perf top", and have dug into
  the compiled code a bit, which resulted in a few of the new
  cleanup patches (e.g. cs_base, arm_mmu_idx_el, and
  arm_cpu_data_is_big_endian).

Changes since v3:
  * Rebase.
  * Do not cache XSCALE_CPAR now that it overlaps VECSTRIDE.
  * Leave the new v7m bits as uncached.  I haven't figured
out all of the ways fpccr is modified.

Changes since v2:
  * Do not cache VECLEN, VECSTRIDE, VFPEN.
These variables come from VFP_FPSCR and VFP_FPEXC, not from
system control registers.
  * Move HANDLER and STACKCHECK to rebuild_hflags_a32,
instead of building them in rebuild_hflags_common.

Changes since v1:
  * Apparently I had started a last-minute API change, and failed to
covert all of the users, and also failed to re-test afterward.
  * Retain assertions for --enable-debug-tcg.

Richard Henderson (17):
  target/arm: Split out rebuild_hflags_common
  target/arm: Split out rebuild_hflags_a64
  target/arm: Split out rebuild_hflags_common_32
  target/arm: Split arm_cpu_data_is_big_endian
  target/arm: Split out rebuild_hflags_m32
  target/arm: Reduce tests vs M-profile in cpu_get_tb_cpu_state
  target/arm: Split out rebuild_hflags_a32
  target/arm: Split out rebuild_hflags_aprofile
  target/arm: Hoist XSCALE_CPAR, VECLEN, VECSTRIDE in
cpu_get_tb_cpu_state
  target/arm: Simplify set of PSTATE_SS in cpu_get_tb_cpu_state
  target/arm: Hoist computation of TBFLAG_A32.VFPEN
  target/arm: Add arm_rebuild_hflags
  target/arm: Split out arm_mmu_idx_el
  target/arm: Hoist store to cs_base in cpu_get_tb_cpu_state
  target/arm: Add HELPER(rebuild_hflags_{a32,a64,m32})
  target/arm: Rebuild hflags at EL changes and MSR writes
  target/arm: Rely on hflags correct in cpu_get_tb_cpu_state

 target/arm/cpu.h   |  84 +---
 target/arm/helper.h|   4 +
 target/arm/internals.h |   9 +
 linux-user/syscall.c   |   1 +
 target/arm/cpu.c   |   1 +
 target/arm/helper-a64.c|   3 +
 target/arm/helper.c| 383 -
 target/arm/machine.c   |   1 +
 target/arm/op_helper.c |   1 +
 target/arm/translate-a64.c |   6 +-
 target/arm/translate.c |  18 +-
 11 files changed, 341 insertions(+), 170 deletions(-)

-- 
2.17.1

[Qemu-devel] [PATCH v5 04/17] target/arm: Split arm_cpu_data_is_big_endian

[Richard Henderson]

Set TBFLAG_ANY.BE_DATA in rebuild_hflags_common_32 and
rebuild_hflags_a64 instead of rebuild_hflags_common, where we do
not need to re-test is_a64() nor re-compute the various inputs.

Signed-off-by: Richard Henderson 
---
 target/arm/cpu.h| 49 +++--
 target/arm/helper.c | 16 +++
 2 files changed, 42 insertions(+), 23 deletions(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 3dc52c032b..5dec4d3b3a 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -3104,33 +3104,44 @@ static inline uint64_t arm_sctlr(CPUARMState *env, int 
el)
 }
 }
 
+static inline bool arm_cpu_data_is_big_endian_a32(CPUARMState *env,
+  bool sctlr_b)
+{
+#ifdef CONFIG_USER_ONLY
+/*
+ * In system mode, BE32 is modelled in line with the
+ * architecture (as word-invariant big-endianness), where loads
+ * and stores are done little endian but from addresses which
+ * are adjusted by XORing with the appropriate constant. So the
+ * endianness to use for the raw data access is not affected by
+ * SCTLR.B.
+ * In user mode, however, we model BE32 as byte-invariant
+ * big-endianness (because user-only code cannot tell the
+ * difference), and so we need to use a data access endianness
+ * that depends on SCTLR.B.
+ */
+if (sctlr_b) {
+return true;
+}
+#endif
+/* In 32bit endianness is determined by looking at CPSR's E bit */
+return env->uncached_cpsr & CPSR_E;
+}
+
+static inline bool arm_cpu_data_is_big_endian_a64(int el, uint64_t sctlr)
+{
+return sctlr & (el ? SCTLR_EE : SCTLR_E0E);
+}
 
 /* Return true if the processor is in big-endian mode. */
 static inline bool arm_cpu_data_is_big_endian(CPUARMState *env)
 {
-/* In 32bit endianness is determined by looking at CPSR's E bit */
 if (!is_a64(env)) {
-return
-#ifdef CONFIG_USER_ONLY
-/* In system mode, BE32 is modelled in line with the
- * architecture (as word-invariant big-endianness), where loads
- * and stores are done little endian but from addresses which
- * are adjusted by XORing with the appropriate constant. So the
- * endianness to use for the raw data access is not affected by
- * SCTLR.B.
- * In user mode, however, we model BE32 as byte-invariant
- * big-endianness (because user-only code cannot tell the
- * difference), and so we need to use a data access endianness
- * that depends on SCTLR.B.
- */
-arm_sctlr_b(env) ||
-#endif
-((env->uncached_cpsr & CPSR_E) ? 1 : 0);
+return arm_cpu_data_is_big_endian_a32(env, arm_sctlr_b(env));
 } else {
 int cur_el = arm_current_el(env);
 uint64_t sctlr = arm_sctlr(env, cur_el);
-
-return (sctlr & (cur_el ? SCTLR_EE : SCTLR_E0E)) != 0;
+return arm_cpu_data_is_big_endian_a64(cur_el, sctlr);
 }
 }
 
diff --git a/target/arm/helper.c b/target/arm/helper.c
index 1844c13a19..6570d7e195 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -11023,9 +11023,6 @@ static uint32_t rebuild_hflags_common(CPUARMState *env, 
int fp_el,
 flags = FIELD_DP32(flags, TBFLAG_ANY, MMUIDX,
arm_to_core_mmu_idx(mmu_idx));
 
-if (arm_cpu_data_is_big_endian(env)) {
-flags = FIELD_DP32(flags, TBFLAG_ANY, BE_DATA, 1);
-}
 if (arm_singlestep_active(env)) {
 flags = FIELD_DP32(flags, TBFLAG_ANY, SS_ACTIVE, 1);
 }
@@ -11035,7 +11032,14 @@ static uint32_t rebuild_hflags_common(CPUARMState 
*env, int fp_el,
 static uint32_t rebuild_hflags_common_32(CPUARMState *env, int fp_el,
  ARMMMUIdx mmu_idx, uint32_t flags)
 {
-flags = FIELD_DP32(flags, TBFLAG_A32, SCTLR_B, arm_sctlr_b(env));
+bool sctlr_b = arm_sctlr_b(env);
+
+if (sctlr_b) {
+flags = FIELD_DP32(flags, TBFLAG_A32, SCTLR_B, 1);
+}
+if (arm_cpu_data_is_big_endian_a32(env, sctlr_b)) {
+flags = FIELD_DP32(flags, TBFLAG_ANY, BE_DATA, 1);
+}
 flags = FIELD_DP32(flags, TBFLAG_A32, NS, !access_secure_reg(env));
 
 return rebuild_hflags_common(env, fp_el, mmu_idx, flags);
@@ -11084,6 +11088,10 @@ static uint32_t rebuild_hflags_a64(CPUARMState *env, 
int el, int fp_el,
 
 sctlr = arm_sctlr(env, el);
 
+if (arm_cpu_data_is_big_endian_a64(el, sctlr)) {
+flags = FIELD_DP32(flags, TBFLAG_ANY, BE_DATA, 1);
+}
+
 if (cpu_isar_feature(aa64_pauth, env_archcpu(env))) {
 /*
  * In order to save space in flags, we record only whether
-- 
2.17.1

[Qemu-devel] [PATCH v5 06/17] target/arm: Reduce tests vs M-profile in cpu_get_tb_cpu_state

[Richard Henderson]

Hoist the computation of some TBFLAG_A32 bits that only apply to
M-profile under a single test for ARM_FEATURE_M.

Signed-off-by: Richard Henderson 
---
 target/arm/helper.c | 49 +
 1 file changed, 23 insertions(+), 26 deletions(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index c36ec6c530..570f2dcc98 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -11156,6 +11156,29 @@ void cpu_get_tb_cpu_state(CPUARMState *env, 
target_ulong *pc,
 
 if (arm_feature(env, ARM_FEATURE_M)) {
 flags = rebuild_hflags_m32(env, fp_el, mmu_idx);
+
+if (arm_feature(env, ARM_FEATURE_M_SECURITY) &&
+FIELD_EX32(env->v7m.fpccr[M_REG_S], V7M_FPCCR, S)
+!= env->v7m.secure) {
+flags = FIELD_DP32(flags, TBFLAG_A32, FPCCR_S_WRONG, 1);
+}
+
+if ((env->v7m.fpccr[env->v7m.secure] & R_V7M_FPCCR_ASPEN_MASK) &&
+(!(env->v7m.control[M_REG_S] & R_V7M_CONTROL_FPCA_MASK) ||
+ (env->v7m.secure &&
+  !(env->v7m.control[M_REG_S] & R_V7M_CONTROL_SFPA_MASK {
+/*
+ * ASPEN is set, but FPCA/SFPA indicate that there is no
+ * active FP context; we must create a new FP context before
+ * executing any FP insn.
+ */
+flags = FIELD_DP32(flags, TBFLAG_A32, NEW_FP_CTXT_NEEDED, 1);
+}
+
+bool is_secure = env->v7m.fpccr[M_REG_S] & R_V7M_FPCCR_S_MASK;
+if (env->v7m.fpccr[is_secure] & R_V7M_FPCCR_LSPACT_MASK) {
+flags = FIELD_DP32(flags, TBFLAG_A32, LSPACT, 1);
+}
 } else {
 flags = rebuild_hflags_common_32(env, fp_el, mmu_idx, 0);
 }
@@ -11195,32 +11218,6 @@ void cpu_get_tb_cpu_state(CPUARMState *env, 
target_ulong *pc,
 }
 }
 
-if (arm_feature(env, ARM_FEATURE_M_SECURITY) &&
-FIELD_EX32(env->v7m.fpccr[M_REG_S], V7M_FPCCR, S) != env->v7m.secure) {
-flags = FIELD_DP32(flags, TBFLAG_A32, FPCCR_S_WRONG, 1);
-}
-
-if (arm_feature(env, ARM_FEATURE_M) &&
-(env->v7m.fpccr[env->v7m.secure] & R_V7M_FPCCR_ASPEN_MASK) &&
-(!(env->v7m.control[M_REG_S] & R_V7M_CONTROL_FPCA_MASK) ||
- (env->v7m.secure &&
-  !(env->v7m.control[M_REG_S] & R_V7M_CONTROL_SFPA_MASK {
-/*
- * ASPEN is set, but FPCA/SFPA indicate that there is no active
- * FP context; we must create a new FP context before executing
- * any FP insn.
- */
-flags = FIELD_DP32(flags, TBFLAG_A32, NEW_FP_CTXT_NEEDED, 1);
-}
-
-if (arm_feature(env, ARM_FEATURE_M)) {
-bool is_secure = env->v7m.fpccr[M_REG_S] & R_V7M_FPCCR_S_MASK;
-
-if (env->v7m.fpccr[is_secure] & R_V7M_FPCCR_LSPACT_MASK) {
-flags = FIELD_DP32(flags, TBFLAG_A32, LSPACT, 1);
-}
-}
-
 if (!arm_feature(env, ARM_FEATURE_M)) {
 int target_el = arm_debug_target_el(env);
 
-- 
2.17.1

[Qemu-devel] [PATCH v5 01/17] target/arm: Split out rebuild_hflags_common

[Richard Henderson]

Create a function to compute the values of the TBFLAG_ANY bits
that will be cached.  For now, the env->hflags variable is not
used, and the results are fed back to cpu_get_tb_cpu_state.

Signed-off-by: Richard Henderson 
---
 target/arm/cpu.h| 29 ++---
 target/arm/helper.c | 26 +++---
 2 files changed, 37 insertions(+), 18 deletions(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 0981303170..3dc52c032b 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -231,6 +231,9 @@ typedef struct CPUARMState {
 uint32_t pstate;
 uint32_t aarch64; /* 1 if CPU is in aarch64 state; inverse of PSTATE.nRW */
 
+/* Cached TBFLAGS state.  See below for which bits are included.  */
+uint32_t hflags;
+
 /* Frequently accessed CPSR bits are stored separately for efficiency.
This contains all the other bits.  Use cpsr_{read,write} to access
the whole CPSR.  */
@@ -3136,15 +3139,18 @@ typedef ARMCPU ArchCPU;
 
 #include "exec/cpu-all.h"
 
-/* Bit usage in the TB flags field: bit 31 indicates whether we are
+/*
+ * Bit usage in the TB flags field: bit 31 indicates whether we are
  * in 32 or 64 bit mode. The meaning of the other bits depends on that.
  * We put flags which are shared between 32 and 64 bit mode at the top
  * of the word, and flags which apply to only one mode at the bottom.
+ *
+ * Unless otherwise noted, these bits are cached in env->hflags.
  */
 FIELD(TBFLAG_ANY, AARCH64_STATE, 31, 1)
 FIELD(TBFLAG_ANY, MMUIDX, 28, 3)
 FIELD(TBFLAG_ANY, SS_ACTIVE, 27, 1)
-FIELD(TBFLAG_ANY, PSTATE_SS, 26, 1)
+FIELD(TBFLAG_ANY, PSTATE_SS, 26, 1) /* Not cached. */
 /* Target EL if we take a floating-point-disabled exception */
 FIELD(TBFLAG_ANY, FPEXC_EL, 24, 2)
 FIELD(TBFLAG_ANY, BE_DATA, 23, 1)
@@ -3155,13 +3161,14 @@ FIELD(TBFLAG_ANY, BE_DATA, 23, 1)
 FIELD(TBFLAG_ANY, DEBUG_TARGET_EL, 21, 2)
 
 /* Bit usage when in AArch32 state: */
-FIELD(TBFLAG_A32, THUMB, 0, 1)
-FIELD(TBFLAG_A32, VECLEN, 1, 3)
-FIELD(TBFLAG_A32, VECSTRIDE, 4, 2)
+FIELD(TBFLAG_A32, THUMB, 0, 1)  /* Not cached. */
+FIELD(TBFLAG_A32, VECLEN, 1, 3) /* Not cached. */
+FIELD(TBFLAG_A32, VECSTRIDE, 4, 2)  /* Not cached. */
 /*
  * We store the bottom two bits of the CPAR as TB flags and handle
  * checks on the other bits at runtime. This shares the same bits as
  * VECSTRIDE, which is OK as no XScale CPU has VFP.
+ * Not cached, because VECLEN+VECSTRIDE are not cached.
  */
 FIELD(TBFLAG_A32, XSCALE_CPAR, 4, 2)
 /*
@@ -3170,15 +3177,15 @@ FIELD(TBFLAG_A32, XSCALE_CPAR, 4, 2)
  * the same thing as the current security state of the processor!
  */
 FIELD(TBFLAG_A32, NS, 6, 1)
-FIELD(TBFLAG_A32, VFPEN, 7, 1)
-FIELD(TBFLAG_A32, CONDEXEC, 8, 8)
+FIELD(TBFLAG_A32, VFPEN, 7, 1)  /* Not cached. */
+FIELD(TBFLAG_A32, CONDEXEC, 8, 8)   /* Not cached. */
 FIELD(TBFLAG_A32, SCTLR_B, 16, 1)
 /* For M profile only, set if FPCCR.LSPACT is set */
-FIELD(TBFLAG_A32, LSPACT, 18, 1)
+FIELD(TBFLAG_A32, LSPACT, 18, 1)/* Not cached. */
 /* For M profile only, set if we must create a new FP context */
-FIELD(TBFLAG_A32, NEW_FP_CTXT_NEEDED, 19, 1)
+FIELD(TBFLAG_A32, NEW_FP_CTXT_NEEDED, 19, 1) /* Not cached. */
 /* For M profile only, set if FPCCR.S does not match current security state */
-FIELD(TBFLAG_A32, FPCCR_S_WRONG, 20, 1)
+FIELD(TBFLAG_A32, FPCCR_S_WRONG, 20, 1) /* Not cached. */
 /* For M profile only, Handler (ie not Thread) mode */
 FIELD(TBFLAG_A32, HANDLER, 21, 1)
 /* For M profile only, whether we should generate stack-limit checks */
@@ -3190,7 +3197,7 @@ FIELD(TBFLAG_A64, SVEEXC_EL, 2, 2)
 FIELD(TBFLAG_A64, ZCR_LEN, 4, 4)
 FIELD(TBFLAG_A64, PAUTH_ACTIVE, 8, 1)
 FIELD(TBFLAG_A64, BT, 9, 1)
-FIELD(TBFLAG_A64, BTYPE, 10, 2)
+FIELD(TBFLAG_A64, BTYPE, 10, 2) /* Not cached. */
 FIELD(TBFLAG_A64, TBID, 12, 2)
 
 static inline bool bswap_code(bool sctlr_b)
diff --git a/target/arm/helper.c b/target/arm/helper.c
index 7e0d5398ab..f2c6419369 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -11016,6 +11016,22 @@ ARMMMUIdx arm_stage1_mmu_idx(CPUARMState *env)
 }
 #endif
 
+static uint32_t rebuild_hflags_common(CPUARMState *env, int fp_el,
+  ARMMMUIdx mmu_idx, uint32_t flags)
+{
+flags = FIELD_DP32(flags, TBFLAG_ANY, FPEXC_EL, fp_el);
+flags = FIELD_DP32(flags, TBFLAG_ANY, MMUIDX,
+   arm_to_core_mmu_idx(mmu_idx));
+
+if (arm_cpu_data_is_big_endian(env)) {
+flags = FIELD_DP32(flags, TBFLAG_ANY, BE_DATA, 1);
+}
+if (arm_singlestep_active(env)) {
+flags = FIELD_DP32(flags, TBFLAG_ANY, SS_ACTIVE, 1);
+}
+return flags;
+}
+
 void cpu_get_tb_cpu_state(CPUARMState *env, target_ulong *pc,
   target_ulong *cs_base, uint32_t *pflags)
 {
@@ -11107,7 +11123,7 @@ void cpu_get_tb_cpu_state(CPUARMState *env, 
target_ulong *pc,
 }
 }
 
-flags = FIELD_DP32(flags, TBFLAG_ANY, MMUIDX, 
arm_to_core_mmu_id

Re: [Qemu-devel] [PATCH 3/3] pc: Don't make CPU properties mandatory unless necessary

[Eduardo Habkost]

On Fri, Aug 16, 2019 at 05:07:10PM -0400, Yash Mankad wrote:
> On 8/16/19 1:42 PM, Eduardo Habkost wrote:
> > On Fri, Aug 16, 2019 at 02:22:58PM +0200, Markus Armbruster wrote:
> >> Erik Skultety  writes:
> >>
> >>> On Fri, Aug 16, 2019 at 08:10:20AM +0200, Markus Armbruster wrote:
>  Eduardo Habkost  writes:
> 
> > We have this issue reported when using libvirt to hotplug CPUs:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1741451
> >
> > Basically, libvirt is not copying die-id from
> > query-hotpluggable-cpus, but die-id is now mandatory.
>  Uh-oh, "is now mandatory": making an optional property mandatory is an
>  incompatible change.  When did we do that?  Commit hash, please.
> 
>  [...]
> 
> >>> I don't even see it as being optional ever - the property wasn't even
> >>> recognized before commit 176d2cda0de introduced it as mandatory.
> >> Compatibility break.
> >>
> >> Commit 176d2cda0de is in v4.1.0.  If I had learned about it a bit
> >> earlier, I would've argued for a last minute fix or a revert.  Now we
> >> have a regression in the release.
> >>
> >> Eduardo, I think this fix should go into v4.1.1.  Please add cc:
> >> qemu-stable.
> > I did it in v2.
> >
> >> How can we best avoid such compatibility breaks to slip in undetected?
> >>
> >> A static checker would be nice.  For vmstate, we have
> >> scripts/vmstate-static-checker.py.  Not sure it's used.
> > I don't think this specific bug would be detected with a static
> > checker.  "die-id is mandatory" is not something that can be
> > extracted by looking at QOM data structures.  The new rule was
> > being enforced by the hotplug handler callbacks, and the hotplug
> > handler call tree is a bit complex (too complex for my taste, but
> > I digress).
> >
> > We could have detected this with a simple CPU hotplug automated
> > test case, though.  Or with a very simple -device test case like
> > the one I have submitted with this patch.
> >
> > This was detected by libvirt automated test cases.  It would be
> > nice if this was run during the -rc stage and not only after the
> > 4.1.0 release, though.
> >
> > I don't know details of the test job.  Danilo, Mirek, Yash: do
> > you know how this bug was detected, and what we could do to run
> > the same test jobs in upstream QEMU release candidates?
> 
> This bug was caught by our internal gating tests.
> 
> The libvirt gating tests for the virt module include the
> following Avocado-VT test case:
> 
> libvirt_vcpu_plug_unplug.positive_test.vcpu_set.live.vm_operate.save
> 
> This job failed with the error that you can see in the description
> of the BZ#1741451 [0].
> 
> If you think that this would have been caught by a simple hotplug
> case, I'd recommend adding a test for hotplug to avocado_qemu.
> Otherwise, if you want, I can look into adding this particular
> libvirt test case to our QEMU CI efforts.

Having a hotplug test case using avocado_qemu would help catch
some bugs, but it's not enough if we want to catch integration
issues between QEMU and libvirt (like this one).

I wouldn't focus just on that particular libvirt test case.
I suggest we run a reasonably large set of libvirt test cases
against QEMU release candidates as soon as they are tagged.

> 
> Thanks,
> Yash
> 
> [0] https://bugzilla.redhat.com/show_bug.cgi?id=1741451#c0
> 

-- 
Eduardo

Re: [Qemu-devel] [PATCH v3 2/8] iotests: Prefer null-co over null-aio

[John Snow]

On 8/19/19 4:22 PM, Max Reitz wrote:
> On 19.08.19 22:18, Max Reitz wrote:
>> We use null-co basically everywhere in the iotests.  Unless we want to
>> test null-aio specifically, we should use it instead (for consistency).
>>
>> Signed-off-by: Max Reitz 
>> Reviewed-by: John Snow 
> 
> Hm, sorry, I just noticed that I probably should have dropped this R-b. :-/
> 
> (I mean, apart from the rebase conflict, nothing has changed, but still.)
> 
> Max
> 

It's fine.

Re: [Qemu-devel] [PATCH] block: Use QEMU_IS_ALIGNED instead of reinventing it

[Nir Soffer]

On Tue, Aug 20, 2019 at 10:51 PM Max Reitz  wrote:

> On 17.08.19 19:53, Nir Soffer wrote:
> > Replace instances of:
> >
> > (n & (BDRV_SECTOR_SIZE - 1)) == 0)
> >
> > With:
> >
> > QEMU_IS_ALIGNED(n, BDRV_SECTOR_SIZE)
> >
> > Which reveals the intent of the code better, and makes it easier to
> > locate the code checking alignment.
> >
> > QEMU_IS_ALIGNED is implemented using %, which may be less efficient but
> > it is used only in assert() except one instance, so it should not
> > matter.
> >
> > Signed-off-by: Nir Soffer 
> > ---
> >  block/bochs.c | 4 ++--
> >  block/cloop.c | 4 ++--
> >  block/dmg.c   | 4 ++--
> >  block/io.c| 8 
> >  block/qcow2.c | 4 ++--
> >  block/vvfat.c | 8 
> >  qemu-img.c| 2 +-
> >  7 files changed, 17 insertions(+), 17 deletions(-)
>
> Because John was speaking about a magical incantation, I found
> BDRV_SECTOR_MASK.  There are two places in block/qcow2-cluster.c that
> use that to check alignment, I think those should be amended as well.
>

$ git grep BDRV_SECTOR_MASK
block/qcow2-cluster.c:assert((offset_in_cluster &
~BDRV_SECTOR_MASK) == 0);
block/qcow2-cluster.c:assert((bytes & ~BDRV_SECTOR_MASK) == 0);

Right, should use QEMU_IS_ALIGNED

include/block/block.h:#define BDRV_SECTOR_MASK   ~(BDRV_SECTOR_SIZE - 1)
include/block/block.h:#define BDRV_BLOCK_OFFSET_MASK  BDRV_SECTOR_MASK
migration/block.c:flags = addr & ~BDRV_SECTOR_MASK;

This could use (BDRV_SECTOR_SIZE - 1).
In Linux SECTOR_MASK is defined as:

drivers/block/null_blk_main.c:#define SECTOR_MASK
(PAGE_SECTORS - 1)

It seems that qemu use use the same.

I will try to handle these in v2.

Nir

Re: [Qemu-devel] [PATCH v7 10/13] vfio: Add load state functions to SaveVMHandlers

[Kirti Wankhede]

On 7/23/2019 3:20 AM, Yan Zhao wrote:
> On Tue, Jul 23, 2019 at 03:07:13AM +0800, Alex Williamson wrote:
>> On Sun, 21 Jul 2019 23:20:28 -0400
>> Yan Zhao  wrote:
>>
>>> On Fri, Jul 19, 2019 at 03:00:13AM +0800, Kirti Wankhede wrote:


 On 7/12/2019 8:22 AM, Yan Zhao wrote:  
> On Tue, Jul 09, 2019 at 05:49:17PM +0800, Kirti Wankhede wrote:  
>> Flow during _RESUMING device state:
>> - If Vendor driver defines mappable region, mmap migration region.
>> - Load config state.
>> - For data packet, till VFIO_MIG_FLAG_END_OF_STATE is not reached
>> - read data_size from packet, read buffer of data_size
>> - read data_offset from where QEMU should write data.
>> if region is mmaped, write data of data_size to mmaped region.
>> - write data_size.
>> In case of mmapped region, write to data_size indicates kernel
>> driver that data is written in staging buffer.
>> - if region is trapped, pwrite() data of data_size from data_offset.
>> - Repeat above until VFIO_MIG_FLAG_END_OF_STATE.
>> - Unmap migration region.
>>
>> For user, data is opaque. User should write data in the same order as
>> received.
>>
>> Signed-off-by: Kirti Wankhede 
>> Reviewed-by: Neo Jia 
>> ---
>>  hw/vfio/migration.c  | 162 
>> +++
>>  hw/vfio/trace-events |   3 +
>>  2 files changed, 165 insertions(+)
>>
>> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
>> index 4e9b4cce230b..5fb4c5329ede 100644
>> --- a/hw/vfio/migration.c
>> +++ b/hw/vfio/migration.c
>> @@ -249,6 +249,26 @@ static int vfio_save_device_config_state(QEMUFile 
>> *f, void *opaque)
>>  return qemu_file_get_error(f);
>>  }
>>  
>> +static int vfio_load_device_config_state(QEMUFile *f, void *opaque)
>> +{
>> +VFIODevice *vbasedev = opaque;
>> +uint64_t data;
>> +
>> +if (vbasedev->ops && vbasedev->ops->vfio_load_config) {
>> +vbasedev->ops->vfio_load_config(vbasedev, f);
>> +}
>> +
>> +data = qemu_get_be64(f);
>> +if (data != VFIO_MIG_FLAG_END_OF_STATE) {
>> +error_report("%s: Failed loading device config space, "
>> + "end flag incorrect 0x%"PRIx64, vbasedev->name, 
>> data);
>> +return -EINVAL;
>> +}
>> +
>> +trace_vfio_load_device_config_state(vbasedev->name);
>> +return qemu_file_get_error(f);
>> +}
>> +
>>  /* 
>> -- */
>>  
>>  static int vfio_save_setup(QEMUFile *f, void *opaque)
>> @@ -421,12 +441,154 @@ static int vfio_save_complete_precopy(QEMUFile 
>> *f, void *opaque)
>>  return ret;
>>  }
>>  
>> +static int vfio_load_setup(QEMUFile *f, void *opaque)
>> +{
>> +VFIODevice *vbasedev = opaque;
>> +VFIOMigration *migration = vbasedev->migration;
>> +int ret = 0;
>> +
>> +if (migration->region.buffer.mmaps) {
>> +ret = vfio_region_mmap(&migration->region.buffer);
>> +if (ret) {
>> +error_report("%s: Failed to mmap VFIO migration region %d: 
>> %s",
>> + vbasedev->name, migration->region.index,
>> + strerror(-ret));
>> +return ret;
>> +}
>> +}
>> +
>> +ret = vfio_migration_set_state(vbasedev, 
>> VFIO_DEVICE_STATE_RESUMING);
>> +if (ret) {
>> +error_report("%s: Failed to set state RESUMING", 
>> vbasedev->name);
>> +}
>> +return ret;
>> +}
>> +
>> +static int vfio_load_cleanup(void *opaque)
>> +{
>> +vfio_save_cleanup(opaque);
>> +return 0;
>> +}
>> +
>> +static int vfio_load_state(QEMUFile *f, void *opaque, int version_id)
>> +{
>> +VFIODevice *vbasedev = opaque;
>> +VFIOMigration *migration = vbasedev->migration;
>> +int ret = 0;
>> +uint64_t data, data_size;
>> +  
> I think checking of version_id is still needed.
>   

 Checking version_id with what value?
  
>>> this version_id passed-in is the source VFIO software interface id.
>>> need to check it with the value in target side, right?
>>>
>>> Though we previously discussed the sysfs node interface to check live
>>> migration version even before launching live migration, I think we still
>>> need this runtime software version check in qemu to ensure software
>>> interfaces in QEMU VFIO are compatible.
>>
>> Do we want QEMU to interact directly with sysfs for that, which would
>> require write privileges to sysfs, or do we want to suggest that vendor
>> drivers should include equivalent information early in their migration
>> data stream to force a migration failure

Re: [Qemu-devel] Regression with floppy drive controller

[Eduardo Habkost]

On Tue, Aug 20, 2019 at 06:21:28PM +0200, Philippe Mathieu-Daudé wrote:
> Cc'ing Eduardo, Paolo.
> 
> On 8/20/19 3:38 PM, Philippe Mathieu-Daudé wrote:
> > On 8/20/19 3:12 PM, John Snow wrote:
> >> On 8/20/19 6:25 AM, Philippe Mathieu-Daudé wrote:
> >>> [cross posting QEMU & SeaBIOS]
> >>>
> >>> Hello,
> >>>
> >>> I'v been looking at a QEMU bug report [1] which bisection resulted in a
> >>> SeaBIOS commit:
> >>>
> >>> 4a6dbcea3e412fe12effa2f812f50dd7eae90955 is the first bad commit
> >>> commit 4a6dbcea3e412fe12effa2f812f50dd7eae90955
> >>> Author: Nikolay Nikolov 
> >>> Date:   Sun Feb 4 17:27:01 2018 +0200
> >>>
> >>> floppy: Use timer_check() in floppy_wait_irq()
> >>>
> >>> Use timer_check() instead of using floppy_motor_counter in BDA for the
> >>> timeout check in floppy_wait_irq().
> >>>
> >>> The problem with using floppy_motor_counter was that, after it reaches
> >>> 0, it immediately stops the floppy motors, which is not what is
> >>> supposed to happen on real hardware. Instead, after a timeout (like in
> >>> the end of every floppy operation, regardless of the result - success,
> >>> timeout or error), the floppy motors must be kept spinning for
> >>> additional 2 seconds (the FLOPPY_MOTOR_TICKS). So, now the
> >>> floppy_motor_counter is initialized to 255 (the max value) in the
> >>> beginning of the floppy operation. For IRQ timeouts, a different
> >>> timeout is used, specified by the new FLOPPY_IRQ_TIMEOUT constant
> >>> (currently set to 5 seconds - a fairly conservative value, but should
> >>> work reliably on most floppies).
> >>>
> >>> After the floppy operation, floppy_drive_pio() resets the
> >>> floppy_motor_counter to 2 seconds (FLOPPY_MOTOR_TICKS).
> >>>
> >>> This is also consistent with what other PC BIOSes do.
> >>>
> >>>
> >>> This commit improve behavior with real hardware, so maybe QEMU is not
> >>> modelling something or modelling it incorrectly?
> > [...]
> >>
> >> Well, that's unfortunate.
> >>
> >> What version of QEMU shipped the SeaBIOS that caused the regression?
> > 
> > See https://bugs.launchpad.net/qemu/+bug/1840719/comments/3
> > 
> > QEMU commit 0b8f74488e, slighly before QEMU v3.1.0
> > (previous tag is v3.0.0).
> > 
> > But you can use v4.1.0 too, simply change the SeaBIOS bios.bin, i.e.:
> > 
> >   qemu$ git checkout v4.1.0
> > 
> >   qemu$ (cd roms/seabios && git checkout 4a6dbcea3e4~) && \
> > make -C roms bios
> > 
> > Now pc-bios/bios.bin is built using the last commit working,
> > 
> >   qemu$ (cd roms/seabios && git checkout 4a6dbcea3e4) && \
> > make -C roms bios
> > 
> > And you can reproduce the error.
> 
> Back from here.
> 
> So the SeaBIOS patch is:
> 
> diff --git a/src/hw/floppy.c b/src/hw/floppy.c
> index 77dbade..3012b3a 100644
> --- a/src/hw/floppy.c
> +++ b/src/hw/floppy.c
> @@ -34,6 +34,7 @@
>  #define FLOPPY_GAPLEN 0x1B
>  #define FLOPPY_FORMAT_GAPLEN 0x6c
>  #define FLOPPY_PIO_TIMEOUT 1000
> +#define FLOPPY_IRQ_TIMEOUT 5000
> 
>  #define FLOPPY_DOR_MOTOR_D 0x80 // Set to turn drive 3's motor ON
>  #define FLOPPY_DOR_MOTOR_C 0x40 // Set to turn drive 2's motor ON
> @@ -221,8 +222,9 @@ floppy_wait_irq(void)
>  {
>  u8 frs = GET_BDA(floppy_recalibration_status);
>  SET_BDA(floppy_recalibration_status, frs & ~FRS_IRQ);
> +u32 end = timer_calc(FLOPPY_IRQ_TIMEOUT);
>  for (;;) {
> -if (!GET_BDA(floppy_motor_counter)) {
> +if (timer_check(end)) {
>  warn_timeout();
>  floppy_disable_controller();
>  return DISK_RET_ETIMEOUT;
> 
> timer_calc() unit is milliseconds, so this patch should wait upto
> 5seconds before failing, and it seems the timeout is not used at all.
> 
> SeaBIOS timer.c:
> 
> // Return the TSC value that is 'msecs' time in the future.
> u32
> timer_calc(u32 msecs)
> {
> return timer_read() + (GET_GLOBAL(TimerKHz) * msecs);
> }
> 
> static u32
> timer_read(void)
> {
> u16 port = GET_GLOBAL(TimerPort);
> if (CONFIG_TSC_TIMER && !port)
> // Read from CPU TSC
> return rdtscll() >> GET_GLOBAL(ShiftTSC);
> if (CONFIG_PMTIMER && port != PORT_PIT_COUNTER0)
> // Read from PMTIMER
> return timer_adjust_bits(inl(port), 0xff);
> // Read from PIT.
> outb(PM_SEL_READBACK | PM_READ_VALUE | PM_READ_COUNTER0, PORT_PIT_MODE);
> u16 v = inb(PORT_PIT_COUNTER0) | (inb(PORT_PIT_COUNTER0) << 8);
> return timer_adjust_bits(v, 0x);
> }
> 
> Using the default QEMU config, we build SeaBIOS to use the TSC timer:
> 
> builds/seabios-128k/.config:CONFIG_TSC_TIMER=y
> builds/seabios-256k/.config:CONFIG_TSC_TIMER=y
> 
> $ qemu-system-i386 -M isapc -cpu 486 \
>   -fda Windows\ 98\ Second\ Edition\ Boot.img \
>   -chardev stdio,id=seabios \
>   -device isa-debugcon,iobase=0x402,chardev=seabios
> Booting from Floppy...
> Floppy_drive_recal 0
> Floppy_enable_controller
> WARNING - Timeout at floppy_wait_irq:228!
> Floppy_disable_controll

Re: [Qemu-devel] [PATCH v7 08/13] vfio: Register SaveVMHandlers for VFIO device

[Kirti Wankhede]

On 7/22/2019 2:04 PM, Yan Zhao wrote:
> On Tue, Jul 09, 2019 at 05:49:15PM +0800, Kirti Wankhede wrote:
>> Define flags to be used as delimeter in migration file stream.
>> Added .save_setup and .save_cleanup functions. Mapped & unmapped migration
>> region from these functions at source during saving or pre-copy phase.
>> Set VFIO device state depending on VM's state. During live migration, VM is
>> running when .save_setup is called, _SAVING | _RUNNING state is set for VFIO
>> device. During save-restore, VM is paused, _SAVING state is set for VFIO 
>> device.
>>
>> Signed-off-by: Kirti Wankhede 
>> Reviewed-by: Neo Jia 
>> ---
>>  hw/vfio/migration.c  | 82 
>> +++-
>>  hw/vfio/trace-events |  2 ++
>>  2 files changed, 83 insertions(+), 1 deletion(-)
>>
>> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
>> index e4a89a6f9bc7..0597a45fda2d 100644
>> --- a/hw/vfio/migration.c
>> +++ b/hw/vfio/migration.c
>> @@ -23,6 +23,17 @@
>>  #include "pci.h"
>>  #include "trace.h"
>>  
>> +/*
>> + * Flags used as delimiter:
>> + * 0x => MSB 32-bit all 1s
>> + * 0xef10 => emulated (virtual) function IO
>> + * 0x => 16-bits reserved for flags
>> + */
>> +#define VFIO_MIG_FLAG_END_OF_STATE  (0xef11ULL)
>> +#define VFIO_MIG_FLAG_DEV_CONFIG_STATE  (0xef12ULL)
>> +#define VFIO_MIG_FLAG_DEV_SETUP_STATE   (0xef13ULL)
>> +#define VFIO_MIG_FLAG_DEV_DATA_STATE(0xef14ULL)
>> +
>>  static void vfio_migration_region_exit(VFIODevice *vbasedev)
>>  {
>>  VFIOMigration *migration = vbasedev->migration;
>> @@ -106,6 +117,74 @@ static int vfio_migration_set_state(VFIODevice 
>> *vbasedev, uint32_t state)
>>  return 0;
>>  }
>>  
>> +/* -- */
>> +
>> +static int vfio_save_setup(QEMUFile *f, void *opaque)
>> +{
>> +VFIODevice *vbasedev = opaque;
>> +VFIOMigration *migration = vbasedev->migration;
>> +int ret;
>> +
>> +qemu_put_be64(f, VFIO_MIG_FLAG_DEV_SETUP_STATE);
>> +
>> +if (migration->region.buffer.mmaps) {
>> +qemu_mutex_lock_iothread();
>> +ret = vfio_region_mmap(&migration->region.buffer);
>> +qemu_mutex_unlock_iothread();
>> +if (ret) {
>> +error_report("%s: Failed to mmap VFIO migration region %d: %s",
>> + vbasedev->name, migration->region.index,
>> + strerror(-ret));
>> +return ret;
>> +}
>> +}
>> +
>> +if (vbasedev->vm_running) {
>> +ret = vfio_migration_set_state(vbasedev,
>> + VFIO_DEVICE_STATE_RUNNING | 
>> VFIO_DEVICE_STATE_SAVING);
>> +if (ret) {
>> +error_report("%s: Failed to set state RUNNING and SAVING",
>> + vbasedev->name);
>> +return ret;
>> +}
>> +} else {
> hi Kirti
> May I know in which condition will this "else" case happen?
> 

This can happen in savevm case.

Thanks,
Kirti

> Thanks
> Yan
> 
>> +ret = vfio_migration_set_state(vbasedev, VFIO_DEVICE_STATE_SAVING);
>> +if (ret) {
>> +error_report("%s: Failed to set state STOP and SAVING",
>> + vbasedev->name);
>> +return ret;
>> +}
>> +}
>> +
>> +qemu_put_be64(f, VFIO_MIG_FLAG_END_OF_STATE);
>> +
>> +ret = qemu_file_get_error(f);
>> +if (ret) {
>> +return ret;
>> +}
>> +
>> +trace_vfio_save_setup(vbasedev->name);
>> +return 0;
>> +}
>> +
>> +static void vfio_save_cleanup(void *opaque)
>> +{
>> +VFIODevice *vbasedev = opaque;
>> +VFIOMigration *migration = vbasedev->migration;
>> +
>> +if (migration->region.buffer.mmaps) {
>> +vfio_region_unmap(&migration->region.buffer);
>> +}
>> +trace_vfio_save_cleanup(vbasedev->name);
>> +}
>> +
>> +static SaveVMHandlers savevm_vfio_handlers = {
>> +.save_setup = vfio_save_setup,
>> +.save_cleanup = vfio_save_cleanup,
>> +};
>> +
>> +/* -- */
>> +
>>  static void vfio_vmstate_change(void *opaque, int running, RunState state)
>>  {
>>  VFIODevice *vbasedev = opaque;
>> @@ -195,7 +274,8 @@ static int vfio_migration_init(VFIODevice *vbasedev,
>>  }
>>  
>>  qemu_mutex_init(&vbasedev->migration->lock);
>> -
>> +register_savevm_live(vbasedev->dev, "vfio", -1, 1, 
>> &savevm_vfio_handlers,
>> + vbasedev);
>>  vbasedev->vm_state = 
>> qemu_add_vm_change_state_handler(vfio_vmstate_change,
>>vbasedev);
>>  
>> diff --git a/hw/vfio/trace-events b/hw/vfio/trace-events
>> index 69503228f20e..4bb43f18f315 100644
>> --- a/hw/vfio/trace-events
>> +++ b/hw/vfio/trace-events
>> @@ -149,3 +149,5 @@ vfio_migration_probe(char *name, uint32_t index) " (%s) 
>> Region %d"
>>  vfio_migration_set_

Re: [Qemu-devel] [PATCH v7 11/13] vfio: Add function to get dirty page list

[Kirti Wankhede]

On 7/22/2019 2:09 PM, Yan Zhao wrote:
> On Tue, Jul 09, 2019 at 05:49:18PM +0800, Kirti Wankhede wrote:
>> Dirty page tracking (.log_sync) is part of RAM copying state, where
>> vendor driver provides the bitmap of pages which are dirtied by vendor
>> driver through migration region and as part of RAM copy, those pages
>> gets copied to file stream.
>>
>> To get dirty page bitmap:
>> - write start address, page_size and pfn count.
>> - read count of pfns copied.
>> - Vendor driver should return 0 if driver doesn't have any page to
>>   report dirty in given range.
>> - Vendor driver should return -1 to mark all pages dirty for given range.
>> - read data_offset, where vendor driver has written bitmap.
>> - read bitmap from the region or mmaped part of the region.
>> - Iterate above steps till page bitmap for all requested pfns are copied.
>>
>> Signed-off-by: Kirti Wankhede 
>> Reviewed-by: Neo Jia 
>> ---
>>  hw/vfio/migration.c   | 123 
>> ++
>>  hw/vfio/trace-events  |   1 +
>>  include/hw/vfio/vfio-common.h |   2 +
>>  3 files changed, 126 insertions(+)
>>
>> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
>> index 5fb4c5329ede..ca1a8c0f5f1f 100644
>> --- a/hw/vfio/migration.c
>> +++ b/hw/vfio/migration.c
>> @@ -269,6 +269,129 @@ static int vfio_load_device_config_state(QEMUFile *f, 
>> void *opaque)
>>  return qemu_file_get_error(f);
>>  }
>>  
>> +void vfio_get_dirty_page_list(VFIODevice *vbasedev,
>> +  uint64_t start_pfn,
>> +  uint64_t pfn_count,
>> +  uint64_t page_size)
>> +{
>> +VFIOMigration *migration = vbasedev->migration;
>> +VFIORegion *region = &migration->region.buffer;
>> +uint64_t count = 0;
>> +int64_t copied_pfns = 0;
>> +int64_t total_pfns = pfn_count;
>> +int ret;
>> +
>> +qemu_mutex_lock(&migration->lock);
>> +
>> +while (total_pfns > 0) {
>> +uint64_t bitmap_size, data_offset = 0;
>> +uint64_t start = start_pfn + count;
>> +void *buf = NULL;
>> +bool buffer_mmaped = false;
>> +
>> +ret = pwrite(vbasedev->fd, &start, sizeof(start),
>> + region->fd_offset + offsetof(struct 
>> vfio_device_migration_info,
>> +  start_pfn));
>> +if (ret < 0) {
>> +error_report("%s: Failed to set dirty pages start address %d 
>> %s",
>> + vbasedev->name, ret, strerror(errno));
>> +goto dpl_unlock;
>> +}
>> +
>> +ret = pwrite(vbasedev->fd, &page_size, sizeof(page_size),
>> + region->fd_offset + offsetof(struct 
>> vfio_device_migration_info,
>> +  page_size));
>> +if (ret < 0) {
>> +error_report("%s: Failed to set dirty page size %d %s",
>> + vbasedev->name, ret, strerror(errno));
>> +goto dpl_unlock;
>> +}
>> +
>> +ret = pwrite(vbasedev->fd, &total_pfns, sizeof(total_pfns),
>> + region->fd_offset + offsetof(struct 
>> vfio_device_migration_info,
>> +  total_pfns));
>> +if (ret < 0) {
>> +error_report("%s: Failed to set dirty page total pfns %d %s",
>> + vbasedev->name, ret, strerror(errno));
>> +goto dpl_unlock;
>> +}
>> +
>> +/* Read copied dirty pfns */
>> +ret = pread(vbasedev->fd, &copied_pfns, sizeof(copied_pfns),
>> +region->fd_offset + offsetof(struct 
>> vfio_device_migration_info,
>> + copied_pfns));
>> +if (ret < 0) {
>> +error_report("%s: Failed to get dirty pages bitmap count %d %s",
>> + vbasedev->name, ret, strerror(errno));
>> +goto dpl_unlock;
>> +}
>> +
>> +if (copied_pfns == VFIO_DEVICE_DIRTY_PFNS_NONE) {
>> +/*
>> + * copied_pfns could be 0 if driver doesn't have any page to
>> + * report dirty in given range
>> + */
>> +break;
>> +} else if (copied_pfns == VFIO_DEVICE_DIRTY_PFNS_ALL) {
>> +/* Mark all pages dirty for this range */
>> +cpu_physical_memory_set_dirty_range(start_pfn * page_size,
>> +pfn_count * page_size,
>> +DIRTY_MEMORY_MIGRATION);
>> +break;
>> +}
>> +
>> +bitmap_size = (BITS_TO_LONGS(copied_pfns) + 1) * sizeof(unsigned 
>> long);
> hi Kirti
> 
> why bitmap_size is 
> (BITS_TO_LONGS(copied_pfns) + 1) * sizeof(unsigned long).
> why it's not
> BITS_TO_LONGS(copied_pfns) * sizeof(unsigned long) ?
> 

It should be later. I'll update in next version.

Thanks,
Kirti


> Thanks
> Yan
> 
>> +re

Re: [Qemu-devel] [PATCH v7 06/13] vfio: Add VM state change handler to know state of VM

[Kirti Wankhede]

On 7/22/2019 2:07 PM, Yan Zhao wrote:
> On Tue, Jul 09, 2019 at 05:49:13PM +0800, Kirti Wankhede wrote:
>> VM state change handler gets called on change in VM's state. This is used to 
>> set
>> VFIO device state to _RUNNING.
>> VM state change handler, migration state change handler and log_sync listener
>> are called asynchronously, which sometimes lead to data corruption in 
>> migration
>> region. Initialised mutex that is used to serialize operations on migration 
>> data
>> region during saving state.
>>
>> Signed-off-by: Kirti Wankhede 
>> Reviewed-by: Neo Jia 
>> ---
>>  hw/vfio/migration.c   | 64 
>> +++
>>  hw/vfio/trace-events  |  2 ++
>>  include/hw/vfio/vfio-common.h |  4 +++
>>  3 files changed, 70 insertions(+)
>>
>> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
>> index a2cfbd5af2e1..c01f08b659d0 100644
>> --- a/hw/vfio/migration.c
>> +++ b/hw/vfio/migration.c
>> @@ -78,6 +78,60 @@ err:
>>  return ret;
>>  }
>>  
>> +static int vfio_migration_set_state(VFIODevice *vbasedev, uint32_t state)
>> +{
>> +VFIOMigration *migration = vbasedev->migration;
>> +VFIORegion *region = &migration->region.buffer;
>> +uint32_t device_state;
>> +int ret = 0;
>> +
>> +device_state = (state & VFIO_DEVICE_STATE_MASK) |
>> +   (vbasedev->device_state & ~VFIO_DEVICE_STATE_MASK);
>> +
>> +if ((device_state & VFIO_DEVICE_STATE_MASK) == 
>> VFIO_DEVICE_STATE_INVALID) {
>> +return -EINVAL;
>> +}
>> +
>> +ret = pwrite(vbasedev->fd, &device_state, sizeof(device_state),
>> + region->fd_offset + offsetof(struct 
>> vfio_device_migration_info,
>> +  device_state));
>> +if (ret < 0) {
>> +error_report("%s: Failed to set device state %d %s",
>> + vbasedev->name, ret, strerror(errno));
>> +return ret;
>> +}
>> +
>> +vbasedev->device_state = device_state;
>> +trace_vfio_migration_set_state(vbasedev->name, device_state);
>> +return 0;
>> +}
>> +
>> +static void vfio_vmstate_change(void *opaque, int running, RunState state)
>> +{
>> +VFIODevice *vbasedev = opaque;
>> +
>> +if ((vbasedev->vm_running != running)) {
>> +int ret;
>> +uint32_t dev_state;
>> +
>> +if (running) {
>> +dev_state = VFIO_DEVICE_STATE_RUNNING;
> should be
> dev_state |= VFIO_DEVICE_STATE_RUNNING; ?
> 

vfio_migration_set_state() takes case of ORing.

Thanks,
Kirti

>> +} else {
>> +dev_state = (vbasedev->device_state & VFIO_DEVICE_STATE_MASK) &
>> + ~VFIO_DEVICE_STATE_RUNNING;
>> +}
>> +
>> +ret = vfio_migration_set_state(vbasedev, dev_state);
>> +if (ret) {
>> +error_report("%s: Failed to set device state 0x%x",
>> + vbasedev->name, dev_state);
>> +}
>> +vbasedev->vm_running = running;
>> +trace_vfio_vmstate_change(vbasedev->name, running, 
>> RunState_str(state),
>> +  dev_state);
>> +}
>> +}
>> +
>>  static int vfio_migration_init(VFIODevice *vbasedev,
>> struct vfio_region_info *info)
>>  {
>> @@ -93,6 +147,11 @@ static int vfio_migration_init(VFIODevice *vbasedev,
>>  return ret;
>>  }
>>  
>> +qemu_mutex_init(&vbasedev->migration->lock);
>> +
>> +vbasedev->vm_state = 
>> qemu_add_vm_change_state_handler(vfio_vmstate_change,
>> +  vbasedev);
>> +
>>  return 0;
>>  }
>>  
>> @@ -135,11 +194,16 @@ void vfio_migration_finalize(VFIODevice *vbasedev)
>>  return;
>>  }
>>  
>> +if (vbasedev->vm_state) {
>> +qemu_del_vm_change_state_handler(vbasedev->vm_state);
>> +}
>> +
>>  if (vbasedev->migration_blocker) {
>>  migrate_del_blocker(vbasedev->migration_blocker);
>>  error_free(vbasedev->migration_blocker);
>>  }
>>  
>> +qemu_mutex_destroy(&vbasedev->migration->lock);
>>  vfio_migration_region_exit(vbasedev);
>>  g_free(vbasedev->migration);
>>  }
>> diff --git a/hw/vfio/trace-events b/hw/vfio/trace-events
>> index 191a726a1312..3d15bacd031a 100644
>> --- a/hw/vfio/trace-events
>> +++ b/hw/vfio/trace-events
>> @@ -146,3 +146,5 @@ vfio_display_edid_write_error(void) ""
>>  
>>  # migration.c
>>  vfio_migration_probe(char *name, uint32_t index) " (%s) Region %d"
>> +vfio_migration_set_state(char *name, uint32_t state) " (%s) state %d"
>> +vfio_vmstate_change(char *name, int running, const char *reason, uint32_t 
>> dev_state) " (%s) running %d reason %s device state %d"
>> diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h
>> index 152da3f8d6f3..f6c70db3a9c1 100644
>> --- a/include/hw/vfio/vfio-common.h
>> +++ b/include/hw/vfio/vfio-common.h
>> @@ -29,6 +29,7 @@
>>  #ifdef CONFIG_LINUX
>>  #include 
>>  #endif
>> +#include 

Re: [Qemu-devel] [PATCH v7 06/13] vfio: Add VM state change handler to know state of VM

[Kirti Wankhede]

On 7/22/2019 1:53 PM, Yan Zhao wrote:
> On Fri, Jul 12, 2019 at 03:14:03AM +0800, Kirti Wankhede wrote:
>>
>>
>> On 7/11/2019 5:43 PM, Dr. David Alan Gilbert wrote:
>>> * Kirti Wankhede (kwankh...@nvidia.com) wrote:
 VM state change handler gets called on change in VM's state. This is used 
 to set
 VFIO device state to _RUNNING.
 VM state change handler, migration state change handler and log_sync 
 listener
 are called asynchronously, which sometimes lead to data corruption in 
 migration
 region. Initialised mutex that is used to serialize operations on 
 migration data
 region during saving state.

 Signed-off-by: Kirti Wankhede 
 Reviewed-by: Neo Jia 
 ---
  hw/vfio/migration.c   | 64 
 +++
  hw/vfio/trace-events  |  2 ++
  include/hw/vfio/vfio-common.h |  4 +++
  3 files changed, 70 insertions(+)

 diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
 index a2cfbd5af2e1..c01f08b659d0 100644
 --- a/hw/vfio/migration.c
 +++ b/hw/vfio/migration.c
 @@ -78,6 +78,60 @@ err:
  return ret;
  }
  
 +static int vfio_migration_set_state(VFIODevice *vbasedev, uint32_t state)
 +{
 +VFIOMigration *migration = vbasedev->migration;
 +VFIORegion *region = &migration->region.buffer;
 +uint32_t device_state;
 +int ret = 0;
 +
 +device_state = (state & VFIO_DEVICE_STATE_MASK) |
 +   (vbasedev->device_state & ~VFIO_DEVICE_STATE_MASK);
 +
 +if ((device_state & VFIO_DEVICE_STATE_MASK) == 
 VFIO_DEVICE_STATE_INVALID) {
 +return -EINVAL;
 +}
 +
 +ret = pwrite(vbasedev->fd, &device_state, sizeof(device_state),
 + region->fd_offset + offsetof(struct 
 vfio_device_migration_info,
 +  device_state));
 +if (ret < 0) {
 +error_report("%s: Failed to set device state %d %s",
 + vbasedev->name, ret, strerror(errno));
 +return ret;
 +}
 +
 +vbasedev->device_state = device_state;
 +trace_vfio_migration_set_state(vbasedev->name, device_state);
 +return 0;
 +}
 +
 +static void vfio_vmstate_change(void *opaque, int running, RunState state)
 +{
 +VFIODevice *vbasedev = opaque;
 +
 +if ((vbasedev->vm_running != running)) {
 +int ret;
 +uint32_t dev_state;
 +
 +if (running) {
 +dev_state = VFIO_DEVICE_STATE_RUNNING;
 +} else {
 +dev_state = (vbasedev->device_state & VFIO_DEVICE_STATE_MASK) 
 &
 + ~VFIO_DEVICE_STATE_RUNNING;
 +}
 +
 +ret = vfio_migration_set_state(vbasedev, dev_state);
 +if (ret) {
 +error_report("%s: Failed to set device state 0x%x",
 + vbasedev->name, dev_state);
 +}
 +vbasedev->vm_running = running;
 +trace_vfio_vmstate_change(vbasedev->name, running, 
 RunState_str(state),
 +  dev_state);
 +}
 +}
 +
  static int vfio_migration_init(VFIODevice *vbasedev,
 struct vfio_region_info *info)
  {
 @@ -93,6 +147,11 @@ static int vfio_migration_init(VFIODevice *vbasedev,
  return ret;
  }
  
 +qemu_mutex_init(&vbasedev->migration->lock);
>>>
>>> Does this and it's friend below belong in this patch?  As far as I can
>>> tell you init/deinit the lock here but don't use it which is strange.
>>>
>>
>> This lock is used in
>> 0009-vfio-Add-save-state-functions-to-SaveVMHandlers.patch and
>> 0011-vfio-Add-function-to-get-dirty-page-list.patch
>>
>> Hm. I'll move this init/deinit to patch 0009 in next iteration.
>>
>> Thanks,
>> Kirti
>>
> This lock is used to protect vfio_save_buffer and read dirty page,
> right?
> if data subregion and bitmap subregion do not reuse "data_offset" in
> vfio_device_migration_info.
> It seems that this lock can be avoided.
> 

Same migration region either trapped or mapped can be used for device
data and dirty page. Its not just "data_offset"

Thanks,
Kirti


> Thanks
> Yan
> 
> 
>>
>>> Dave
>>>
 +vbasedev->vm_state = 
 qemu_add_vm_change_state_handler(vfio_vmstate_change,
 +  vbasedev);
 +
  return 0;
  }
  
 @@ -135,11 +194,16 @@ void vfio_migration_finalize(VFIODevice *vbasedev)
  return;
  }
  
 +if (vbasedev->vm_state) {
 +qemu_del_vm_change_state_handler(vbasedev->vm_state);
 +}
 +
  if (vbasedev->migration_blocker) {
  migrate_del_blocker(vbasedev->migration_blocker);
  e

Re: [Qemu-devel] [PATCH v7 09/13] vfio: Add save state functions to SaveVMHandlers

[Kirti Wankhede]

On 7/17/2019 8:20 AM, Yan Zhao wrote:
> On Tue, Jul 09, 2019 at 05:49:16PM +0800, Kirti Wankhede wrote:
>> Added .save_live_pending, .save_live_iterate and .save_live_complete_precopy
>> functions. These functions handles pre-copy and stop-and-copy phase.
>>
>> In _SAVING|_RUNNING device state or pre-copy phase:
>> - read pending_bytes
>> - read data_offset - indicates kernel driver to write data to staging
>>   buffer which is mmapped.
>> - read data_size - amount of data in bytes written by vendor driver in 
>> migration
>>   region.
>> - if data section is trapped, pread() from data_offset of data_size.
>> - if data section is mmaped, read mmaped buffer of data_size.
>> - Write data packet to file stream as below:
>> {VFIO_MIG_FLAG_DEV_DATA_STATE, data_size, actual data,
>> VFIO_MIG_FLAG_END_OF_STATE }
>>
>> In _SAVING device state or stop-and-copy phase
>> a. read config space of device and save to migration file stream. This
>>doesn't need to be from vendor driver. Any other special config state
>>from driver can be saved as data in following iteration.
>> b. read pending_bytes
>> c. read data_offset - indicates kernel driver to write data to staging
>>buffer which is mmapped.
>> d. read data_size - amount of data in bytes written by vendor driver in
>>migration region.
>> e. if data section is trapped, pread() from data_offset of data_size.
>> f. if data section is mmaped, read mmaped buffer of data_size.
>> g. Write data packet as below:
>>{VFIO_MIG_FLAG_DEV_DATA_STATE, data_size, actual data}
>> h. iterate through steps b to g while (pending_bytes > 0)
>> i. Write {VFIO_MIG_FLAG_END_OF_STATE}
>>
>> When data region is mapped, its user's responsibility to read data from
>> data_offset of data_size before moving to next steps.
>>
> each iteration, vendor driver has to set data_offset for device data once
> and for dirty page once. it's really cumbersome.

This should be done so that vendor driver has the flexibility to decide
whether to have data in trapped region or mmapped region. For example,
device data can be in mmapped region and dirty pages data in trapped region.

> could dirty page and device data use different data_offset? e.g.
> data_offset, dirty_page_offset? or just keep them constant after being
> read first time?
> 

Reading device data and dirty page bitmap are atomic operations since
same region can be used to share those. Then having different variable
for both seems redundant.

Later option was discussion in v4 version and we decided not to assume
data_offset for each iteration
https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg05223.html

Thanks,
Kirti

>> .save_live_iterate runs outside the iothread lock in the migration case, 
>> which
>> could race with asynchronous call to get dirty page list causing data 
>> corruption
>> in mapped migration region. Mutex added here to serial migration buffer read
>> operation.
>>
>> Signed-off-by: Kirti Wankhede 
>> Reviewed-by: Neo Jia 
>> ---
>>  hw/vfio/migration.c  | 246 
>> +++
>>  hw/vfio/trace-events |   6 ++
>>  2 files changed, 252 insertions(+)
>>
>> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
>> index 0597a45fda2d..4e9b4cce230b 100644
>> --- a/hw/vfio/migration.c
>> +++ b/hw/vfio/migration.c
>> @@ -117,6 +117,138 @@ static int vfio_migration_set_state(VFIODevice 
>> *vbasedev, uint32_t state)
>>  return 0;
>>  }
>>  
>> +static void *find_data_region(VFIORegion *region,
>> +  uint64_t data_offset,
>> +  uint64_t data_size)
>> +{
>> +void *ptr = NULL;
>> +int i;
>> +
>> +for (i = 0; i < region->nr_mmaps; i++) {
>> +if ((data_offset >= region->mmaps[i].offset) &&
>> +(data_offset < region->mmaps[i].offset + region->mmaps[i].size) 
>> &&
>> +(data_size <= region->mmaps[i].size)) {
>> +ptr = region->mmaps[i].mmap + (data_offset -
>> +   region->mmaps[i].offset);
>> +break;
>> +}
>> +}
>> +return ptr;
>> +}
>> +
>> +static int vfio_save_buffer(QEMUFile *f, VFIODevice *vbasedev)
>> +{
>> +VFIOMigration *migration = vbasedev->migration;
>> +VFIORegion *region = &migration->region.buffer;
>> +uint64_t data_offset = 0, data_size = 0;
>> +int ret;
>> +
>> +ret = pread(vbasedev->fd, &data_offset, sizeof(data_offset),
>> +region->fd_offset + offsetof(struct 
>> vfio_device_migration_info,
>> + data_offset));
>> +if (ret != sizeof(data_offset)) {
>> +error_report("%s: Failed to get migration buffer data offset %d",
>> + vbasedev->name, ret);
>> +return -EINVAL;
>> +}
>> +
>> +ret = pread(vbasedev->fd, &data_size, sizeof(data_size),
>> +region->fd_offset + offsetof(struct 
>> vfio_device_migration_info,
>> + 

Re: [Qemu-devel] [Qemu-block] [PATCH] block: Use QEMU_IS_ALIGNED instead of reinventing it

[Nir Soffer]

On Tue, Aug 20, 2019 at 10:30 PM John Snow  wrote:

>
>
> On 8/17/19 1:53 PM, Nir Soffer wrote:
> > Replace instances of:
> >
> > (n & (BDRV_SECTOR_SIZE - 1)) == 0)
> >
> > With:
> >
> > QEMU_IS_ALIGNED(n, BDRV_SECTOR_SIZE)
> >
>
> Do you have a magical incantation you used to find these?
>

I found the first by accident, then I used:

git grep 'BDRV_SECTOR_SIZE - 1'

> Which reveals the intent of the code better, and makes it easier to
> > locate the code checking alignment.
> >
> > QEMU_IS_ALIGNED is implemented using %, which may be less efficient but
> > it is used only in assert() except one instance, so it should not
> > matter.
> >
>
> There is virtually no way these aren't optimized by the compiler.
>

Makes sense, but I did not check.


>
> > Signed-off-by: Nir Soffer 
>
> Therefore:
>
> Reviewed-by: John Snow 
>
> > ---
> >  block/bochs.c | 4 ++--
> >  block/cloop.c | 4 ++--
> >  block/dmg.c   | 4 ++--
> >  block/io.c| 8 
> >  block/qcow2.c | 4 ++--
> >  block/vvfat.c | 8 
> >  qemu-img.c| 2 +-
> >  7 files changed, 17 insertions(+), 17 deletions(-)
> >
> > diff --git a/block/bochs.c b/block/bochs.c
> > index 962f18592d..32bb83b268 100644
> > --- a/block/bochs.c
> > +++ b/block/bochs.c
> > @@ -248,8 +248,8 @@ bochs_co_preadv(BlockDriverState *bs, uint64_t
> offset, uint64_t bytes,
> >  QEMUIOVector local_qiov;
> >  int ret;
> >
> > -assert((offset & (BDRV_SECTOR_SIZE - 1)) == 0);
> > -assert((bytes & (BDRV_SECTOR_SIZE - 1)) == 0);
> > +assert(QEMU_IS_ALIGNED(offset, BDRV_SECTOR_SIZE));
> > +assert(QEMU_IS_ALIGNED(bytes, BDRV_SECTOR_SIZE));
> >
> >  qemu_iovec_init(&local_qiov, qiov->niov);
> >  qemu_co_mutex_lock(&s->lock);
> > diff --git a/block/cloop.c b/block/cloop.c
> > index 384c9735bb..4de94876d4 100644
> > --- a/block/cloop.c
> > +++ b/block/cloop.c
> > @@ -253,8 +253,8 @@ cloop_co_preadv(BlockDriverState *bs, uint64_t
> offset, uint64_t bytes,
> >  int nb_sectors = bytes >> BDRV_SECTOR_BITS;
> >  int ret, i;
> >
> > -assert((offset & (BDRV_SECTOR_SIZE - 1)) == 0);
> > -assert((bytes & (BDRV_SECTOR_SIZE - 1)) == 0);
> > +assert(QEMU_IS_ALIGNED(offset, BDRV_SECTOR_SIZE));
> > +assert(QEMU_IS_ALIGNED(bytes, BDRV_SECTOR_SIZE));
> >
> >  qemu_co_mutex_lock(&s->lock);
> >
> > diff --git a/block/dmg.c b/block/dmg.c
> > index 45f6b28f17..4a045f2b3e 100644
> > --- a/block/dmg.c
> > +++ b/block/dmg.c
> > @@ -697,8 +697,8 @@ dmg_co_preadv(BlockDriverState *bs, uint64_t offset,
> uint64_t bytes,
> >  int nb_sectors = bytes >> BDRV_SECTOR_BITS;
> >  int ret, i;
> >
> > -assert((offset & (BDRV_SECTOR_SIZE - 1)) == 0);
> > -assert((bytes & (BDRV_SECTOR_SIZE - 1)) == 0);
> > +assert(QEMU_IS_ALIGNED(offset, BDRV_SECTOR_SIZE));
> > +assert(QEMU_IS_ALIGNED(bytes, BDRV_SECTOR_SIZE));
> >
> >  qemu_co_mutex_lock(&s->lock);
> >
> > diff --git a/block/io.c b/block/io.c
> > index 56bbf195bb..7508703ecd 100644
> > --- a/block/io.c
> > +++ b/block/io.c
> > @@ -1080,8 +1080,8 @@ static int coroutine_fn
> bdrv_driver_preadv(BlockDriverState *bs,
> >  sector_num = offset >> BDRV_SECTOR_BITS;
> >  nb_sectors = bytes >> BDRV_SECTOR_BITS;
> >
> > -assert((offset & (BDRV_SECTOR_SIZE - 1)) == 0);
> > -assert((bytes & (BDRV_SECTOR_SIZE - 1)) == 0);
> > +assert(QEMU_IS_ALIGNED(offset, BDRV_SECTOR_SIZE));
> > +assert(QEMU_IS_ALIGNED(bytes, BDRV_SECTOR_SIZE));
> >  assert(bytes <= BDRV_REQUEST_MAX_BYTES);
> >  assert(drv->bdrv_co_readv);
> >
> > @@ -1133,8 +1133,8 @@ static int coroutine_fn
> bdrv_driver_pwritev(BlockDriverState *bs,
> >  sector_num = offset >> BDRV_SECTOR_BITS;
> >  nb_sectors = bytes >> BDRV_SECTOR_BITS;
> >
> > -assert((offset & (BDRV_SECTOR_SIZE - 1)) == 0);
> > -assert((bytes & (BDRV_SECTOR_SIZE - 1)) == 0);
> > +assert(QEMU_IS_ALIGNED(offset, BDRV_SECTOR_SIZE));
> > +assert(QEMU_IS_ALIGNED(bytes, BDRV_SECTOR_SIZE));
> >  assert(bytes <= BDRV_REQUEST_MAX_BYTES);
> >
> >  assert(drv->bdrv_co_writev);
> > diff --git a/block/qcow2.c b/block/qcow2.c
> > index 59cff1d4cb..41cab70e1d 100644
> > --- a/block/qcow2.c
> > +++ b/block/qcow2.c
> > @@ -2072,8 +2072,8 @@ static coroutine_fn int
> qcow2_co_preadv(BlockDriverState *bs, uint64_t offset,
> >  }
> >  if (bs->encrypted) {
> >  assert(s->crypto);
> > -assert((offset & (BDRV_SECTOR_SIZE - 1)) == 0);
> > -assert((cur_bytes & (BDRV_SECTOR_SIZE - 1)) == 0);
> > +assert(QEMU_IS_ALIGNED(offset, BDRV_SECTOR_SIZE));
> > +assert(QEMU_IS_ALIGNED(cur_bytes, BDRV_SECTOR_SIZE));
> >  if (qcow2_co_decrypt(bs, cluster_offset, offset,
> >   cluster_data, cur_bytes) < 0) {
> >  ret = -EIO;
> > diff --git a/block/vvfat.c b/block/vvfat.c
> > index f6c28805dd..019b8f1341 100644
> > --- a/block/vvfat.c
> > +++ b/block/vvf

Re: [Qemu-devel] [PATCH v7 07/13] vfio: Add migration state change notifier

[Kirti Wankhede]

On 7/17/2019 7:55 AM, Yan Zhao wrote:
> On Tue, Jul 09, 2019 at 05:49:14PM +0800, Kirti Wankhede wrote:
>> Added migration state change notifier to get notification on migration state
>> change. These states are translated to VFIO device state and conveyed to 
>> vendor
>> driver.
>>
>> Signed-off-by: Kirti Wankhede 
>> Reviewed-by: Neo Jia 
>> ---
>>  hw/vfio/migration.c   | 54 
>> +++
>>  hw/vfio/trace-events  |  1 +
>>  include/hw/vfio/vfio-common.h |  1 +
>>  3 files changed, 56 insertions(+)
>>
>> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
>> index c01f08b659d0..e4a89a6f9bc7 100644
>> --- a/hw/vfio/migration.c
>> +++ b/hw/vfio/migration.c
>> @@ -132,6 +132,53 @@ static void vfio_vmstate_change(void *opaque, int 
>> running, RunState state)
>>  }
>>  }
>>  
>> +static void vfio_migration_state_notifier(Notifier *notifier, void *data)
>> +{
>> +MigrationState *s = data;
>> +VFIODevice *vbasedev = container_of(notifier, VFIODevice, 
>> migration_state);
>> +int ret;
>> +
>> +trace_vfio_migration_state_notifier(vbasedev->name, s->state);
>> +
>> +switch (s->state) {
>> +case MIGRATION_STATUS_ACTIVE:
>> +if (vbasedev->device_state & VFIO_DEVICE_STATE_RUNNING) {
>> +if (vbasedev->vm_running) {
>> +ret = vfio_migration_set_state(vbasedev,
>> +  VFIO_DEVICE_STATE_RUNNING | 
>> VFIO_DEVICE_STATE_SAVING);
>> +if (ret) {
>> +error_report("%s: Failed to set state RUNNING and 
>> SAVING",
>> +  vbasedev->name);
>> +}
>> +} else {
>> +ret = vfio_migration_set_state(vbasedev,
>> +   VFIO_DEVICE_STATE_SAVING);
>> +if (ret) {
>> +error_report("%s: Failed to set state STOP and SAVING",
>> + vbasedev->name);
>> +}
>> +}
>> +} else {
>> +ret = vfio_migration_set_state(vbasedev,
>> +   VFIO_DEVICE_STATE_RESUMING);
>> +if (ret) {
>> +error_report("%s: Failed to set state RESUMING",
>> + vbasedev->name);
>> +}
>> +}
>> +return;
>> +
> hi Kirti
> currently, migration state notifiers are only notified in below 3 interfaces:
> migrate_fd_connect, migrate_fd_cleanup, postcopy_start, where
> MIGRATION_STATUS_ACTIVE is not an valid state.
> Have you tested the above code? what's the purpose of the code?
> 

Sorry for delayed response.

migration_iteration_finish() -> qemu_bh_schedule(s->cleanup_bh) which is
migrate_fd_cleanup().

migration_iteration_finish() can be called with MIGRATION_STATUS_ACTIVE
state. So migration state notifiers can be called with
MIGRATION_STATUS_ACTIVE. So handled that case here.


Thanks,
Kirti


> Thanks
> Yan
> 
>> +case MIGRATION_STATUS_CANCELLING:
>> +case MIGRATION_STATUS_CANCELLED:
>> +case MIGRATION_STATUS_FAILED:
>> +ret = vfio_migration_set_state(vbasedev, VFIO_DEVICE_STATE_RUNNING);
>> +if (ret) {
>> +error_report("%s: Failed to set state RUNNING", vbasedev->name);
>> +}
>> +return;
>> +}
>> +}
>> +
>>  static int vfio_migration_init(VFIODevice *vbasedev,
>> struct vfio_region_info *info)
>>  {
>> @@ -152,6 +199,9 @@ static int vfio_migration_init(VFIODevice *vbasedev,
>>  vbasedev->vm_state = 
>> qemu_add_vm_change_state_handler(vfio_vmstate_change,
>>vbasedev);
>>  
>> +vbasedev->migration_state.notify = vfio_migration_state_notifier;
>> +add_migration_state_change_notifier(&vbasedev->migration_state);
>> +
>>  return 0;
>>  }
>>  
>> @@ -194,6 +244,10 @@ void vfio_migration_finalize(VFIODevice *vbasedev)
>>  return;
>>  }
>>  
>> +if (vbasedev->migration_state.notify) {
>> +remove_migration_state_change_notifier(&vbasedev->migration_state);
>> +}
>> +
>>  if (vbasedev->vm_state) {
>>  qemu_del_vm_change_state_handler(vbasedev->vm_state);
>>  }
>> diff --git a/hw/vfio/trace-events b/hw/vfio/trace-events
>> index 3d15bacd031a..69503228f20e 100644
>> --- a/hw/vfio/trace-events
>> +++ b/hw/vfio/trace-events
>> @@ -148,3 +148,4 @@ vfio_display_edid_write_error(void) ""
>>  vfio_migration_probe(char *name, uint32_t index) " (%s) Region %d"
>>  vfio_migration_set_state(char *name, uint32_t state) " (%s) state %d"
>>  vfio_vmstate_change(char *name, int running, const char *reason, uint32_t 
>> dev_state) " (%s) running %d reason %s device state %d"
>> +vfio_migration_state_notifier(char *name, int state) " (%s) state %d"
>> diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h
>> index f6c70db3a9c1..a022484d2636 100644
>> --

Re: [Qemu-devel] [PATCH v2] RISC-V: Select FPU gdb xml file based on the supported extensions

[Richard Henderson]

On 8/20/19 1:06 PM, Jim Wilson wrote:
> I don't see a need to remove the fp csr's from the csr list.  There are other
> extension dependent CSRs, like hypervisor ones. I think it makes more sense 
> for
> the csr list to contain all of the csrs, and then disable access to them if
> that extension is not enabled.  If there is a good reason to require changes 
> to
> the csr XML files, then it probably should be discussed with the gdb 
> developers
> too, so that the gdb and qemu copies of the files remain consistent.

Another possibility is to generate the list of csr's at runtime and export that
to the connecting gdb.

We do this in target/arm/gdbstub.c, arm_gen_dynamic_xml.


r~

Re: [Qemu-devel] [PATCH v2] RISC-V: Select FPU gdb xml file based on the supported extensions

[Jim Wilson]

On 8/20/19 7:39 AM, Georg Kotheimer wrote:

The size of the FPU registers depends solely on the floating point
extensions supported by the target architecture.
However, in the previous implementation the floating point register
size was derived from whether the target architecture is 32-bit or
64-bit.

To allow RVF without RVD, changes to riscv_gdb_get_fpu() and
riscv_gdb_set_fpu() were necessary.

In addition fflags, frm and fcsr were removed from
riscv-XXbit-csr.xml, as the floating point csr registers are only
available, if a FPU is present.


The current XML files were identical to the XML files in gdb when 
implemented.  This seems to be existing practice, as this is true of all 
of the other targets I looked at when I implemented this.  Also, the 
file names are the same with a / replaced with a -.  These files are in 
the gdb/features/riscv dir in a gdb source tree.  It would be a shame to 
break this.  I'm not sure if they are still identical.  The gdb copies 
might have been updated since then, and may need to be copied into qemu 
to update qemu, but we don't have a dedicated gdb/qemu maintainer to do 
this.


I don't see a need to remove the fp csr's from the csr list.  There are 
other extension dependent CSRs, like hypervisor ones. I think it makes 
more sense for the csr list to contain all of the csrs, and then disable 
access to them if that extension is not enabled.  If there is a good 
reason to require changes to the csr XML files, then it probably should 
be discussed with the gdb developers too, so that the gdb and qemu 
copies of the files remain consistent.


Fixing the rvf/rvd 32/64-bit support is good.  That is a bug in my 
original implementation.


Jim

Re: [Qemu-devel] [PATCH] block: Use QEMU_IS_ALIGNED instead of reinventing it

[Max Reitz]

On 17.08.19 19:53, Nir Soffer wrote:
> Replace instances of:
> 
> (n & (BDRV_SECTOR_SIZE - 1)) == 0)
> 
> With:
> 
> QEMU_IS_ALIGNED(n, BDRV_SECTOR_SIZE)
> 
> Which reveals the intent of the code better, and makes it easier to
> locate the code checking alignment.
> 
> QEMU_IS_ALIGNED is implemented using %, which may be less efficient but
> it is used only in assert() except one instance, so it should not
> matter.
> 
> Signed-off-by: Nir Soffer 
> ---
>  block/bochs.c | 4 ++--
>  block/cloop.c | 4 ++--
>  block/dmg.c   | 4 ++--
>  block/io.c| 8 
>  block/qcow2.c | 4 ++--
>  block/vvfat.c | 8 
>  qemu-img.c| 2 +-
>  7 files changed, 17 insertions(+), 17 deletions(-)

Because John was speaking about a magical incantation, I found
BDRV_SECTOR_MASK.  There are two places in block/qcow2-cluster.c that
use that to check alignment, I think those should be amended as well.

Max



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 0/4] backup: fix skipping unallocated clusters

[John Snow]

On 8/20/19 4:28 AM, Vladimir Sementsov-Ogievskiy wrote:
> 16.08.2019 22:11, John Snow wrote:
>>
>>
>> On 8/14/19 12:54 PM, Vladimir Sementsov-Ogievskiy wrote:
>>>
>>>
>>> 14 авг. 2019 г. 17:43 пользователь Vladimir Sementsov-Ogievskiy
>>>  написал:
>>>
>>>  Hi all!
>>>
>>>  There is a bug in not yet merged patch
>>>  "block/backup: teach TOP to never copy unallocated regions"
>>>  in https://github.com/jnsnow/qemu bitmaps. 04 fixes it. So, I propose
>>>  to put 01-03 somewhere before
>>>  "block/backup: teach TOP to never copy unallocated regions"
>>>  and squash 04 into "block/backup: teach TOP to never copy
>>>  unallocated regions"
>>>
>>>
>>> Hmm, don't bother with it. Simpler is fix the bug in your commit by just
>>> use skip_bytes variable when initializing dirty_end.
>>>
>>
>> OK, just use Max's fix instead of this entire 4 patch series?
>>
>> --js
>>
> 
> Yes, I think it's OK
> 

ACK, thank you!

Re: [Qemu-devel] [Qemu-block] [PATCH] block: Use QEMU_IS_ALIGNED instead of reinventing it

[John Snow]

On 8/17/19 1:53 PM, Nir Soffer wrote:
> Replace instances of:
> 
> (n & (BDRV_SECTOR_SIZE - 1)) == 0)
> 
> With:
> 
> QEMU_IS_ALIGNED(n, BDRV_SECTOR_SIZE)
> 

Do you have a magical incantation you used to find these?

> Which reveals the intent of the code better, and makes it easier to
> locate the code checking alignment.
> 
> QEMU_IS_ALIGNED is implemented using %, which may be less efficient but
> it is used only in assert() except one instance, so it should not
> matter.
> 

There is virtually no way these aren't optimized by the compiler.

> Signed-off-by: Nir Soffer 

Therefore:

Reviewed-by: John Snow 

> ---
>  block/bochs.c | 4 ++--
>  block/cloop.c | 4 ++--
>  block/dmg.c   | 4 ++--
>  block/io.c| 8 
>  block/qcow2.c | 4 ++--
>  block/vvfat.c | 8 
>  qemu-img.c| 2 +-
>  7 files changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/block/bochs.c b/block/bochs.c
> index 962f18592d..32bb83b268 100644
> --- a/block/bochs.c
> +++ b/block/bochs.c
> @@ -248,8 +248,8 @@ bochs_co_preadv(BlockDriverState *bs, uint64_t offset, 
> uint64_t bytes,
>  QEMUIOVector local_qiov;
>  int ret;
>  
> -assert((offset & (BDRV_SECTOR_SIZE - 1)) == 0);
> -assert((bytes & (BDRV_SECTOR_SIZE - 1)) == 0);
> +assert(QEMU_IS_ALIGNED(offset, BDRV_SECTOR_SIZE));
> +assert(QEMU_IS_ALIGNED(bytes, BDRV_SECTOR_SIZE));
>  
>  qemu_iovec_init(&local_qiov, qiov->niov);
>  qemu_co_mutex_lock(&s->lock);
> diff --git a/block/cloop.c b/block/cloop.c
> index 384c9735bb..4de94876d4 100644
> --- a/block/cloop.c
> +++ b/block/cloop.c
> @@ -253,8 +253,8 @@ cloop_co_preadv(BlockDriverState *bs, uint64_t offset, 
> uint64_t bytes,
>  int nb_sectors = bytes >> BDRV_SECTOR_BITS;
>  int ret, i;
>  
> -assert((offset & (BDRV_SECTOR_SIZE - 1)) == 0);
> -assert((bytes & (BDRV_SECTOR_SIZE - 1)) == 0);
> +assert(QEMU_IS_ALIGNED(offset, BDRV_SECTOR_SIZE));
> +assert(QEMU_IS_ALIGNED(bytes, BDRV_SECTOR_SIZE));
>  
>  qemu_co_mutex_lock(&s->lock);
>  
> diff --git a/block/dmg.c b/block/dmg.c
> index 45f6b28f17..4a045f2b3e 100644
> --- a/block/dmg.c
> +++ b/block/dmg.c
> @@ -697,8 +697,8 @@ dmg_co_preadv(BlockDriverState *bs, uint64_t offset, 
> uint64_t bytes,
>  int nb_sectors = bytes >> BDRV_SECTOR_BITS;
>  int ret, i;
>  
> -assert((offset & (BDRV_SECTOR_SIZE - 1)) == 0);
> -assert((bytes & (BDRV_SECTOR_SIZE - 1)) == 0);
> +assert(QEMU_IS_ALIGNED(offset, BDRV_SECTOR_SIZE));
> +assert(QEMU_IS_ALIGNED(bytes, BDRV_SECTOR_SIZE));
>  
>  qemu_co_mutex_lock(&s->lock);
>  
> diff --git a/block/io.c b/block/io.c
> index 56bbf195bb..7508703ecd 100644
> --- a/block/io.c
> +++ b/block/io.c
> @@ -1080,8 +1080,8 @@ static int coroutine_fn 
> bdrv_driver_preadv(BlockDriverState *bs,
>  sector_num = offset >> BDRV_SECTOR_BITS;
>  nb_sectors = bytes >> BDRV_SECTOR_BITS;
>  
> -assert((offset & (BDRV_SECTOR_SIZE - 1)) == 0);
> -assert((bytes & (BDRV_SECTOR_SIZE - 1)) == 0);
> +assert(QEMU_IS_ALIGNED(offset, BDRV_SECTOR_SIZE));
> +assert(QEMU_IS_ALIGNED(bytes, BDRV_SECTOR_SIZE));
>  assert(bytes <= BDRV_REQUEST_MAX_BYTES);
>  assert(drv->bdrv_co_readv);
>  
> @@ -1133,8 +1133,8 @@ static int coroutine_fn 
> bdrv_driver_pwritev(BlockDriverState *bs,
>  sector_num = offset >> BDRV_SECTOR_BITS;
>  nb_sectors = bytes >> BDRV_SECTOR_BITS;
>  
> -assert((offset & (BDRV_SECTOR_SIZE - 1)) == 0);
> -assert((bytes & (BDRV_SECTOR_SIZE - 1)) == 0);
> +assert(QEMU_IS_ALIGNED(offset, BDRV_SECTOR_SIZE));
> +assert(QEMU_IS_ALIGNED(bytes, BDRV_SECTOR_SIZE));
>  assert(bytes <= BDRV_REQUEST_MAX_BYTES);
>  
>  assert(drv->bdrv_co_writev);
> diff --git a/block/qcow2.c b/block/qcow2.c
> index 59cff1d4cb..41cab70e1d 100644
> --- a/block/qcow2.c
> +++ b/block/qcow2.c
> @@ -2072,8 +2072,8 @@ static coroutine_fn int 
> qcow2_co_preadv(BlockDriverState *bs, uint64_t offset,
>  }
>  if (bs->encrypted) {
>  assert(s->crypto);
> -assert((offset & (BDRV_SECTOR_SIZE - 1)) == 0);
> -assert((cur_bytes & (BDRV_SECTOR_SIZE - 1)) == 0);
> +assert(QEMU_IS_ALIGNED(offset, BDRV_SECTOR_SIZE));
> +assert(QEMU_IS_ALIGNED(cur_bytes, BDRV_SECTOR_SIZE));
>  if (qcow2_co_decrypt(bs, cluster_offset, offset,
>   cluster_data, cur_bytes) < 0) {
>  ret = -EIO;
> diff --git a/block/vvfat.c b/block/vvfat.c
> index f6c28805dd..019b8f1341 100644
> --- a/block/vvfat.c
> +++ b/block/vvfat.c
> @@ -1547,8 +1547,8 @@ vvfat_co_preadv(BlockDriverState *bs, uint64_t offset, 
> uint64_t bytes,
>  int nb_sectors = bytes >> BDRV_SECTOR_BITS;
>  void *buf;
>  
> -assert((offset & (BDRV_SECTOR_SIZE - 1)) == 0);
> -assert((bytes & (BDRV_SECTOR_SIZE - 1)) == 0);
> +assert(QEMU_IS_ALIGNED(offset, BDRV_SECTOR_SIZE));
> +assert(QEMU_IS_ALIGNED(bytes, BDRV_

Re: [Qemu-devel] [PATCH] iotests: Check for enabled drivers before testing them

[Max Reitz]

On 20.08.19 21:19, Thomas Huth wrote:
> On 8/20/19 8:48 PM, Max Reitz wrote:
>> On 20.08.19 18:01, Thomas Huth wrote:
> [...]
>>> Well, we disable blkverify in our downstream RHEL version of QEMU - so
>>> it would be great if the iotests could at least adapt to that missing
>>> driver.
>>
>> I would like to say that RHEL is not a gold standard
> 
> Well, let's put it this way: The less changes we have to carry along
> downstream (and thus review each time we rebase the downstream tree),
> the more time we have to work on upstream.

As I said, I’m guilty myself.

>> It feels a bit weird to me to say “blkverify is not essential, because
>> RHEL disables it, but null-co is” – even though there is no reason why
>> anyone would need null-co except for testing either.
> 
> Ok, fine for me, too, if we also declare "null-co" as optional for the
> iotests - let's make sure that the tests in the "auto" group also work
> without them.

Well, should we or not?  You said there are other tests (outside of the
iotests) that break without null-co.  If so, I don’t think there’s any
point in making it optional here.

 Of course, that no longer works as an argument now that we
 unconditionally run some iotests in make check.

 But still, the question is how strict you want to be.  If blkdebug
 cannot be assumed to be present, what about null-co?  What about raw?
>>>
>>> I tried to disable everything beside qcow2 - but that causes so many
>>> things to fail that it hardly makes sense to try to get that working.
>>
>> Hm, really?  I just whitelisted qcow2 and file and running the auto
>> group worked rather well (except for the failing tests you address here,
>> and the two others I mentioned).
> 
> IIRC I tried to run all qcow2 tests when I disabled null-co and saw lots
> of failures ... but anyway, let's just focus on the "auto" tests right
> now, that should be doable.

OK, I didn’t bother running all. :-)

Max



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH] iotests: Check for enabled drivers before testing them

[Thomas Huth]

On 8/20/19 8:48 PM, Max Reitz wrote:
> On 20.08.19 18:01, Thomas Huth wrote:
[...]
>> Well, we disable blkverify in our downstream RHEL version of QEMU - so
>> it would be great if the iotests could at least adapt to that missing
>> driver.
> 
> I would like to say that RHEL is not a gold standard

Well, let's put it this way: The less changes we have to carry along
downstream (and thus review each time we rebase the downstream tree),
the more time we have to work on upstream.

> It feels a bit weird to me to say “blkverify is not essential, because
> RHEL disables it, but null-co is” – even though there is no reason why
> anyone would need null-co except for testing either.

Ok, fine for me, too, if we also declare "null-co" as optional for the
iotests - let's make sure that the tests in the "auto" group also work
without them.

>>> Of course, that no longer works as an argument now that we
>>> unconditionally run some iotests in make check.
>>>
>>> But still, the question is how strict you want to be.  If blkdebug
>>> cannot be assumed to be present, what about null-co?  What about raw?
>>
>> I tried to disable everything beside qcow2 - but that causes so many
>> things to fail that it hardly makes sense to try to get that working.
> 
> Hm, really?  I just whitelisted qcow2 and file and running the auto
> group worked rather well (except for the failing tests you address here,
> and the two others I mentioned).

IIRC I tried to run all qcow2 tests when I disabled null-co and saw lots
of failures ... but anyway, let's just focus on the "auto" tests right
now, that should be doable.

 Thomas



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v10] qemu-io: add pattern file for write command

[Max Reitz]

On 20.08.19 19:24, Eric Blake wrote:
> On 8/20/19 11:46 AM, Denis Plotnikov wrote:
>> The patch allows to provide a pattern file for write
>> command. There was no similar ability before.
>>
>> Signed-off-by: Denis Plotnikov 
>> ---
> 
>> @@ -983,8 +1057,9 @@ static int write_f(BlockBackend *blk, int argc, char 
>> **argv)
>>  /* Some compilers get confused and warn if this is not initialized.  */
>>  int64_t total = 0;
>>  int pattern = 0xcd;
>> +const char *file_name = NULL;
>>  
>> -while ((c = getopt(argc, argv, "bcCfnpP:quz")) != -1) {
>> +while ((c = getopt(argc, argv, "bcCfnpP:quzs:")) != -1) {
> 
> This one looks odd (I would have preserved ordering by sticking s:
> between q and u).  But a maintainer could fix that.
> 
>>  switch (c) {
>>  case 'b':
>>  bflag = true;
>> @@ -1020,6 +1095,10 @@ static int write_f(BlockBackend *blk, int argc, char 
>> **argv)
>>  case 'z':
>>  zflag = true;
>>  break;
>> +case 's':
>> +sflag = true;
>> +file_name = optarg;
>> +break;
> 
> Likewise, sorting the cases in the same order as the getopt() listing
> helps in finding code during later edits.

But it is in order of the getopt() listing. ;-)

>> @@ -1088,7 +1168,14 @@ static int write_f(BlockBackend *blk, int argc, char 
>> **argv)
>>  }
>>  
>>  if (!zflag) {
>> -buf = qemu_io_alloc(blk, count, pattern);
>> +if (sflag) {
>> +buf = qemu_io_alloc_from_file(blk, count, file_name);
>> +if (!buf) {
>> +return -EINVAL;
>> +}
>> +} else {
>> +buf = qemu_io_alloc(blk, count, pattern);
>> +}
> 
> Pre-existing, but it is odd that qemu_io_alloc() exit()s rather than
> returning NULL on huge allocation requests that can't be met.  (Then
> again, we have an early exit on any length > 2G, and 2G allocations tend
> to succeed on modern development machines).  Perhaps it would be nice to
> teach qemu-io to use blk_try_blockalign for more graceful handling even
> on 32-bit platforms, but that's not the problem of your patch.

Then again, this is qemu-io.  Printing an error instead of just aborting
doesn’t really help anyone.

Also, the code would be wrong without an early exit on a length >
INT_MAX.  (Because pattern_len is an int, so the result of fread() might
overflow otherwise, which would be bad.)

(I just noticed that fread() might do a short read, but let’s just
ignore this at this point.)

> Option ordering is minor enough that I'm fine giving:
> 
> Reviewed-by: Eric Blake 
> 
> Now, to figure out which maintainer should take it.  Perhaps you want to
> add a patch 2/1 that adds an iotest using this new mode, to a) ensure it
> doesn't regress, and b) makes it reasonable to take in through the
> iotest tree.

Adding a test does not seem to bad of an idea, but I don’t see how that
would clarify things.  Both qemu-io and the iotests are part of the
block layer core:

$ scripts/get_maintainer.pl -f qemu-io-cmds.c
Kevin Wolf  (supporter:Block layer core)
Max Reitz  (supporter:Block layer core)
qemu-bl...@nongnu.org (open list:Block layer core)
qemu-devel@nongnu.org (open list:All patches CC here)

$ scripts/get_maintainer.pl -f tests/qemu-iotests
Kevin Wolf  (supporter:Block layer core)
Max Reitz  (supporter:Block layer core)
qemu-bl...@nongnu.org (open list:Block layer core)
qemu-devel@nongnu.org (open list:All patches CC here)


So we only need to figure out whether it should be Kevin or me to take
it; but Kevin is on PTO, so that decision is simple. :-)

Therefor, I’ve changed the optstring (and switch case) order to be
alphabetical, and applied the patch to my block branch:

https://git.xanclic.moe/XanClic/qemu/commits/branch/block

Thanks for the patch and the review,

Max


(I wouldn’t mind an iotest, but well.  qemu-io itself is a testing
utility, so I don’t deem it important to test it.)



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v10] qemu-io: add pattern file for write command

[John Snow]

On 8/20/19 1:24 PM, Eric Blake wrote:
> On 8/20/19 11:46 AM, Denis Plotnikov wrote:
>> The patch allows to provide a pattern file for write
>> command. There was no similar ability before.
>>
>> Signed-off-by: Denis Plotnikov 
>> ---
> 
>> @@ -983,8 +1057,9 @@ static int write_f(BlockBackend *blk, int argc, char 
>> **argv)
>>  /* Some compilers get confused and warn if this is not initialized.  */
>>  int64_t total = 0;
>>  int pattern = 0xcd;
>> +const char *file_name = NULL;
>>  
>> -while ((c = getopt(argc, argv, "bcCfnpP:quz")) != -1) {
>> +while ((c = getopt(argc, argv, "bcCfnpP:quzs:")) != -1) {
> 
> This one looks odd (I would have preserved ordering by sticking s:
> between q and u).  But a maintainer could fix that.
> 
>>  switch (c) {
>>  case 'b':
>>  bflag = true;
>> @@ -1020,6 +1095,10 @@ static int write_f(BlockBackend *blk, int argc, char 
>> **argv)
>>  case 'z':
>>  zflag = true;
>>  break;
>> +case 's':
>> +sflag = true;
>> +file_name = optarg;
>> +break;
> 
> Likewise, sorting the cases in the same order as the getopt() listing
> helps in finding code during later edits.
> 
>> @@ -1088,7 +1168,14 @@ static int write_f(BlockBackend *blk, int argc, char 
>> **argv)
>>  }
>>  
>>  if (!zflag) {
>> -buf = qemu_io_alloc(blk, count, pattern);
>> +if (sflag) {
>> +buf = qemu_io_alloc_from_file(blk, count, file_name);
>> +if (!buf) {
>> +return -EINVAL;
>> +}
>> +} else {
>> +buf = qemu_io_alloc(blk, count, pattern);
>> +}
> 
> Pre-existing, but it is odd that qemu_io_alloc() exit()s rather than
> returning NULL on huge allocation requests that can't be met.  (Then
> again, we have an early exit on any length > 2G, and 2G allocations tend
> to succeed on modern development machines).  Perhaps it would be nice to
> teach qemu-io to use blk_try_blockalign for more graceful handling even
> on 32-bit platforms, but that's not the problem of your patch.
> 
> Option ordering is minor enough that I'm fine giving:
> 
> Reviewed-by: Eric Blake 
> 
> Now, to figure out which maintainer should take it.  Perhaps you want to
> add a patch 2/1 that adds an iotest using this new mode, to a) ensure it
> doesn't regress, and b) makes it reasonable to take in through the
> iotest tree.
> 

Yes, this is a good idea. I'm sure over time we'll pick up uses of
pattern writing that will strengthen the the regression testing of the
feature, but for now a simple test case will help ensure it.

(It'll also help "document" how to use the feature for other test writers.)

Thanks!

Re: [Qemu-devel] [RFC v2] hw/sd/aspeed_sdhci: New device

[Eddie James]

On 8/19/19 1:41 AM, Cédric Le Goater wrote:

On 15/08/2019 22:13, Eddie James wrote:

On 8/15/19 3:05 AM, Cédric Le Goater wrote:

Hello Eddie,

On 14/08/2019 22:27, Eddie James wrote:

The Aspeed SOCs have two SD/MMC controllers. Add a device that
encapsulates both of these controllers and models the Aspeed-specific
registers and behavior.

Tested by reading from mmcblk0 in Linux:
qemu-system-arm -machine romulus-bmc -nographic -serial mon:stdio \
   -drive file=_tmp/flash-romulus,format=raw,if=mtd \
   -device sd-card,drive=sd0 -drive file=_tmp/kernel,format=raw,if=sd

Signed-off-by: Eddie James 
---
This patch applies on top of Cedric's set of recent Aspeed changes. Therefore,
I'm sending as an RFC rather than a patch.

yes. we can worked that out when the patch is reviewed. You can base on
mainline when ready. My tree serves as an overall test base.


Changes since v1:
   - Move slot realize code into the Aspeed SDHCI realize function
   - Fix interrupt handling by creating input irqs and connecting them to the
     slot irqs.
   - Removed card device creation code

I think all the code is here but it needs some more reshuffling :)
   The raspi machine is a good source for modelling pratices.


   hw/arm/aspeed.c  |   1 -
   hw/arm/aspeed_soc.c  |  24 ++
   hw/sd/Makefile.objs  |   1 +
   hw/sd/aspeed_sdhci.c | 190 
+++
   include/hw/arm/aspeed_soc.h  |   3 +
   include/hw/sd/aspeed_sdhci.h |  35 
   6 files changed, 253 insertions(+), 1 deletion(-)
   create mode 100644 hw/sd/aspeed_sdhci.c
   create mode 100644 include/hw/sd/aspeed_sdhci.h

diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index 2574425..aeed5b6 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -480,7 +480,6 @@ static void aspeed_machine_class_init(ObjectClass *oc, void 
*data)
   mc->desc = board->desc;
   mc->init = aspeed_machine_init;
   mc->max_cpus = ASPEED_CPUS_NUM;
-    mc->no_sdcard = 1;
   mc->no_floppy = 1;
   mc->no_cdrom = 1;
   mc->no_parallel = 1;
diff --git a/hw/arm/aspeed_soc.c b/hw/arm/aspeed_soc.c
index 8df96f2..a12f14a 100644
--- a/hw/arm/aspeed_soc.c
+++ b/hw/arm/aspeed_soc.c
@@ -22,6 +22,7 @@
   #include "qemu/error-report.h"
   #include "hw/i2c/aspeed_i2c.h"
   #include "net/net.h"
+#include "sysemu/blockdev.h"

I would expect block devices to be handled at the machine level in
aspeed.c, like the flash devices are. Something like :


OK, I did have that in v1 but Peter mentioned it was typically done at the 
command line?

yes, indeed. This works also and this is less code which is even better.


I guess it can go in aspeed.c too.

Well, let's do without if we can.

We might be able to get rid of aspeed_board_init_flashes() now.

We should start writing a QEMU cookbook page on the OpenBMC wiki to
document the Aspeed machine command line.





  /* Create and plug in the SD cards */
  for (i = 0; i < ASPEED_SDHCI_NUM_SLOTS; i++) {
  BusState *bus;
  DriveInfo *di = drive_get_next(IF_SD);
  BlockBackend *blk = di ? blk_by_legacy_dinfo(di) : NULL;
  DeviceState *carddev;

  bus = qdev_get_child_bus(DEVICE(&s->soc), "sd-bus");
  if (!bus) {
  error_report("No SD bus found for SD card %d", i);
  exit(1);
  }
  carddev = qdev_create(bus, TYPE_SD_CARD);
  qdev_prop_set_drive(carddev, "drive", blk, &error_fatal);
  object_property_set_bool(OBJECT(carddev), true, "realized",
   &error_fatal);
  }


     #define ASPEED_SOC_IOMEM_SIZE   0x0020
   @@ -62,6 +63,7 @@ static const hwaddr aspeed_soc_ast2500_memmap[] = {
   [ASPEED_XDMA]   = 0x1E6E7000,
   [ASPEED_ADC]    = 0x1E6E9000,
   [ASPEED_SRAM]   = 0x1E72,
+    [ASPEED_SDHCI]  = 0x1E74,
   [ASPEED_GPIO]   = 0x1E78,
   [ASPEED_RTC]    = 0x1E781000,
   [ASPEED_TIMER1] = 0x1E782000,
@@ -100,6 +102,7 @@ static const hwaddr aspeed_soc_ast2600_memmap[] = {
   [ASPEED_XDMA]   = 0x1E6E7000,
   [ASPEED_ADC]    = 0x1E6E9000,
   [ASPEED_VIDEO]  = 0x1E70,
+    [ASPEED_SDHCI]  = 0x1E74,
   [ASPEED_GPIO]   = 0x1E78,
   [ASPEED_RTC]    = 0x1E781000,
   [ASPEED_TIMER1] = 0x1E782000,
@@ -146,6 +149,7 @@ static const int aspeed_soc_ast2400_irqmap[] = {
   [ASPEED_ETH1]   = 2,
   [ASPEED_ETH2]   = 3,
   [ASPEED_XDMA]   = 6,
+    [ASPEED_SDHCI]  = 26,
   };
     #define aspeed_soc_ast2500_irqmap aspeed_soc_ast2400_irqmap
@@ -163,6 +167,7 @@ static const int aspeed_soc_ast2600_irqmap[] = {
   [ASPEED_SDMC]   = 0,
   [ASPEED_SCU]    = 12,
   [ASPEED_XDMA]   = 6,
+    [ASPEED_SDHCI]  = 43,
   [ASPEED_ADC]    = 46,
   [ASPEED_GPIO]   = 40,
   [ASPEED_RTC]    = 13,
@@ -350,6 +355,15 @@ static void aspeed_soc_init(Object *obj)
   sysbus_init_child_obj(obj, "fsi[*]", OBJECT(&s->fsi[0]),
  

[Qemu-devel] [RFC v3] hw/sd/aspeed_sdhci: New device

[Eddie James]

The Aspeed SOCs have two SD/MMC controllers. Add a device that
encapsulates both of these controllers and models the Aspeed-specific
registers and behavior.

Tested by reading from mmcblk0 in Linux:
qemu-system-arm -machine romulus-bmc -nographic \
 -drive file=flash-romulus,format=raw,if=mtd \
 -device sd-card,drive=sd0 -drive file=_tmp/kernel,format=raw,if=sd

Signed-off-by: Eddie James 
---
This patch applies on top of Cedric's set of recent Aspeed changes.
Therefore, I'm sending as an RFC rather than a patch for review.

Changes since v2:
 - Do the memory mapping at the SOC level
 - Add guest errors for out-of-bounds access to the SDHCI regs
 - Remove unnecessary blockdev include in aspeed_soc.c
 - Better naming for SDHCI objects.

Changes since v1:
 - Move slot realize code into the Aspeed SDHCI realize function
 - Fix interrupt handling by creating input irqs and connecting them to the
   slot irqs.
 - Removed card device creation code
 hw/arm/aspeed.c  |   1 -
 hw/arm/aspeed_soc.c  |  28 +++
 hw/sd/Makefile.objs  |   1 +
 hw/sd/aspeed_sdhci.c | 194 +++
 include/hw/arm/aspeed_soc.h  |   3 +
 include/hw/sd/aspeed_sdhci.h |  34 
 6 files changed, 260 insertions(+), 1 deletion(-)
 create mode 100644 hw/sd/aspeed_sdhci.c
 create mode 100644 include/hw/sd/aspeed_sdhci.h

diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index 2574425..aeed5b6 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -480,7 +480,6 @@ static void aspeed_machine_class_init(ObjectClass *oc, void 
*data)
 mc->desc = board->desc;
 mc->init = aspeed_machine_init;
 mc->max_cpus = ASPEED_CPUS_NUM;
-mc->no_sdcard = 1;
 mc->no_floppy = 1;
 mc->no_cdrom = 1;
 mc->no_parallel = 1;
diff --git a/hw/arm/aspeed_soc.c b/hw/arm/aspeed_soc.c
index c9f6e01..292751e 100644
--- a/hw/arm/aspeed_soc.c
+++ b/hw/arm/aspeed_soc.c
@@ -62,6 +62,7 @@ static const hwaddr aspeed_soc_ast2500_memmap[] = {
 [ASPEED_XDMA]   = 0x1E6E7000,
 [ASPEED_ADC]= 0x1E6E9000,
 [ASPEED_SRAM]   = 0x1E72,
+[ASPEED_SDHCI]  = 0x1E74,
 [ASPEED_GPIO]   = 0x1E78,
 [ASPEED_RTC]= 0x1E781000,
 [ASPEED_TIMER1] = 0x1E782000,
@@ -102,6 +103,7 @@ static const hwaddr aspeed_soc_ast2600_memmap[] = {
 [ASPEED_XDMA]  = 0x1E6E7000,
 [ASPEED_ADC]   = 0x1E6E9000,
 [ASPEED_VIDEO] = 0x1E70,
+[ASPEED_SDHCI] = 0x1E74,
 [ASPEED_GPIO]  = 0x1E78,
 [ASPEED_GPIO_1_8V] = 0x1E780800,
 [ASPEED_RTC]   = 0x1E781000,
@@ -147,6 +149,7 @@ static const int aspeed_soc_ast2400_irqmap[] = {
 [ASPEED_ETH1]   = 2,
 [ASPEED_ETH2]   = 3,
 [ASPEED_XDMA]   = 6,
+[ASPEED_SDHCI]  = 26,
 };
 
 #define aspeed_soc_ast2500_irqmap aspeed_soc_ast2400_irqmap
@@ -185,6 +188,7 @@ static const int aspeed_soc_ast2600_irqmap[] = {
 [ASPEED_ETH2]  = 3,
 [ASPEED_FSI1]  = 100,
 [ASPEED_FSI2]  = 101,
+[ASPEED_SDHCI] = 43,
 };
 
 static const AspeedSoCInfo aspeed_socs[] = {
@@ -357,6 +361,15 @@ static void aspeed_soc_init(Object *obj)
 sysbus_init_child_obj(obj, "fsi[*]", OBJECT(&s->fsi[0]),
   sizeof(s->fsi[0]), TYPE_ASPEED_FSI);
 }
+
+sysbus_init_child_obj(obj, "sdc", OBJECT(&s->sdhci), sizeof(s->sdhci),
+  TYPE_ASPEED_SDHCI);
+
+/* Init sd card slot class here so that they're under the correct parent */
+for (i = 0; i < ASPEED_SDHCI_NUM_SLOTS; ++i) {
+sysbus_init_child_obj(obj, "sdhci[*]", OBJECT(&s->sdhci.slots[i]),
+  sizeof(s->sdhci.slots[i]), TYPE_SYSBUS_SDHCI);
+}
 }
 
 /*
@@ -698,6 +711,21 @@ static void aspeed_soc_realize(DeviceState *dev, Error 
**errp)
 sysbus_connect_irq(SYS_BUS_DEVICE(&s->fsi[0]), 0,
aspeed_soc_get_irq(s, ASPEED_FSI1));
 }
+
+/* SDHCI */
+object_property_set_bool(OBJECT(&s->sdhci), true, "realized", &err);
+if (err) {
+error_propagate(errp, err);
+return;
+}
+for (i = 0; i < ASPEED_SDHCI_NUM_SLOTS; ++i) {
+sysbus_mmio_map(SYS_BUS_DEVICE(&s->sdhci.slots[i]), 0,
+sc->info->memmap[ASPEED_SDHCI] + ((i + 1) * 0x100));
+}
+sysbus_mmio_map(SYS_BUS_DEVICE(&s->sdhci), 0,
+sc->info->memmap[ASPEED_SDHCI]);
+sysbus_connect_irq(SYS_BUS_DEVICE(&s->sdhci), 0,
+   aspeed_soc_get_irq(s, ASPEED_SDHCI));
 }
 static Property aspeed_soc_properties[] = {
 DEFINE_PROP_UINT32("num-cpus", AspeedSoCState, num_cpus, 0),
diff --git a/hw/sd/Makefile.objs b/hw/sd/Makefile.objs
index 0665727..a884c23 100644
--- a/hw/sd/Makefile.objs
+++ b/hw/sd/Makefile.objs
@@ -8,3 +8,4 @@ obj-$(CONFIG_MILKYMIST) += milkymist-memcard.o
 obj-$(CONFIG_OMAP) += omap_mmc.o
 obj-$(CONFIG_PXA2XX) += pxa2xx_mmci.o
 obj-$(CONFIG_RASPI) += bcm2835_sdhost.o
+obj-$(CONFIG_ASPEED_SOC) += aspeed_sdhci.o
diff --git a/hw/sd/aspe

Re: [Qemu-devel] [PATCH] ppc: Fix xscvdpspn for SNAN

[Richard Henderson]

On 8/20/19 10:26 AM, Paul A. Clarke wrote:
> From: "Paul A. Clarke" 
> 
> helper_xscvdpspn() uses float64_to_float32() to convert double-precision
> floating-point to single-precision.  Unfortunately, float64_to_float32()
> converts SNAN to QNAN, which should not happen with xscvdpspn.
> 
> float64_to_float32() is also used by other instruction implementations
> for conversions which _should_ convert SNAN to QNAN.
> 
> Rather than trying to wedge code to preserve SNAN in float64_to_float32()
> just for this this one case, I instead embed an embodiment of the
> conversion code outlined in the POWER ISA for xscvdpspn.
> 
> Signed-off-by: Paul A. Clarke 
> ---
>  target/ppc/fpu_helper.c | 32 ++--
>  1 file changed, 30 insertions(+), 2 deletions(-)

Perhaps a better description is:

---

The xscvdpspn instruction implements a non-arithmetic conversion.
In particular, NaNs are not silenced and rounding is not performed.

Rewrite to match the pseudocode for ConvertDPtoSP_NS() in the
Power 3.0B manual.

---

The term comes from the ieee spec, in that "arithmetic" operations (like add)
are required to notice exceptional conditions like NaN but "non-arithmetic"
operations (like abs) are not required to do so.  Thus a valid implementation
of abs merely clears the sign bit without otherwise transforming NaNs.

The code does match the pseudocode, so
Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH] iotests: Check for enabled drivers before testing them

[Max Reitz]

On 20.08.19 18:01, Thomas Huth wrote:
> On 8/20/19 5:01 PM, Max Reitz wrote:
>> On 19.08.19 09:53, Thomas Huth wrote:
>>> It is possible to enable only a subset of the block drivers with the
>>> "--block-drv-rw-whitelist" option of the "configure" script. All other
>>> drivers are marked as unusable (or only included as read-only with the
>>> "--block-drv-ro-whitelist" option). If an iotest is now using such a
>>> disabled block driver, it is failing - which is bad, since at least the
>>> tests in the "auto" group should be able to deal with this situation.
>>> Thus let's introduce a "_require_drivers" function that can be used by
>>> the shell tests to check for the availability of certain drivers first,
>>> and marks the test as "not run" if one of the drivers is missing.
>>
>> Well, the reasoning for generally not making blkdebug/blkverify explicit
>> requirements was that you should just have both enabled when running
>> iotests.
> 
> Well, we disable blkverify in our downstream RHEL version of QEMU - so
> it would be great if the iotests could at least adapt to that missing
> driver.

I would like to say that RHEL is not a gold standard, but then I have
this series of selfish patches that specifically addresses RHEL
whitelisting issues.

It feels a bit weird to me to say “blkverify is not essential, because
RHEL disables it, but null-co is” – even though there is no reason why
anyone would need null-co except for testing either.

>> Of course, that no longer works as an argument now that we
>> unconditionally run some iotests in make check.
>>
>> But still, the question is how strict you want to be.  If blkdebug
>> cannot be assumed to be present, what about null-co?  What about raw?
> 
> I tried to disable everything beside qcow2 - but that causes so many
> things to fail that it hardly makes sense to try to get that working.

Hm, really?  I just whitelisted qcow2 and file and running the auto
group worked rather well (except for the failing tests you address here,
and the two others I mentioned).

> I think we can assume that at least null-co, qcow2 and raw are enabled.
> (If anybody still wants to try to run "make check" with one of these
> drivers disabled, I think we should rather add a superior check to
> tests/check-block.sh or tests/qemu-iotests/check instead and skip the
> iotests completely in that case).

I’m OK either way: We can add a global check, or we just make a decision
on what users definitely have to have enabled or the qemu build would be
a bit boring.

Assuming file, qcow2, and raw to be enabled seems reasonable.  I’m not
so sure about null-co.

(I mean, I personally don’t really care.  I never added such checks
myself, even a bit purposefully so, because it was my opinion that you
should probably have all block drivers whitelisted before running the
iotests.  But then came CI and make check-block integration...)

((Also, you’ll notice that I was really inconsequential about adding
null-co checks in my “selfish patches” series, precisely because I
assumed everyone would have whitelisted null-co.  So I’m indeed OK with
just making it an implicit prerequisite.))

>>> Signed-off-by: Thomas Huth 
>>> ---
>>>  tests/qemu-iotests/071   |  1 +
>>>  tests/qemu-iotests/081   |  1 +
>>>  tests/qemu-iotests/099   |  1 +
>>>  tests/qemu-iotests/184   |  1 +
>>>  tests/qemu-iotests/common.rc | 13 +
>>>  5 files changed, 17 insertions(+)
>>>
>>> diff --git a/tests/qemu-iotests/071 b/tests/qemu-iotests/071
>>> index 1cca9233d0..fab52b 100755
>>> --- a/tests/qemu-iotests/071
>>> +++ b/tests/qemu-iotests/071
>>> @@ -38,6 +38,7 @@ trap "_cleanup; exit \$status" 0 1 2 3 15
>>>  
>>>  _supported_fmt qcow2
>>>  _supported_proto file
>>> +_require_drivers blkdebug blkverify
>>
>> Because this test also requires the raw driver.
> 
> The test also works for me when I configured QEMU with:
> 
>  --block-drv-rw-whitelist="qcow2 file null-co blkdebug blkverify"
> 
> i.e. the raw driver should be disabled in that case?

Ah, it’s just used by qemu-io, which of course ignores whitelisting.

>>>  
>>>  do_run_qemu()
>>>  {
>>> diff --git a/tests/qemu-iotests/081 b/tests/qemu-iotests/081
>>> index c418bab093..1695781bc0 100755
>>> --- a/tests/qemu-iotests/081
>>> +++ b/tests/qemu-iotests/081
>>> @@ -41,6 +41,7 @@ trap "_cleanup; exit \$status" 0 1 2 3 15
>>>  _supported_fmt raw
>>>  _supported_proto file
>>>  _supported_os Linux
>>> +_require_drivers quorum
>>
>> This test has already a check whether quorum is supported, that should
>> be removed now.
> 
> Hmm, true ... apparently that test was not working for my case ... could
> it be that qemu-img ignores the whitelist and simply says that all
> drivers are supported?

Ah, yeah.  The whitelist is relevant only for the system emulator.

I forgot why we even had the existing check, then.  Maybe just a mistake
to use qemu-img.

>> (Also, this test requires the raw driver.)
> 
> Agreed, this test indeed does not work without 'raw'.

Re: [Qemu-devel] [PATCH 2/2] riscv: Resolve full path of the given bios image

[Alistair Francis]

On Fri, Aug 16, 2019 at 6:11 AM Bin Meng  wrote:
>
> At present when "-bios image" is supplied, we just use the straight
> path without searching for the configured data directories. Like
> "-bios default", we add the same logic so that "-L" actually works.
>
> Signed-off-by: Bin Meng 

Reviewed-by: Alistair Francis 

Alistair

>
> ---
>
>  hw/riscv/boot.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/hw/riscv/boot.c b/hw/riscv/boot.c
> index a122846..15002d3 100644
> --- a/hw/riscv/boot.c
> +++ b/hw/riscv/boot.c
> @@ -72,14 +72,14 @@ void riscv_find_and_load_firmware(MachineState *machine,
>  firmware_filename = riscv_find_firmware(default_machine_firmware);
>  } else {
>  firmware_filename = machine->firmware;
> +if (strcmp(firmware_filename, "none")) {
> +firmware_filename = riscv_find_firmware(firmware_filename);
> +}
>  }
>
>  if (strcmp(firmware_filename, "none")) {
>  /* If not "none" load the firmware */
>  riscv_load_firmware(firmware_filename, firmware_load_addr);
> -}
> -
> -if (!strcmp(machine->firmware, "default")) {
>  g_free(firmware_filename);
>  }
>  }
> --
> 2.7.4
>
>

Re: [Qemu-devel] [PATCH v4 20/28] riscv: sifive_u: Reference PRCI clocks in UART and ethernet nodes

[Alistair Francis]

On Sun, Aug 18, 2019 at 10:24 PM Bin Meng  wrote:
>
> Now that we have added a PRCI node, update existing UART and ethernet
> nodes to reference PRCI as their clock sources, to keep in sync with
> the Linux kernel device tree.
>
> Signed-off-by: Bin Meng 

Reviewed-by: Alistair Francis 

Alistair

> ---
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  hw/riscv/sifive_u.c  |  7 ---
>  include/hw/riscv/sifive_u_prci.h | 10 ++
>  2 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
> index bd5551c..8818fd6 100644
> --- a/hw/riscv/sifive_u.c
> +++ b/hw/riscv/sifive_u.c
> @@ -80,7 +80,7 @@ static void create_fdt(SiFiveUState *s, const struct 
> MemmapEntry *memmap,
>  int cpu;
>  uint32_t *cells;
>  char *nodename;
> -char ethclk_names[] = "pclk\0hclk\0tx_clk";
> +char ethclk_names[] = "pclk\0hclk";
>  uint32_t plic_phandle, prci_phandle, ethclk_phandle, phandle = 1;
>  uint32_t uartclk_phandle;
>  uint32_t hfclk_phandle, rtcclk_phandle;
> @@ -265,7 +265,7 @@ static void create_fdt(SiFiveUState *s, const struct 
> MemmapEntry *memmap,
>  qemu_fdt_setprop_cell(fdt, nodename, "interrupt-parent", plic_phandle);
>  qemu_fdt_setprop_cell(fdt, nodename, "interrupts", SIFIVE_U_GEM_IRQ);
>  qemu_fdt_setprop_cells(fdt, nodename, "clocks",
> -ethclk_phandle, ethclk_phandle, ethclk_phandle);
> +prci_phandle, PRCI_CLK_GEMGXLPLL, prci_phandle, PRCI_CLK_GEMGXLPLL);
>  qemu_fdt_setprop(fdt, nodename, "clock-names", ethclk_names,
>  sizeof(ethclk_names));
>  qemu_fdt_setprop_cell(fdt, nodename, "#address-cells", 1);
> @@ -295,7 +295,8 @@ static void create_fdt(SiFiveUState *s, const struct 
> MemmapEntry *memmap,
>  qemu_fdt_setprop_cells(fdt, nodename, "reg",
>  0x0, memmap[SIFIVE_U_UART0].base,
>  0x0, memmap[SIFIVE_U_UART0].size);
> -qemu_fdt_setprop_cell(fdt, nodename, "clocks", uartclk_phandle);
> +qemu_fdt_setprop_cells(fdt, nodename, "clocks",
> +prci_phandle, PRCI_CLK_TLCLK);
>  qemu_fdt_setprop_cell(fdt, nodename, "interrupt-parent", plic_phandle);
>  qemu_fdt_setprop_cell(fdt, nodename, "interrupts", SIFIVE_U_UART0_IRQ);
>
> diff --git a/include/hw/riscv/sifive_u_prci.h 
> b/include/hw/riscv/sifive_u_prci.h
> index 66eacb5..cdf1d33 100644
> --- a/include/hw/riscv/sifive_u_prci.h
> +++ b/include/hw/riscv/sifive_u_prci.h
> @@ -87,4 +87,14 @@ typedef struct SiFiveUPRCIState {
>
>  DeviceState *sifive_u_prci_create(hwaddr addr);
>
> +/*
> + * Clock indexes for use by Device Tree data and the PRCI driver.
> + *
> + * These values are from sifive-fu540-prci.h in the Linux kernel.
> + */
> +#define PRCI_CLK_COREPLL0
> +#define PRCI_CLK_DDRPLL 1
> +#define PRCI_CLK_GEMGXLPLL  2
> +#define PRCI_CLK_TLCLK  3
> +
>  #endif /* HW_SIFIVE_U_PRCI_H */
> --
> 2.7.4
>
>

Re: [Qemu-devel] [PATCH 12/13] qemu-img: implement key management

[Max Reitz]

On 14.08.19 22:22, Maxim Levitsky wrote:
> Signed-off-by: Maxim Levitsky 
> ---
>  block/crypto.c   |  16 ++
>  block/crypto.h   |   3 +
>  qemu-img-cmds.hx |  13 +
>  qemu-img.c   | 140 +++
>  4 files changed, 172 insertions(+)

Yes, this seems a bit weird.  Putting it under amend seems like the
natural thing if that works; if not, I think it should be a single
qemu-img subcommand instead of two.

Max



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 07/13] block: add manage-encryption command (qmp and blockdev)

[Max Reitz]

On 14.08.19 22:22, Maxim Levitsky wrote:
> This adds:
> 
> * x-blockdev-update-encryption and x-blockdev-erase-encryption qmp commands
>   Both commands take the QCryptoKeyManageOptions
>   the x-blockdev-update-encryption is meant for non destructive addition
>   of key slots / whatever the encryption driver supports in the future
> 
>   x-blockdev-erase-encryption is meant for destructive encryption key erase,
>   in some cases even without way to recover the data.
> 
> 
> * bdrv_setup_encryption callback in the block driver
>   This callback does both the above functions with 'action' parameter
> 
> * QCryptoKeyManageOptions with set of options that drivers can use for 
> encryption managment
>   Currently it has all the options that LUKS needs, and later it can be 
> extended
>   (via union) to support more encryption drivers if needed
> 
> * blk_setup_encryption / bdrv_setup_encryption - the usual block layer 
> wrappers.
>   Note that bdrv_setup_encryption takes BlockDriverState and not BdrvChild,
>   for the ease of use from the qmp code. It is not expected that this function
>   will be used by anything but qmp and qemu-img code
> 
> 
> Signed-off-by: Maxim Levitsky 
> ---
>  block/block-backend.c  |  9 
>  block/io.c | 24 
>  blockdev.c | 40 ++
>  include/block/block.h  | 12 ++
>  include/block/block_int.h  | 11 ++
>  include/sysemu/block-backend.h |  7 ++
>  qapi/block-core.json   | 36 ++
>  qapi/crypto.json   | 26 ++
>  8 files changed, 165 insertions(+)

Now I don’t know whether you want to keep this interface at all, because
the cover letter seemed to imply you’d prefer a QMP amend.  But let it
be said that a QMP amend is no trivial task.  I think the most difficult
bit is that the qcow2 implementation currently is inherently an offline
operation.  It isn’t a good idea to use it on a live image.  (Maybe it
works, but it’s definitely not what I had in mind when I wrote it.)

So I’ll still take a quick glance at the interface here.

[...]

> diff --git a/qapi/block-core.json b/qapi/block-core.json
> index 0d43d4f37c..53ed411eed 100644
> --- a/qapi/block-core.json
> +++ b/qapi/block-core.json
> @@ -5327,3 +5327,39 @@
>'data' : { 'node-name': 'str',
>   'iothread': 'StrOrNull',
>   '*force': 'bool' } }
> +
> +
> +##
> +# @x-blockdev-update-encryption:
> +#
> +# Update the encryption keys for an encrypted block device
> +#
> +# @node-name:  Name of the blockdev to operate on
> +# @force: Disable safety checks (use with care)
> +# @options:   Driver specific options
> +#
> +
> +# Since: 4.2
> +##
> +{ 'command': 'x-blockdev-update-encryption',
> +  'data': { 'node-name' : 'str',
> +'*force' : 'bool',
> +'options': 'QCryptoEncryptionSetupOptions' } }
> +
> +##
> +# @x-blockdev-erase-encryption:
> +#
> +# Erase the encryption keys for an encrypted block device
> +#
> +# @node-name:  Name of the blockdev to operate on

Why the tab?

> +# @force: Disable safety checks (use with care)

I think being a bit more verbose wouldn’t hurt.

(Same above.)

> +# @options:   Driver specific options
> +#
> +# Returns: @QCryptoKeyManageResult
> +#
> +# Since: 4.2
> +##
> +{ 'command': 'x-blockdev-erase-encryption',
> +  'data': { 'node-name' : 'str',
> +'*force' : 'bool',
> +'options': 'QCryptoEncryptionSetupOptions' } }
> diff --git a/qapi/crypto.json b/qapi/crypto.json
> index b2a4cff683..69e8b086db 100644
> --- a/qapi/crypto.json
> +++ b/qapi/crypto.json
> @@ -309,3 +309,29 @@
>'base': 'QCryptoBlockInfoBase',
>'discriminator': 'format',
>'data': { 'luks': 'QCryptoBlockInfoLUKS' } }
> +
> +
> +##
> +# @QCryptoEncryptionSetupOptions:
> +#
> +# Driver specific options for encryption key management.

The options do seem LUKS-specific, but the name of this structure does not.

> +# @key-secret: the ID of a QCryptoSecret object providing the password
> +#  to add or to erase (optional for erase)
> +#
> +# @old-key-secret: the ID of a QCryptoSecret object providing the password
> +#  that can currently unlock the image
> +#
> +# @slot: Key slot to update/erase
> +#(optional, for update will select a free slot,
> +#for erase will erase all slots that match the password)
> +#
> +# @iter-time: number of milliseconds to spend in
> +# PBKDF passphrase processing. Currently defaults to 2000
> +# Since: 4.2
> +##

Does it really make sense to use the same structure for erasing and
updating?  I think there are ways to represent @key-secret vs. @slot
being alternatives to each other for erase; @iter-time doesn’t seem to
make sense for erase; and @slot doesn’t seem to make sense for update.
Also, I don’t know whether to use @key-secret or @old-k

Re: [Qemu-devel] Difference between commit and rebase

[John Snow]

On 8/20/19 5:27 AM, lampahome wrote:
> I want to remove snapshots and I found two ways:
> qemu-img commit

Commit takes a chain of images:

[base] <-- [top]

and commits the top image down into the base image:

[base+top]

> qemu-img rebase

Rebase takes a chain of images:

[base] <-- [top]

And moves the top image onto a new base image, copying data as necessary
to preserve the differential relationship:

[different_base] <-- [top]

> 
> I found they both can choose where to rebase(merge) the images.
> commit can truncate or not on specific image.
> rebase won't truncate rebased image.
> 
> I found they have something similarity and I don't know what situation is
> suitable for commit or rebase?
> 

Commit is best when you have a single lineage of snapshots, like
A<--B<--C and you decide you don't actually need all of those snapshots
anymore, and would prefer to go back to a single image.

Rebase is most useful when you have several different chains of images
that are based on some common ancestor, and you would like to reparent
an image on top of a cousin branch.

(There are many more uses, but these ones are the most obvious to me
personally.)

--js

Re: [Qemu-devel] [PATCH 05/13] qcrypto-luks: clear the masterkey and password before freeing them always

[Max Reitz]

On 14.08.19 22:22, Maxim Levitsky wrote:
> While there are other places where these are still stored in memory,
> this is still one less key material area that can be sniffed with
> various side channel attacks
> 
> 
> 

(Many empty lines here)

> Signed-off-by: Maxim Levitsky 
> ---
>  crypto/block-luks.c | 52 ++---
>  1 file changed, 44 insertions(+), 8 deletions(-)

Wouldn’t it make sense to introduce a dedicated function for this?

Max



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [EXTERNAL]Re: Proposal for amending TCG interface naming scheme

[David Hildenbrand]

On 20.08.19 19:02, Aleksandar Markovic wrote:
>> From: David Hildenbrand 
>>
>> I just got familiar with the terminology and everything I read so far
>> confuses me even more (gather/pick/extend/extl/shrd). No, I don't like that.
> 
> David,
> 
> How often did you use the functions in question? Thinks about that,
> and about reasons for that.

I just used a whole bunch of them when implementing vector instruction
support for s390x. See target/s390x/translate_vx.inc.c for example.

-- 

Thanks,

David / dhildenb

[Qemu-devel] [PULL v3 00/33] Misc patches for 2019-08-20

[Paolo Bonzini]

The following changes since commit 17dc57990320edaad52ac9ea808be9719c91cea6:

  Merge remote-tracking branch 
'remotes/huth-gitlab/tags/pull-request-2019-08-20' into staging (2019-08-20 
14:14:20 +0100)

are available in the git repository at:


  git://github.com/bonzini/qemu.git tags/for-upstream

for you to fetch changes up to 80db491da4ce8b199e0e8d1e23943b20aab82f69:

  x86: Intel AVX512_BF16 feature enabling (2019-08-20 20:00:52 +0200)


* New KVM PV features (Marcelo, Wanpeng)
* valgrind fixes (Andrey)
* Remove clock reset notifiers (David)
* KConfig and Makefile cleanups (Paolo)
* Replay and icount improvements (Pavel)
* x86 FP fixes (Peter M.)
* TCG locking assertions (Roman)
* x86 support for mmap-ed -kernel/-initrd (Stefano)
* Other cleanups (Wei Yang, Yan Zhao, Tony)
* LSI fix for infinite loop (Prasad)
* ARM migration fix (Catherine)
* AVX512_BF16 feature (Jing)


Andrey Shinkevich (3):
  test-throttle: Fix uninitialized use of burst_length
  tests: Fix uninitialized byte in test_visitor_in_fuzz
  i386/kvm: initialize struct at full before ioctl call

Catherine Ho (1):
  migration: do not rom_reset() during incoming migration

Dr. David Alan Gilbert (4):
  mc146818rtc: Remove reset notifiers
  timer: Remove reset notifiers
  replay: Remove host_clock_last
  timer: last, remove last bits of last

Eduardo Habkost (1):
  HACKING: Document 'struct' keyword usage

Jan Kiszka (1):
  kvm: vmxcap: Enhance with latest features

Jing Liu (1):
  x86: Intel AVX512_BF16 feature enabling

Li Qiang (1):
  target-i386: kvm: 'kvm_get_supported_msrs' cleanup

Marcelo Tosatti (1):
  kvm: i386: halt poll control MSR support

Paolo Bonzini (3):
  9p: simplify source file selection
  memory: fix race between TCG and accesses to dirty bitmap
  scsi: lsi: exit infinite loop while executing script (CVE-2019-12068)

Pavel Dovgalyuk (8):
  replay: add missing fix for internal function
  replay: document development rules
  util/qemu-timer: refactor deadline calculation for external timers
  replay: fix replay shutdown
  replay: refine replay-time module
  replay: rename step-related variables and functions
  icount: clean up cpu_can_io at the entry to the block
  icount: remove unnecessary gen_io_end calls

Peter Maydell (1):
  target/i386: Return 'indefinite integer value' for invalid SSE fp->int 
conversions

Roman Kagan (1):
  cpus-common: nuke finish_safe_work

Stefano Garzarella (3):
  loader: Handle memory-mapped ELFs
  elf-ops.h: Map into memory the ELF to load
  hw/i386/pc: Map into memory the initrd

Wanpeng Li (1):
  target-i386: adds PV_SCHED_YIELD CPUID feature bit

Wei Yang (1):
  test-bitmap: test set 1 bit case for bitmap_set

Yan Zhao (1):
  memory: assert on out of scope notification

tony.ngu...@bt.com (1):
  configure: Define target access alignment in configure

 HACKING |  14 +-
 Kconfig.host|   1 +
 accel/tcg/cpu-exec.c|   1 -
 accel/tcg/translator.c  |   1 -
 configure   |  12 +-
 cpus-common.c   |   8 --
 cpus.c  |  17 ++-
 docs/devel/replay.txt   |  46 +++
 exec.c  |  31 +
 fsdev/Makefile.objs |   2 +-
 hw/9pfs/Kconfig |   5 +
 hw/core/loader.c|  48 +--
 hw/i386/pc.c|  17 ++-
 hw/scsi/lsi53c895a.c|  41 --
 hw/timer/mc146818rtc.c  |  19 ---
 include/exec/gen-icount.h   |  44 +++---
 include/exec/memory.h   |  12 ++
 include/exec/poison.h   |   1 +
 include/hw/elf_ops.h|  71 ++
 include/hw/i386/pc.h|   1 +
 include/hw/loader.h |   5 +-
 include/qemu/timer.h|  43 +-
 include/qom/cpu.h   |   2 +-
 include/standard-headers/asm-x86/kvm_para.h |   2 +
 include/sysemu/replay.h |   2 +-
 memory.c|  16 ++-
 migration/ram.c |   1 +
 qtest.c |   3 +-
 replay/replay-events.c  |   2 +-
 replay/replay-internal.c|  10 +-
 replay/replay-internal.h|  10 +-
 replay/replay-snapshot.c|  13 +-
 replay/replay-time.c|  36 +++--
 replay/replay.c |  30 ++--
 scripts/kvm/vmxcap  |   8 

Re: [Qemu-devel] [PATCH 03/13] qcrypto-luks: refactoring: extract load/store/check/parse header functions

[Max Reitz]

On 14.08.19 22:22, Maxim Levitsky wrote:
> With upcoming key management, the header will
> need to be stored after the image is created.
> 
> Extracting load header isn't strictly needed, but
> do this anyway for the symmetry.
> 
> Also I extracted a function that does basic sanity
> checks on the just read header, and a function
> which parses all the crypto format to make the
> code a bit more readable, plus now the code
> doesn't destruct the in-header cipher-mode string,
> so that the header now can be stored many times,
> which is needed for the key management.
> 
> Also this allows to contain the endianess conversions
> in these functions alone
> 
> The header is no longer endian swapped in place,
> to prevent (mostly theoretical races I think)
> races where someone could see the header in the
> process of beeing byteswapped.

The formatting looks weird, it doesn’t look quite 72 characters wide...
 (what commit messages normally use)

> Signed-off-by: Maxim Levitsky 
> ---
>  crypto/block-luks.c | 756 ++--
>  1 file changed, 440 insertions(+), 316 deletions(-)

Also, this commit is just too big.

Max



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 00/13] RFC: luks/encrypted qcow2 key management

[Max Reitz]

On 14.08.19 22:22, Maxim Levitsky wrote:

[...]

> Testing. This was lightly tested with manual testing and with few iotests 
> that I prepared.
> I haven't yet tested fully the write sharing behavior, nor did I run the 
> whole iotests
> suite to see if this code causes some regressions. Since I will need probably
> to rewrite some chunks of it to change to 'amend' interface, I decided to 
> post it now,
> to see if you have other ideas/comments to add.

I can see that, because half of the qcow2 tests that contain the string
“secret” break:

Failures: 087 134 158 178 188 198 206
Failed 7 of 13 tests

Also, 210 when run with -luks.

Some are just due to different test outputs (because you change
_filter_img_create to filter some encrypt.* parameters), but some of
them are due to aborts.  All of them look like different kinds of heap
corruptions.


I can fully understand not running all iotests (because only the
maintainers do that before pull requests), but just running the iotests
that immediately concern a series seems prudent to me (unless the series
is trivial).

(Just “(cd tests/qemu-iotests && grep -l secret ???)” tells you which
tests to run that may concern themselves with qcow2 encryption, for
example.)


So I suppose I’ll stop reviewing the series in detail and just give a
more cursory glance from now on.

Max



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [EXTERNAL]Re: Proposal for amending TCG interface naming scheme

[Aleksandar Markovic]

20.08.2019. 18.49, "Peter Maydell"  је написао/ла:
>
> On Tue, 20 Aug 2019 at 17:44, David Hildenbrand  wrote:
> >
> > On 20.08.19 18:38, Aleksandar Markovic wrote:
> > >> From: BALATON Zoltan 
> > >>
> > >> Sorry to comment on this without really knowing what is it about but
maybe
> > >> my view is not completely useless if this is to be understood by
people
> > >> who don't know anything about it. If it is not useful just ignore.
> > >
> > > No, Zoltan, to the contrary, you hit the nail - the good interface
scheme
> > > should look natural even for people not acquainted with the gory
details
> > > of the area.
> > >
> >
> > I just got familiar with the terminology and everything I read so far
> > confuses me even more (gather/pick/extend/extl/shrd). No, I don't like
that.
>
> FWIW the way I tend to approach these is to say "I want to do
> $WHATEVER, surely we must have a tcg op for that, it's probably
> got 'ext' in it, search through tcg/README to find something
> that seems like it matches what I want to do"...
>

I must admit this is the most practical, pragmatic view among us.

Aleksamdar

> thanks
> -- PMM
>

Re: [Qemu-devel] [PATCH 02/13] qcrypto-luks: misc refactoring

[Max Reitz]

On 14.08.19 22:22, Maxim Levitsky wrote:
> This is also a preparation for key read/write/erase functions
> 
> * use master key len from the header
> * prefer to use crypto params in the QCryptoBlockLUKS
>   over passing them as function arguments
> * define QCRYPTO_BLOCK_LUKS_DEFAULT_ITER_TIME
> * Add comments to various crypto parameters in the QCryptoBlockLUKS
> 
> Signed-off-by: Maxim Levitsky 
> ---
>  crypto/block-luks.c | 213 ++--
>  1 file changed, 105 insertions(+), 108 deletions(-)
> 
> diff --git a/crypto/block-luks.c b/crypto/block-luks.c
> index 409ab50f20..48213abde7 100644
> --- a/crypto/block-luks.c
> +++ b/crypto/block-luks.c

[...]

> @@ -199,13 +201,25 @@ QEMU_BUILD_BUG_ON(sizeof(struct QCryptoBlockLUKSHeader) 
> != 592);
>  struct QCryptoBlockLUKS {
>  QCryptoBlockLUKSHeader header;
>  
> -/* Cache parsed versions of what's in header fields,
> - * as we can't rely on QCryptoBlock.cipher being
> - * non-NULL */

Hm, why remove this comment?

> +/* Main encryption algorithm used for encryption*/
>  QCryptoCipherAlgorithm cipher_alg;
> +
> +/* Mode of encryption for the selected encryption algorithm */
>  QCryptoCipherMode cipher_mode;
> +
> +/* Initialization vector generation algorithm */
>  QCryptoIVGenAlgorithm ivgen_alg;
> +
> +/* Hash algorithm used for IV generation*/
>  QCryptoHashAlgorithm ivgen_hash_alg;
> +
> +/*
> + * Encryption algorithm used for IV generation.
> + * Usually the same as main encryption algorithm
> + */
> +QCryptoCipherAlgorithm ivgen_cipher_alg;
> +
> +/* Hash algorithm used in pbkdf2 function */
>  QCryptoHashAlgorithm hash_alg;
>  };
>  
> @@ -397,6 +411,12 @@ qcrypto_block_luks_essiv_cipher(QCryptoCipherAlgorithm 
> cipher,
>  }
>  }
>  
> +static int masterkeylen(QCryptoBlockLUKS *luks)

This should be a const pointer.

> +{
> +return luks->header.key_bytes;
> +}
> +
> +
>  /*
>   * Given a key slot, and user password, this will attempt to unlock
>   * the master encryption key from the key slot.
> @@ -410,21 +430,15 @@ qcrypto_block_luks_essiv_cipher(QCryptoCipherAlgorithm 
> cipher,
>   */
>  static int
>  qcrypto_block_luks_load_key(QCryptoBlock *block,
> -QCryptoBlockLUKSKeySlot *slot,
> +uint slot_idx,

Did you use uint on purpose or do you mean a plain “unsigned”?

>  const char *password,
> -QCryptoCipherAlgorithm cipheralg,
> -QCryptoCipherMode ciphermode,
> -QCryptoHashAlgorithm hash,
> -QCryptoIVGenAlgorithm ivalg,
> -QCryptoCipherAlgorithm ivcipheralg,
> -QCryptoHashAlgorithm ivhash,
>  uint8_t *masterkey,
> -size_t masterkeylen,
>  QCryptoBlockReadFunc readfunc,
>  void *opaque,
>  Error **errp)
>  {
>  QCryptoBlockLUKS *luks = block->opaque;
> +QCryptoBlockLUKSKeySlot *slot = &luks->header.key_slots[slot_idx];

I think this is a great opportunity to make this a const pointer.

>  uint8_t *splitkey;
>  size_t splitkeylen;
>  uint8_t *possiblekey;

[...]

> @@ -710,6 +696,8 @@ qcrypto_block_luks_open(QCryptoBlock *block,
>  goto fail;
>  }
>  
> +cipher_mode = g_strdup(luks->header.cipher_mode);
> +

This should be freed under the fail label.

(And maybe the fact that this no longer modifies
luks->header.cipher_mode should be mentioned in the commit message, I
don’t know.)

>  /*
>   * The cipher_mode header contains a string that we have
>   * to further parse, of the format

[...]

> @@ -730,13 +718,13 @@ qcrypto_block_luks_open(QCryptoBlock *block,
>  
>  ivhash_name = strchr(ivgen_name, ':');
>  if (!ivhash_name) {
> -ivhash = 0;
> +luks->ivgen_hash_alg = 0;

*luks is initialized to 0 anyway, but it doesn’t hurt, of course.

>  } else {
>  *ivhash_name = '\0';
>  ivhash_name++;
>  
> -ivhash = qcrypto_block_luks_hash_name_lookup(ivhash_name,
> - &local_err);
> +luks->ivgen_hash_alg = 
> qcrypto_block_luks_hash_name_lookup(ivhash_name,
> +   
> &local_err);
>  if (local_err) {
>  ret = -ENOTSUP;
>  error_propagate(errp, local_err);
> @@ -744,25 +732,27 @@ qcrypto_block_luks_open(QCryptoBlock *block,

[...]

>  
> -hash = qcrypto_block_luks_hash_name_lookup(luks->header.hash_spec,
> +luks->hash_alg =
> +qcrypto_block_luks_hash_name_lookup(luks->header.hash_spec,
> &local_err);

Indentation is off now.

>  if (local_e

[Qemu-devel] [PATCH] ppc: Fix xscvdpspn for SNAN

[Paul A. Clarke]

From: "Paul A. Clarke" 

helper_xscvdpspn() uses float64_to_float32() to convert double-precision
floating-point to single-precision.  Unfortunately, float64_to_float32()
converts SNAN to QNAN, which should not happen with xscvdpspn.

float64_to_float32() is also used by other instruction implementations
for conversions which _should_ convert SNAN to QNAN.

Rather than trying to wedge code to preserve SNAN in float64_to_float32()
just for this this one case, I instead embed an embodiment of the
conversion code outlined in the POWER ISA for xscvdpspn.

Signed-off-by: Paul A. Clarke 
---
 target/ppc/fpu_helper.c | 32 ++--
 1 file changed, 30 insertions(+), 2 deletions(-)

diff --git a/target/ppc/fpu_helper.c b/target/ppc/fpu_helper.c
index 07bc905..c8e7192 100644
--- a/target/ppc/fpu_helper.c
+++ b/target/ppc/fpu_helper.c
@@ -2887,12 +2887,40 @@ void helper_xscvqpdp(CPUPPCState *env, uint32_t opcode,
 
 uint64_t helper_xscvdpspn(CPUPPCState *env, uint64_t xb)
 {
-uint64_t result;
+uint64_t result, sign, exp, frac;
 
 float_status tstat = env->fp_status;
 set_float_exception_flags(0, &tstat);
 
-result = (uint64_t)float64_to_float32(xb, &tstat);
+sign = extract64(xb, 63,  1);
+exp  = extract64(xb, 52, 11);
+frac = extract64(xb,  0, 52) | 0x10ULL;
+
+if (unlikely(exp == 0 && extract64(frac, 0, 52) != 0)) {
+/* DP denormal operand.  */
+/* Exponent override to DP min exp.  */
+exp = 1;
+/* Implicit bit override to 0.  */
+frac = deposit64(frac, 53, 1, 0);
+}
+
+if (unlikely(exp < 897 && frac != 0)) {
+/* SP tiny operand.  */
+if (897 - exp > 63) {
+frac = 0;
+} else {
+/* Denormalize until exp = SP min exp.  */
+frac >>= (897 - exp);
+}
+/* Exponent override to SP min exp - 1.  */
+exp = 896;
+}
+
+result = sign << 31;
+result |= extract64(exp, 10, 1) << 30;
+result |= extract64(exp, 0, 7) << 23;
+result |= extract64(frac, 29, 23);
+
 /* hardware replicates result to both words of the doubleword result.  */
 return (result << 32) | result;
 }
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH v10] qemu-io: add pattern file for write command

[Eric Blake]

On 8/20/19 11:46 AM, Denis Plotnikov wrote:
> The patch allows to provide a pattern file for write
> command. There was no similar ability before.
> 
> Signed-off-by: Denis Plotnikov 
> ---

> @@ -983,8 +1057,9 @@ static int write_f(BlockBackend *blk, int argc, char 
> **argv)
>  /* Some compilers get confused and warn if this is not initialized.  */
>  int64_t total = 0;
>  int pattern = 0xcd;
> +const char *file_name = NULL;
>  
> -while ((c = getopt(argc, argv, "bcCfnpP:quz")) != -1) {
> +while ((c = getopt(argc, argv, "bcCfnpP:quzs:")) != -1) {

This one looks odd (I would have preserved ordering by sticking s:
between q and u).  But a maintainer could fix that.

>  switch (c) {
>  case 'b':
>  bflag = true;
> @@ -1020,6 +1095,10 @@ static int write_f(BlockBackend *blk, int argc, char 
> **argv)
>  case 'z':
>  zflag = true;
>  break;
> +case 's':
> +sflag = true;
> +file_name = optarg;
> +break;

Likewise, sorting the cases in the same order as the getopt() listing
helps in finding code during later edits.

> @@ -1088,7 +1168,14 @@ static int write_f(BlockBackend *blk, int argc, char 
> **argv)
>  }
>  
>  if (!zflag) {
> -buf = qemu_io_alloc(blk, count, pattern);
> +if (sflag) {
> +buf = qemu_io_alloc_from_file(blk, count, file_name);
> +if (!buf) {
> +return -EINVAL;
> +}
> +} else {
> +buf = qemu_io_alloc(blk, count, pattern);
> +}

Pre-existing, but it is odd that qemu_io_alloc() exit()s rather than
returning NULL on huge allocation requests that can't be met.  (Then
again, we have an early exit on any length > 2G, and 2G allocations tend
to succeed on modern development machines).  Perhaps it would be nice to
teach qemu-io to use blk_try_blockalign for more graceful handling even
on 32-bit platforms, but that's not the problem of your patch.

Option ordering is minor enough that I'm fine giving:

Reviewed-by: Eric Blake 

Now, to figure out which maintainer should take it.  Perhaps you want to
add a patch 2/1 that adds an iotest using this new mode, to a) ensure it
doesn't regress, and b) makes it reasonable to take in through the
iotest tree.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [Bug 1819289] Re: Windows 95 and Windows 98 will not install or run

[Peter Maydell]

If your bisect hit e3af7c788b73a6495 can you try it with
cfcca361d77142f25f applied on top? That commit fixed a bug in
e3af7c788b73a6495 which may be throwing off your bisection results.

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

Title:
  Windows 95 and Windows 98 will not install or run

Status in QEMU:
  New

Bug description:
  The last version of QEMU I have been able to run Windows 95 or Windows
  98 on was 2.7 or 2.8. Recent versions since then even up to 3.1 will
  either not install or will not run 95 or 98 at all. I have tried every
  combination of options like isapc or no isapc, cpu pentium  or cpu as
  486. Tried different memory configurations, but they just don't work
  anymore.

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

Re: [Qemu-devel] [EXTERNAL]Re: Proposal for amending TCG interface naming scheme

[Aleksandar Markovic]

> From: David Hildenbrand 
> 
> I just got familiar with the terminology and everything I read so far
> confuses me even more (gather/pick/extend/extl/shrd). No, I don't like that.

David,

How often did you use the functions in question? Thinks about that,
and about reasons for that.

Yours,
Aleksandar

Re: [Qemu-devel] [PATCH] Fix: fp-test uninitialized member floatX::exp

[Andrey Shinkevich]

On 13/08/2019 15:21, Alex Bennée wrote:
> 
> Andrey Shinkevich  writes:
> 
>> PINGING...
> 
> Sorry about the delay. I did attempt see if the existing code threw up
> any errors when built with clang's undefined sanitizer. I think this is
> because xPtr->exp will only get read if none of the xPtr->isFOO returns
> false. In all those cases xPtr->exp is set.
> 
> What pointed you towards this missing initialisations?
> 

I am sorry about missing the message. It appeared in other email thread 
where I didn't expect. So, I missed the response.
When I ran the fp-tests under the Valgrind, I got lots of reports about 
using uninitialized memory. They all disappeared after applying this 
patch. I concluded that there are paths that use xPtr->exp uninitialized.

$ /usr/bin/valgrind --leak-check=no --trace-children=yes 
--keep-stacktraces=alloc-and-free --track-origins=yes 
--log-file=myqemu-%p.log make check-softfloat

==720268== Conditional jump or move depends on uninitialised value(s)
==720268==at 0x112C72: floatXRoundToInt (slowfloat.c:1371)
==720268==by 0x115920: slow_f16_roundToInt (slowfloat.c:2408)
==720268==by 0x133A87: test_az_f16_rx (test_az_f16_rx.c:73)
==720268==by 0x10E635: do_testfloat (fp-test.c:304)
==720268==by 0x10FD02: run_test (fp-test.c:1003)
==720268==by 0x10FDA4: main (fp-test.c:1017)
==720268==  Uninitialised value was created by a stack allocation
==720268==at 0x1158D3: slow_f16_roundToInt (slowfloat.c:2404)

==720311== Conditional jump or move depends on uninitialised value(s)
==720311==at 0x112E54: floatXAdd (slowfloat.c:1411)
==720311==by 0x115A2D: slow_f16_sub (slowfloat.c:2431)
==720311==by 0x133CEC: test_abz_f16 (test_abz_f16.c:70)
==720311==by 0x10E6D5: do_testfloat (fp-test.c:326)
==720311==by 0x10FD02: run_test (fp-test.c:1003)
==720311==by 0x10FDA4: main (fp-test.c:1017)
==720311==  Uninitialised value was created by a stack allocation
==720311==at 0x1159C0: slow_f16_sub (slowfloat.c:2425)

==720273== Conditional jump or move depends on uninitialised value(s)
==720273==at 0x113D54: floatXEq (slowfloat.c:1661)
==720273==by 0x115EAD: slow_f16_eq_signaling (slowfloat.c:2538)
==720273==by 0x1341D3: test_ab_f16_z_bool (test_ab_f16_z_bool.c:71)
==720273==by 0x10E7DE: do_testfloat (fp-test.c:358)
==720273==by 0x10FD02: run_test (fp-test.c:1003)
==720273==by 0x10FDA4: main (fp-test.c:1017)
==720273==  Uninitialised value was created by a stack allocation
==720273==at 0x115E38: slow_f16_eq_signaling (slowfloat.c:2530)

Even if Valgrind is wrong, the purpose of the patch is to reduce the 
number of error reports from the Valgrind to locate other memory serious 
issues, if any.

Andrey

>>
>> On 30/07/2019 13:13, Andrey Shinkevich wrote:
>>> Not all the paths in the functions, such as f16ToFloatX(), initialize
>>> the member 'exp' of the structure floatX.
>>>
>>> Signed-off-by: Andrey Shinkevich 
>>> ---
>>>source/slowfloat.c | 4 
>>>1 file changed, 4 insertions(+)
>>>
>>> diff --git a/tests/fp/berkeley-testfloat-3/source/slowfloat.c 
>>> b/tests/fp/berkeley-testfloat-3/source/slowfloat.c
>>> index 4e84656..6e0f0a6 100644
>>> --- a/tests/fp/berkeley-testfloat-3/source/slowfloat.c
>>> +++ b/tests/fp/berkeley-testfloat-3/source/slowfloat.c
>>> @@ -623,6 +623,7 @@ static void f16ToFloatX( float16_t a, struct floatX 
>>> *xPtr )
>>>xPtr->isInf = false;
>>>xPtr->isZero = false;
>>>xPtr->sign = ((uiA & 0x8000) != 0);
>>> +xPtr->exp = 0;
>>>exp = uiA>>10 & 0x1F;
>>>sig64 = uiA & 0x03FF;
>>>sig64 <<= 45;
>>> @@ -759,6 +760,7 @@ static void f32ToFloatX( float32_t a, struct floatX 
>>> *xPtr )
>>>xPtr->isInf = false;
>>>xPtr->isZero = false;
>>>xPtr->sign = ((uiA & 0x8000) != 0);
>>> +xPtr->exp = 0;
>>>exp = uiA>>23 & 0xFF;
>>>sig64 = uiA & 0x007F;
>>>sig64 <<= 32;
>>> @@ -895,6 +897,7 @@ static void f64ToFloatX( float64_t a, struct floatX 
>>> *xPtr )
>>>xPtr->isInf = false;
>>>xPtr->isZero = false;
>>>xPtr->sign = ((uiA & UINT64_C( 0x8000 )) != 0);
>>> +xPtr->exp = 0;
>>>exp = uiA>>52 & 0x7FF;
>>>sig64 = uiA & UINT64_C( 0x000F );
>>>if ( exp == 0x7FF ) {
>>> @@ -1220,6 +1223,7 @@ static void f128MToFloatX( const float128_t *aPtr, 
>>> struct floatX *xPtr )
>>>xPtr->isZero = false;
>>>uiA64 = uiAPtr->v64;
>>>xPtr->sign = ((uiA64 & UINT64_C( 0x8000 )) != 0);
>>> +xPtr->exp = 0;
>>>exp = uiA64>>48 & 0x7FFF;
>>>sig.v64 = uiA64 & UINT64_C( 0x );
>>>sig.v0  = uiAPtr->v0;
>>>
> 
> 
> --
> Alex Bennée
> 

-- 
With the best regards,
Andrey Shinkevich

[Qemu-devel] [Bug 1819289] Re: Windows 95 and Windows 98 will not install or run

[Brad Parker]

Hopefully third time's the charm. I ran yet another bisect, between
2.5.0 (working) and 2.11.0 (not working), this time reinstalling the
entire OS from scratch with a blank disk every single time. Results:

$ git bisect good
e3af7c788b73a6495eb9d94992ef11f6ad6f3c56 is the first bad commit
commit e3af7c788b73a6495eb9d94992ef11f6ad6f3c56
Author: Paolo Bonzini 
Date:   Wed Apr 26 13:59:34 2017 +0200

target/i386: introduce x86_ld*_code

These take care of advancing s->pc, and will provide a unified point
where to check for the 15-byte instruction length limit.

Signed-off-by: Paolo Bonzini 

 target/i386/translate.c | 228 ++--
 1 file changed, 125 insertions(+), 103 deletions(-)

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

Title:
  Windows 95 and Windows 98 will not install or run

Status in QEMU:
  New

Bug description:
  The last version of QEMU I have been able to run Windows 95 or Windows
  98 on was 2.7 or 2.8. Recent versions since then even up to 3.1 will
  either not install or will not run 95 or 98 at all. I have tried every
  combination of options like isapc or no isapc, cpu pentium  or cpu as
  486. Tried different memory configurations, but they just don't work
  anymore.

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

Re: [Qemu-devel] [EXTERNAL]Re: Proposal for amending TCG interface naming scheme

[Aleksandar Markovic]

> From: Laurent Vivier 
> 
> Personally I agree with David, proposed terminology is not more obvious
> to me and changing things just for matter of taste is not a good idea.

Thanks, Laurent for your input, but this in not a matter of taste, there
are exact metrics here - different things should be called differently,
not almost the same. Also, the API names should describe something,
they are not mnemonics.

Aleksandar

Re: [Qemu-devel] [EXTERNAL]Re: Proposal for amending TCG interface naming scheme

[Laurent Vivier]

Le 20/08/2019 à 18:44, David Hildenbrand a écrit :
> On 20.08.19 18:38, Aleksandar Markovic wrote:
>>> From: BALATON Zoltan 
>>>
>>> Sorry to comment on this without really knowing what is it about but maybe
>>> my view is not completely useless if this is to be understood by people
>>> who don't know anything about it. If it is not useful just ignore.
>>
>> No, Zoltan, to the contrary, you hit the nail - the good interface scheme
>> should look natural even for people not acquainted with the gory details
>> of the area.
>>
> 
> I just got familiar with the terminology and everything I read so far
> confuses me even more (gather/pick/extend/extl/shrd). No, I don't like that.

Personally I agree with David, proposed terminology is not more obvious
to me and changing things just for matter of taste is not a good idea.

Thanks,
Laurent

Re: [Qemu-devel] [EXTERNAL]Re: Proposal for amending TCG interface naming scheme

[Richard Henderson]

On 8/20/19 9:15 AM, Aleksandar Markovic wrote:
> > tcg_gen_gather_i32
> > tcg_gen_gather_i64
> > tcg_gen_gather_tl
> 
> I'm not sure how "gather" applies.
> 
> 
> gather = come together; assemble or accumulate

Sure, but...

> To me this sounds like a vector
> scatter/gather operation, where N different addresses are used to load 
> the N
> elements of the vector.

... it also has a completely different well-known meaning.


> Hmm, "pick" doesn't mean anything to me. 
> 
> 
> and "extl" does?

Sure: "EXTract Low".  Paired with "EXTract High" it certainly makes sense.


> I was hoping we would remove "sextract" (well, it is funny a little bit
> definitely, but if there are zillion occurrences, and used everyday, it just
> stops being funny, and is somewhat distracting...), however it looks we will
> get "sextend", and "sextend2", and "sex_h" and "sex_l"...

Why mention all of these brand new straw-man variants?  Anyway, we are not
children, giggling at a sequence of letters taken out of context.


r~

Re: [Qemu-devel] [EXTERNAL]Re: Proposal for amending TCG interface naming scheme

[Peter Maydell]

On Tue, 20 Aug 2019 at 17:44, David Hildenbrand  wrote:
>
> On 20.08.19 18:38, Aleksandar Markovic wrote:
> >> From: BALATON Zoltan 
> >>
> >> Sorry to comment on this without really knowing what is it about but maybe
> >> my view is not completely useless if this is to be understood by people
> >> who don't know anything about it. If it is not useful just ignore.
> >
> > No, Zoltan, to the contrary, you hit the nail - the good interface scheme
> > should look natural even for people not acquainted with the gory details
> > of the area.
> >
>
> I just got familiar with the terminology and everything I read so far
> confuses me even more (gather/pick/extend/extl/shrd). No, I don't like that.

FWIW the way I tend to approach these is to say "I want to do
$WHATEVER, surely we must have a tcg op for that, it's probably
got 'ext' in it, search through tcg/README to find something
that seems like it matches what I want to do"...

thanks
-- PMM

Re: [Qemu-devel] [EXTERNAL]Re: Proposal for amending TCG interface naming scheme

[David Hildenbrand]

On 20.08.19 17:37, Richard Henderson wrote:
> On 8/20/19 6:49 AM, Aleksandar Markovic wrote:
>>> From: Peter Maydell 
>>> On Tue, 20 Aug 2019 at 13:50, Aleksandar Markovic
>>>  wrote:
 The idea is to provide significant "lexicographic" distance between those 
 > groups of functions, rather than having the similar name (wiht common 
 root > "ext) for all of them.
>>>
>>> The current naming of the extract/sextract TCG ops is intended to keep
>>> them in line with the extract32/sextract32/extract64/sextract64 utility
>>> functions in bitops.h. I think those ones are reasonably named. The
>>> other ops are a bit more ad-hoc in naming, admittedly...
>>>
>>
>> How about
>>
>> tcg_gen_extract2_i32
>> tcg_gen_extract2_i64
>> tcg_gen_extract2_tl
>> tcg_gen_extrl_i64_i32
>> tcg_gen_extrh_i64_i32
>> tcg_gen_ext_i32_i64
>> tcg_gen_extu_i32_i64
>>
>> to
>>
>> tcg_gen_gather_i32
>> tcg_gen_gather_i64
>> tcg_gen_gather_tl
> 
> I'm not sure how "gather" applies.  To me this sounds like a vector
> scatter/gather operation, where N different addresses are used to load the N
> elements of the vector.
> 
> When extract2 was named, I was only thinking "extract" because of how the
> AArch64 instruction that implements this operation is named (EXTR), and "extr"
> itself was already taken.  We did ask for naming suggestions at the time, but
> no better ideas were floated...
> 
> Would it be clearer to use the x86 instruction name: SHRD (SHift Right 
> Doubleword)?
> 

I still think your proposal back then made sense - extract2. Extract a
64bit value from a 128bit value.

-- 

Thanks,

David / dhildenb

[Qemu-devel] [PATCH v10] qemu-io: add pattern file for write command

[Denis Plotnikov]

The patch allows to provide a pattern file for write
command. There was no similar ability before.

Signed-off-by: Denis Plotnikov 
---
v10:
  * fix overflow [Max]
  * remove casting to bool [Max, Eric]
  * fix wording [Max]

v9:
  * replace flag cast to int with bool [Eric]
  * fix the error message [Eric]
  * use qemu_io_free instead of qemu_vfree [Eric]
  * add function description [Eric]

v8: fix according to Max's comments
  * get rid of unnecessary buffer for the pattern
  * buffer allocation just in bytes
  * take into account the missalign offset
  * don't copy file name
  * changed char* to const char* in input params

v7:
  * fix variable naming
  * make code more readable
  * extend help for write command

v6:
  * the pattern file is read once to reduce io

v5:
  * file name initiated with null to make compilers happy

v4:
  * missing signed-off clause added

v3:
  * missing file closing added
  * exclusive flags processing changed
  * buffer void* converted to char* to fix pointer arithmetics
  * file reading error processing added
---
 qemu-io-cmds.c | 99 +++---
 1 file changed, 93 insertions(+), 6 deletions(-)

diff --git a/qemu-io-cmds.c b/qemu-io-cmds.c
index 09750a23ce..f411811d95 100644
--- a/qemu-io-cmds.c
+++ b/qemu-io-cmds.c
@@ -351,6 +351,79 @@ static void qemu_io_free(void *p)
 qemu_vfree(p);
 }
 
+/*
+ * qemu_io_alloc_from_file()
+ *
+ * Allocates the buffer and populates it with the content of the given file
+ * up to @len bytes. If the file length is less than @len, then the buffer
+ * is populated with the file content cyclically.
+ *
+ * @blk - the block backend where the buffer content is going to be written to
+ * @len - the buffer length
+ * @file_name - the file to read the content from
+ *
+ * Returns: the buffer pointer on success
+ *  NULL on error
+ */
+static void *qemu_io_alloc_from_file(BlockBackend *blk, size_t len,
+ const char *file_name)
+{
+char *buf, *buf_origin;
+FILE *f = fopen(file_name, "r");
+int pattern_len;
+
+if (!f) {
+perror(file_name);
+return NULL;
+}
+
+if (qemuio_misalign) {
+len += MISALIGN_OFFSET;
+}
+
+buf_origin = buf = blk_blockalign(blk, len);
+
+if (qemuio_misalign) {
+buf_origin += MISALIGN_OFFSET;
+buf += MISALIGN_OFFSET;
+len -= MISALIGN_OFFSET;
+}
+
+pattern_len = fread(buf_origin, 1, len, f);
+
+if (ferror(f)) {
+perror(file_name);
+goto error;
+}
+
+if (pattern_len == 0) {
+fprintf(stderr, "%s: file is empty\n", file_name);
+goto error;
+}
+
+fclose(f);
+
+if (len > pattern_len) {
+len -= pattern_len;
+buf += pattern_len;
+
+while (len > 0) {
+size_t len_to_copy = MIN(pattern_len, len);
+
+memcpy(buf, buf_origin, len_to_copy);
+
+len -= len_to_copy;
+buf += len_to_copy;
+}
+}
+
+return buf_origin;
+
+error:
+qemu_io_free(buf_origin);
+return NULL;
+}
+
 static void dump_buffer(const void *buffer, int64_t offset, int64_t len)
 {
 uint64_t i;
@@ -949,6 +1022,7 @@ static void write_help(void)
 " -n, -- with -z, don't allow slow fallback\n"
 " -p, -- ignored for backwards compatibility\n"
 " -P, -- use different pattern to fill file\n"
+" -s, -- use a pattern file to fill the write buffer\n"
 " -C, -- report statistics in a machine parsable format\n"
 " -q, -- quiet mode, do not show I/O statistics\n"
 " -u, -- with -z, allow unmapping\n"
@@ -965,7 +1039,7 @@ static const cmdinfo_t write_cmd = {
 .perm   = BLK_PERM_WRITE,
 .argmin = 2,
 .argmax = -1,
-.args   = "[-bcCfnquz] [-P pattern] off len",
+.args   = "[-bcCfnquz] [-P pattern | -s source_file] off len",
 .oneline= "writes a number of bytes at a specified offset",
 .help   = write_help,
 };
@@ -974,7 +1048,7 @@ static int write_f(BlockBackend *blk, int argc, char 
**argv)
 {
 struct timeval t1, t2;
 bool Cflag = false, qflag = false, bflag = false;
-bool Pflag = false, zflag = false, cflag = false;
+bool Pflag = false, zflag = false, cflag = false, sflag = false;
 int flags = 0;
 int c, cnt, ret;
 char *buf = NULL;
@@ -983,8 +1057,9 @@ static int write_f(BlockBackend *blk, int argc, char 
**argv)
 /* Some compilers get confused and warn if this is not initialized.  */
 int64_t total = 0;
 int pattern = 0xcd;
+const char *file_name = NULL;
 
-while ((c = getopt(argc, argv, "bcCfnpP:quz")) != -1) {
+while ((c = getopt(argc, argv, "bcCfnpP:quzs:")) != -1) {
 switch (c) {
 case 'b':
 bflag = true;
@@ -1020,6 +1095,10 @@ static int write_f(BlockBackend *blk, int argc, char 
**argv)
 case 'z':
 zflag = true;
 break;
+case 's':
+sflag = true;
+file_name = optarg