Re: [Xen-devel] [PATCH V3 2/29] VIOMMU: Add vIOMMU helper functions to create, destroy vIOMMU instance

[Jan Beulich]

>>> On 30.10.17 at 02:51,  wrote:
> On 2017年10月18日 22:05, Roger Pau Monné wrote:
>>> +int viommu_register_type(uint64_t type, struct viommu_ops *ops)
>>> > +{
>>> > +struct viommu_type *viommu_type = NULL;
>>> > +
>>> > +if ( !viommu_enabled() )
>>> > +return -ENODEV;
>>> > +
>>> > +if ( viommu_get_type(type) )
>>> > +return -EEXIST;
>>> > +
>>> > +viommu_type = xzalloc(struct viommu_type);
>>> > +if ( !viommu_type )
>>> > +return -ENOMEM;
>>> > +
>>> > +viommu_type->type = type;
>>> > +viommu_type->ops = ops;
>>> > +
>>> > +spin_lock(&type_list_lock);
>>> > +list_add_tail(&viommu_type->node, &type_list);
>>> > +spin_unlock(&type_list_lock);
>>> > +
>>> > +return 0;
>>> > +}
>> As mentioned above, I think this viommu_register_type helper could be
>> avoided. I would rather use a macro similar to REGISTER_SCHEDULER in
>> order to populate an array at link time, and then just iterate over
>> it.
>> 
> 
> Hi Jan:
>   Could you help to check whether REGISTER_SCHEDULER is right direction
> for vIOMMU? It needs to change Xen lds layout. From my view, a list to
> manage vIOMMU device model types will be more easy and this maybe a
> common solution.

I think the suggested approach is generally the neater one; there
may be a few other things we could convert to a similar model, to
clean up code. Hence yes, unless there are strong reasons against
it, I agree with Roger.

Jan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.10.0 RC1 test result

[Jan Beulich]

>>> On 30.10.17 at 03:21,  wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Friday, October 27, 2017 5:19 PM
>> >>> On 27.10.17 at 10:28,  wrote:
>> > RAS:
>> > [BUG] xen-mceinj tool testing cause dom0 crash
>> > https://www.mail-archive.com/xen-devel@lists.xen.org/msg108671.html 
>> 
>> Please can you provide helpful links? This doesn't point to the beginning of 
>> the
>> thread, and the mail archive chosen doesn't appear to have an easy way to go
>> back to the head of a thread. And when I go through the parts of the thread
> 
> Unfortunately I didn't find the original link from mail-archive, but I pick 
> up it in my mail client, attach the original mail.

Did you also check our own archive, rather than just that foreign
one?

>> which are easily accessible there, it looks like you've never followed up on 
>> the
>> additional information (log) request. 
> 
> I've provided the full log which included Xen and Dom0's, even though there 
> was no valid error message from Dom0.

If Dom0 crashes without any log messages, this is very likely a bug
by itself.

>> This way I don't see how we can make
>> progress there. 
> 
> Yes, this is the end mail 
> https://www.mail-archive.com/xen-devel@lists.xen.org/msg108894.html.
> 
>> Plus, looking over the Cc lists there, Linux maintainers also don't
>> appear to have been involved at any time.
>> 
> 
> I'm not sure if it's related with Dom0's kernel. My intention is we could 
> discuss in Xen list only till we make sure it's Dom0's issue.

The question isn't where to discuss the issue, but who to involve
in the discussion. For a Dom0 kernel issue the Linux maintainers
would need to be pulled in.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [qemu-mainline test] 115600: regressions - FAIL

[osstest service owner]

flight 115600 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115600/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-vhd  16 guest-start.2  fail in 115575 REGR. vs. 114507

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail in 115575 pass in 
115600
 test-amd64-amd64-libvirt-vhd 18 guest-start.2fail in 115575 pass in 115600
 test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeat fail in 115587 pass 
in 115600
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail in 115587 pass 
in 115600
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 115587 
pass in 115600
 test-armhf-armhf-xl-vhd  15 guest-start/debian.repeat  fail pass in 115575
 test-amd64-i386-xl-xsm   20 guest-start/debian.repeat  fail pass in 115587
 test-amd64-amd64-xl-qcow220 guest-start.2  fail pass in 115587

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop  fail blocked in 114507
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 114507
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 114507
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114507
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114507
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 114507
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 qemuub33afc415622e5eb26e0f14fd27eb86e32a5472e
baseline version:
 qemuuf90ea7ba7c5ae7010ee0ce062207ae42530f57d6

Last test of basis   114507  2017-10-15 01:03:38 Z   22 days
Failing since114546  2017-10-16 12:16:28 Z   20 days   55 attempts
Testing same since   115529  2017-11-03 15:30:10 Z2 days5 attempts


People who touched revisions under test:
  Aaron Lindsay 
  Alberto Garcia 
  Aleksandr Bezzubikov 
  Alex Bennée 
  Alexey Kardashevskiy 
  Alexey Perevalov 
  Alistair Francis 
  Amarnath Valluri 
  Andreas Färber 
  Andrew Baumann 
  Anthoine Bourgeois 
  Anthony PERARD 
  Artyom Tarasenko 
  Bishara AbuHattoum 
  Carlo Marc

Re: [Xen-devel] Xen 4.10.0 RC1 test result

[Hao, Xudong]

Hi Jan

We have update of this issue and I sent mail two three days ago, maybe you 
haven't read it yet, but I think you'll read it soon.

Thanks,
-Xudong


> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, November 6, 2017 4:24 PM
> To: Hao, Xudong 
> Cc: Julien Grall ; Lars Kurth ;
> xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] Xen 4.10.0 RC1 test result
> 
> >>> On 30.10.17 at 03:21,  wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Friday, October 27, 2017 5:19 PM
> >> >>> On 27.10.17 at 10:28,  wrote:
> >> > RAS:
> >> > [BUG] xen-mceinj tool testing cause dom0 crash
> >> > https://www.mail-archive.com/xen-devel@lists.xen.org/msg108671.html
> >>
> >> Please can you provide helpful links? This doesn't point to the
> >> beginning of the thread, and the mail archive chosen doesn't appear
> >> to have an easy way to go back to the head of a thread. And when I go
> >> through the parts of the thread
> >
> > Unfortunately I didn't find the original link from mail-archive, but I
> > pick up it in my mail client, attach the original mail.
> 
> Did you also check our own archive, rather than just that foreign one?
> 
> >> which are easily accessible there, it looks like you've never
> >> followed up on the additional information (log) request.
> >
> > I've provided the full log which included Xen and Dom0's, even though
> > there was no valid error message from Dom0.
> 
> If Dom0 crashes without any log messages, this is very likely a bug by itself.
> 
> >> This way I don't see how we can make
> >> progress there.
> >
> > Yes, this is the end mail
> > https://www.mail-archive.com/xen-devel@lists.xen.org/msg108894.html.
> >
> >> Plus, looking over the Cc lists there, Linux maintainers also don't
> >> appear to have been involved at any time.
> >>
> >
> > I'm not sure if it's related with Dom0's kernel. My intention is we
> > could discuss in Xen list only till we make sure it's Dom0's issue.
> 
> The question isn't where to discuss the issue, but who to involve in the
> discussion. For a Dom0 kernel issue the Linux maintainers would need to be
> pulled in.
> 
> Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [libvirt test] 115605: regressions - FAIL

[osstest service owner]

flight 115605 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115605/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeat fail REGR. vs. 
115476

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat  fail pass in 115583

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 115476
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 115476
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 115476
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  27b67eba22bd587f3422d52c1779b98dba30949f
baseline version:
 libvirt  1bf893406637e852daeaafec6617d3ee3716de25

Last test of basis   115476  2017-11-02 04:22:37 Z4 days
Failing since115509  2017-11-03 04:20:26 Z3 days4 attempts
Testing same since   115583  2017-11-05 04:23:00 Z1 days2 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Daniel Veillard 
  Dawid Zamirski 
  Jiri Denemark 
  Michal Privoznik 
  Peter Krempa 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-amd64-i386-libvirt-qcow2fail
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd fail



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 488 lines long.)

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [BUG] xen-mceinj tool testing cause dom0 crash

[Jan Beulich]

>>> On 03.11.17 at 09:29,  wrote:
> We figured out the problem, some corner scripts triggered the error 
> injection at the same page (pfn 0x180020) twice, i.e. "./xen-mceinj -t 0" run 
> over one time, which resulted in Dom0 crash.

But isn't this a valid scenario, which shouldn't result in a kernel
crash? What if two successive #MCs occurred for the same page?
I.e. ...

> Let's close this bug thread, sorry for the invalid report

... wasn't this premature?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] Confused about mapped pages "struct page" updates

[Waseem, Amna]

Hello All,

I am a little confused about mapping mechanism in Xen for page from DomU to 
Dom0.

When Dom0 maps DomU page to its applied host_addr, Page table entries are 
created by Xen hypervisor for mapping  applied host_addr vritual  address of 
Dom0 to DomU physical page. The result is host_addr maps to DomU phsyical page.

Now in network backend driver, virt_to_page macro is called on this mapped 
host_addr. How does Dom0 gets struct page for the mapped DomU page in its 
domain? Is Xen also updates mem_map array of Dom0 to create struct page for the 
mapped page? Or Dom0 creates struct page for all the physical memory including 
provided to DomU during its creation ?

Can anybody tell me how struct page for mapped pages from another domain gets 
updated or created in DOm0?

Any help will be appreciated
Thanks
Amna
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Confused about mapped pages "struct page" updates

[Juergen Gross]

On 06/11/17 10:57, Waseem, Amna wrote:
> Hello All,
> 
> I am a little confused about mapping mechanism in Xen for page from DomU to 
> Dom0.
> 
> When Dom0 maps DomU page to its applied host_addr, Page table entries are 
> created by Xen hypervisor for mapping  applied host_addr vritual  address of 
> Dom0 to DomU physical page. The result is host_addr maps to DomU phsyical 
> page.
> 
> Now in network backend driver, virt_to_page macro is called on this mapped 
> host_addr. How does Dom0 gets struct page for the mapped DomU page in its 
> domain? Is Xen also updates mem_map array of Dom0 to create struct page for 
> the mapped page? Or Dom0 creates struct page for all the physical memory 
> including provided to DomU during its creation ?
> 
> Can anybody tell me how struct page for mapped pages from another domain gets 
> updated or created in DOm0?

Dom0 requests the mapping for a specific Dom0 physical address
(normally this is a page from the balloon driver, but in case no
ballooned page is available a kernel page is being allocated for
that purpose). So there always is a struct page available in Dom0.

host_addr above is part of Dom0 physical addresses. And the hypervisor
either modifies the Dom0 page table entry (in case of a PV Dom0 on
X86) or it just modifies the p2m mapping of the Dom0 physical address
(in case of ARM).


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Help：Can xen restore several snapshots more faster at same time？

[Wei Liu]

On Mon, Nov 06, 2017 at 04:38:51AM +, HUANG SHENGQIANG wrote:
> Dear XEN expert,
> 
> I find a blocker issue in my project. Would you please offer us some feedback?
> 
> The description from my development team:
> we need restore as much as xen snapshot at same times, but we found ‘xl 
> restore’ command is work linearly,  if we want to restore a new xen snapshot, 
> we need to wait for the previous snapshot finish it’s work. We try to debug 
> the xl source ,we found the follow information:
> [cid:image001.png@01D356F6.B8EE87E0]
> 

Please don't send pictures.

> When an snapshot is being restore, we can see another process is blocked.  We 
> trying to delete the acquire_lock from the source code , then we see all the 
> snapshots are being restore at same time, but restore is still very slow, one 
> snapshot needs about 25 seconds  to finish restore(our environment is cpu 
> E52620,  256G memory, SSD hard disk. The snapshot is Win7 OS with 2G memory).
> 

There is a lock in xl as you can see in the stack trace.

> So , does xen have the way to restore more faster when several snapshot is 
> restore at same time? Why KVM can restore several snapshot fast at same time? 
> (We try the same experiment in KVM, we got we can restore about 50+ snapshot 
> in 20S. )
> 

Part of the toolstack needs to be reworked. You can start by removing
the lock in xl to see what breaks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [distros-debian-sid test] 72429: tolerable FAIL

[Platform Team regression test user]

flight 72429 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72429/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-i386-sid-netboot-pvgrub 10 debian-di-install   fail like 72376
 test-armhf-armhf-armhf-sid-netboot-pygrub 10 debian-di-install fail like 72376
 test-amd64-amd64-amd64-sid-netboot-pvgrub 10 debian-di-install fail like 72376
 test-amd64-i386-amd64-sid-netboot-pygrub 10 debian-di-install  fail like 72376
 test-amd64-amd64-i386-sid-netboot-pygrub 10 debian-di-install  fail like 72376

baseline version:
 flight   72376

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-sid-netboot-pvgrubfail
 test-amd64-i386-i386-sid-netboot-pvgrub  fail
 test-amd64-i386-amd64-sid-netboot-pygrub fail
 test-armhf-armhf-armhf-sid-netboot-pygrubfail
 test-amd64-amd64-i386-sid-netboot-pygrub fail



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Confused about mapped pages "struct page" updates

[Waseem, Amna]

Thanks a lot
I understood it now 


From: Juergen Gross 
Sent: Monday, November 6, 2017 11:24 AM
To: Waseem, Amna; Julien Grall
Cc: xen-devel; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Confused about mapped pages "struct page" updates

On 06/11/17 10:57, Waseem, Amna wrote:
> Hello All,
>
> I am a little confused about mapping mechanism in Xen for page from DomU to 
> Dom0.
>
> When Dom0 maps DomU page to its applied host_addr, Page table entries are 
> created by Xen hypervisor for mapping  applied host_addr vritual  address of 
> Dom0 to DomU physical page. The result is host_addr maps to DomU phsyical 
> page.
>
> Now in network backend driver, virt_to_page macro is called on this mapped 
> host_addr. How does Dom0 gets struct page for the mapped DomU page in its 
> domain? Is Xen also updates mem_map array of Dom0 to create struct page for 
> the mapped page? Or Dom0 creates struct page for all the physical memory 
> including provided to DomU during its creation ?
>
> Can anybody tell me how struct page for mapped pages from another domain gets 
> updated or created in DOm0?

Dom0 requests the mapping for a specific Dom0 physical address
(normally this is a page from the balloon driver, but in case no
ballooned page is available a kernel page is being allocated for
that purpose). So there always is a struct page available in Dom0.

host_addr above is part of Dom0 physical addresses. And the hypervisor
either modifies the Dom0 page table entry (in case of a PV Dom0 on
X86) or it just modifies the p2m mapping of the Dom0 physical address
(in case of ARM).


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-next 1/9] gcov: return ENOSYS for unimplemented gcov domctl

[Jan Beulich]

>>> On 26.10.17 at 11:19,  wrote:
> --- a/xen/common/gcov/gcov.c
> +++ b/xen/common/gcov/gcov.c
> @@ -239,7 +239,7 @@ int sysctl_gcov_op(struct xen_sysctl_gcov_op *op)
>  break;
>  
>  default:
> -ret = -EINVAL;
> +ret = -ENOSYS;
>  break;
>  }

Very certainly ENOSYS is not in any way better. Despite the many
misuses of it, we've started enforcing that this wouldn't be spread.
-EOPNOTSUPP may be fine here, but -EINVAL is suitable as well.
-ENOSYS exclusively means that a _top level_ hypercall is
unimplemented (i.e. with very few exceptions there should be
exactly one place where it gets returned, which is in the main
hypercall dispatch code).

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC 2/8] public/io/netif: add directory for backend parameters

[Paul Durrant]

> -Original Message-
> From: Joao Martins [mailto:joao.m.mart...@oracle.com]
> Sent: 02 November 2017 18:06
> To: Xen Development List 
> Cc: Joao Martins ; Konrad Rzeszutek Wilk
> ; Paul Durrant ; Wei Liu
> 
> Subject: [PATCH RFC 2/8] public/io/netif: add directory for backend
> parameters
> 
> The proposed directory provides a mechanism for tools to control the
> maximum feature set of the device being provisioned by backend.
> The parameters/features include offloading features, number of
> queues etc.
> 
> Signed-off-by: Joao Martins 
> ---
>  xen/include/public/io/netif.h | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/xen/include/public/io/netif.h b/xen/include/public/io/netif.h
> index 2454448baa..a412e4771d 100644
> --- a/xen/include/public/io/netif.h
> +++ b/xen/include/public/io/netif.h
> @@ -161,6 +161,22 @@
>   */
> 
>  /*
> + * The directory "require" maybe be created in backend path by tools
> + * domain to override the maximum feature set that backend provides to
> the
> + * frontend. The children entries within this directory are features names
> + * and the correspondent values that should be used backend as defaults
> e.g.:
> + *
> + * /local/domain/X/backend///require
> + * /local/domain/X/backend///require/multi-queue-
> max-queues = "2"
> + * /local/domain/X/backend///require/feature-no-csum-
> offload = "1"
> + *
> + * In the example above, network backend will negotiate up to a maximum
> of
> + * two queues with frontend plus disabling IPv4 checksum offloading.
> + *
> + * This directory and its children entries shall only be visible to the 
> backend.
> + */
> +

What should happen if the toolstack sets something in 'require' that the 
backend cannot provide? I don't see anything in your RFC patches to check that 
the backend has responded appropriately to the keys.

  Paul

> +/*
>   * Control ring
>   * 
>   *
> --
> 2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [For Xen-4.10 PATCH] docs/features: update the status of Credit2 implemented features

[Dario Faggioli]

As soft-affinity and caps will be available in Xen 4.10.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Julien Grall 
Cc: Lars Kurth 
---
Julien, doc change, so no risk.

Sorry I missed doing this at the same time of the changes themselves.
---
 docs/features/sched_credit2.pandoc |   13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/docs/features/sched_credit2.pandoc 
b/docs/features/sched_credit2.pandoc
index 9c8e15bdac..6dbfdf9d33 100644
--- a/docs/features/sched_credit2.pandoc
+++ b/docs/features/sched_credit2.pandoc
@@ -1,5 +1,5 @@
 % Credit2 Scheduler
-% Revision 1
+% Revision 2
 
 \clearpage
 
@@ -60,14 +60,6 @@ limiting, is only available from Xen 4.8 onward. In libxl, 
the
 `LIBXL\_HAVE\_SCHED\_CREDIT2\_PARAMS` symbol is introduced to
 indicate their availability.
 
-# Limitations
-
-The Credit1 scheduler comes with vCPU hard-affinity, vCPU soft-affinity
-and caps (see `docs/man/xl.pod.1.in` for more details). In Credit2,
-vCPU hard affinity is supported starting from Xen 4.8, while soft-affinity
-and caps, while being worked on, are not yet available in any released
-hypervisor.
-
 # Testing
 
 Any change done in Credit2 wants to be tested by doing at least the
@@ -87,8 +79,6 @@ following:
 
 # Areas for improvement
 
-* Close the feature gap with Credit1 (i.e., finishing implementing vCPU
-  soft-affinity and caps);
 * vCPUs' reservations (similar to caps, but providing a vCPU with guarantees
   about some pCPU time it will always be able to execute for);
 * benchmarking for assessing the best combination of values for the various
@@ -115,4 +105,5 @@ following:
 Date   Revision Version  Notes
 --   ---
 2016-10-14 1Xen 4.8  Document written
+2017-11-6  2Xen 4.10 Soft-affinity and caps implemented
 --   ---


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/cpuid: Enable new SSE/AVX/AVX512 cpu features

[Jan Beulich]

>>> On 27.10.17 at 16:18,  wrote:
> Intel IceLake cpu has added new cpu features: AVX512VBMI2/GFNI/
> VAES/AVX512VNNI/AVX512BITALG/VPCLMULQDQ. Those new cpu features
> need expose to guest.wq

First of all, please don't forget to Cc relevant maintainers.

> The bit definition:
> CPUID.(EAX=7,ECX=0):ECX[bit 06] AVX512VBMI2
> CPUID.(EAX=7,ECX=0):ECX[bit 08] GFNI
> CPUID.(EAX=7,ECX=0):ECX[bit 09] VAES
> CPUID.(EAX=7,ECX=0):ECX[bit 10] VPCLMULQDQ

These last three have VEX (and for GFNI even legacy) encodings.
While it wouldn't be reasonable yet to request EVEX encoded insn
support to be added to the emulator while enabling new ISA
extensions, I think legacy and VEX encoded ones should be taken
care of with the state the emulator is currently in.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.10] common/spinlock: Improve the output from check_lock() if it trips

[Jan Beulich]

>>> On 31.10.17 at 11:49,  wrote:
> --- a/xen/common/spinlock.c
> +++ b/xen/common/spinlock.c
> @@ -44,7 +44,13 @@ static void check_lock(struct lock_debug *debug)
>  if ( unlikely(debug->irq_safe != irq_safe) )
>  {
>  int seen = cmpxchg(&debug->irq_safe, -1, irq_safe);
> -BUG_ON(seen == !irq_safe);
> +
> +if ( seen == !irq_safe )
> +{
> +printk("CHECKLOCK FAILURE: prev irqsafe: %d, curr irqsafe %d\n",
> +   seen, irq_safe);
> +BUG();

This really should use XENLOG_ERR imo, so that the message won't
be lost if warnings are rate limited.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-next 1/9] gcov: return ENOSYS for unimplemented gcov domctl

[Ian Jackson]

Jan Beulich writes ("Re: [PATCH for-next 1/9] gcov: return ENOSYS for 
unimplemented gcov domctl"):
> On 26.10.17 at 11:19,  wrote:
> > --- a/xen/common/gcov/gcov.c
> > +++ b/xen/common/gcov/gcov.c
> > @@ -239,7 +239,7 @@ int sysctl_gcov_op(struct xen_sysctl_gcov_op *op)
> >  break;
> >  
> >  default:
> > -ret = -EINVAL;
> > +ret = -ENOSYS;
> >  break;
> >  }
> 
> Very certainly ENOSYS is not in any way better. Despite the many
> misuses of it, we've started enforcing that this wouldn't be spread.
> -EOPNOTSUPP may be fine here, but -EINVAL is suitable as well.
> -ENOSYS exclusively means that a _top level_ hypercall is
> unimplemented (i.e. with very few exceptions there should be
> exactly one place where it gets returned, which is in the main
> hypercall dispatch code).

The distinction between unimplemented status of a top-level hypercall
and unimplemented status of a sub-op is rarely useful to the caller.

Conversely, the distinction between an unimplemented facility, and a
facility which is exists but is being used improperly, is vitally
important to anyone who is trying to write compatibility code.

I don't mind if you want to insist on the former distinction,
reserving ENOSYS for top-level hypercalls and EOPNOTSUPP for other
functions.

But I absolutely do mind the use of EINVAL for "unsupported function".
I appreciate that much of the hypervisor has historically used EINVAL
this way, but this is (a) a pain for callers (b) evil, bad, and wrong
(c) unnecessary since EOPNOTSUPP is available.  We should at least not
perpetrate any more of this.  In an unreleased API we should change it
before release.

Thanks for your attention.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen PVH support in grub2

[Juergen Gross]

On 03/11/17 13:17, Roger Pau Monné wrote:
> On Fri, Nov 03, 2017 at 01:00:46PM +0100, Juergen Gross wrote:
>> On 29/09/17 17:51, Roger Pau Monné wrote:
>>> On Fri, Sep 29, 2017 at 03:33:58PM +, Juergen Gross wrote:
 On 29/09/17 17:24, Roger Pau Monné wrote:
> On Fri, Sep 29, 2017 at 02:46:53PM +, Juergen Gross wrote:
> Then, I also wonder whether it would make sense for this grub to load
> the kernel using the PVH entry point or the native entry point. Would
> it be possible to boot a Linux kernel up to the point where cpuid can
> be used inside of a PVH container?

 I don't think today's Linux allows that. This has been discussed
 very thoroughly at the time Boris added PVH V2 support to the kernel.
>>>
>>> OK, I'm not going to insist on that, but my plans for FreeBSD is to
>>> make the native entry point capable of booting inside of a PVH
>>> container up to the point where cpuid (or whatever method) can be used
>>> to detect the environment.
>>
>> Looking more thoroughly into the Linux boot code I think this could
>> work for Linux, too. But only if we can tell PVH from HVM in the guest.
>> How would you do that in FreeBSD? Via flags in the boot params? This
>> would the have to be done in the boot loader (e.g. grub or OVMF).
> 
> My plan was not to differentiate between HVM and PVH, but rather to
> make use of the ACPI information in order to decide which devices are
> available and which are not inside of a PVH guest.
> 
> For example in the FADT "IA-PC Boot Architecture Flags" field for PVH
> we already set "VGA Not Present" and "CMOS RTC Not Present". There
> might be other flags/fields that must be set, but I would like to
> avoid having a CPUID bit or similar saying "PVH", because then Xen
> will be tied to always providing the same set of devices in PVH
> containers.

I looked through the xen_pvh_domain() use cases in the Linux kernel
again.

Maybe we can really manage to not need differentiating PVH from HVM
until ACPI table scan. We'd need another hook for Xen, but this should
be easy as KVM already has a hook where we'd need one. So this can be
made more general and we are fine.

I even think we can drop some of the PVH tests, as the PVH-specific
handling (e.g. for grant table initialization) should work for HVM, too.


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 for-next 0/4] xen: Convert __page_to_mfn and _mfn_to_page to use typesafe MFN

[Jan Beulich]

>>> On 01.11.17 at 15:03,  wrote:
> Most of the users of page_to_mfn and mfn_to_page are either overriding
> the macros to make them work with mfn_t or use mfn_x/_mfn becaue the rest
> of the function use mfn_t.
> 
> So I think it is time to make __page_to_mfn and __mfn_to_page using typesafe
> MFN.

I have to admit that I still find the overall goal confusing: Afaict
the double-underscore-prefixed versions exist only to allow
easily overriding the non-prefixed ones. Hence the first and
foremost goal ought to be to convert everyone to using the
non-prefixed versions. Files wanting to avoid the typed forms
could then continue to use / be switched to the prefixed ones.

What you're doing here is producing a mess: The prefixed
versions should never have been touched in the first place.
And iirc this was discussed before, with the suggestion to use
overrides (for the non-prefixed versions) to limit overall patch
size.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [linux-4.9 test] 115597: regressions - FAIL

[osstest service owner]

flight 115597 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115597/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 114814

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-libvirt-vhd 18 guest-start.2fail in 115538 pass in 115597
 test-amd64-i386-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail in 
115566 pass in 115597
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail in 115582 pass 
in 115597
 test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeat fail pass in 115483
 test-armhf-armhf-xl-vhd  15 guest-start/debian.repeat  fail pass in 115538
 test-amd64-amd64-xl-qcow219 guest-start/debian.repeat  fail pass in 115566
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail pass in 
115566
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail pass in 115582

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop   fail REGR. vs. 114814

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop  fail in 115566 like 114814
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114814
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114814
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linux06b639e5a1a665ba6c959398ea0e6171c162028b
baseline version:
 linux5d7a76acad403638f635c918cc63d1d44ffa4065

Last test of basis   114814  2017-10-20 20:51:56 Z   16 days
Failing since114845  2017-10-21 16:14:17 Z   15 days   27 attempts
Te

Re: [Xen-devel] [For Xen-4.10 PATCH] docs/features: update the status of Credit2 implemented features

[George Dunlap]

On 11/06/2017 10:35 AM, Dario Faggioli wrote:
> As soft-affinity and caps will be available in Xen 4.10.
> 
> Signed-off-by: Dario Faggioli 

Reviewed-by: George Dunlap 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 for-next 0/4] xen: Convert __page_to_mfn and _mfn_to_page to use typesafe MFN

[Julien Grall]

Hi Jan,

On 06/11/17 11:37, Jan Beulich wrote:

On 01.11.17 at 15:03,  wrote:

Most of the users of page_to_mfn and mfn_to_page are either overriding
the macros to make them work with mfn_t or use mfn_x/_mfn becaue the rest
of the function use mfn_t.

So I think it is time to make __page_to_mfn and __mfn_to_page using typesafe
MFN.


I have to admit that I still find the overall goal confusing: Afaict
the double-underscore-prefixed versions exist only to allow
easily overriding the non-prefixed ones. Hence the first and
foremost goal ought to be to convert everyone to using the
non-prefixed versions. Files wanting to avoid the typed forms
could then continue to use / be switched to the prefixed ones.

What you're doing here is producing a mess: The prefixed
versions should never have been touched in the first place.
And iirc this was discussed before, with the suggestion to use
overrides (for the non-prefixed versions) to limit overall patch
size.


At the end of the discussion in the previous version, you were happy 
with the modification done here (see [1]).


Overall, I think this is an improvement compare to what we have today. 
Because we enforce the use of MFN typesafe by default. The developer 
would have to override the helpers if he wants to to use the 
non-typesafe version.


With your suggestion here, you would just keep the override around even 
when they are not necessary. They will have to be dropped at some point, 
so why not now?


Cheers,

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2017-10/msg00986.html




Jan



--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] Ping: [PATCH] x86emul: keep compiler from using {x, y, z}mm registers itself

[Jan Beulich]

>>> On 16.10.17 at 14:42,  wrote:
 On 16.10.17 at 14:37,  wrote:
> > On 16/10/17 13:32, Jan Beulich wrote:
> >> Since the emulator acts on the live hardware registers, we need to
> >> prevent the compiler from using them e.g. for inlined memcpy() /
> >> memset() (as gcc7 does). We can't, however, set this from the command
> >> line, as otherwise the 64-bit build would face issues with functions
> >> returning floating point values and being declared in standard headers.
> >>
> >> As the pragma isn't available prior to gcc6, we need to invoke it
> >> conditionally. Luckily up to gcc6 we haven't seen generated code access
> >> SIMD registers beyond what our asm()s do.
> >>
> >> Reported-by: George Dunlap 
> >> Signed-off-by: Jan Beulich 
> >> ---
> >> While this doesn't affect core functionality, I think it would still be
> >> nice for it to be allowed in for 4.10.
> > 
> > Agreed.
> > 
> > Has this been tested with Clang?
> 
> Sorry, no - still haven't got around to set up a suitable Clang
> locally.
> 
> >  It stands a good chance of being
> > compatible, but we may need an && !defined(__clang__) included.
> 
> Should non-gcc silently ignore "#pragma GCC ..." it doesn't
> recognize, or not define __GNUC__ in the first place if it isn't
> sufficiently compatible? I.e. if anything I'd expect we need
> "#elif defined(__clang__)" to achieve the same for Clang by
> some different pragma (if such exists).

Not having received any reply so far, I'm wondering whether
being able to build the test harness with clang is more
important than for it to work correctly when built with gcc. I
can't predict when I would get around to set up a suitable
clang on my dev systems.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-next 1/9] gcov: return ENOSYS for unimplemented gcov domctl

[Jan Beulich]

>>> On 06.11.17 at 12:16,  wrote:
> Jan Beulich writes ("Re: [PATCH for-next 1/9] gcov: return ENOSYS for 
> unimplemented gcov domctl"):
>> On 26.10.17 at 11:19,  wrote:
>> > --- a/xen/common/gcov/gcov.c
>> > +++ b/xen/common/gcov/gcov.c
>> > @@ -239,7 +239,7 @@ int sysctl_gcov_op(struct xen_sysctl_gcov_op *op)
>> >  break;
>> >  
>> >  default:
>> > -ret = -EINVAL;
>> > +ret = -ENOSYS;
>> >  break;
>> >  }
>> 
>> Very certainly ENOSYS is not in any way better. Despite the many
>> misuses of it, we've started enforcing that this wouldn't be spread.
>> -EOPNOTSUPP may be fine here, but -EINVAL is suitable as well.
>> -ENOSYS exclusively means that a _top level_ hypercall is
>> unimplemented (i.e. with very few exceptions there should be
>> exactly one place where it gets returned, which is in the main
>> hypercall dispatch code).
> 
> The distinction between unimplemented status of a top-level hypercall
> and unimplemented status of a sub-op is rarely useful to the caller.
> 
> Conversely, the distinction between an unimplemented facility, and a
> facility which is exists but is being used improperly, is vitally
> important to anyone who is trying to write compatibility code.
> 
> I don't mind if you want to insist on the former distinction,
> reserving ENOSYS for top-level hypercalls and EOPNOTSUPP for other
> functions.
> 
> But I absolutely do mind the use of EINVAL for "unsupported function".
> I appreciate that much of the hypervisor has historically used EINVAL
> this way, but this is (a) a pain for callers (b) evil, bad, and wrong
> (c) unnecessary since EOPNOTSUPP is available.  We should at least not
> perpetrate any more of this.  In an unreleased API we should change it
> before release.

Okay, so EOPNOTSUPP is it then, which is also my preference
(due to there being so many uses of EINVAL elsewhere). I've
merely mentioned that EINVAL would be suitable since,
technically speaking, the value in a "sub-operation" field being
invalid is no different from this being the case for the value in
any other field.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 for-next 0/4] xen: Convert __page_to_mfn and _mfn_to_page to use typesafe MFN

[Jan Beulich]

>>> On 06.11.17 at 12:47,  wrote:
> Hi Jan,
> 
> On 06/11/17 11:37, Jan Beulich wrote:
> On 01.11.17 at 15:03,  wrote:
>>> Most of the users of page_to_mfn and mfn_to_page are either overriding
>>> the macros to make them work with mfn_t or use mfn_x/_mfn becaue the rest
>>> of the function use mfn_t.
>>>
>>> So I think it is time to make __page_to_mfn and __mfn_to_page using typesafe
>>> MFN.
>> 
>> I have to admit that I still find the overall goal confusing: Afaict
>> the double-underscore-prefixed versions exist only to allow
>> easily overriding the non-prefixed ones. Hence the first and
>> foremost goal ought to be to convert everyone to using the
>> non-prefixed versions. Files wanting to avoid the typed forms
>> could then continue to use / be switched to the prefixed ones.
>> 
>> What you're doing here is producing a mess: The prefixed
>> versions should never have been touched in the first place.
>> And iirc this was discussed before, with the suggestion to use
>> overrides (for the non-prefixed versions) to limit overall patch
>> size.
> 
> At the end of the discussion in the previous version, you were happy 
> with the modification done here (see [1]).

From the angle looked at it back then I indeed was, but I'm looking
at this from a slightly different angle now with the reply above.

> Overall, I think this is an improvement compare to what we have today. 
> Because we enforce the use of MFN typesafe by default. The developer 
> would have to override the helpers if he wants to to use the 
> non-typesafe version.
> 
> With your suggestion here, you would just keep the override around even 
> when they are not necessary. They will have to be dropped at some point, 
> so why not now?

Why would we keep the overrides in place once no longer needed?
All I'm asking for is that the double-underscore prefixed macros be
left alone, and the non-prefixed versions be converted to be
type-safe by default (with the option to override). That'll allow the
prefixed variants to go way altogether once all code was switched
to typesafe, no longer requiring any overrides.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 for-next 0/4] xen: Convert __page_to_mfn and _mfn_to_page to use typesafe MFN

[Julien Grall]

On 06/11/17 12:11, Jan Beulich wrote:

On 06.11.17 at 12:47,  wrote:

Hi Jan,

On 06/11/17 11:37, Jan Beulich wrote:

On 01.11.17 at 15:03,  wrote:

Most of the users of page_to_mfn and mfn_to_page are either overriding
the macros to make them work with mfn_t or use mfn_x/_mfn becaue the rest
of the function use mfn_t.

So I think it is time to make __page_to_mfn and __mfn_to_page using typesafe
MFN.


I have to admit that I still find the overall goal confusing: Afaict
the double-underscore-prefixed versions exist only to allow
easily overriding the non-prefixed ones. Hence the first and
foremost goal ought to be to convert everyone to using the
non-prefixed versions. Files wanting to avoid the typed forms
could then continue to use / be switched to the prefixed ones.

What you're doing here is producing a mess: The prefixed
versions should never have been touched in the first place.
And iirc this was discussed before, with the suggestion to use
overrides (for the non-prefixed versions) to limit overall patch
size.


At the end of the discussion in the previous version, you were happy
with the modification done here (see [1]).


 From the angle looked at it back then I indeed was, but I'm looking
at this from a slightly different angle now with the reply above.


Overall, I think this is an improvement compare to what we have today.
Because we enforce the use of MFN typesafe by default. The developer
would have to override the helpers if he wants to to use the
non-typesafe version.

With your suggestion here, you would just keep the override around even
when they are not necessary. They will have to be dropped at some point,
so why not now?


Why would we keep the overrides in place once no longer needed?
All I'm asking for is that the double-underscore prefixed macros be
left alone, and the non-prefixed versions be converted to be
type-safe by default (with the option to override). That'll allow the
prefixed variants to go way altogether once all code was switched
to typesafe, no longer requiring any overrides.


If you left the double-underscore alone, then you can't convert headers 
using them to typesafe. This is because they can't use the non-prefixed 
version as they may be override.


So what you are suggesting here is will avoid converting those headers 
until someone step up and finish to convert all the source to MFN 
typesafe. Personally, I find quite silly to have to delay that...


Cheers,



Jan



--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [Qemu-devel] [PATCH 7/8] os-posix: Provide new -runasid option

[Markus Armbruster]

Sorry for the slow response.

Ian Jackson  writes:

> This allows the caller to specify a uid and gid to use, even if there
> is no corresponding password entry.  This will be useful in certain
> Xen configurations.
>
> Signed-off-by: Ian Jackson 
> ---
> v3: Error messages fixed.  Thanks to Peter Maydell and Ross Lagerwall.
> v2: Coding style fixes.
> ---
>  os-posix.c  | 49 -
>  qemu-options.hx | 12 
>  2 files changed, 52 insertions(+), 9 deletions(-)
>
> diff --git a/os-posix.c b/os-posix.c
> index 92e9d85..6cc5868 100644
> --- a/os-posix.c
> +++ b/os-posix.c
> @@ -43,6 +43,8 @@
>  #endif
>  
>  static struct passwd *user_pwd;
> +static uid_t user_uid = (uid_t)-1;
> +static gid_t user_gid = (gid_t)-1;
>  static const char *chroot_dir;
>  static int daemonize;
>  static int daemon_pipe;
> @@ -134,6 +136,9 @@ void os_set_proc_name(const char *s)
>   */
>  void os_parse_cmd_args(int index, const char *optarg)
>  {
> +unsigned long lv;
> +char *ep;
> +int rc;
>  switch (index) {
>  #ifdef CONFIG_SLIRP
>  case QEMU_OPTION_smb:
> @@ -150,6 +155,22 @@ void os_parse_cmd_args(int index, const char *optarg)
>  exit(1);
>  }
>  break;
> +case QEMU_OPTION_runasid:
> +errno = 0;
> +lv = strtoul(optarg, &ep, 0); /* can't qemu_strtoul, want *ep=='.' */

I'm afraid I can't see why qemu_strtoul() wouldn't work here.  Can you
enlighten me?

> +user_uid = lv; /* overflow here is ID in C99 */

I don't get the comment.  You check for overflow the obvious way below.
Sure you need a comment?

> +if (errno || *ep != '.' || user_uid != lv || user_uid == (uid_t)-1) {
> +fprintf(stderr, "Could not obtain uid from \"%s\"", optarg);
> +exit(1);
> +}
> +lv = 0;
> +rc = qemu_strtoul(ep + 1, 0, 0, &lv);
> +user_gid = lv; /* overflow here is ID in C99 */

Likewise.

> +if (rc || user_gid != lv || user_gid == (gid_t)-1) {
> +fprintf(stderr, "Could not obtain gid from \"%s\"", optarg);
> +exit(1);
> +}
> +break;
>  case QEMU_OPTION_chroot:
>  chroot_dir = optarg;
>  break;
> @@ -166,18 +187,28 @@ void os_parse_cmd_args(int index, const char *optarg)
>  
>  static void change_process_uid(void)
>  {
> -if (user_pwd) {
> -if (setgid(user_pwd->pw_gid) < 0) {
> -fprintf(stderr, "Failed to setgid(%d)\n", user_pwd->pw_gid);
> +if (user_pwd || user_uid != (uid_t)-1) {
> +gid_t intended_gid = user_pwd ? user_pwd->pw_gid : user_gid;
> +uid_t intended_uid = user_pwd ? user_pwd->pw_uid : user_uid;
> +if (setgid(intended_gid) < 0) {
> +fprintf(stderr, "Failed to setgid(%d)\n", intended_gid);
>  exit(1);
>  }
> -if (initgroups(user_pwd->pw_name, user_pwd->pw_gid) < 0) {
> -fprintf(stderr, "Failed to initgroups(\"%s\", %d)\n",
> -user_pwd->pw_name, user_pwd->pw_gid);
> -exit(1);
> +if (user_pwd) {
> +if (initgroups(user_pwd->pw_name, user_pwd->pw_gid) < 0) {
> +fprintf(stderr, "Failed to initgroups(\"%s\", %d)\n",
> +user_pwd->pw_name, user_pwd->pw_gid);
> +exit(1);
> +}
> +} else {
> +if (setgroups(1, &user_gid) < 0) {
> +fprintf(stderr, "Failed to setgroups(1, [%d])",
> +user_gid);
> +exit(1);
> +}
>  }
> -if (setuid(user_pwd->pw_uid) < 0) {
> -fprintf(stderr, "Failed to setuid(%d)\n", user_pwd->pw_uid);
> +if (setuid(intended_uid) < 0) {
> +fprintf(stderr, "Failed to setuid(%d)\n", intended_uid);
>  exit(1);
>  }
>  if (setuid(0) != -1) {
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 9f6e2ad..34a5329 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -3968,6 +3968,18 @@ Immediately before starting guest execution, drop root 
> privileges, switching
>  to the specified user.
>  ETEXI
>  
> +#ifndef _WIN32
> +DEF("runasid", HAS_ARG, QEMU_OPTION_runasid, \
> +"-runasid uid.gid change to numeric uid and gid just before starting 
> the VM\n",
> +QEMU_ARCH_ALL)
> +#endif
> +STEXI
> +@item -runasid @var{uid}.@var{gid}

Didn't we agree on using ':' instead of '.' as separator?

Sure we need yet another option?  Why can't we compatibly extend -runas?

If we truly need both, the rationale belongs into the commit message,
and we need to consider how they interact.  I'd recommend left-to-right
semantics, i.e. if you specify both, the last one wins.  Not what your
current code does, if I read it correctly.

> +@findex -runasid
> +Immediately before starting guest execution, drop root privileges, switching
> +to the specified uid and gid.
> +ETEXI
> +
>  DEF("prom-env", HAS_ARG, 

Re: [Xen-devel] [PATCH RFC 2/8] public/io/netif: add directory for backend parameters

[Joao Martins]

On Mon, Nov 06, 2017 at 10:33:59AM +, Paul Durrant wrote:
> > -Original Message-
> > From: Joao Martins [mailto:joao.m.mart...@oracle.com]
> > Sent: 02 November 2017 18:06
> > To: Xen Development List 
> > Cc: Joao Martins ; Konrad Rzeszutek Wilk
> > ; Paul Durrant ; Wei Liu
> > 
> > Subject: [PATCH RFC 2/8] public/io/netif: add directory for backend
> > parameters
> > 
> > The proposed directory provides a mechanism for tools to control the
> > maximum feature set of the device being provisioned by backend.
> > The parameters/features include offloading features, number of
> > queues etc.
> > 
> > Signed-off-by: Joao Martins 
> > ---
> >  xen/include/public/io/netif.h | 16 
> >  1 file changed, 16 insertions(+)
> > 
> > diff --git a/xen/include/public/io/netif.h b/xen/include/public/io/netif.h
> > index 2454448baa..a412e4771d 100644
> > --- a/xen/include/public/io/netif.h
> > +++ b/xen/include/public/io/netif.h
> > @@ -161,6 +161,22 @@
> >   */
> > 
> >  /*
> > + * The directory "require" maybe be created in backend path by tools
> > + * domain to override the maximum feature set that backend provides to
> > the
> > + * frontend. The children entries within this directory are features names
> > + * and the correspondent values that should be used backend as defaults
> > e.g.:
> > + *
> > + * /local/domain/X/backend///require
> > + * /local/domain/X/backend///require/multi-queue-
> > max-queues = "2"
> > + * /local/domain/X/backend///require/feature-no-csum-
> > offload = "1"
> > + *
> > + * In the example above, network backend will negotiate up to a maximum
> > of
> > + * two queues with frontend plus disabling IPv4 checksum offloading.
> > + *
> > + * This directory and its children entries shall only be visible to the 
> > backend.
> > + */
> > +
> 
> What should happen if the toolstack sets something in 'require' that
> the backend cannot provide? I don't see anything in your RFC patches
> to check that the backend has responded appropriately to the keys.

Hmm, you're right that this RFC doesn't handle that properly - but for the
ones the backend provide I had suggested (albeit not implemented here)
back in the other thread that we could compare the values of feature in
"require" with the one announced to the frontend. But well this wouldn't
cover the non-provided ones, and possibly would fall a bit as a hack.

I could change the format of the entries within "require"
directory to be e.g. "- = " and the
acknowledgement entry would come in the form "-status
= ". Consequently the lack of a "-status" entry would
have a stronger semantic i.e. unsupported and ignored. The toolstack then would 
have
means to check whether the feature was really succesfull set as desired
or not. But then one question comes to mind: should the backend be
prevented to init in the event that the features requested fail to be
set? In which case uevent (on Linux) isn't triggered and xenbus state doesn't
get changed and toolstack would fail with timeout later on.

Also, a nice thing of this stuff is that we could also use this to set
set backend implementation specific parameters that are not
described or relevant in I/O specs. But then I start to wonder where would
be the correct place for backends to specify its maximum feature set of
changeable entries? Maybe:

/local/domain/X/backend/vif/features/
/local/domain/X/backend/vif/features/-desc = "Description
of "

Cheers,
Joao

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [BUG] blkback reporting incorrect number of sectors, unable to boot

[Jan Beulich]

>>> On 04.11.17 at 05:48,  wrote:
> I added some additional storage to my server with some native 4k sector
> size disks.  The LVM volumes on that array seem to work fine when mounted
> by the host, and when passed through to any of the Linux guests, but
> Windows guests aren't able to use them when using PV drivers.  The work
> fine to install when I first install Windows (Windows 10, latest build) but
> once I install the PV drivers it will no longer boot and give an
> inaccessible boot device error.  If I assign the storage to a different
> Windows guest that already has the drivers installed (as secondary storage,
> not as the boot device) I see the disk listed in disk management, but the
> size of the disk is 8x larger than it should be.  After looking into it a
> bit, the disk is reporting 8x the number of sectors it should have when I
> run xenstore-ls.  Here is the info from xenstore-ls for the relevant volume:
> 
>   51712 = ""
>frontend = "/local/domain/8/device/vbd/51712"
>params = "/dev/tv_storage/main-storage"
>script = "/etc/xen/scripts/block"
>frontend-id = "8"
>online = "1"
>removable = "0"
>bootable = "1"
>state = "2"
>dev = "xvda"
>type = "phy"
>mode = "w"
>device-type = "disk"
>discard-enable = "1"
>feature-max-indirect-segments = "256"
>multi-queue-max-queues = "12"
>max-ring-page-order = "4"
>physical-device = "fe:0"
>physical-device-path = "/dev/dm-0"
>hotplug-status = "connected"
>feature-flush-cache = "1"
>feature-discard = "0"
>feature-barrier = "1"
>feature-persistent = "1"
>sectors = "34359738368"
>info = "0"
>sector-size = "4096"
>physical-sector-size = "4096"
> 
> 
> Here are the numbers for the volume as reported by fdisk:
> 
> Disk /dev/tv_storage/main-storage: 16 TiB, 17592186044416 bytes, 4294967296
> sectors
> Units: sectors of 1 * 4096 = 4096 bytes
> Sector size (logical/physical): 4096 bytes / 4096 bytes
> I/O size (minimum/optimal): 4096 bytes / 4096 bytes
> Disklabel type: dos
> Disk identifier: 0x
> 
> DeviceBoot StartEndSectors Size Id Type
> /dev/tv_storage/main-storage1  1 4294967295 4294967295  16T ee GPT
> 
> 
> As with the size reported in Windows disk management, the number of sectors
> from xenstore seems is 8x higher than what it should be.  The disks aren't
> using 512b sector emulation, they are natively 4k, so I have no idea where
> the 8x increase is coming from.

Hmm, looks like a backend problem indeed: struct hd_struct's
nr_sects (which get_capacity() returns) looks to be in 512-byte
units, regardless of actual sector size. Hence the plain
get_capacity() use as well the (wrongly open coded) use of
part_nr_sects_read() looks insufficient in vbd_sz(). Roger,
Konrad? Question of course is whether the Linux frontend then
also needs adjustment, and hence whether the backend can
be corrected in a compatible way in the first place.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.10] x86/cpuid: Minor fixups missed from previous work

[Jan Beulich]

 >>> On 03.11.17 at 18:35,  wrote:
> * Add more feature names to ./xen-cpuid
>  * Vertically align the magic comments in cpufeatureset.h
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Jan Beulich 



___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 for-next 0/4] xen: Convert __page_to_mfn and _mfn_to_page to use typesafe MFN

[Jan Beulich]

>>> On 06.11.17 at 13:16,  wrote:

> 
> On 06/11/17 12:11, Jan Beulich wrote:
> On 06.11.17 at 12:47,  wrote:
>>> Hi Jan,
>>>
>>> On 06/11/17 11:37, Jan Beulich wrote:
>>> On 01.11.17 at 15:03,  wrote:
> Most of the users of page_to_mfn and mfn_to_page are either overriding
> the macros to make them work with mfn_t or use mfn_x/_mfn becaue the rest
> of the function use mfn_t.
>
> So I think it is time to make __page_to_mfn and __mfn_to_page using 
> typesafe
> MFN.

 I have to admit that I still find the overall goal confusing: Afaict
 the double-underscore-prefixed versions exist only to allow
 easily overriding the non-prefixed ones. Hence the first and
 foremost goal ought to be to convert everyone to using the
 non-prefixed versions. Files wanting to avoid the typed forms
 could then continue to use / be switched to the prefixed ones.

 What you're doing here is producing a mess: The prefixed
 versions should never have been touched in the first place.
 And iirc this was discussed before, with the suggestion to use
 overrides (for the non-prefixed versions) to limit overall patch
 size.
>>>
>>> At the end of the discussion in the previous version, you were happy
>>> with the modification done here (see [1]).
>> 
>>  From the angle looked at it back then I indeed was, but I'm looking
>> at this from a slightly different angle now with the reply above.
>> 
>>> Overall, I think this is an improvement compare to what we have today.
>>> Because we enforce the use of MFN typesafe by default. The developer
>>> would have to override the helpers if he wants to to use the
>>> non-typesafe version.
>>>
>>> With your suggestion here, you would just keep the override around even
>>> when they are not necessary. They will have to be dropped at some point,
>>> so why not now?
>> 
>> Why would we keep the overrides in place once no longer needed?
>> All I'm asking for is that the double-underscore prefixed macros be
>> left alone, and the non-prefixed versions be converted to be
>> type-safe by default (with the option to override). That'll allow the
>> prefixed variants to go way altogether once all code was switched
>> to typesafe, no longer requiring any overrides.
> 
> If you left the double-underscore alone, then you can't convert headers 
> using them to typesafe. This is because they can't use the non-prefixed 
> version as they may be override.
> 
> So what you are suggesting here is will avoid converting those headers 
> until someone step up and finish to convert all the source to MFN 
> typesafe. Personally, I find quite silly to have to delay that...

Hmm, I see your point, but if we went the route you suggest,
what would be the steps to reach the ultimate result I've
described (the prefixed variants gone)? I seems to me that
this would require touching a lot of code a second time that is
being touched now, or is going to be touched as further
conversion happens.

Otoh, considering all the acks you've got already, if I'm the
only one thinking that switching the prefixed ones around is
the wrong thing, I perhaps shouldn't stand in the way of this
patch going in as is.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-i386-pvgrub

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-i386-pvgrub
testid guest-start

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  f48b5449dabc770acdde6d25cfbd265cfb71034d
  Bug not present: 86cf189a957129ea1ad6468fe9a0887b9e2819f3
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/115612/


  commit f48b5449dabc770acdde6d25cfbd265cfb71034d
  Author: Wei Liu 
  Date:   Thu Oct 12 20:19:07 2017 +0100
  
  tools/dombuilder: Switch to using gfn terminology for console and 
xenstore rings
  
  The sole use of xc_dom_translated() and xc_dom_p2m() outside of the domain
  builder is for libxl_dom() to translate the console and xenstore pfns back
  into useful values.  PV guest pfns are only interesting to the domain 
builder,
  and gfns are the address space used by all other hypercalls.
  
  Renaming the fields in xc_dom_image is deliberate, as it will cause
  out-of-tree users of the dombuilder to notice the different semantics.
  
  Correct the terminology throughout xc_dom_gnttab{_hvm,}_seed(), which are 
all
  using gfns despite the existing variable names.
  
  Signed-off-by: Andrew Cooper 
  Reviewed-by: Roger Pau Monné 
  Acked-by: Wei Liu 
  Tested-by: Julien Grall 
  Release-acked-by: Julien Grall 
  [ wei: fix stubdom build ]
  Signed-off-by: Wei Liu 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-amd64-i386-pvgrub.guest-start.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-unstable/test-amd64-amd64-i386-pvgrub.guest-start
 --summary-out=tmp/115612.bisection-summary --basis-template=115526 
--blessings=real,real-bisect xen-unstable test-amd64-amd64-i386-pvgrub 
guest-start
Searching for failure / basis pass:
 115593 fail [host=merlot1] / 115526 [host=italia1] 115496 [host=nobling0] 
115471 [host=godello0] 115464 [host=godello0] 115450 [host=fiano0] 115419 
[host=huxelrebe0] 115401 [host=pinot1] 115378 [host=baroque1] 115362 
[host=merlot0] 115345 [host=rimava1] 115331 [host=elbling1] 115314 
[host=nocera1] 115295 [host=chardonnay1] 115272 [host=fiano1] 115235 
[host=nobling1] 115195 [host=baroque0] 115174 [host=elbling0] 115163 
[host=italia0] 115132 [host=huxelrebe1] 115087 [host=nocera0] 115037 
[host=rimava0] 114972 [host=chardonnay0] 114836 [host=nobling0] 114808 ok.
Failure / basis pass flights: 115593 / 114808
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 5d7a76acad403638f635c918cc63d1d44ffa4065 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
5cd7ce5dde3f228b3b669ed9ca432f588947bd40 
e07ebab86595df29838f0960693df84f34528833
Basis pass 9d36d3eff2f85efad0a3b0c6031081654ae33928 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
5cd7ce5dde3f228b3b669ed9ca432f588947bd40 
8e77dabc58c4b6c747dfb4b948551147905a7840
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/linux-pvops.git#9d36d3eff2f85efad0a3b0c6031081654ae33928-5d7a76acad403638f635c918cc63d1d44ffa4065
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#c8ea0457495342c417c3dc033bba25148b279f60-c8ea0457495342c417c3dc033bba25148b279f60
 
git://xenbits.xen.org/qemu-xen.git#5cd7ce5dde3f228b3b669ed9ca432f588947bd40-5cd7ce5dde3f228b3b669ed9ca432f588947bd40
 
git://xenbits.xen.org/xen.git#8e77dabc58c4b6c747dfb4b948551147905a7840-e07ebab86595df29838f0960693df84f34528833
Loaded 2001 nodes in revision graph
Searching for test results:
 114808 pass 9d36d3eff2f85efad0a3b0c6031081654ae33928 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
5cd7ce5dde3f228b3b669ed9ca432f588947bd40 
8e77dabc58c4b6c747dfb4b948551147905a7840
 114836 [host=nobling0]
 115037 [host=rimava0]
 114972 [host=chardonnay0]
 115087 [host=nocera0]
 115132 [host=huxelrebe1]
 115163 [host=italia0]
 115272 [host=fiano1]
 115174 [host=elbling0]
 115235 [host=nobling1]
 115195 [host=baroque0]
 115345 [host=rimava1]
 115295 [host=chardonnay1]
 115314 [host=nocera1]
 115331 [host=elb

Re: [Xen-devel] [PATCH for-4.10] x86/cpuid: Minor fixups missed from previous work

[Wei Liu]

On Mon, Nov 06, 2017 at 05:35:10AM -0700, Jan Beulich wrote:
>  >>> On 03.11.17 at 18:35,  wrote:
> > * Add more feature names to ./xen-cpuid
> >  * Vertically align the magic comments in cpufeatureset.h
> > 
> > Signed-off-by: Andrew Cooper 
> 
> Acked-by: Jan Beulich 
> 
> 

Acked-by: Wei Liu 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [linux-linus test] 115599: regressions - FAIL

[osstest service owner]

flight 115599 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115599/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel   broken in 115585
 test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeat fail REGR. vs. 
114682
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop   fail REGR. vs. 114682

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-qemuu-nested-intel 4 host-install(4) broken in 115585 pass in 
115599
 test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail in 115585 pass in 
115599
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail in 115585 pass 
in 115599
 test-armhf-armhf-xl-vhd  15 guest-start/debian.repeat  fail pass in 115585

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 114682
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114682
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114682
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 114682
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114682
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 114682
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114682
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 114682
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass

version targeted for testing:
 linux2d6349944d967129c1da3c47287376f10121dbe1
baseline version:
 linuxebe6e90ccc6679cb01d2b280e4b61e6092d4bedb

Last test of basis   114682  2017-10-18 09:54:11 Z   19 days
Failing since114781  2017-10-20 01:00:47 Z   17 days   29 attempts
Testing same since   115585  2017-11-05 06:54:49 Z1 days2 attempts


504 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass   

Re: [Xen-devel] Xen PVH support in grub2

[Boris Ostrovsky]

On 11/06/2017 02:16 AM, Juergen Gross wrote:
> On 03/11/17 20:00, Boris Ostrovsky wrote:
>> On 11/03/2017 02:40 PM, Juergen Gross wrote:
>>> On 03/11/17 19:35, Boris Ostrovsky wrote:
 On 11/03/2017 02:23 PM, Juergen Gross wrote:
> On 03/11/17 19:19, Boris Ostrovsky wrote:
>> On 11/03/2017 02:05 PM, Juergen Gross wrote:
>>> So again the question: how to tell whether we are PVH or HVM in
>>> init_hypervisor_platform()? ACPi tables are scanned way later...
>> Can we make grub/OVMF append a boot option?
>>
>> Or set setup_header.hardware_subarch to something? We already have
>> X86_SUBARCH_XEN but it is only used by PV.  Or we might be able to use
>> hardware_subarch_data (will need to get a buy-in from x86 maintainers, I
>> think).
> But wouldn't this break the idea to reuse the native boot paths in
> grub/OVMF without further modifications?
 WDYM? We will have to have some sort of a plugin in either one to build
 the zeropage anyway. So we'd set hardware_subarch there, in addition to
 other things like setting memory and such.
>>> But isn't the zeropage already being built? I admit that setting subarch
>>> isn't a big deal, but using another entry with a passed-through pvh
>>> start struct isn't either...
>> I don't follow, sorry. My understanding is that zeropage will be built
>> by PVH-enlightened grub so part of this process would be setting the
>> subarch bit.
> My reasoning was based on Roger's remark:
>
> "OTOH if Linux is capable of booting from the native entry point inside
> of a PVH container, we would only have to port OVMF and grub in order
> to work inside of a PVH container, leaving the rest of the logic
> untouched."

Right, and in my mind porting OVMF/grub includes creating proper zeropage.

BTW, another option might be to "type_of_loader = (9 << 4) | 0", which
is what init_pvh_bootparams() does. In fact, whatever is done in the
firmware should probably match what that routine does.

-boris

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-i386-pvgrub

[Wei Liu]

On Mon, Nov 06, 2017 at 01:47:56PM +, osstest service owner wrote:
> branch xen-unstable
> xenbranch xen-unstable
> job test-amd64-amd64-i386-pvgrub
> testid guest-start
> 
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
> Tree: qemuu git://xenbits.xen.org/qemu-xen.git
> Tree: xen git://xenbits.xen.org/xen.git
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  xen git://xenbits.xen.org/xen.git
>   Bug introduced:  f48b5449dabc770acdde6d25cfbd265cfb71034d
>   Bug not present: 86cf189a957129ea1ad6468fe9a0887b9e2819f3
>   Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/115612/
> 
> 
>   commit f48b5449dabc770acdde6d25cfbd265cfb71034d
>   Author: Wei Liu 
>   Date:   Thu Oct 12 20:19:07 2017 +0100
>   
>   tools/dombuilder: Switch to using gfn terminology for console and 
> xenstore rings
>   
>   The sole use of xc_dom_translated() and xc_dom_p2m() outside of the 
> domain
>   builder is for libxl_dom() to translate the console and xenstore pfns 
> back
>   into useful values.  PV guest pfns are only interesting to the domain 
> builder,
>   and gfns are the address space used by all other hypercalls.
>   
>   Renaming the fields in xc_dom_image is deliberate, as it will cause
>   out-of-tree users of the dombuilder to notice the different semantics.
>   
>   Correct the terminology throughout xc_dom_gnttab{_hvm,}_seed(), which 
> are all
>   using gfns despite the existing variable names.
>   
>   Signed-off-by: Andrew Cooper 
>   Reviewed-by: Roger Pau Monn?? 
>   Acked-by: Wei Liu 
>   Tested-by: Julien Grall 
>   Release-acked-by: Julien Grall 
>   [ wei: fix stubdom build ]
>   Signed-off-by: Wei Liu 

This has broken pvgrub. The problem is more than just the name of the
variables. I have reverted this and its successor patch.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Ping: [PATCH] x86emul: keep compiler from using {x, y, z}mm registers itself

[George Dunlap]

On 11/06/2017 11:59 AM, Jan Beulich wrote:
 On 16.10.17 at 14:42,  wrote:
> On 16.10.17 at 14:37,  wrote:
>>> On 16/10/17 13:32, Jan Beulich wrote:
 Since the emulator acts on the live hardware registers, we need to
 prevent the compiler from using them e.g. for inlined memcpy() /
 memset() (as gcc7 does). We can't, however, set this from the command
 line, as otherwise the 64-bit build would face issues with functions
 returning floating point values and being declared in standard headers.

 As the pragma isn't available prior to gcc6, we need to invoke it
 conditionally. Luckily up to gcc6 we haven't seen generated code access
 SIMD registers beyond what our asm()s do.

 Reported-by: George Dunlap 
 Signed-off-by: Jan Beulich 
 ---
 While this doesn't affect core functionality, I think it would still be
 nice for it to be allowed in for 4.10.
>>>
>>> Agreed.
>>>
>>> Has this been tested with Clang?
>>
>> Sorry, no - still haven't got around to set up a suitable Clang
>> locally.
>>
>>>  It stands a good chance of being
>>> compatible, but we may need an && !defined(__clang__) included.
>>
>> Should non-gcc silently ignore "#pragma GCC ..." it doesn't
>> recognize, or not define __GNUC__ in the first place if it isn't
>> sufficiently compatible? I.e. if anything I'd expect we need
>> "#elif defined(__clang__)" to achieve the same for Clang by
>> some different pragma (if such exists).
> 
> Not having received any reply so far, I'm wondering whether
> being able to build the test harness with clang is more
> important than for it to work correctly when built with gcc. I
> can't predict when I would get around to set up a suitable
> clang on my dev systems.

I agree with the argument you make above.  On the unlikely chance
there's a problem Travis should catch it, and someone who actually has a
clang setup can help sort it out.

 -George

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen PVH support in grub2

[Juergen Gross]

On 06/11/17 15:51, Boris Ostrovsky wrote:
> On 11/06/2017 02:16 AM, Juergen Gross wrote:
>> On 03/11/17 20:00, Boris Ostrovsky wrote:
>>> On 11/03/2017 02:40 PM, Juergen Gross wrote:
 On 03/11/17 19:35, Boris Ostrovsky wrote:
> On 11/03/2017 02:23 PM, Juergen Gross wrote:
>> On 03/11/17 19:19, Boris Ostrovsky wrote:
>>> On 11/03/2017 02:05 PM, Juergen Gross wrote:
 So again the question: how to tell whether we are PVH or HVM in
 init_hypervisor_platform()? ACPi tables are scanned way later...
>>> Can we make grub/OVMF append a boot option?
>>>
>>> Or set setup_header.hardware_subarch to something? We already have
>>> X86_SUBARCH_XEN but it is only used by PV.  Or we might be able to use
>>> hardware_subarch_data (will need to get a buy-in from x86 maintainers, I
>>> think).
>> But wouldn't this break the idea to reuse the native boot paths in
>> grub/OVMF without further modifications?
> WDYM? We will have to have some sort of a plugin in either one to build
> the zeropage anyway. So we'd set hardware_subarch there, in addition to
> other things like setting memory and such.
 But isn't the zeropage already being built? I admit that setting subarch
 isn't a big deal, but using another entry with a passed-through pvh
 start struct isn't either...
>>> I don't follow, sorry. My understanding is that zeropage will be built
>>> by PVH-enlightened grub so part of this process would be setting the
>>> subarch bit.
>> My reasoning was based on Roger's remark:
>>
>> "OTOH if Linux is capable of booting from the native entry point inside
>> of a PVH container, we would only have to port OVMF and grub in order
>> to work inside of a PVH container, leaving the rest of the logic
>> untouched."
> 
> Right, and in my mind porting OVMF/grub includes creating proper zeropage.

Aah, okay. I reasoned on the assumption to just enable OVMF/grub to run
in PVH environment without touching the parts setting up anything for
the new kernel.

> BTW, another option might be to "type_of_loader = (9 << 4) | 0", which
> is what init_pvh_bootparams() does. In fact, whatever is done in the
> firmware should probably match what that routine does.

So it wouldn't be possible any longer to tell whether the kernel has
been booted directly or via grub. I don't like this. The loader type
is accessible via sysfs after all.


Juergen


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [Qemu-devel] [PATCH 7/8] os-posix: Provide new -runasid option

[Ian Jackson]

Hi.  Thanks for the (re)-review.

Markus Armbruster writes ("Re: [Qemu-devel] [PATCH 7/8] os-posix: Provide new 
-runasid option"):
> Ian Jackson  writes:
> > +case QEMU_OPTION_runasid:
> > +errno = 0;
> > +lv = strtoul(optarg, &ep, 0); /* can't qemu_strtoul, want *ep=='.' 
> > */
> 
> I'm afraid I can't see why qemu_strtoul() wouldn't work here.  Can you
> enlighten me?

qemu_strtoul fails (returns an error) if the delimiter (that is, the
first character which is not processed as digit by strtoul) is not
'\0'.  Normally this is desirable, because it correctly rejects
strings like "123blather".  But here we are trying to process a string
whose first non-digit is ':', and we will handle the tail part
explicitly.

It would be possible to use strchr and then to write a '\0' over the
':' but I dislike that processing style (and it is forbidden by the
const annotations on os_parse_cmd_args etc.)

> > +user_uid = lv; /* overflow here is ID in C99 */
> 
> I don't get the comment.  You check for overflow the obvious way below.
> Sure you need a comment?

This relates to overflow in the assignment, only.  lv is an unsigned
long and user_uid is a uid_t (which may be smaller).  Normally, signed
integer overflow is UB, but this is not the case when converting from
another integer type.

There are two possible overflows: 1. a string that strtoul cannot get
to fit in an unsigned long, which produces a nonzero errno; and, 2. a
value which fits in an unsigned long but not a uid_t.  In the latter
case, we convert it _back_ into an unsigned long, as an implicit
conversion in this middle test:

> > +if (errno || *ep != '.' || user_uid != lv || user_uid == 
> > (uid_t)-1) {

If that succeeds, we know we can round-trip it so it is valid.  The
remaining check needed is that it doesn't round trip to the sentinel
uid value.

Does that all make sense ?  I'm not sure how much of this to document
in comments.  It's deeply annoying that C is such a puzzle language
here and that therefore such complicated reasoning and
not-immediately-obvious code is needed, to do something so simple.

If you would like me to remove the comment, I can drop it, of course.
I don't really mind.

> > +#ifndef _WIN32
> > +DEF("runasid", HAS_ARG, QEMU_OPTION_runasid, \
> > +"-runasid uid.gid change to numeric uid and gid just before 
> > starting the VM\n",
> > +QEMU_ARCH_ALL)
> > +#endif
> > +STEXI
> > +@item -runasid @var{uid}.@var{gid}
> 
> Didn't we agree on using ':' instead of '.' as separator?
> 
> Sure we need yet another option?  Why can't we compatibly extend -runas?

For some reason you are looking at an old version of the patch.  That
may be my fault - there were a few mis-posts.  Sorry about that.

The final version does indeed have ':' and does reuse the -runas
option.

> If we truly need both, the rationale belongs into the commit message,
> and we need to consider how they interact.  I'd recommend left-to-right
> semantics, i.e. if you specify both, the last one wins.  Not what your
> current code does, if I read it correctly.

Happily this is now irrelevant.

I will repost this series after I hear from you about strtoul and the
overflow comment.

Regards,
Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v7 2/5] x86/pvclock: add setter for pvclock_pvti_cpu0_va

[Paolo Bonzini]

On 19/10/2017 15:39, Joao Martins wrote:
> Right now there is only a pvclock_pvti_cpu0_va() which is defined
> on kvmclock since:
> 
> commit dac16fba6fc5
> ("x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap")
> 
> The only user of this interface so far is kvm. This commit adds a
> setter function for the pvti page and moves pvclock_pvti_cpu0_va
> to pvclock, which is a more generic place to have it; and would
> allow other PV clocksources to use it, such as Xen.
> 
> Signed-off-by: Joao Martins 
> Acked-by: Andy Lutomirski 

Acked-by: Paolo Bonzini 

IOW, the Xen folks are free to pick up the whole series. :)

Paolo

> ---
> Changes since v1:
>  * Rebased: the only conflict was that I had move the export
>  pvclock_pvti_cpu0_va() symbol as it is used by kvm PTP driver.
>  * Do not initialize pvti_cpu0_va to NULL (checkpatch error)
>  ( Comments from Andy Lutomirski )
>  * Removed asm/pvclock.h 'pvclock_set_pvti_cpu0_va' definition
>  for non !PARAVIRT_CLOCK to better track screwed Kconfig stuff.
>  * Add his Acked-by (provided the previous adjustment was made)
> 
> Changes since RFC:
>  (Comments from Andy Lutomirski)
>  * Add __init to pvclock_set_pvti_cpu0_va
>  * Add WARN_ON(vclock_was_used(VCLOCK_PVCLOCK)) to
>  pvclock_set_pvti_cpu0_va
> ---
>  arch/x86/include/asm/pvclock.h | 19 ++-
>  arch/x86/kernel/kvmclock.c |  7 +--
>  arch/x86/kernel/pvclock.c  | 14 ++
>  3 files changed, 25 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/x86/include/asm/pvclock.h b/arch/x86/include/asm/pvclock.h
> index 448cfe1b48cf..6f228f90cdd7 100644
> --- a/arch/x86/include/asm/pvclock.h
> +++ b/arch/x86/include/asm/pvclock.h
> @@ -4,15 +4,6 @@
>  #include 
>  #include 
>  
> -#ifdef CONFIG_KVM_GUEST
> -extern struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void);
> -#else
> -static inline struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
> -{
> - return NULL;
> -}
> -#endif
> -
>  /* some helper functions for xen and kvm pv clock sources */
>  u64 pvclock_clocksource_read(struct pvclock_vcpu_time_info *src);
>  u8 pvclock_read_flags(struct pvclock_vcpu_time_info *src);
> @@ -101,4 +92,14 @@ struct pvclock_vsyscall_time_info {
>  
>  #define PVTI_SIZE sizeof(struct pvclock_vsyscall_time_info)
>  
> +#ifdef CONFIG_PARAVIRT_CLOCK
> +void pvclock_set_pvti_cpu0_va(struct pvclock_vsyscall_time_info *pvti);
> +struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void);
> +#else
> +static inline struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
> +{
> + return NULL;
> +}
> +#endif
> +
>  #endif /* _ASM_X86_PVCLOCK_H */
> diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
> index d88967659098..538738047ff5 100644
> --- a/arch/x86/kernel/kvmclock.c
> +++ b/arch/x86/kernel/kvmclock.c
> @@ -47,12 +47,6 @@ early_param("no-kvmclock", parse_no_kvmclock);
>  static struct pvclock_vsyscall_time_info *hv_clock;
>  static struct pvclock_wall_clock wall_clock;
>  
> -struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
> -{
> - return hv_clock;
> -}
> -EXPORT_SYMBOL_GPL(pvclock_pvti_cpu0_va);
> -
>  /*
>   * The wallclock is the time of day when we booted. Since then, some time may
>   * have elapsed since the hypervisor wrote the data. So we try to account for
> @@ -334,6 +328,7 @@ int __init kvm_setup_vsyscall_timeinfo(void)
>   return 1;
>   }
>  
> + pvclock_set_pvti_cpu0_va(hv_clock);
>   put_cpu();
>  
>   kvm_clock.archdata.vclock_mode = VCLOCK_PVCLOCK;
> diff --git a/arch/x86/kernel/pvclock.c b/arch/x86/kernel/pvclock.c
> index 5c3f6d6a5078..cb7d6d9c9c2d 100644
> --- a/arch/x86/kernel/pvclock.c
> +++ b/arch/x86/kernel/pvclock.c
> @@ -25,8 +25,10 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  static u8 valid_flags __read_mostly = 0;
> +static struct pvclock_vsyscall_time_info *pvti_cpu0_va __read_mostly;
>  
>  void pvclock_set_flags(u8 flags)
>  {
> @@ -144,3 +146,15 @@ void pvclock_read_wallclock(struct pvclock_wall_clock 
> *wall_clock,
>  
>   set_normalized_timespec(ts, now.tv_sec, now.tv_nsec);
>  }
> +
> +void pvclock_set_pvti_cpu0_va(struct pvclock_vsyscall_time_info *pvti)
> +{
> + WARN_ON(vclock_was_used(VCLOCK_PVCLOCK));
> + pvti_cpu0_va = pvti;
> +}
> +
> +struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
> +{
> + return pvti_cpu0_va;
> +}
> +EXPORT_SYMBOL_GPL(pvclock_pvti_cpu0_va);
> 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [linux-4.9 test] 115538: regressions - FAIL

[Ian Jackson]

osstest service owner writes ("[linux-4.9 test] 115538: regressions - FAIL"):
> flight 115538 linux-4.9 real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/115538/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 
> 114814
...> 
> version targeted for testing:
>  linux06b639e5a1a665ba6c959398ea0e6171c162028b

(test-lab)osstest@osstest:/home/iwj/testing.git$ 
OSSTEST_CONFIG=production-config ./mg-force-push linux-4.9 115538 
06b639e5a1a665ba6c959398ea0e6171c162028b
tree in flights should be 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
checking revisioins used in 115538...
  06b639e5a1a665ba6c959398ea0e6171c162028b (ours)  3 uses
build-amd64-pvops  built_revision_linux
build-armhf-pvops  built_revision_linux
build-i386-pvops   built_revision_linux
./ap-fetch-version linux-4.9
06b639e5a1a665ba6c959398ea0e6171c162028b
./ap-push linux-4.9 06b639e5a1a665ba6c959398ea0e6171c162028b
...
To osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
   5d7a76a..06b639e  06b639e5a1a665ba6c959398ea0e6171c162028b -> 
tested/linux-4.9

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen PVH support in grub2

[Boris Ostrovsky]

On 11/06/2017 10:05 AM, Juergen Gross wrote:
> On 06/11/17 15:51, Boris Ostrovsky wrote:
>> On 11/06/2017 02:16 AM, Juergen Gross wrote:
>>> On 03/11/17 20:00, Boris Ostrovsky wrote:
 On 11/03/2017 02:40 PM, Juergen Gross wrote:
> On 03/11/17 19:35, Boris Ostrovsky wrote:
>> On 11/03/2017 02:23 PM, Juergen Gross wrote:
>>> On 03/11/17 19:19, Boris Ostrovsky wrote:
 On 11/03/2017 02:05 PM, Juergen Gross wrote:
> So again the question: how to tell whether we are PVH or HVM in
> init_hypervisor_platform()? ACPi tables are scanned way later...
 Can we make grub/OVMF append a boot option?

 Or set setup_header.hardware_subarch to something? We already have
 X86_SUBARCH_XEN but it is only used by PV.  Or we might be able to use
 hardware_subarch_data (will need to get a buy-in from x86 maintainers, 
 I
 think).
>>> But wouldn't this break the idea to reuse the native boot paths in
>>> grub/OVMF without further modifications?
>> WDYM? We will have to have some sort of a plugin in either one to build
>> the zeropage anyway. So we'd set hardware_subarch there, in addition to
>> other things like setting memory and such.
> But isn't the zeropage already being built? I admit that setting subarch
> isn't a big deal, but using another entry with a passed-through pvh
> start struct isn't either...
 I don't follow, sorry. My understanding is that zeropage will be built
 by PVH-enlightened grub so part of this process would be setting the
 subarch bit.
>>> My reasoning was based on Roger's remark:
>>>
>>> "OTOH if Linux is capable of booting from the native entry point inside
>>> of a PVH container, we would only have to port OVMF and grub in order
>>> to work inside of a PVH container, leaving the rest of the logic
>>> untouched."
>> Right, and in my mind porting OVMF/grub includes creating proper zeropage.
> Aah, okay. I reasoned on the assumption to just enable OVMF/grub to run
> in PVH environment without touching the parts setting up anything for
> the new kernel.

Someone needs to do what xen_prepare_pvh() does.

And, for 64-bit, we also may need to build early pagetables since
startup_64() (unlike startup_32()) expects paging to be on. (I don't
know whether this is already part of standard FW codepath)

>
>> BTW, another option might be to "type_of_loader = (9 << 4) | 0", which
>> is what init_pvh_bootparams() does. In fact, whatever is done in the
>> firmware should probably match what that routine does.
> So it wouldn't be possible any longer to tell whether the kernel has
> been booted directly or via grub. I don't like this. The loader type
> is accessible via sysfs after all.

I didn't know that. What is the path?

-boris


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [OSSTEST PATCH 2/2] ap-push: turn off set -x

[Ian Jackson]

This makes the output of mg-force-push quite unpleasant, amongst other
things.

Signed-off-by: Ian Jackson 
---
 ap-push | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ap-push b/ap-push
index a27ccc2..6c95b1f 100755
--- a/ap-push
+++ b/ap-push
@@ -17,7 +17,7 @@
 # along with this program.  If not, see .
 
 
-set -ex -o posix
+set -e -o posix
 
 branch=$1
 revision=$2
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [OSSTEST PATCH 1/2] mg-force-push: New script

[Ian Jackson]

This does some safety checks and reduces the risk of c&p mistakes.
It has to be run as osst...@osstest.test-lab (or equivalent).

Signed-off-by: Ian Jackson 
---
 mg-force-push | 121 ++
 1 file changed, 121 insertions(+)
 create mode 100755 mg-force-push

diff --git a/mg-force-push b/mg-force-push
new file mode 100755
index 000..19f99ad
--- /dev/null
+++ b/mg-force-push
@@ -0,0 +1,121 @@
+#!/usr/bin/perl -w
+#
+# usage:
+#  ./mg-force-push BRANCH FLIGHT REVISION
+#
+# works only if BRANCH is
+#  valid for ap-fetch and ap-print-url
+#  the branch of flight FLIGHT
+
+use strict;
+use warnings;
+
+use Osstest;
+
+my @dryrun;
+
+while (@ARGV && $ARGV[0] =~ m/^-/) {
+$_ = shift @ARGV;
+last if $_ eq '-';
+while (m/^-./) {
+if (s/^-n/-/ || s/^--dry-run$//) {
+push @dryrun, qw(echo);
+} else {
+die "$_ ?";
+}
+}
+}
+
+die unless @ARGV==3;
+
+our ($branch, $flight, $revision) = @ARGV;
+
+csreadconfig();
+
+our $url;
+
+sub db_checks () {
+my $flt_q = $dbh_tests->prepare(fetchrow_hashref();
+$flt_row->{blessing} eq 'real' or die "$flt_row->{blessing} ?";
+$flt_row->{branch} eq $branch or die "$flt_row->{branch} ?";
+
+%revuses = ();
+$rev_q->execute($flight, $url);
+while (my $rev_row = $rev_q->fetchrow_hashref()) {
+push @{ $revuses{ $rev_row->{brevision} } }, $rev_row;
+}
+});
+
+die unless $revuses{$revision};
+my $bad;
+foreach my $brevision (sort { @{ $revuses{$b} } <=>
+  @{ $revuses{$a} } } keys %revuses) {
+my $rj = $revuses{$brevision};
+printf "  %s%s  %d uses\n", $brevision,
+($brevision eq $revision ? ' (ours)' : ''),
+scalar @$rj;
+foreach my $use (@$rj) {
+printf "%-30s %s\n", $use->{job}, $use->{bname};
+}
+if (@$rj > @{ $revuses{$revision} }) {
+printf " ^^ more popular!\n";
+$bad = 1;
+}
+}
+die "our revision $revision is not most popular in $flight !" if $bad;
+}
+
+sub geturl () {
+$!=0; $?=0; $url = `./ap-print-url $branch`;
+die "$? $!" unless chomp $url;
+printf "tree in flights should be %s\n", $url;
+}
+
+sub runcmd_ordryrun {
+$!=0; $?=0;
+print "@_\n" unless @dryrun;
+system((@dryrun, @_))
+and die "@dryrun @_ $! $?" if $! or $:
+}
+
+sub fetch () {
+runcmd_ordryrun qw(./ap-fetch-version), $branch;
+}
+
+sub dopush () {
+runcmd_ordryrun qw(./ap-push), $branch, $revision;
+}
+
+geturl();
+db_checks();
+fetch();
+dopush();
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [qemu-mainline test] 115609: regressions - FAIL

[osstest service owner]

flight 115609 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115609/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-vhd  16 guest-start.2  fail in 115575 REGR. vs. 114507

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-libvirt-vhd 18 guest-start.2fail in 115575 pass in 115600
 test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail in 115575 pass in 
115609
 test-amd64-amd64-xl-qcow220 guest-start.2fail in 115600 pass in 115609
 test-armhf-armhf-xl-vhd  15 guest-start/debian.repeat  fail pass in 115575
 test-amd64-i386-xl-xsm   20 guest-start/debian.repeat  fail pass in 115587
 test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeat fail pass in 115600
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat  fail pass in 115600
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail pass in 
115600

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop  fail blocked in 114507
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop  fail in 115600 like 114507
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 114507
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 114507
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114507
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 114507
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 qemuub33afc415622e5eb26e0f14fd27eb86e32a5472e
baseline version:
 qemuuf90ea7ba7c5ae7010ee0ce062207ae42530f57d6

Last test of basis   114507  2017-10-15 01:03:38 Z   22 days
Failing since114546  2017-10-16 12:16:28 Z   21 days   56 attempts
Testing same since   115529  2017-11-03 15:30:10 Z3 days6 attempts


People who touched revisions under test:
  Aaron Lindsay 
  Alberto Garcia 
  Aleksandr Bezzubikov 
  Alex Bennée 
  Alexey Kardashevskiy 
  Alexey Perevalov 
  Alistair Francis 
  Amarnath Valluri 
  Andreas Färber 
  Andrew Baumann 
  Anthoine Bourgeois 
  Anthony PERARD 
  Artyom Tarasenko 
  Bishara AbuHattoum 
  Carlo Marcelo Arenas Belón 
  Chen Hanxi

[Xen-devel] [xen-unstable-smoke test] 115616: tolerable all pass - PUSHED

[osstest service owner]

flight 115616 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115616/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  1f61c07d79abda1e747d70d83edffe4efca48e17
baseline version:
 xen  e07ebab86595df29838f0960693df84f34528833

Last test of basis   115531  2017-11-03 16:04:11 Z3 days
Testing same since   115616  2017-11-06 15:01:19 Z0 days1 attempts


People who touched revisions under test:
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=1f61c07d79abda1e747d70d83edffe4efca48e17
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.
 PERLLIB=.:.
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
1f61c07d79abda1e747d70d83edffe4efca48e17
+ branch=xen-unstable-smoke
+ revision=1f61c07d79abda1e747d70d83edffe4efca48e17
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.:.
 PERLLIB=.:.:.
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
+++ export PERLLIB=.:.:.:.
+++ PERLLIB=.:.:.:.
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.9-testing
+ '[' x1f61c07d79abda1e747d70d83edffe4efca48e17 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.g

[Xen-devel] [PATCH] Xen/pciback: Implement PCI slot or bus reset with 'do_flr' SysFS attribute

[Govinda Tatti]

The life-cycle of a PCI device in Xen pciback is complex and is constrained
by the generic PCI locking mechanism.

- It starts with the device being bound to us, for which we do a function
  reset (done via SysFS so the PCI lock is held).
- If the device is unbound from us, we also do a function reset
  (done via SysFS so the PCI lock is held).
- If the device is un-assigned from a guest - we do a function reset
  (no PCI lock is held).

All reset operations are done on the individual PCI function level
(so bus:device:function).

The reset for an individual PCI function means device must support FLR
(PCIe or AF), PM reset on D3hot->D0 device specific reset, or a secondary
bus reset for a singleton device on a bus but FLR does not have widespread
support or it is not reliable in some cases. So, we need to provide an
alternate mechanism to users to perform a slot or bus level reset.

Currently, a slot or bus reset is not exposed in SysFS as there is no good
way of exposing a bus topology there. This is due to the complexity -
we MUST know that the different functions of a PCIe device are not in use
by other drivers, or if they are in use (say one of them is assigned to a
guest and the other is  idle) - it is still OK to reset the slot (assuming
both of them are owned by Xen pciback).

This patch does that by doing a slot or bus reset (if slot not supported)
if all of the functions of a PCIe device belong to Xen PCIback.

Due to the complexity with the PCI lock we cannot do the reset when a
device is bound ('echo $BDF > bind') or when unbound ('echo $BDF > unbind')
as the pci_[slot|bus]_reset also takes the same lock resulting in a
dead-lock.

Putting the reset function in a work-queue or thread won't work either -
as we have to do the reset function outside the 'unbind' context (it holds
the PCI lock). But once you 'unbind' a device the device is no longer under
the ownership of Xen pciback and the pci_set_drvdata has been reset, so
we cannot use a thread for this.

Instead of doing all this complex dance, we depend on the tool-stack doing
the right thing. As such, we implement the 'do_flr' SysFS attribute which
'xl' uses when a device is detached or attached from/to a guest. It
bypasses the need to worry about the PCI lock.

To not inadvertently do a bus reset that would affect devices that are in
use by other drivers (other than Xen pciback) prior to the reset, we check
that all of the devices under the bridge are owned by Xen pciback. If they
are not, we refrain from executing the bus (or slot) reset.

Signed-off-by: Govinda Tatti 
Signed-off-by: Konrad Rzeszutek Wilk 
Reviewed-by: Boris Ostrovsky 
---
 Documentation/ABI/testing/sysfs-driver-pciback |  12 +++
 drivers/xen/xen-pciback/pci_stub.c | 125 +
 2 files changed, 137 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-driver-pciback 
b/Documentation/ABI/testing/sysfs-driver-pciback
index 6a733bf..ccf7dc0 100644
--- a/Documentation/ABI/testing/sysfs-driver-pciback
+++ b/Documentation/ABI/testing/sysfs-driver-pciback
@@ -11,3 +11,15 @@ Description:
 #echo 00:19.0-E0:2:FF > /sys/bus/pci/drivers/pciback/quirks
 will allow the guest to read and write to the configuration
 register 0x0E.
+
+What:   /sys/bus/pci/drivers/pciback/do_flr
+Date:   Nov 2017
+KernelVersion:  4.15
+Contact:xen-de...@lists.xenproject.org
+Description:
+An option to perform a slot or bus reset when a PCI device
+   is owned by Xen PCI backend. Writing a string of :BB:DD.F
+   will cause the pciback driver to perform a slot or bus reset
+   if the device supports it. It also checks to make sure that
+   all of the devices under the bridge are owned by Xen PCI
+   backend.
diff --git a/drivers/xen/xen-pciback/pci_stub.c 
b/drivers/xen/xen-pciback/pci_stub.c
index 6331a95..2b2c269 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -244,6 +244,96 @@ struct pci_dev *pcistub_get_pci_dev(struct 
xen_pcibk_device *pdev,
return found_dev;
 }
 
+struct pcistub_args {
+   struct pci_dev *dev;
+   int dcount;
+};
+
+static int pcistub_search_dev(struct pci_dev *dev, void *data)
+{
+   struct pcistub_device *psdev;
+   struct pcistub_args *arg = data;
+   bool found_dev = false;
+   unsigned long flags;
+
+   spin_lock_irqsave(&pcistub_devices_lock, flags);
+
+   list_for_each_entry(psdev, &pcistub_devices, dev_list) {
+   if (psdev->dev == dev) {
+   found_dev = true;
+   arg->dcount++;
+   break;
+   }
+   }
+
+   spin_unlock_irqrestore(&pcistub_devices_lock, flags);
+
+   /* Device not owned by pcistub, someone owns it. Abort the walk */
+   if (!found_dev)
+   arg->dev = dev;
+
+   return found_dev ? 0 :

Re: [Xen-devel] Commit moratorium to staging

[George Dunlap]

On 11/03/2017 06:35 PM, Juergen Gross wrote:
> On 03/11/17 19:29, Roger Pau Monné wrote:
>> On Fri, Nov 03, 2017 at 05:57:52PM +, George Dunlap wrote:
>>> On 11/03/2017 02:52 PM, George Dunlap wrote:
 On 11/03/2017 02:14 PM, Roger Pau Monné wrote:
> On Thu, Nov 02, 2017 at 09:55:11AM +, Paul Durrant wrote:
>> Hmm. I wonder whether the guest is actually healthy after the migrate. 
>> One could imagine a situation where the storage device model (IDE in our 
>> case I guess) gets stuck in some way but recovers after a timeout in the 
>> guest storage stack. Thus, if you happen to try shut down while it is 
>> still stuck Windows starts trying to shut down but can't. Try after the 
>> timeout though and it can.
>> In the past we did make attempts to support Windows without PV drivers 
>> in XenServer but xenrt would never reliably pass VM lifecycle tests 
>> using emulated devices. That was with qemu trad, but I wonder whether 
>> upstream qemu is actually any better particularly if using older device 
>> models such as IDE and RTL8139 (which are probably largely unmodified 
>> from trad).
>
> Since I've been looking into this for a couple of days, and found no
> solution I'm going to write what I've found so far:
>
>  - The issue only affects Windows guests.
>  - It only manifests itself when doing live migration, non-live
>migration or save/resume work fine.
>  - It affects all x86 hardware, the amount of migrations in order to
>trigger it seems to depend on the hardware, but doing 20 migrations
>reliably triggers it on all the hardware I've tested.

 Not good.

 You said that Windows reported that the login process failed somehow?

 Is it possible something bad is happening, like sending spurious page
 faults to the guest in logdirty mode?

 I wonder if we could reproduce something like it on Linux -- set a build
 going and start localhost migrating; a spurious page fault is likely to
 cause the build to fail.
>>>
>>> Well, with a looping xen-build going on in the guest, I've done 40 local
>>> migrates with no problems yet.
>>>
>>> But Roger -- is this on emulated devices only, no PV drivers?
>>>
>>> That might be something worth looking at.
>>
>> Yes, windows doesn't have PV devices. But save/restore and non-live
>> migration seems fine, so it doesn't look to be related to devices, but
>> rather to log-dirty or some other aspect of live-migration.
> 
> log-dirty for read-I/Os of emulated devices?

FWIW I booted a Linux guest with "xen_nopv" on the command-line, gave it
256 MiB of RAM, and then ran a Xen build on it in a loop (see command
below).

Then I started migrating it in a loop.

After an hour or two it had done 146 local migrations, and 46 builds of
Xen (swapping onto emulated disk is pretty slow), without any issues.

Build command:

# while make -j 3 xen ; do git clean -ffdx ; done

I'm shutting down the VM and I'll leave it running overnight.

 -George

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [Qemu-devel] [PATCH 7/8] os-posix: Provide new -runasid option

[Markus Armbruster]

Ian Jackson  writes:

> Hi.  Thanks for the (re)-review.
>
> Markus Armbruster writes ("Re: [Qemu-devel] [PATCH 7/8] os-posix: Provide new 
> -runasid option"):
>> Ian Jackson  writes:
>> > +case QEMU_OPTION_runasid:
>> > +errno = 0;
>> > +lv = strtoul(optarg, &ep, 0); /* can't qemu_strtoul, want 
>> > *ep=='.' */
>> 
>> I'm afraid I can't see why qemu_strtoul() wouldn't work here.  Can you
>> enlighten me?
>
> qemu_strtoul fails (returns an error) if the delimiter (that is, the
> first character which is not processed as digit by strtoul) is not
> '\0'.

It does that *only* when its @endptr argument is null.  Since you pass
&ep, it should work fine here.

>Normally this is desirable, because it correctly rejects
> strings like "123blather".  But here we are trying to process a string
> whose first non-digit is ':', and we will handle the tail part
> explicitly.
>
> It would be possible to use strchr and then to write a '\0' over the
> ':' but I dislike that processing style (and it is forbidden by the
> const annotations on os_parse_cmd_args etc.)

I'd dislike that, too.

>> > +user_uid = lv; /* overflow here is ID in C99 */
>> 
>> I don't get the comment.  You check for overflow the obvious way below.
>> Sure you need a comment?
>
> This relates to overflow in the assignment, only.  lv is an unsigned
> long and user_uid is a uid_t (which may be smaller).  Normally, signed
> integer overflow is UB, but this is not the case when converting from
> another integer type.
>
> There are two possible overflows: 1. a string that strtoul cannot get
> to fit in an unsigned long, which produces a nonzero errno; and, 2. a
> value which fits in an unsigned long but not a uid_t.  In the latter
> case, we convert it _back_ into an unsigned long, as an implicit
> conversion in this middle test:
>
>> > +if (errno || *ep != '.' || user_uid != lv || user_uid == 
>> > (uid_t)-1) {
>
> If that succeeds, we know we can round-trip it so it is valid.  The
> remaining check needed is that it doesn't round trip to the sentinel
> uid value.
>
> Does that all make sense ?

Your code makes sense to me.  It's just the comment that confuses me.
Does ID mean "implementation-defined behavior"?  That would be wrong:

   6.3.1.3  Signed and unsigned integers

   [#1] When a value with integer type is converted to  another
   integer   type  other  than  _Bool,  if  the  value  can  be
   represented by the new type, it is unchanged.

   [#2] Otherwise, if the new type is unsigned,  the  value  is
   converted  by repeatedly adding or subtracting one more than
   the maximum value that can be represented in  the  new  type
   until the value is in the range of the new type.

> I'm not sure how much of this to document
> in comments.  It's deeply annoying that C is such a puzzle language
> here and that therefore such complicated reasoning and
> not-immediately-obvious code is needed, to do something so simple.
>
> If you would like me to remove the comment, I can drop it, of course.
> I don't really mind.

I'd drop it.

You might find this variation of your code slightly more obvious, or
slightly less:

if (errno || *ep != '.' || (uid_t)lv != lv || user_uid == (uid_t)-1) {
fprintf(stderr, "Could not obtain uid from \"%s\"", optarg);
exit(1);
}
user_uid = lv;

Your choice.

One more thing: please report errors with error_report().  Here:

error_report("Could not obtain uid");

No need to quote optarg back at the user, because error_report() already
does.

>> > +#ifndef _WIN32
>> > +DEF("runasid", HAS_ARG, QEMU_OPTION_runasid, \
>> > +"-runasid uid.gid change to numeric uid and gid just before 
>> > starting the VM\n",
>> > +QEMU_ARCH_ALL)
>> > +#endif
>> > +STEXI
>> > +@item -runasid @var{uid}.@var{gid}
>> 
>> Didn't we agree on using ':' instead of '.' as separator?
>> 
>> Sure we need yet another option?  Why can't we compatibly extend -runas?
>
> For some reason you are looking at an old version of the patch.  That
> may be my fault - there were a few mis-posts.  Sorry about that.

It could be just as well my fault: my inbox spun out of control before
KVM Forum.

> The final version does indeed have ':' and does reuse the -runas
> option.
>
>> If we truly need both, the rationale belongs into the commit message,
>> and we need to consider how they interact.  I'd recommend left-to-right
>> semantics, i.e. if you specify both, the last one wins.  Not what your
>> current code does, if I read it correctly.
>
> Happily this is now irrelevant.
>
> I will repost this series after I hear from you about strtoul and the
> overflow comment.

Thanks!

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [linux-next test] 115610: regressions - FAIL

[osstest service owner]

flight 115610 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115610/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops 6 kernel-build fail REGR. vs. 115599

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-examine  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 115599
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 115599
 test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeatfail like 115599
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 115599
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115599
 test-armhf-armhf-xl-vhd  15 guest-start/debian.repeatfail  like 115599
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 115599
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115599
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf

Re: [Xen-devel] [PATCH v2 0/5] xen: grant table interface v2 support

[Boris Ostrovsky]

On 11/02/2017 05:19 AM, Juergen Gross wrote:
> In order to support Linux to run as a pv guest on machines with huge
> memory (>16TB) or as a hvm guest with more than 16TB of memory the
> kernel has to support grant table interface v2, as v1 is limited to
> 32 bit frame numbers.
>
> This series re-adds that support (it has been removed in 2015) and
> restricts usage of v2 to the features of v1 in order to support
> migration to hosts which only support v1.
>
> V2 is selected only in the following cases:
> - the user has specified v2 via module parameter
> - in a pv guest if the maximum possible memory address of the host is
>   above 16TB (memory hotplug taken into account)
> - in a hvm guest if the maximum guest memory address is above 16TB
>   (again with memory hotplug taken into account)
>
> Changes in V2:
> - patch 2: remove update_trans_entry() from gnttab_ops (Boris Ostrovsky)
> - added new patch 4
> - patch 5: use cpuid on pv and max_possible_pfn on hvm for version select
>
> Juergen Gross (5):
>   xen: re-introduce support for grant v2 interface
>   xen: limit grant v2 interface to the v1 functionality
>   xen: add grant interface version dependent constants to gnttab_ops
>   xen: update arch/x86/include/asm/xen/cpuid.h
>   xen: select grant interface version
>
>  arch/arm/xen/grant-table.c   |   9 +-
>  arch/x86/include/asm/xen/cpuid.h |  42 +--
>  arch/x86/xen/grant-table.c   |  60 +-
>  drivers/xen/grant-table.c| 244 
> +++
>  include/xen/grant_table.h|   5 +-
>  5 files changed, 318 insertions(+), 42 deletions(-)
>


Reviewed-by: Boris Ostrovsky 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable test] 115606: regressions - FAIL

[osstest service owner]

flight 115606 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115606/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-amd64-pvgrub 11 guest-start fail REGR. vs. 115526
 test-amd64-amd64-i386-pvgrub 11 guest-start  fail REGR. vs. 115526

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore fail in 11 pass 
in 115606
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 115593 
pass in 115606
 test-armhf-armhf-xl-vhd  15 guest-start/debian.repeat  fail pass in 11
 test-armhf-armhf-xl-xsm   6 xen-installfail pass in 115593
 test-amd64-i386-xl   20 guest-start/debian.repeat  fail pass in 115593
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail pass in 115593
 test-armhf-armhf-xl-rtds  6 xen-installfail pass in 115593

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop   fail in 115593 like 115526
 test-armhf-armhf-xl-xsm 13 migrate-support-check fail in 115593 never pass
 test-armhf-armhf-xl-xsm 14 saverestore-support-check fail in 115593 never pass
 test-armhf-armhf-xl-rtds13 migrate-support-check fail in 115593 never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 115593 never pass
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeatfail  like 115496
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 115526
 test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeatfail like 115526
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115526
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 115526
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115526
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 115526
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 115526
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 115526
 test-amd64-amd64-xl-qcow219 guest-start/debian.repeatfail  like 115526
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 115526
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 115526
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen  e07ebab86595df29838f096069

[Xen-devel] [linux-4.9 test] 115613: regressions - FAIL

[osstest service owner]

flight 115613 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115613/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 114814

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail in 115538 pass in 115613
 test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail in 115538 pass in 
115613
 test-amd64-amd64-libvirt-vhd 18 guest-start.2fail in 115538 pass in 115613
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail in 115566 pass 
in 115613
 test-amd64-i386-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail in 
115566 pass in 115613
 test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeat fail pass in 115483
 test-armhf-armhf-xl-vhd  15 guest-start/debian.repeat  fail pass in 115538
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail pass in 
115566

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop   fail REGR. vs. 114814

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop  fail in 115483 like 114814
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114814
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114814
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linux06b639e5a1a665ba6c959398ea0e6171c162028b
baseline version:
 linux5d7a76acad403638f635c918cc63d1d44ffa4065

Last test of basis   114814  2017-10-20 20:51:56 Z   17 days
Failing since114845  2017-10-21 16:14:17 Z   16 days

Re: [Xen-devel] [bug report] xen/pvcalls: implement release command

[Stefano Stabellini]

On Sat, 4 Nov 2017, Dan Carpenter wrote:
> Hello Stefano Stabellini,
> 
> The patch 235a71c53903: "xen/pvcalls: implement release command" from
> Oct 30, 2017, leads to the following static checker warning:
> 
>   drivers/xen/pvcalls-front.c:1051 pvcalls_front_release()
>   error: double lock 'mutex:&map->active.in_mutex'
> 
> drivers/xen/pvcalls-front.c
>   1037  if (map->active_socket) {
>   1038  /*
>   1039   * Set in_error and wake up inflight_conn_req to force
>   1040   * recvmsg waiters to exit.
>   1041   */
>   1042  map->active.ring->in_error = -EBADF;
>   1043  wake_up_interruptible(&map->active.inflight_conn_req);
>   1044  
>   1045  /*
>   1046   * Wait until there are no more waiters on the 
> mutexes.
>   1047   * We know that no new waiters can be added because 
> sk_send_head
>   1048   * is set to NULL -- we only need to wait for the 
> existing
>   1049   * waiters to return.
>   1050   */
>   1051  while (!mutex_trylock(&map->active.in_mutex) ||
>   1052 !mutex_trylock(&map->active.out_mutex))
>   1053  cpu_relax();
> 
> mutex_trylock() returns 1 if you take the lock and 0 if not.  So I think
> the static checker is right that this code has an issue.
> 
> Assume you take in_mutex on the first try, but you can't take out_mutex.
> That means you the next times you call mutex_trylock() in_mutex is going
> to fail.  So it's an endless loop.
> 
> But it could also be that I haven't slept well recently and my eyes are
> cross eyed.

Yes, you are right. Thanks for your help. I think the code should be:

while (!mutex_trylock(&map->active.in_mutex))
cpu_relax();
while (!mutex_trylock(&map->active.out_mutex))
cpu_relax();

I'll send a patch.


>   1054  
>   1055  pvcalls_front_free_map(bedata, map);
>   1056  } else {



___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2] aarch64: advertise the GIC system register interface

[Stefano Stabellini]

When QEMU emulates a GICv3, it needs to advertise the presence of the
system register interface, which is done via id_aa64pfr0.

To do that, and at the same time to avoid advertising the presence of
the system register interface when it is actually not available, set a
boolean property in machvirt_init. Check on the boolean property from
register_cp_regs_for_features and set id_aa64pfr0 accordingly.

Signed-off-by: Stefano Stabellini 

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 9e18b41..369d36b 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1401,6 +1401,9 @@ static void machvirt_init(MachineState *machine)
 object_property_set_link(cpuobj, OBJECT(secure_sysmem),
  "secure-memory", &error_abort);
 }
+if (vms->gic_version == 3) {
+object_property_set_bool(cpuobj, true, "gicv3-sysregs", NULL);
+}
 
 object_property_set_bool(cpuobj, true, "realized", NULL);
 object_unref(cpuobj);
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 88578f3..259cad1 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -1690,6 +1690,7 @@ static Property arm_cpu_properties[] = {
 DEFINE_PROP_UINT64("mp-affinity", ARMCPU,
 mp_affinity, ARM64_AFFINITY_INVALID),
 DEFINE_PROP_INT32("node-id", ARMCPU, node_id, CPU_UNSET_NUMA_NODE_ID),
+DEFINE_PROP_BOOL("gicv3-sysregs", ARMCPU, gicv3_sysregs, false),
 DEFINE_PROP_END_OF_LIST()
 };
 
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 89d49cd..0015b37 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -657,6 +657,9 @@ struct ARMCPU {
 /* Should CPU start in PSCI powered-off state? */
 bool start_powered_off;
 
+/* GICv3 sysregs present */
+bool gicv3_sysregs;
+
 /* Current power state, access guarded by BQL */
 ARMPSCIState power_state;
 
diff --git a/target/arm/helper.c b/target/arm/helper.c
index 37af750..6f21900 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -4687,7 +4687,8 @@ void register_cp_regs_for_features(ARMCPU *cpu)
 { .name = "ID_AA64PFR0_EL1", .state = ARM_CP_STATE_AA64,
   .opc0 = 3, .opc1 = 0, .crn = 0, .crm = 4, .opc2 = 0,
   .access = PL1_R, .type = ARM_CP_CONST,
-  .resetvalue = cpu->id_aa64pfr0 },
+  .resetvalue = cpu->gicv3_sysregs ? (cpu->id_aa64pfr0|0x0100) 
:
+  cpu->id_aa64pfr0 },
 { .name = "ID_AA64PFR1_EL1", .state = ARM_CP_STATE_AA64,
   .opc0 = 3, .opc1 = 0, .crn = 0, .crm = 4, .opc2 = 1,
   .access = PL1_R, .type = ARM_CP_CONST,

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH] xen/pvcalls: fix potential endless loop in pvcalls-front.c

[Stefano Stabellini]

mutex_trylock() returns 1 if you take the lock and 0 if not. Assume you
take in_mutex on the first try, but you can't take out_mutex. Next times
you call mutex_trylock() in_mutex is going to fail. It's an endless
loop.

Solve the problem by moving the two mutex_trylock calls to two separate
loops.

Reported-by: Dan Carpenter 
Signed-off-by: Stefano Stabellini 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-front.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
index 0c1ec68..047dce7 100644
--- a/drivers/xen/pvcalls-front.c
+++ b/drivers/xen/pvcalls-front.c
@@ -1048,8 +1048,9 @@ int pvcalls_front_release(struct socket *sock)
 * is set to NULL -- we only need to wait for the existing
 * waiters to return.
 */
-   while (!mutex_trylock(&map->active.in_mutex) ||
-  !mutex_trylock(&map->active.out_mutex))
+   while (!mutex_trylock(&map->active.in_mutex))
+   cpu_relax();
+   while (!mutex_trylock(&map->active.out_mutex))
cpu_relax();
 
pvcalls_front_free_map(bedata, map);
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [Qemu-devel] [PATCH v2] aarch64: advertise the GIC system register interface

[no-reply]

Hi,

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

Subject: [Qemu-devel] [PATCH v2] aarch64: advertise the GIC system register 
interface
Type: series
Message-id: alpine.DEB.2.10.1711061412330.30448@sstabellini-ThinkPad-X260

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

git config --local diff.renamelimit 0
git config --local diff.renames True

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag]   
patchew/alpine.DEB.2.10.1711061412330.30448@sstabellini-ThinkPad-X260 -> 
patchew/alpine.DEB.2.10.1711061412330.30448@sstabellini-ThinkPad-X260
Switched to a new branch 'test'
d3e1cec549 aarch64: advertise the GIC system register interface

=== OUTPUT BEGIN ===
Checking PATCH 1/1: aarch64: advertise the GIC system register interface...
ERROR: spaces required around that '|' (ctx:VxV)
#67: FILE: target/arm/helper.c:4690:
+  .resetvalue = cpu->gicv3_sysregs ? (cpu->id_aa64pfr0|0x0100) 
:
   ^

total: 1 errors, 0 warnings, 34 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

=== OUTPUT END ===

Test command exited with code: 1


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@freelists.org
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen/pvcalls: fix potential endless loop in pvcalls-front.c

[Boris Ostrovsky]

On 11/06/2017 05:17 PM, Stefano Stabellini wrote:
> mutex_trylock() returns 1 if you take the lock and 0 if not. Assume you
> take in_mutex on the first try, but you can't take out_mutex. Next times
> you call mutex_trylock() in_mutex is going to fail. It's an endless
> loop.
>
> Solve the problem by moving the two mutex_trylock calls to two separate
> loops.
>
> Reported-by: Dan Carpenter 
> Signed-off-by: Stefano Stabellini 
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com

Reviewed-by: Boris Ostrovsky 

BTW, I assume that when recvmsg or sendmsg is called no other locks are
held, right? (otherwise we'd get into a deadlock.)

-boris

> ---
>  drivers/xen/pvcalls-front.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
> index 0c1ec68..047dce7 100644
> --- a/drivers/xen/pvcalls-front.c
> +++ b/drivers/xen/pvcalls-front.c
> @@ -1048,8 +1048,9 @@ int pvcalls_front_release(struct socket *sock)
>* is set to NULL -- we only need to wait for the existing
>* waiters to return.
>*/
> - while (!mutex_trylock(&map->active.in_mutex) ||
> -!mutex_trylock(&map->active.out_mutex))
> + while (!mutex_trylock(&map->active.in_mutex))
> + cpu_relax();
> + while (!mutex_trylock(&map->active.out_mutex))
>   cpu_relax();
>  
>   pvcalls_front_free_map(bedata, map);


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen/pvcalls: fix potential endless loop in pvcalls-front.c

[Stefano Stabellini]

On Mon, 6 Nov 2017, Boris Ostrovsky wrote:
> On 11/06/2017 05:17 PM, Stefano Stabellini wrote:
> > mutex_trylock() returns 1 if you take the lock and 0 if not. Assume you
> > take in_mutex on the first try, but you can't take out_mutex. Next times
> > you call mutex_trylock() in_mutex is going to fail. It's an endless
> > loop.
> >
> > Solve the problem by moving the two mutex_trylock calls to two separate
> > loops.
> >
> > Reported-by: Dan Carpenter 
> > Signed-off-by: Stefano Stabellini 
> > CC: boris.ostrov...@oracle.com
> > CC: jgr...@suse.com
> 
> Reviewed-by: Boris Ostrovsky 
> 
> BTW, I assume that when recvmsg or sendmsg is called no other locks are
> held, right? (otherwise we'd get into a deadlock.)

Yes, but most importantly the other assumption is that recvmsg and
sendmsg are already running: the partially visible comment explains it:

* Wait until there are no more waiters on the mutexes.
* We know that no new waiters can be added because sk_send_head
* is set to NULL -- we only need to wait for the existing
* waiters to return.


> > ---
> >  drivers/xen/pvcalls-front.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
> > index 0c1ec68..047dce7 100644
> > --- a/drivers/xen/pvcalls-front.c
> > +++ b/drivers/xen/pvcalls-front.c
> > @@ -1048,8 +1048,9 @@ int pvcalls_front_release(struct socket *sock)
> >  * is set to NULL -- we only need to wait for the existing
> >  * waiters to return.
> >  */
> > -   while (!mutex_trylock(&map->active.in_mutex) ||
> > -  !mutex_trylock(&map->active.out_mutex))
> > +   while (!mutex_trylock(&map->active.in_mutex))
> > +   cpu_relax();
> > +   while (!mutex_trylock(&map->active.out_mutex))
> > cpu_relax();
> >  
> > pvcalls_front_free_map(bedata, map);
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [linux-linus test] 115615: regressions - FAIL

[osstest service owner]

flight 115615 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115615/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeat fail REGR. vs. 
114682
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 114682
 test-armhf-armhf-xl-arndale   5 host-ping-check-native   fail REGR. vs. 114682
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop   fail REGR. vs. 114682
 test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail REGR. vs. 114682

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 114682
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114682
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114682
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 114682
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 114682
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114682
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 114682
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114682
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass

version targeted for testing:
 linux39dae59d66acd86d1de24294bd2f343fd5e7a625
baseline version:
 linuxebe6e90ccc6679cb01d2b280e4b61e6092d4bedb

Last test of basis   114682  2017-10-18 09:54:11 Z   19 days
Failing since114781  2017-10-20 01:00:47 Z   17 days   30 attempts
Testing same since   115615  2017-11-06 14:21:32 Z0 days1 attempts


517 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt

Re: [Xen-devel] [BUG] xen-mceinj tool testing cause dom0 crash

[Hao, Xudong]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, November 6, 2017 5:17 PM
> To: Hao, Xudong 
> Cc: Julien Grall ; George Dunlap
> ; Lars Kurth ; Zhang,
> Haozhong ; xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] [BUG] xen-mceinj tool testing cause dom0 crash
> 
> >>> On 03.11.17 at 09:29,  wrote:
> > We figured out the problem, some corner scripts triggered the error
> > injection at the same page (pfn 0x180020) twice, i.e. "./xen-mceinj -t
> > 0" run over one time, which resulted in Dom0 crash.
> 
> But isn't this a valid scenario, which shouldn't result in a kernel crash? 
> What if
> two successive #MCs occurred for the same page?
> I.e. ...
> 

Yes, it's another valid scenario, the expect result is kernel crash. 
Our scenario is injecting #MCs to different pages and expect no crash of 
result, however our internal scripts handled it to same page but still expect 
no crash of result, it's our internal scripts problem.

> > Let's close this bug thread, sorry for the invalid report
> 
> ... wasn't this premature?
> 

Could we close it now?


Thanks,
-Xudong

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [qemu-mainline test] 115620: regressions - FAIL

[osstest service owner]

flight 115620 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115620/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-xsm  12 guest-start  fail REGR. vs. 114507
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 114507
 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail REGR. vs. 114507
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install   fail REGR. vs. 114507

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop  fail blocked in 114507
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 114507
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 114507
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114507
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114507
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 114507
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 qemuu299d1ea9bb56bd9f45f905125489bdd7d543a1aa
baseline version:
 qemuuf90ea7ba7c5ae7010ee0ce062207ae42530f57d6

Last test of basis   114507  2017-10-15 01:03:38 Z   23 days
Failing since114546  2017-10-16 12:16:28 Z   21 days   57 attempts
Testing same since   115620  2017-11-06 17:20:55 Z0 days1 attempts


People who touched revisions under test:
  Aaron Lindsay 
  Alberto Garcia 
  Aleksandr Bezzubikov 
  Alex Bennée 
  Alexey Kardashevskiy 
  Alexey Perevalov 
  Alistair Francis 
  Amarnath Valluri 
  Andreas Färber 
  Andrew Baumann 
  Anthoine Bourgeois 
  Anthony PERARD 
  Artyom Tarasenko 
  Bishara AbuHattoum 
  Carlo Marcelo Arenas Belón 
  Chen Hanxiao 
  Christian Borntraeger 
  Collin L. Walling 
  Cornelia Huck 
  Cornelia Huck 
  Cornelia Huck 
  Daniel Henrique Barboza 
  Daniel P. Berrange 
  David Gibson 
  David Hildenbrand 
  Dong Jia Shi 
  Dr. David Alan Gilbert 
  Eduardo Habkost 
  Eduardo Otubo 
  Emilio G. Cota 
  Eric Auger 
  Eric Blake 
  Fam Zheng 
  Farhan Ali 
  Felipe Franciosi 
  Gerd Hoffmann 
  Greg Kurz 
  Halil Pasic 
  Igor Mammedov 
  James Hogan 
  Jason J. Herne 
  Jason Wang 
  Joe Clifford 
  John Arbuckle 
  John Snow 
  Juan Quintela 
  Juergen Gross 
  Kamil Rytarowski 
  Kevin Wolf 
  Knut Omang 
  Lan Tianyu 
  Laszlo Ersek 
  Laurent Desnogues 
  Laurent Vivier 
  Laurent Vivier 
  Manos Pitsidianakis 
  

Re: [Xen-devel] Libvirt config converter can't handle file not ending with new line

[Jim Fehlig]

On 10/30/2017 06:17 AM, Wei Liu wrote:

Hi Jim

I discover a problem when using xen_xl converter. When the file in
question doesn't end with a new line, I get the following error:

   error: configuration file syntax error: memory conf:53: expecting a value


I'm not able to reproduce this issue. The libvirt.git tree I tried was a bit 
dated, but even after updating to latest master I can't reproduce.



After digging a bit (but haven't read libvirt code), it appears that the
file didn't end with a new line.


I tried several files without ending new lines, going both directions 
(domxml-to-native and domxml-from-native), but didn't see the mentioned error. 
Perhaps your config is revealing another bug which is being improperly reported. 
Can you provide an example of the problematic config?


Regards,
Jim



___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen/pvcalls: fix potential endless loop in pvcalls-front.c

[Juergen Gross]

On 06/11/17 23:17, Stefano Stabellini wrote:
> mutex_trylock() returns 1 if you take the lock and 0 if not. Assume you
> take in_mutex on the first try, but you can't take out_mutex. Next times
> you call mutex_trylock() in_mutex is going to fail. It's an endless
> loop.
> 
> Solve the problem by moving the two mutex_trylock calls to two separate
> loops.
> 
> Reported-by: Dan Carpenter 
> Signed-off-by: Stefano Stabellini 
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
> ---
>  drivers/xen/pvcalls-front.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
> index 0c1ec68..047dce7 100644
> --- a/drivers/xen/pvcalls-front.c
> +++ b/drivers/xen/pvcalls-front.c
> @@ -1048,8 +1048,9 @@ int pvcalls_front_release(struct socket *sock)
>* is set to NULL -- we only need to wait for the existing
>* waiters to return.
>*/
> - while (!mutex_trylock(&map->active.in_mutex) ||
> -!mutex_trylock(&map->active.out_mutex))
> + while (!mutex_trylock(&map->active.in_mutex))
> + cpu_relax();
> + while (!mutex_trylock(&map->active.out_mutex))
>   cpu_relax();

Any reason you don't just use mutex_lock()?


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] Bringing up OSS test framework on moonshot(aarch64) systems

[Bhupinder Thakur]

Hi,

I am trying to bring up OSS test framework on a couple of moonshot
systems which are accessible to me remotely.

While going through [1], I have some queries/doubts on the configuration.

1. The following configuration:

DnsDomain uk.xensource.com
NetNameservers 10.80.248.2 10.80.16.28 10.80.16.67
HostProp_DhcpWatchMethod leases dhcp3 dhcp.uk.xensource.com:5556
TftpPath /usr/groups/netboot/

DebianNonfreeFirmware firmware-bnx2
DebianSuite squeeze
DebianMirrorHost debian.uk.xensource.com
DebianPreseed= < <‘END’
d-i clock-setup/ntp-server string ntp.uk.xensource.com
END

1. In this configuration, where would the DNS server be running? Does
it expect that a DNS server is already configured in the network and
it has mapping of name <--> IP address for all test hosts? Or do we
need to setup it up on the OSS controller?

2. What is the DhcpWatchMethod option used for?

3. How are the debian related options mentioned above used? Does OSS
fetches the installers/preseed files from DEbianMirrorHost and place
them in the required tftp folders?

I may have more doubts as I try to set things up.

[1] https://blog.xenproject.org/2013/09/30/osstest-standalone-mode-step-by-step/

Regards,
Bhupinder

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/cpuid: Enable new SSE/AVX/AVX512 cpu features

[Zhong Yang]

On Mon, Nov 06, 2017 at 03:39:45AM -0700, Jan Beulich wrote:
> >>> On 27.10.17 at 16:18,  wrote:
> > Intel IceLake cpu has added new cpu features: AVX512VBMI2/GFNI/
> > VAES/AVX512VNNI/AVX512BITALG/VPCLMULQDQ. Those new cpu features
> > need expose to guest.wq
> 
> First of all, please don't forget to Cc relevant maintainers.
> 
  Thanks Jan's remind.
  
> > The bit definition:
> > CPUID.(EAX=7,ECX=0):ECX[bit 06] AVX512VBMI2
> > CPUID.(EAX=7,ECX=0):ECX[bit 08] GFNI
> > CPUID.(EAX=7,ECX=0):ECX[bit 09] VAES
> > CPUID.(EAX=7,ECX=0):ECX[bit 10] VPCLMULQDQ
> 
> These last three have VEX (and for GFNI even legacy) encodings.
> While it wouldn't be reasonable yet to request EVEX encoded insn
> support to be added to the emulator while enabling new ISA
> extensions, I think legacy and VEX encoded ones should be taken
> care of with the state the emulator is currently in.
> 
> Jan
  
  Hello Jan,

  Thanks for reviewing my patch! 
  For those new instructions, you mean i also need to support those 
  three instructions(GFNI,VAES and VPCLMULQDQ) in x86_emulate() in PV? 

  Many thanks!

  Regards,

  Yang


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen PVH support in grub2

[Juergen Gross]

On 06/11/17 17:42, Boris Ostrovsky wrote:
> On 11/06/2017 10:05 AM, Juergen Gross wrote:
>> On 06/11/17 15:51, Boris Ostrovsky wrote:
>>> On 11/06/2017 02:16 AM, Juergen Gross wrote:
 On 03/11/17 20:00, Boris Ostrovsky wrote:
> On 11/03/2017 02:40 PM, Juergen Gross wrote:
>> On 03/11/17 19:35, Boris Ostrovsky wrote:
>>> On 11/03/2017 02:23 PM, Juergen Gross wrote:
 On 03/11/17 19:19, Boris Ostrovsky wrote:
> On 11/03/2017 02:05 PM, Juergen Gross wrote:
>> So again the question: how to tell whether we are PVH or HVM in
>> init_hypervisor_platform()? ACPi tables are scanned way later...
> Can we make grub/OVMF append a boot option?
>
> Or set setup_header.hardware_subarch to something? We already have
> X86_SUBARCH_XEN but it is only used by PV.  Or we might be able to use
> hardware_subarch_data (will need to get a buy-in from x86 
> maintainers, I
> think).
 But wouldn't this break the idea to reuse the native boot paths in
 grub/OVMF without further modifications?
>>> WDYM? We will have to have some sort of a plugin in either one to build
>>> the zeropage anyway. So we'd set hardware_subarch there, in addition to
>>> other things like setting memory and such.
>> But isn't the zeropage already being built? I admit that setting subarch
>> isn't a big deal, but using another entry with a passed-through pvh
>> start struct isn't either...
> I don't follow, sorry. My understanding is that zeropage will be built
> by PVH-enlightened grub so part of this process would be setting the
> subarch bit.
 My reasoning was based on Roger's remark:

 "OTOH if Linux is capable of booting from the native entry point inside
 of a PVH container, we would only have to port OVMF and grub in order
 to work inside of a PVH container, leaving the rest of the logic
 untouched."
>>> Right, and in my mind porting OVMF/grub includes creating proper zeropage.
>> Aah, okay. I reasoned on the assumption to just enable OVMF/grub to run
>> in PVH environment without touching the parts setting up anything for
>> the new kernel.
> 
> Someone needs to do what xen_prepare_pvh() does.

As the loader is filling in the memory map information the only thing
remaining would be setting xen_pvh. And this could be delayed as my test
have shown, so we only need to detect the PVH case from inside the
kernel. One possibility would be the flags in the ACPI FADT table as
Roger mentioned, another idea would be a flag in zeropage set by the
loader.

> And, for 64-bit, we also may need to build early pagetables since
> startup_64() (unlike startup_32()) expects paging to be on. (I don't
> know whether this is already part of standard FW codepath)

This would be done the same way as for a native kernel.

>>> BTW, another option might be to "type_of_loader = (9 << 4) | 0", which
>>> is what init_pvh_bootparams() does. In fact, whatever is done in the
>>> firmware should probably match what that routine does.
>> So it wouldn't be possible any longer to tell whether the kernel has
>> been booted directly or via grub. I don't like this. The loader type
>> is accessible via sysfs after all.
> 
> I didn't know that. What is the path?

/proc/sys/kernel/bootloader_type


Juergen


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel