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

Re: [xen-unstable test] 162845: regressions - FAIL

  • To: Anthony PERARD <anthony.perard@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 16 Jun 2021 17:01:15 +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=3lFacDmEIodEaoxeJPMMmvxpxSTyv01Hwb2O7xxbCpc=; b=XXKxOYVVWlmCe6ODR8ymkc37QGGF/QnfpCQfBk36U82naQ2+ojgPkqNwNQW29VwUj+axRS0F9crbO9o1f2iyUar7STLp8TaiXSYXEAi0Tcq5bcaybbFPC6YEey8Ep7q+SF2Gg3lCBDI9JEgfSVQocE2lQViKwD7A/YEeCKU+a3tBRiXq61EBkQGstAvi8EBO2UcV9TwyIvg9CRCe/yO40VsWyv8xovHti8KA9VDXyeMrFw3kMIblRGm11cimlYECByePXV1JuzXNig5h4rxQDBd5jFmwnmjx7ioZ3m/Bvpwq/p2zWPDAHrrliccqDO3YKEoXVHg+S/6rG1NNMRMb0A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iXKbNE6I8vjYZ6lLSeuqxy7kB9HAilJdZqGwAWBj+lJmbFE94drAiQt1GpO/XhRwnHn24yyYwtgLd/3yf1nx3dRUg3jphIqyaiEn1jMTG3Bk6xe/akrfPeHyXbWHHFyHStCmz9WY/K00bPKmUiZawfcokfStdbibo7eZF3rywnGqaa1YR/bK1gMvhDXX1kIU/4/HlpnvE+wKRLz+ToAcYg9en7hdZ5afBJY0dQKodBKP6K2lljETwC5StwbMw5LAGyKY9Dn4gRofpt6AcN2FuC4ejfGN4FGZaq3jvbHDyXgNLbRkkT/d5eHWqe2JGft8ZOqabsvrS/1uhTuvieZX4A==
  • Authentication-results: xenproject.org; dkim=none (message not signed) header.d=none;xenproject.org; dmarc=none action=none header.from=suse.com;
  • Cc: Ian Jackson <iwj@xxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, osstest service owner <osstest-admin@xxxxxxxxxxxxxx>
  • Delivery-date: Wed, 16 Jun 2021 15:01:31 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 16.06.2021 16:49, Jan Beulich wrote:
> On 16.06.2021 16:21, Anthony PERARD wrote:
>> On Wed, Jun 16, 2021 at 09:12:52AM +0200, Jan Beulich wrote:
>>> On 16.06.2021 08:54, osstest service owner wrote:
>>>> flight 162845 xen-unstable real [real]
>>>> flight 162853 xen-unstable real-retest [real]
>>>> http://logs.test-lab.xenproject.org/osstest/logs/162845/
>>>> http://logs.test-lab.xenproject.org/osstest/logs/162853/
>>>> Regressions :-(
>>>> Tests which did not succeed and are blocking,
>>>> including tests which could not be run:
>>>>  test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-saverestore fail REGR. vs. 
>>>> 162533
>>>>  test-amd64-i386-xl-qemuu-ovmf-amd64 15 guest-saverestore fail REGR. vs. 
>>>> 162533
>>> There looks to still be an issue with the ovmf version used. I'm
>>> puzzled to find this flight reporting
>>> built_revision_ovmf e1999b264f1f9d7230edf2448f757c73da567832
>>> which isn't what the tree recently was rewound to, but about two
>>> dozen commits older. I hope one of you has a clue at what is going
>>> on here.
>> So this commit is "master" from https://xenbits.xen.org/git-http/ovmf.git
>> rather than "xen-tested-master" from 
>> https://xenbits.xen.org/git-http/osstest/ovmf.git
>> master is what xen.git would have cloned. And "xen-tested-master" is the
>> commit that I was expecting osstest to pick up, but maybe that as been
>> setup only for stable trees?
>> Anyway, after aad7b5c11d51 ("tools/firmware/ovmf: Use OvmfXen platform
>> file is exist"), it isn't the same OVMF that is been used. We used to
>> use OvmfX64, but now we are going to use OvmfXen. (Xen support in
>> OvmfX64 has been removed so can't be used anymore.)
>> So there is maybe an issue with OvmfXen which doesn't need to block
>> xen-unstable flights.
>> As for the failure, I can think of one thing in that is different,
>> OvmfXen maps the XENMAPSPACE_shared_info page as high as possible in the
>> guest physical memory, in order to avoid creating hole the RAM, but a
>> call to XENMEM_remove_from_physmap is done as well. Could that actually
>> cause issues with saverestore?
> I don't think it should. But I now notice I should have looked at the
> logs of these tests:
> xc: info: Saving domain 2, type x86 HVM
> xc: error: Unable to obtain the guest p2m size (1 = Operation not permitted): 
> Internal error
> xc: error: Save failed (1 = Operation not permitted): Internal error
> which looks suspiciously similar to the issue Jürgen's d21121685fac
> ("tools/libs/guest: fix save and restore of pv domains after 32-bit
> de-support") took care of, just that here we're dealing with a HVM
> guest. I'll have to go inspect what exactly the library is doing there,
> and hence where in Xen the -EPERM may be coming from all of the
> sudden (and only for OVMF).

The *-amd64-i386-* variant has

xc: info: Saving domain 2, type x86 HVM
xc: error: Cannot save this big a guest (7 = Argument list too long): Internal 

which to me hints at ...

> Of course the behavior you describe above may play into this, since
> aiui this might lead to an excessively large p2m (depending what
> exactly you mean with "as high as possible").

.. a connection, but I'm not sure at all. XENMEM_maximum_gpfn returns
its result as the hypercall return value, so huge values could be a
problem at least for 32-bit tool stacks.

What page number are you mapping the shared info page at in OVMF?




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