Re: [Xen-devel] [xen-unstable test] 144091: regressions - FAIL

[Jan Beulich <jbeulich@xxxxxxxx>]

On 14.11.2019 17:21, Jan Beulich wrote:
> On 14.11.2019 16:52, osstest service owner wrote:
>> flight 144091 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/144091/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12 
>> guest-start/debianhvm.repeat fail REGR. vs. 144042
>>  test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. 
>> vs. 144042
> 
> I've taken another look, and I now think the L2 guest doesn't even
> make it to the bootloader. Taking together
> 
> (d1) SeaBIOS (version rel-1.12.1-0-ga5cab58-Xen)
> (d1) BUILD: gcc: (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 binutils: (GNU 
> Binutils for Debian) 2.28
> (d1) 
> (d1) Found Xen hypervisor signature at 40000000
> (d1) Running on QEMU (i440fx)
> (d1) xen: copy e820...
> (d1) Relocating init from 0x000d7c20 to 0x2f7abd80 (size 82400)
> 
> and
> 
> (XEN) *********** VMCS Areas **************
> (XEN) 
> (XEN) >>> Domain 1 <<<
> (XEN)         VCPU 0
> (XEN) *** Guest State ***
> (XEN) CR0: actual=0x0000000000000031, shadow=0x0000000000000011, 
> gh_mask=ffffffffffffffff
> (XEN) CR4: actual=0x0000000000002050, shadow=0x0000000000000000, 
> gh_mask=fffffffffff8f870
> (XEN) CR3 = 0x0000000000400000
> (XEN) RSP = 0x0000000000006fa4 (0x0000000000006fa4)  RIP = 0x000000002f7ba9f4 
> (0x000000002f7ba9f4)
> 
> and similarly in the L0 log
> 
> (XEN) RSP = 0x0000000000006fa4 (0x0000000000006fa4)  RIP = 0x000000002f7ba9f4 
> (0x000000002f7ba9f4)
> 
> I instead think it's still in SeaBIOS code. I'll see if I can
> derive where exactly it's sitting. In any event the most recent
> exit reason to L0 was EPT_VIOLATION with a qualification of 0x19c
> (fetch, eff_read, eff_write, gla_valid, gla_fault), which I don't
> think would allow the guest to continue without an adjustment to
> its EPT permissions.

Isn't the problem here that the XSA-304 fix only updates the host
p2m, but not any entries already propagate to nested or alt p2ms?

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel