[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xen-unstable-smoke test] 162597: regressions - FAIL

  • To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 11 Jun 2021 09:38:53 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X11Ut+Mjv9dMzNg2zGs9HBO5d0wHIHjV5BuGHTa6zMc=; b=nddZC44p4kaGMTgo38Ey2EJtm4xoJYM4G/50L3QJ/sT53h5pDzlBDeg9M6FHHNx5OI7//ygBE3fDUdPHVZYBMT3l7AuC3RZD8CoKyt658RYyYBPx0ym5VJ8Wn0t+CNcRDYNuwV6pzYFBML2Q3yRXunTpytpnSeLadxch0mCXlREOFprkZwfsEZfUb5Cg1UTX9JwRAZvRvEvXGRafdEYodrpb39q3f6HAARCgaCrbyWHcTTVqWMAX7XLuViC/fYQmyZ9gpl/vtMXUAvbc2YmYuULRll77ncnJxBBU91N8MoWapmEhkRUeAakAlg79HNSAOP1rJpnxIHJAZ5rq4UsKQQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SlN0fz6ZbqLziWTH9npyxaEyvG9KZHmYXbFloNm0EPSIex7zfCQEGKONPnBa2c8VkNIqvBT80S+VskdPMNfPTKh744n5lylMna6pOAlNCZ21qEzufMoxjvKkrwQH0D5Oof9BIEIWkg1OTDMjegxCOW65PM/+eoVpcffH5a3Dxj9dpaTs+6O2optewWDt+JXLSl3r9STv5oECpZAq3cva49SLZ1knu4Fl7cIjq3h25+PSAc2wvLZCGNg0a6u68BCzBdJ5vyPGu6uL1UXZwIPoVxUv8QZoIUhX7vXujrB72GpLNzXbOjFbp8z2owXYJcXhw+yJWfP71iygMxroAXdTfQ==
  • Authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=suse.com;
  • Cc: Julien Grall <julien@xxxxxxx>, osstest service owner <osstest-admin@xxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Delivery-date: Fri, 11 Jun 2021 07:39:06 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 11.06.2021 03:49, Stefano Stabellini wrote:
> In any case, I tried to figure it out. I guessed it could be a compiler
> error. I followed the white rabbit down the ARM ARM hole. I disassebled
> the Xen binary [1] from the failed job. "msr SPSR, r11" is 0x0026a38c.
> The encoding should be at B9.3.12 of the ARMv7-A DDI 0406C and F5.1.121
> of ARMv8 DDI 0487D.b. Unfortunately it doesn't seem to match either one
> of them and I don't understand why.
> The "mrs r11, SPSR" is generated as 0x00262ecc. That should be described
> at F5.1.117 for ARMv8 and B9.3.9 for ARMv7. Also doesn't seem to match.

According to my looking at the disassembly, the two numbers you've
quoted are the addresses, not insn encodings. Using my own disassembler
(i.e. there's room for that one being wrong), I do get

        E169F00B        msr     spsr_cf, r11
        E14FB000        mrs     r11, spsr

the former of which doesn't look like an exact equivalent of the input
instruction. I guess it really is "msr spsr_cxsf, r11" which is meant?
In gas sources I find this:

      /* Unadorned APSR is equivalent to APSR_nzcvq/CPSR_f (for writes).  This
         is deprecated, but allow it anyway.  */
      if (is_apsr && lhs)
          psr_field |= PSR_f;
          as_tsktsk (_("writing to APSR without specifying a bitmask is "
      else if (!m_profile)
        /* These bits are never right for M-profile devices: don't set them
           (only code paths which read/write APSR reach here).  */
        psr_field |= (PSR_c | PSR_f);

There's clearly a comment missing to talk about the "unadorned" SPSR
case, but the effect is exactly what is observed: Rather than
defaulting to the setting of all 4 bits, only two of them get set
when plain "SPSR" is used. I've not been able to spot a place where
the Arm ARM specifies this, but given its size I'm not surprised at
all. I'd like to note though that the MSR description doesn't even
allow for plain "SPSR" (unlike MRS); only SPSR_<...> is described

Based on this analysis I guess I can make a patch despite not being
able to test it, as I'm pretty certain you really want to restore
all of PSR; not just the low half ...




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.