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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail 
REGR. vs. 128847

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 12 guest-start  fail REGR. vs. 128847

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 128847
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 128847
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 128847
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 128847
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 128847
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 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 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-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-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail 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-xl  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  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 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 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-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  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-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 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-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail 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-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linuxb24c9962b179803dc1d51f17cf1acc58be8bbb2e
baseline version:
 linuxdeb3303f665b31c29210ef4b30b1e69cb06cc397

Last test of basis   128847  2018-10-17 09:

[Xen-devel] [ovmf test] 128924: all pass - PUSHED

[osstest service owner]

flight 128924 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128924/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf d28daaddb3e732468e930a809d3d3943a5de9558
baseline version:
 ovmf 95aea2fac9117e95ead90378e6bb975e327d7da4

Last test of basis   128923  2018-10-22 01:10:54 Z0 days
Testing same since   128924  2018-10-22 05:38:30 Z0 days1 attempts


People who touched revisions under test:
  Eric Dong 
  Laszlo Ersek 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  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 :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   95aea2fac9..d28daaddb3  d28daaddb3e732468e930a809d3d3943a5de9558 -> 
xen-tested-master

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

Re: [Xen-devel] Interrupt injection with ISR set on Intel hardware

[Chao Gao]

On Mon, Oct 15, 2018 at 01:06:12PM +0100, Andrew Cooper wrote:
>On 15/10/18 11:30, Roger Pau Monné wrote:
>> Hello,
>>
>> Wei recently discovered an issue when running a Linux PVH Dom0 on a
>> box with a Intel Family 6 (0x6), Model 158 (0x9e), Stepping 9 (raw
>> 000906e9) CPU, we are not sure whether the issue is limited to a PVH
>> Dom0, or it just happens to be easier to trigger in this scenario.
>
>This issue has been seen very occasionally for years.  My debugging
>patch dates back to 2013, and it has been observed on Haswell systems as
>well.  There have also been a handful of reports on xen-devel over the
>years.
>
>Wei is the first person to get a reliable enough repro to debug.  It is
>not exclusive to PVH Dom0, but that appears to be the easiest way to
>tickle the problem.
>
>> The issue is caused by what seems to be an interrupt injection while
>> Xen is still servicing a previous interrupt (ie: the interrupt hasn't
>> been EOI'ed and ISR for the vector is set) with the same or lower
>> priority than the interrupt currently being serviced. This injection
>> always happen when returning from idle from a state ACPI_STATE_C3 or
>> lower.
>
>As a bit of background, for some guest irqs, we need to inject the
>interrupt into the guest and wait for an explicit ack.
>
>If the irq source doesn't have a mask bit which Xen can use, the only
>option we have is to avoid repeated interruption is to leave the irq in
>service at the LAPIC.  The purpose of the Pending EOI stack is to manage
>these as acks arrive back from guest context.
>
>For reasons which aren't clear, guest-bound MSI vectors which don't have
>a mask bit also use this PEOI stack mechanism.  I think this is probably
>a Xen bug, but it also relevant to the issue.
>
>In Wei's case, the interrupt in question is an MSI non-maskable
>interrupt from the USB controller.
>
>> Note that I haven't been able to reproduce this issue when using
>> mwait-idle=0 or max_cstate=2 on the Xen command line, but again
>> without knowing the underlying issue it's impossible to tell whether
>> it's relevant.
>>
>> Andrew provided a debug patch which I've expanded to also log power
>> state transition, and is attached to this email.
>>
>> Here is a trace of a crash, together with the debug info.
>>
>> (XEN) *** Pending EOI error ***
>> (XEN)   cpu #1, irq 30, vector 0x21, sp 1
>> (XEN) Peoi stack: sp 1
>> (XEN)   [ 0] irq  30, vec 0x21, ready 0, ISR 1, TMR 0, IRR 0
>> (XEN) Peoi stack trace records:
>> (XEN)   [22619] POP  {sp  1, irq  30, vec 0x21}
>> (XEN)   [22620] POWERTYPE 4
>> (XEN)   [22621] IDLE PPR 0x0010
>> (XEN)IRR 
>> 
>> (XEN)ISR 
>> 
>> (XEN)   [22622] WAKE PPR 0x0010
>> (XEN)IRR 
>> 0004
>> (XEN)ISR 
>> 
>> (XEN)   [22623] ACK_PRE  PPR 0x00f0
>> (XEN)IRR 
>> 
>> (XEN)ISR 
>> 0004
>> (XEN)   [22624] ACK_POST PPR 0x0010
>> (XEN)IRR 
>> 
>> (XEN)ISR 
>> 
>> (XEN)   [22625] POWERTYPE 5
>> (XEN)   [22626] IDLE PPR 0x0010
>> (XEN)IRR 
>> 
>> (XEN)ISR 
>> 
>> (XEN)   [22627] WAKE PPR 0x0010
>> (XEN)IRR 
>> 0200
>> (XEN)ISR 
>> 
>> (XEN)   [22628] PUSH {sp  0, irq  30, vec 0x21}
>> (XEN)   [22629] POWERTYPE 5
>> (XEN)   [22630] IDLE PPR 0x0020
>> (XEN)IRR 
>> 
>> (XEN)ISR 
>> 0200
>> (XEN)   [22631] WAKE PPR 0x0020
>> (XEN)IRR 
>> 0200
>> (XEN)ISR 
>> 0200
>> (XEN)   [22632] POWERTYPE 5
>> (XEN)   [22633] IDLE PPR 0x0020
>> (XEN)IRR 
>> 0200
>> (XEN)ISR 
>> 0200
>> (XEN)   [22634] WAKE PPR 0x0020
>> (XEN)

Re: [Xen-devel] Interrupt injection with ISR set on Intel hardware

[Andrew Cooper]

On 22/10/2018 08:33, Chao Gao wrote:
> On Mon, Oct 15, 2018 at 01:06:12PM +0100, Andrew Cooper wrote:
>> On 15/10/18 11:30, Roger Pau Monné wrote:
>>> Hello,
>>>
>>> Wei recently discovered an issue when running a Linux PVH Dom0 on a
>>> box with a Intel Family 6 (0x6), Model 158 (0x9e), Stepping 9 (raw
>>> 000906e9) CPU, we are not sure whether the issue is limited to a PVH
>>> Dom0, or it just happens to be easier to trigger in this scenario.
>> This issue has been seen very occasionally for years.  My debugging
>> patch dates back to 2013, and it has been observed on Haswell systems as
>> well.  There have also been a handful of reports on xen-devel over the
>> years.
>>
>> Wei is the first person to get a reliable enough repro to debug.  It is
>> not exclusive to PVH Dom0, but that appears to be the easiest way to
>> tickle the problem.
>>
>>> The issue is caused by what seems to be an interrupt injection while
>>> Xen is still servicing a previous interrupt (ie: the interrupt hasn't
>>> been EOI'ed and ISR for the vector is set) with the same or lower
>>> priority than the interrupt currently being serviced. This injection
>>> always happen when returning from idle from a state ACPI_STATE_C3 or
>>> lower.
>> As a bit of background, for some guest irqs, we need to inject the
>> interrupt into the guest and wait for an explicit ack.
>>
>> If the irq source doesn't have a mask bit which Xen can use, the only
>> option we have is to avoid repeated interruption is to leave the irq in
>> service at the LAPIC.  The purpose of the Pending EOI stack is to manage
>> these as acks arrive back from guest context.
>>
>> For reasons which aren't clear, guest-bound MSI vectors which don't have
>> a mask bit also use this PEOI stack mechanism.  I think this is probably
>> a Xen bug, but it also relevant to the issue.
>>
>> In Wei's case, the interrupt in question is an MSI non-maskable
>> interrupt from the USB controller.
>>
>>> Note that I haven't been able to reproduce this issue when using
>>> mwait-idle=0 or max_cstate=2 on the Xen command line, but again
>>> without knowing the underlying issue it's impossible to tell whether
>>> it's relevant.
>>>
>>> Andrew provided a debug patch which I've expanded to also log power
>>> state transition, and is attached to this email.
>>>
>>> Here is a trace of a crash, together with the debug info.
>>>
>>> (XEN) *** Pending EOI error ***
>>> (XEN)   cpu #1, irq 30, vector 0x21, sp 1
>>> (XEN) Peoi stack: sp 1
>>> (XEN)   [ 0] irq  30, vec 0x21, ready 0, ISR 1, TMR 0, IRR 0
>>> (XEN) Peoi stack trace records:
>>> (XEN)   [22619] POP  {sp  1, irq  30, vec 0x21}
>>> (XEN)   [22620] POWERTYPE 4
>>> (XEN)   [22621] IDLE PPR 0x0010
>>> (XEN)IRR 
>>> 
>>> (XEN)ISR 
>>> 
>>> (XEN)   [22622] WAKE PPR 0x0010
>>> (XEN)IRR 
>>> 0004
>>> (XEN)ISR 
>>> 
>>> (XEN)   [22623] ACK_PRE  PPR 0x00f0
>>> (XEN)IRR 
>>> 
>>> (XEN)ISR 
>>> 0004
>>> (XEN)   [22624] ACK_POST PPR 0x0010
>>> (XEN)IRR 
>>> 
>>> (XEN)ISR 
>>> 
>>> (XEN)   [22625] POWERTYPE 5
>>> (XEN)   [22626] IDLE PPR 0x0010
>>> (XEN)IRR 
>>> 
>>> (XEN)ISR 
>>> 
>>> (XEN)   [22627] WAKE PPR 0x0010
>>> (XEN)IRR 
>>> 0200
>>> (XEN)ISR 
>>> 
>>> (XEN)   [22628] PUSH {sp  0, irq  30, vec 0x21}
>>> (XEN)   [22629] POWERTYPE 5
>>> (XEN)   [22630] IDLE PPR 0x0020
>>> (XEN)IRR 
>>> 
>>> (XEN)ISR 
>>> 0200
>>> (XEN)   [22631] WAKE PPR 0x0020
>>> (XEN)IRR 
>>> 0200
>>> (XEN)ISR 
>>> 0200
>>> (XEN)   [22632] POWERTYPE 5
>>> (XEN)   [22633] IDLE PPR 0x0020
>>> (XEN)IRR 
>>> 0200
>>> (XEN)

[Xen-devel] [xen-4.9-testing baseline-only test] 75474: trouble: blocked/broken

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 75474 xen-4.9-testing real [real]
http://osstest.xensource.com/osstest/logs/75474/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64  broken
 build-amd64-prev broken
 build-i386   broken
 build-armhf-pvopsbroken
 build-i386-xsm   broken
 build-amd64-xtf  broken
 build-amd64-xsm  broken
 build-amd64-pvopsbroken
 build-i386-pvops broken
 build-armhf  broken
 build-i386-prev  broken
 build-armhf-pvops 3 syslog-serverrunning
 build-armhf   3 syslog-serverrunning

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-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-xtf-amd64-amd64-11 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-midway1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win10-i386  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-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-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-i386-xl-qemut-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemut-win10-i386  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 build-i386-rumprun1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  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-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  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-xtf-amd64-amd64-21 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 build-amd64-rumprun   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-livepatch 1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-41 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-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 build-amd64-libvirt   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-xtf-amd64-amd64-31 build-check(1)   

Re: [Xen-devel] Ongoing/future speculative mitigation work

[Mihai Donțu]

On Fri, 2018-10-19 at 13:17 +0100, Andrew Cooper wrote:
> [...]
> 
> > Therefore, although I certainly think we _must_ have the proper
> > scheduler enhancements in place (and in fact I'm working on that :-D)
> > it should IMO still be possible for the user to decide whether or not
> > to use them (either by opting-in or opting-out, I don't care much at
> > this stage).
> 
> I'm not suggesting that we leave people without a choice, but given an
> option which doesn't share siblings between different guests, it should
> be the default.

+1

> [...]
> 
> Its best to consider the secret-free Xen and scheduler improvements as
> orthogonal.  In particular, the secret-free Xen is defence in depth
> against SP1, and the risk of future issues, but does have
> non-speculative benefits as well.
> 
> That said, the only way to use HT and definitely be safe to L1TF without
> a secret-free Xen is to have the synchronised entry/exit logic working.
> 
> > > A solution to this issue was proposed, whereby Xen synchronises
> > > siblings on vmexit/entry, so we are never executing code in two different
> > > privilege levels.  Getting this working would make it safe to
> > > continue using hyperthreading even in the presence of L1TF.  
> > 
> > Err... ok, but we still want core-aware scheduling, or at least we want
> > to avoid having vcpus from different domains on siblings, don't we? In
> > order to avoid leaks between guests, I mean.
> 
> Ideally, we'd want all of these.  I expect the only reasonable way to
> develop them is one on top of another.

If there was a vote, I'd place the scheduler changes at the top.

-- 
Mihai Donțu


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

Re: [Xen-devel] [PATCH v8 8/8] xen/arm: map reserved-memory regions as normal memory in dom0

[Julien Grall]

Hi,

On 09/10/2018 00:37, Stefano Stabellini wrote:

reserved-memory regions should be mapped as normal memory.


This is already the case with p2m_mmio_direct_c. The hardware domain 
should have full control on the resulting attributes via its stage-1 
mappings. So what's wrong with that p2m type?


Cheers,


 At the
moment, they get remapped as device memory because Xen doesn't know
better. Add an explicit check for it.

Signed-off-by: Stefano Stabellini 
---
  xen/arch/arm/domain_build.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index f552154..c7df4cf 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1307,6 +1307,13 @@ static int __init handle_node(struct domain *d, struct 
kernel_info *kinfo,
 "WARNING: Path %s is reserved, skip the node as we may re-use the 
path.\n",
 path);
  
+/*

+ * reserved-memory ranges should be mapped as normal memory in the
+ * p2m.
+ */
+if ( !strcmp(dt_node_name(node), "reserved-memory") )
+p2mt = p2m_ram_rw;
+
  res = handle_device(d, node, p2mt);
  if ( res)
  return res;



--
Julien Grall

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

[Xen-devel] [freebsd-master test] 128930: regressions - trouble: blocked/broken

[osstest service owner]

flight 128930 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128930/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-freebsd  broken
 build-amd64-freebsd   6 host-build-prep  fail REGR. vs. 128497

Tests which did not succeed, but are not blocking:
 build-amd64-xen-freebsd   1 build-check(1)   blocked  n/a
 build-amd64-freebsd-again 1 build-check(1)   blocked  n/a

version targeted for testing:
 freebsd  b54bba1abfd48c8c2bf15fb9c032772fcbf36594
baseline version:
 freebsd  c0b412ce93b9d3ee750e5f262b50e64c52d300cc

Last test of basis   128497  2018-10-08 09:19:52 Z   14 days
Failing since128582  2018-10-10 09:19:25 Z   12 days6 attempts
Testing same since   128930  2018-10-22 09:19:08 Z0 days1 attempts


People who touched revisions under test:
  0mp <0...@freebsd.org>
  ae 
  allanjude 
  andrew 
  bapt 
  bcr 
  br 
  brooks 
  bwidawsk 
  bz 
  cem 
  davidcs 
  des 
  dteske 
  eadler 
  egypcio 
  emaste 
  erj 
  eugen 
  gjb 
  glebius 
  gonzo 
  hselasky 
  imp 
  jamie 
  jchandra 
  jhb 
  jhibbits 
  jkim 
  jtl 
  kevans 
  kib 
  kp 
  luporl 
  markj 
  mav 
  mjg 
  mw 
  np 
  nwhitehorn 
  oshogbo 
  peter 
  philip 
  phk 
  rigoletto 
  rmacklem 
  shurd 
  tobik 
  trasz 
  tsoome 
  tuexen 
  vmaffione 
  yuripv 

jobs:
 build-amd64-freebsd-againblocked 
 build-amd64-freebsd  broken  
 build-amd64-xen-freebsd  blocked 



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

broken-job build-amd64-freebsd broken

Not pushing.

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

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

Re: [Xen-devel] [PATCH v2] devicetree, xen: add xen, shared-memory binding

[Julien Grall]

Hi Stefano,

On 18/10/2018 23:10, Stefano Stabellini wrote:

From: Stefano Stabellini 

Introduce a device tree binding for Xen reserved-memory regions. They
are used to share memory across VMs from the VM config files. (See
static_shm config option.)

Signed-off-by: Stefano Stabellini 
---
Changes in v2:
- fix Author line
- add versioning
- xen,id instead of id
---
  .../bindings/reserved-memory/xen,shared-memory.txt   | 20 
  1 file changed, 20 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/reserved-memory/xen,shared-memory.txt

diff --git 
a/Documentation/devicetree/bindings/reserved-memory/xen,shared-memory.txt 
b/Documentation/devicetree/bindings/reserved-memory/xen,shared-memory.txt
new file mode 100644
index 000..9078fb7
--- /dev/null
+++ b/Documentation/devicetree/bindings/reserved-memory/xen,shared-memory.txt
@@ -0,0 +1,20 @@
+* Xen hypervisor reserved-memory binding
+
+Expose one or more memory regions as reserved-memory to the guest
+virtual machine. 
Typically, a region is configured at VM creation time

+to be a shared memory area across multiple virtual machines for
+communication among them.
+
+For each of these pre-shared memory regions, a range is exposed under
+the /reserved-memory node as a child node. Each range sub-node is named
+xen-shmem@ and has the following properties:
+
+- compatible:
+   compatible = "xen,shared-memory-v1", "xen,shared-memory"


Do we need to specify the two compatibles?


+
+- reg:
+   the base guest physical address and size of the shared memory region
+
+- xen,id:
+   a string that identifies the shared memory region as specified in
+   the VM config file



--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 1/2] memory_hotplug: Free pages as higher order

[Arun KS]

On 2018-10-19 13:37, Michal Hocko wrote:

On Thu 18-10-18 19:18:25, Andrew Morton wrote:
[...]

So this patch needs more work, yes?


Yes, I've talked to Arun (he is offline until next week) offlist and he
will play with this some more.


Converted totalhigh_pages, totalram_pages and zone->managed_page to 
atomic and tested hot add. Latency is not effected with this change.

Will send out a separate patch on top of this one.

Regards,
Arun

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

Re: [Xen-devel] [PATCH] x86: Consolidate the storage of MSR_AMD64_DR{0-3}_ADDRESS_MASK

[Wei Liu]

On Fri, Oct 19, 2018 at 06:52:02PM -0400, Boris Ostrovsky wrote:
> On 10/19/18 11:14 AM, Andrew Cooper wrote:
> > diff --git a/xen/include/asm-x86/msr.h b/xen/include/asm-x86/msr.h
> > index 7a061b2..c1cb38f 100644
> > --- a/xen/include/asm-x86/msr.h
> > +++ b/xen/include/asm-x86/msr.h
> > @@ -287,6 +287,12 @@ struct vcpu_msrs
> >  bool cpuid_faulting:1;
> >  };
> >  } misc_features_enables;
> > +
> > +/*
> > + * 0xc00110{27,19-1b} MSR_AMD64_DR{0-3}_ADDRESS_MASK
> > + * TODO: Not yet handled by guest_{rd,wr}msr() infrastructure.
> > + */
> > +uint32_t dr_mask[4];
> >  };
> >  
> 
> You don't think wrapping these into an intel/amd union would be useful?

Same question here. DR masks seem to be AMD specific.

The code change itself looks good to me.

Thanks for posting this patch.

Wei.

> 
> -boris

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

Re: [Xen-devel] [PATCH] x86: Consolidate the storage of MSR_AMD64_DR{0-3}_ADDRESS_MASK

[Andrew Cooper]

On 22/10/18 11:53, Wei Liu wrote:
> On Fri, Oct 19, 2018 at 06:52:02PM -0400, Boris Ostrovsky wrote:
>> On 10/19/18 11:14 AM, Andrew Cooper wrote:
>>> diff --git a/xen/include/asm-x86/msr.h b/xen/include/asm-x86/msr.h
>>> index 7a061b2..c1cb38f 100644
>>> --- a/xen/include/asm-x86/msr.h
>>> +++ b/xen/include/asm-x86/msr.h
>>> @@ -287,6 +287,12 @@ struct vcpu_msrs
>>>  bool cpuid_faulting:1;
>>>  };
>>>  } misc_features_enables;
>>> +
>>> +/*
>>> + * 0xc00110{27,19-1b} MSR_AMD64_DR{0-3}_ADDRESS_MASK
>>> + * TODO: Not yet handled by guest_{rd,wr}msr() infrastructure.
>>> + */
>>> +uint32_t dr_mask[4];
>>>  };
>>>  
>> You don't think wrapping these into an intel/amd union would be useful?
> Same question here. DR masks seem to be AMD specific.

Does the svm/vt-x here pertain to the host processor, or the guest
cross-vendor setting?  (That's a rhetorical question.  Its a complete
can of worms which I don't want to open).

For the sake of 16 bytes, I don't think its worth it.  We can always
revisit this in the future if necessary.

~Andrew

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

Re: [Xen-devel] [PATCH] x86: Consolidate the storage of MSR_AMD64_DR{0-3}_ADDRESS_MASK

[Wei Liu]

On Mon, Oct 22, 2018 at 11:57:17AM +0100, Andrew Cooper wrote:
> On 22/10/18 11:53, Wei Liu wrote:
> > On Fri, Oct 19, 2018 at 06:52:02PM -0400, Boris Ostrovsky wrote:
> >> On 10/19/18 11:14 AM, Andrew Cooper wrote:
> >>> diff --git a/xen/include/asm-x86/msr.h b/xen/include/asm-x86/msr.h
> >>> index 7a061b2..c1cb38f 100644
> >>> --- a/xen/include/asm-x86/msr.h
> >>> +++ b/xen/include/asm-x86/msr.h
> >>> @@ -287,6 +287,12 @@ struct vcpu_msrs
> >>>  bool cpuid_faulting:1;
> >>>  };
> >>>  } misc_features_enables;
> >>> +
> >>> +/*
> >>> + * 0xc00110{27,19-1b} MSR_AMD64_DR{0-3}_ADDRESS_MASK
> >>> + * TODO: Not yet handled by guest_{rd,wr}msr() infrastructure.
> >>> + */
> >>> +uint32_t dr_mask[4];
> >>>  };
> >>>  
> >> You don't think wrapping these into an intel/amd union would be useful?
> > Same question here. DR masks seem to be AMD specific.
> 
> Does the svm/vt-x here pertain to the host processor, or the guest
> cross-vendor setting?  (That's a rhetorical question.  Its a complete
> can of worms which I don't want to open).
> 
> For the sake of 16 bytes, I don't think its worth it.  We can always
> revisit this in the future if necessary.

Sure. Feel free to add my Rb to your patch.

Wei.

> 
> ~Andrew

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

Re: [Xen-devel] [PATCH v2 10/16] x86: don't setup legacy syscall vector when !CONFIG_PV

[Wei Liu]

On Fri, Oct 19, 2018 at 05:09:43PM +0100, Andrew Cooper wrote:
> On 19/10/18 15:28, Wei Liu wrote:
> > Put the code in smpboot.c under CONFIG_PV. Not that we don't need to
> > set up a stub here because entry.S already does that.
> >
> > Signed-off-by: Wei Liu 
> 
> The stub isn't the purpose of the code.  This code is to switch between
> SYS_DESC_trap_gate and SYS_DESC_irq_gate depending on whether we're
> intending to use XPTI.  All other details in the IDT entry are already
> configured correctly for int80_direct_trap.
> 
> The patch is fine, but with an tweaked commit message, Reviewed-by:
> Andrew Cooper 

I have updated the commit message to the following:

The code snippet is to switch between SYS_DECS_trap_gate and
SYS_DESC_irq_gate depending on whether XPTI is used. When PV is disabled
there is no need to switch.

Does that look OK to you?

Wei.

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

Re: [Xen-devel] [PATCH v2 08/18] xen: add basic hooks for PVH in current code

[Daniel Kiper]

On Fri, Oct 19, 2018 at 05:52:44PM +0200, Juergen Gross wrote:
> On 19/10/2018 17:33, Roger Pau Monné wrote:
> > On Tue, Oct 09, 2018 at 01:03:07PM +0200, Juergen Gross wrote:
> >> Add the hooks to current code needed for Xen PVH.
> >>
> >> Signed-off-by: Juergen Gross 
> >> ---
> >>  grub-core/kern/i386/xen/pvh.c | 36 
> >> +++
> >>  grub-core/kern/i386/xen/startup_pvh.S | 29 
> >>  grub-core/kern/xen/init.c |  6 ++
> >>  include/grub/i386/xenpvh/kernel.h | 30 +
> >>  include/grub/xen.h|  6 ++
> >>  5 files changed, 107 insertions(+)
> >>  create mode 100644 grub-core/kern/i386/xen/pvh.c
> >>  create mode 100644 grub-core/kern/i386/xen/startup_pvh.S
> >>  create mode 100644 include/grub/i386/xenpvh/kernel.h
> >>
> >> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
> >> new file mode 100644
> >> index 0..182ef95f9
> >> --- /dev/null
> >> +++ b/grub-core/kern/i386/xen/pvh.c
> >> @@ -0,0 +1,36 @@
> >> +/*
> >> + *  GRUB  --  GRand Unified Bootloader
> >> + *  Copyright (C) 2011  Free Software Foundation, Inc.
> >
> > Isn't this header (and the ones below) kind of off at least year
> > wise?
>
> Hmm, only a little bit :-)
>
> Will update.

Please do this for all headers in the patchset

Daniel

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

Re: [Xen-devel] [PATCH v2 08/18] xen: add basic hooks for PVH in current code

[Juergen Gross]

On 22/10/2018 13:16, Daniel Kiper wrote:
> On Fri, Oct 19, 2018 at 05:52:44PM +0200, Juergen Gross wrote:
>> On 19/10/2018 17:33, Roger Pau Monné wrote:
>>> On Tue, Oct 09, 2018 at 01:03:07PM +0200, Juergen Gross wrote:
 Add the hooks to current code needed for Xen PVH.

 Signed-off-by: Juergen Gross 
 ---
  grub-core/kern/i386/xen/pvh.c | 36 
 +++
  grub-core/kern/i386/xen/startup_pvh.S | 29 
  grub-core/kern/xen/init.c |  6 ++
  include/grub/i386/xenpvh/kernel.h | 30 +
  include/grub/xen.h|  6 ++
  5 files changed, 107 insertions(+)
  create mode 100644 grub-core/kern/i386/xen/pvh.c
  create mode 100644 grub-core/kern/i386/xen/startup_pvh.S
  create mode 100644 include/grub/i386/xenpvh/kernel.h

 diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
 new file mode 100644
 index 0..182ef95f9
 --- /dev/null
 +++ b/grub-core/kern/i386/xen/pvh.c
 @@ -0,0 +1,36 @@
 +/*
 + *  GRUB  --  GRand Unified Bootloader
 + *  Copyright (C) 2011  Free Software Foundation, Inc.
>>>
>>> Isn't this header (and the ones below) kind of off at least year
>>> wise?
>>
>> Hmm, only a little bit :-)
>>
>> Will update.
> 
> Please do this for all headers in the patchset

That was my plan :-)


Juergen

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

Re: [Xen-devel] [PATCH v2 09/18] xen: add PVH boot entry code

[Daniel Kiper]

On Fri, Oct 19, 2018 at 04:50:25PM +0200, Juergen Gross wrote:
> On 19/10/2018 14:17, Daniel Kiper wrote:
> > On Tue, Oct 09, 2018 at 01:03:08PM +0200, Juergen Gross wrote:
> >> Add the code for the Xen PVH mode boot entry.
> >>
> >> Signed-off-by: Juergen Gross 
> >> ---
> >>  grub-core/kern/i386/xen/startup_pvh.S | 50 
> >> +++
> >>  1 file changed, 50 insertions(+)
> >>
> >> diff --git a/grub-core/kern/i386/xen/startup_pvh.S 
> >> b/grub-core/kern/i386/xen/startup_pvh.S
> >> index e18ee5b31..0ddb63b31 100644
> >> --- a/grub-core/kern/i386/xen/startup_pvh.S
> >> +++ b/grub-core/kern/i386/xen/startup_pvh.S
> >> @@ -19,11 +19,61 @@
> >>
> >>  #include 
> >>  #include 
> >> +#include 
> >>
> >>.file   "startup_pvh.S"
> >>.text
> >> +  .globl  start, _start
> >> +  .code32
> >>
> >> +start:
> >> +_start:
> >> +  cld
> >> +  lgdtgdtdesc
> >> +  ljmp$GRUB_MEMORY_MACHINE_PROT_MODE_CSEG, $1f
> >> +1:
> >> +  movl$GRUB_MEMORY_MACHINE_PROT_MODE_DSEG, %eax
> >> +  mov %eax, %ds
> >> +  mov %eax, %es
> >> +  mov %eax, %ss
> >
> > Should not you load null descriptor into %fs and %gs?
> > Just in case...
>
> Hmm, if you want I can do that, sure.

Please do.

> >> +  lealLOCAL(stack_end), %esp
> >> +
> >> +  /* Save address of start info structure. */
> >> +  mov %ebx, pvh_start_info
> >> +  callEXT_C(grub_main)
> >> +  /* Doesn't return. */
> >> +
> >> +  .p2align3
> >> +gdt:
> >> +  .word   0, 0
> >> +  .byte   0, 0, 0, 0
> >> +
> >> +  /* -- code segment --
> >> +   * base = 0x, limit = 0xF (4 KiB Granularity), present
> >> +   * type = 32bit code execute/read, DPL = 0
> >> +   */
> >> +  .word   0x, 0
> >> +  .byte   0, 0x9A, 0xCF, 0
> >> +
> >> +  /* -- data segment --
> >> +   * base = 0x, limit 0xF (4 KiB Granularity), present
> >> +   * type = 32 bit data read/write, DPL = 0
> >> +   */
> >> +  .word   0x, 0
> >> +  .byte   0, 0x92, 0xCF, 0
> >> +
> >> +  .p2align3
> >> +/* this is the GDT descriptor */
> >> +gdtdesc:
> >> +  .word   0x17/* limit */
> >> +  .long   gdt /* addr */
> >> +
> >> +  .p2align2
> >>  /* Saved pointer to start info structure. */
> >>.globl  pvh_start_info
> >>  pvh_start_info:
> >>.long   0
> >> +
> >> +  .bss
> >> +  .space  (1 << 22)
> >
> > Hmmm... Why do we need 4 MiB here? If this is really needed then it begs for
> > a comment. And I would like to see a constant instead of plain number here.
>
> This is just copied from xen/startup.S
>
> I can reduce it to something near GRUB_MEMORY_MACHINE_PROT_STACK_SIZE
> (about 64kB).

GRUB_MEMORY_MACHINE_PROT_STACK_SIZE works for me.

Daniel

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

Re: [Xen-devel] [PATCH v2 10/16] x86: don't setup legacy syscall vector when !CONFIG_PV

[Andrew Cooper]

On 22/10/18 12:12, Wei Liu wrote:
> On Fri, Oct 19, 2018 at 05:09:43PM +0100, Andrew Cooper wrote:
>> On 19/10/18 15:28, Wei Liu wrote:
>>> Put the code in smpboot.c under CONFIG_PV. Not that we don't need to
>>> set up a stub here because entry.S already does that.
>>>
>>> Signed-off-by: Wei Liu 
>> The stub isn't the purpose of the code.  This code is to switch between
>> SYS_DESC_trap_gate and SYS_DESC_irq_gate depending on whether we're
>> intending to use XPTI.  All other details in the IDT entry are already
>> configured correctly for int80_direct_trap.
>>
>> The patch is fine, but with an tweaked commit message, Reviewed-by:
>> Andrew Cooper 
> I have updated the commit message to the following:
>
> The code snippet is to switch between SYS_DECS_trap_gate and
> SYS_DESC_irq_gate depending on whether XPTI is used. When PV is disabled
> there is no need to switch.
>
> Does that look OK to you?

Yup.

~Andrew

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

Re: [Xen-devel] [PATCH v2 13/18] xen: init memory regions for PVH

[Daniel Kiper]

On Tue, Oct 09, 2018 at 01:03:12PM +0200, Juergen Gross wrote:
> Add all usable memory regions to grub memory management and add the
> needed mmap iterate code.

I am missing a few words why this patch is needed. Especially why
grub_machine_mmap_iterate() has to belong to this patch. However,
I think that it should be introduced by patch in which
grub_machine_mmap_iterate() is used at some point.

> As we are running in 32-bit mode don't add memory above 4GB.
>
> Signed-off-by: Juergen Gross 
> ---
>  grub-core/kern/i386/xen/pvh.c | 35 +++
>  1 file changed, 35 insertions(+)
>
> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
> index 93ed68245..c4a8bccf4 100644
> --- a/grub-core/kern/i386/xen/pvh.c
> +++ b/grub-core/kern/i386/xen/pvh.c
> @@ -222,6 +222,30 @@ grub_xen_get_mmap (void)
>grub_xen_sort_mmap ();
>  }
>
> +static void
> +grub_xen_mm_init_regions (void)
> +{
> +  grub_uint64_t modend, from, to;
> +  unsigned int i;
> +
> +  modend = grub_modules_get_end ();
> +
> +  for (i = 0; i < nr_map_entries; i++)
> +{
> +  if (map[i].type != GRUB_MEMORY_AVAILABLE)
> +continue;
> +  from = map[i].addr;
> +  to = from + map[i].len;
> +  if (from < modend)
> +from = modend;
> +  if (from >= to || from >= 0x1ULL)
> +continue;
> +  if (to > 0x1ULL)
> +to = 0x1ULL;
> +  grub_mm_init_region ((void *) (grub_addr_t) from, to - from);
> +}
> +}
> +
>  static grub_uint64_t
>  grub_xen_find_page (grub_uint64_t start)
>  {
> @@ -302,10 +326,21 @@ grub_xen_setup_pvh (void)
>grub_xen_shared_info = grub_xen_add_physmap (XENMAPSPACE_shared_info,
>  (void *) par);
>
> +  grub_xen_mm_init_regions ();
> +
>grub_rsdp_addr = pvh_start_info->rsdp_paddr;
>  }
>
>  grub_err_t
>  grub_machine_mmap_iterate (grub_memory_hook_t hook, void *hook_data)
>  {
> +  unsigned int i;
> +
> +  for (i = 0; i < nr_map_entries; i++)
> +{
> +  if (map[i].len && hook (map[i].addr, map[i].len, map[i].type, 
> hook_data))
> +break;
> +}
> +
> +  return GRUB_ERR_NONE;

Daniel

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

Re: [Xen-devel] [PATCH v2 14/18] xenpvh: add build runes for grub-core

[Daniel Kiper]

On Tue, Oct 09, 2018 at 01:03:13PM +0200, Juergen Gross wrote:
> Add the modifications to the build system needed to build a xenpvh
> grub.
>
> Signed-off-by: Juergen Gross 
> Reviewed-by: Daniel Kiper 
> ---
>  gentpl.py   |  4 ++--
>  grub-core/Makefile.am   | 12 
>  grub-core/Makefile.core.def | 35 +++
>  3 files changed, 49 insertions(+), 2 deletions(-)
>
> diff --git a/gentpl.py b/gentpl.py
> index da67965a4..9732b4aee 100644
> --- a/gentpl.py
> +++ b/gentpl.py
> @@ -28,7 +28,7 @@ import re
>
>  GRUB_PLATFORMS = [ "emu", "i386_pc", "i386_efi", "i386_qemu", 
> "i386_coreboot",
> "i386_multiboot", "i386_ieee1275", "x86_64_efi",
> -   "i386_xen", "x86_64_xen",
> +   "i386_xen", "x86_64_xen", "i386_xenpvh",

s/i386_xenpvh/i386_xen_pvh/ here and below please...

> "mips_loongson", "sparc64_ieee1275",
> "powerpc_ieee1275", "mips_arc", "ia64_efi",
> "mips_qemu_mips", "arm_uboot", "arm_efi", "arm64_efi",
> @@ -71,7 +71,7 @@ GROUPS["videomodules"]   = GRUB_PLATFORMS[:];
>  for i in GROUPS["videoinkernel"]: GROUPS["videomodules"].remove(i)
>
>  # Similar for terminfo
> -GROUPS["terminfoinkernel"] = [ "emu", "mips_loongson", "mips_arc", 
> "mips_qemu_mips" ] + GROUPS["xen"] + GROUPS["ieee1275"] + GROUPS["uboot"];
> +GROUPS["terminfoinkernel"] = [ "emu", "mips_loongson", "mips_arc", 
> "mips_qemu_mips", "i386_xenpvh" ] + GROUPS["xen"] + GROUPS["ieee1275"] + 
> GROUPS["uboot"];
>  GROUPS["terminfomodule"]   = GRUB_PLATFORMS[:];
>  for i in GROUPS["terminfoinkernel"]: GROUPS["terminfomodule"].remove(i)
>
> diff --git a/grub-core/Makefile.am b/grub-core/Makefile.am
> index f4ff62b76..d4417e2c4 100644
> --- a/grub-core/Makefile.am
> +++ b/grub-core/Makefile.am
> @@ -101,6 +101,18 @@ KERNEL_HEADER_FILES += 
> $(top_builddir)/include/grub/machine/int.h
>  KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/i386/tsc.h
>  endif
>
> +if COND_i386_xenpvh
> +KERNEL_HEADER_FILES += $(top_builddir)/include/grub/machine/kernel.h
> +KERNEL_HEADER_FILES += $(top_builddir)/include/grub/machine/int.h
> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/i386/tsc.h
> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/terminfo.h
> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/extcmd.h
> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/loader.h
> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/lib/arg.h
> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/xen.h
> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/i386/xen/hypercall.h
> +endif
> +
>  if COND_i386_efi
>  KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/efi/efi.h
>  KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/efi/disk.h
> diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
> index 9590e87d9..c42cebc38 100644
> --- a/grub-core/Makefile.core.def
> +++ b/grub-core/Makefile.core.def
> @@ -79,6 +79,8 @@ kernel = {
>i386_xen_ldflags = '$(TARGET_IMG_BASE_LDOPT),0';
>x86_64_xen_ldflags   = '$(TARGET_IMG_LDFLAGS)';
>x86_64_xen_ldflags   = '$(TARGET_IMG_BASE_LDOPT),0';
> +  i386_xenpvh_ldflags  = '$(TARGET_IMG_LDFLAGS)';
> +  i386_xenpvh_ldflags  = '$(TARGET_IMG_BASE_LDOPT),0x10';
>
>mips_loongson_ldflags= '-Wl,-Ttext,0x8020';
>powerpc_ieee1275_ldflags = '-Wl,-Ttext,0x20';
> @@ -100,6 +102,7 @@ kernel = {
>x86_64_efi_startup = kern/x86_64/efi/startup.S;
>i386_xen_startup = kern/i386/xen/startup.S;
>x86_64_xen_startup = kern/x86_64/xen/startup.S;
> +  i386_xenpvh_startup = kern/i386/xen/startup_pvh.S;
>i386_qemu_startup = kern/i386/qemu/startup.S;
>i386_ieee1275_startup = kern/i386/ieee1275/startup.S;
>i386_coreboot_startup = kern/i386/coreboot/startup.S;
> @@ -177,6 +180,7 @@ kernel = {
>
>i386 = kern/i386/dl.c;
>i386_xen = kern/i386/dl.c;
> +  i386_xenpvh = kern/i386/dl.c;
>
>i386_coreboot = kern/i386/coreboot/init.c;
>i386_multiboot = kern/i386/coreboot/init.c;
> @@ -222,6 +226,14 @@ kernel = {
>xen = disk/xen/xendisk.c;
>xen = commands/boot.c;
>
> +  i386_xenpvh = kern/i386/tsc.c;
> +  i386_xenpvh = kern/i386/xen/tsc.c;
> +  i386_xenpvh = commands/boot.c;
> +  i386_xenpvh = kern/xen/init.c;
> +  i386_xenpvh = kern/i386/xen/pvh.c;
> +  i386_xenpvh = term/xen/console.c;
> +  i386_xenpvh = disk/xen/xendisk.c;

I would sort all file names here.

Daniel

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

Re: [Xen-devel] [PATCH v2 13/18] xen: init memory regions for PVH

[Juergen Gross]

On 22/10/2018 13:31, Daniel Kiper wrote:
> On Tue, Oct 09, 2018 at 01:03:12PM +0200, Juergen Gross wrote:
>> Add all usable memory regions to grub memory management and add the
>> needed mmap iterate code.
> 
> I am missing a few words why this patch is needed. Especially why
> grub_machine_mmap_iterate() has to belong to this patch. However,
> I think that it should be introduced by patch in which
> grub_machine_mmap_iterate() is used at some point.

That would again lead to one giant PVH patch which you didn't like.

grub_machine_mmap_iterate() is being used by grub common code like
grub-core/lib/relocator.c or grub-core/mmap/mmap.c

grub_machine_mmap_iterate() belongs into this patch as it is the
main user of the memory map introduced here.


Juergen

> 
>> As we are running in 32-bit mode don't add memory above 4GB.
>>
>> Signed-off-by: Juergen Gross 
>> ---
>>  grub-core/kern/i386/xen/pvh.c | 35 +++
>>  1 file changed, 35 insertions(+)
>>
>> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/xen/pvh.c
>> index 93ed68245..c4a8bccf4 100644
>> --- a/grub-core/kern/i386/xen/pvh.c
>> +++ b/grub-core/kern/i386/xen/pvh.c
>> @@ -222,6 +222,30 @@ grub_xen_get_mmap (void)
>>grub_xen_sort_mmap ();
>>  }
>>
>> +static void
>> +grub_xen_mm_init_regions (void)
>> +{
>> +  grub_uint64_t modend, from, to;
>> +  unsigned int i;
>> +
>> +  modend = grub_modules_get_end ();
>> +
>> +  for (i = 0; i < nr_map_entries; i++)
>> +{
>> +  if (map[i].type != GRUB_MEMORY_AVAILABLE)
>> +continue;
>> +  from = map[i].addr;
>> +  to = from + map[i].len;
>> +  if (from < modend)
>> +from = modend;
>> +  if (from >= to || from >= 0x1ULL)
>> +continue;
>> +  if (to > 0x1ULL)
>> +to = 0x1ULL;
>> +  grub_mm_init_region ((void *) (grub_addr_t) from, to - from);
>> +}
>> +}
>> +
>>  static grub_uint64_t
>>  grub_xen_find_page (grub_uint64_t start)
>>  {
>> @@ -302,10 +326,21 @@ grub_xen_setup_pvh (void)
>>grub_xen_shared_info = grub_xen_add_physmap (XENMAPSPACE_shared_info,
>> (void *) par);
>>
>> +  grub_xen_mm_init_regions ();
>> +
>>grub_rsdp_addr = pvh_start_info->rsdp_paddr;
>>  }
>>
>>  grub_err_t
>>  grub_machine_mmap_iterate (grub_memory_hook_t hook, void *hook_data)
>>  {
>> +  unsigned int i;
>> +
>> +  for (i = 0; i < nr_map_entries; i++)
>> +{
>> +  if (map[i].len && hook (map[i].addr, map[i].len, map[i].type, 
>> hook_data))
>> +break;
>> +}
>> +
>> +  return GRUB_ERR_NONE;
> 
> Daniel
> 


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

Re: [Xen-devel] [PATCH v2 15/18] grub-module-verifier: Ignore all_video for xenpvh

[Daniel Kiper]

On Tue, Oct 09, 2018 at 01:03:14PM +0200, Juergen Gross wrote:
> From: Hans van Kranenburg 
>
> This solves the build failing with "Error: no symbol table and no
> .moddeps section"
>
> Also see:
> - 6371e9c10433578bb236a8284ddb9ce9e201eb59
> - https://savannah.gnu.org/bugs/?49012
>
> Signed-off-by: Hans van Kranenburg 

Except s/xenpvh/xen_pvh/ Reviewed-by: Daniel Kiper 

Daniel

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

Re: [Xen-devel] [PATCH v2 14/18] xenpvh: add build runes for grub-core

[Juergen Gross]

On 22/10/2018 13:41, Daniel Kiper wrote:
> On Tue, Oct 09, 2018 at 01:03:13PM +0200, Juergen Gross wrote:
>> Add the modifications to the build system needed to build a xenpvh
>> grub.
>>
>> Signed-off-by: Juergen Gross 
>> Reviewed-by: Daniel Kiper 
>> ---
>>  gentpl.py   |  4 ++--
>>  grub-core/Makefile.am   | 12 
>>  grub-core/Makefile.core.def | 35 +++
>>  3 files changed, 49 insertions(+), 2 deletions(-)
>>
>> diff --git a/gentpl.py b/gentpl.py
>> index da67965a4..9732b4aee 100644
>> --- a/gentpl.py
>> +++ b/gentpl.py
>> @@ -28,7 +28,7 @@ import re
>>
>>  GRUB_PLATFORMS = [ "emu", "i386_pc", "i386_efi", "i386_qemu", 
>> "i386_coreboot",
>> "i386_multiboot", "i386_ieee1275", "x86_64_efi",
>> -   "i386_xen", "x86_64_xen",
>> +   "i386_xen", "x86_64_xen", "i386_xenpvh",
> 
> s/i386_xenpvh/i386_xen_pvh/ here and below please...

... which is the answer to the question I had to your request for patch
07. I'll change it accordingly.

> 
>> "mips_loongson", "sparc64_ieee1275",
>> "powerpc_ieee1275", "mips_arc", "ia64_efi",
>> "mips_qemu_mips", "arm_uboot", "arm_efi", "arm64_efi",
>> @@ -71,7 +71,7 @@ GROUPS["videomodules"]   = GRUB_PLATFORMS[:];
>>  for i in GROUPS["videoinkernel"]: GROUPS["videomodules"].remove(i)
>>
>>  # Similar for terminfo
>> -GROUPS["terminfoinkernel"] = [ "emu", "mips_loongson", "mips_arc", 
>> "mips_qemu_mips" ] + GROUPS["xen"] + GROUPS["ieee1275"] + GROUPS["uboot"];
>> +GROUPS["terminfoinkernel"] = [ "emu", "mips_loongson", "mips_arc", 
>> "mips_qemu_mips", "i386_xenpvh" ] + GROUPS["xen"] + GROUPS["ieee1275"] + 
>> GROUPS["uboot"];
>>  GROUPS["terminfomodule"]   = GRUB_PLATFORMS[:];
>>  for i in GROUPS["terminfoinkernel"]: GROUPS["terminfomodule"].remove(i)
>>
>> diff --git a/grub-core/Makefile.am b/grub-core/Makefile.am
>> index f4ff62b76..d4417e2c4 100644
>> --- a/grub-core/Makefile.am
>> +++ b/grub-core/Makefile.am
>> @@ -101,6 +101,18 @@ KERNEL_HEADER_FILES += 
>> $(top_builddir)/include/grub/machine/int.h
>>  KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/i386/tsc.h
>>  endif
>>
>> +if COND_i386_xenpvh
>> +KERNEL_HEADER_FILES += $(top_builddir)/include/grub/machine/kernel.h
>> +KERNEL_HEADER_FILES += $(top_builddir)/include/grub/machine/int.h
>> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/i386/tsc.h
>> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/terminfo.h
>> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/extcmd.h
>> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/loader.h
>> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/lib/arg.h
>> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/xen.h
>> +KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/i386/xen/hypercall.h
>> +endif
>> +
>>  if COND_i386_efi
>>  KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/efi/efi.h
>>  KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/efi/disk.h
>> diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
>> index 9590e87d9..c42cebc38 100644
>> --- a/grub-core/Makefile.core.def
>> +++ b/grub-core/Makefile.core.def
>> @@ -79,6 +79,8 @@ kernel = {
>>i386_xen_ldflags = '$(TARGET_IMG_BASE_LDOPT),0';
>>x86_64_xen_ldflags   = '$(TARGET_IMG_LDFLAGS)';
>>x86_64_xen_ldflags   = '$(TARGET_IMG_BASE_LDOPT),0';
>> +  i386_xenpvh_ldflags  = '$(TARGET_IMG_LDFLAGS)';
>> +  i386_xenpvh_ldflags  = '$(TARGET_IMG_BASE_LDOPT),0x10';
>>
>>mips_loongson_ldflags= '-Wl,-Ttext,0x8020';
>>powerpc_ieee1275_ldflags = '-Wl,-Ttext,0x20';
>> @@ -100,6 +102,7 @@ kernel = {
>>x86_64_efi_startup = kern/x86_64/efi/startup.S;
>>i386_xen_startup = kern/i386/xen/startup.S;
>>x86_64_xen_startup = kern/x86_64/xen/startup.S;
>> +  i386_xenpvh_startup = kern/i386/xen/startup_pvh.S;
>>i386_qemu_startup = kern/i386/qemu/startup.S;
>>i386_ieee1275_startup = kern/i386/ieee1275/startup.S;
>>i386_coreboot_startup = kern/i386/coreboot/startup.S;
>> @@ -177,6 +180,7 @@ kernel = {
>>
>>i386 = kern/i386/dl.c;
>>i386_xen = kern/i386/dl.c;
>> +  i386_xenpvh = kern/i386/dl.c;
>>
>>i386_coreboot = kern/i386/coreboot/init.c;
>>i386_multiboot = kern/i386/coreboot/init.c;
>> @@ -222,6 +226,14 @@ kernel = {
>>xen = disk/xen/xendisk.c;
>>xen = commands/boot.c;
>>
>> +  i386_xenpvh = kern/i386/tsc.c;
>> +  i386_xenpvh = kern/i386/xen/tsc.c;
>> +  i386_xenpvh = commands/boot.c;
>> +  i386_xenpvh = kern/xen/init.c;
>> +  i386_xenpvh = kern/i386/xen/pvh.c;
>> +  i386_xenpvh = term/xen/console.c;
>> +  i386_xenpvh = disk/xen/xendisk.c;
> 
> I would sort all file names here.

Okay.


Juergen


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

Re: [Xen-devel] [PATCH v2 16/18] xenpvh: support building a standalone image

[Daniel Kiper]

On Tue, Oct 09, 2018 at 01:03:15PM +0200, Juergen Gross wrote:
> Support mkimage for xenpvh.
>
> In order to avoid using plain integers for the ELF notes use the
> available Xen include instead. While at it replace the plain numbers
> for Xen PV mode, too.
>
> Signed-off-by: Juergen Gross 

+/- XENPVH/xenpvh play Reviewed-by: Daniel Kiper 

Daniel

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

Re: [Xen-devel] [PATCH v2 17/18] xenpvh: support grub-install for xenpvh

[Daniel Kiper]

On Tue, Oct 09, 2018 at 01:03:16PM +0200, Juergen Gross wrote:
> Add xenpvh support to grub-install.
>
> Signed-off-by: Juergen Gross 
> Reviewed-by: Daniel Kiper 

+/- XENPVH play still Reviewed-by: Daniel Kiper 

Daniel

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

Re: [Xen-devel] [PATCH v2 18/18] xenpvh: add support to configure

[Daniel Kiper]

On Tue, Oct 09, 2018 at 01:03:17PM +0200, Juergen Gross wrote:
> Support platform i386/xenpvh in configure.
>
> Signed-off-by: Juergen Gross 
> Reviewed-by: Daniel Kiper 

+/- XENPVH/xenpvh play still Reviewed-by: Daniel Kiper 

Daniel

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

Re: [Xen-devel] [PATCH v2 13/18] xen: init memory regions for PVH

[Daniel Kiper]

On Mon, Oct 22, 2018 at 01:43:53PM +0200, Juergen Gross wrote:
> On 22/10/2018 13:31, Daniel Kiper wrote:
> > On Tue, Oct 09, 2018 at 01:03:12PM +0200, Juergen Gross wrote:
> >> Add all usable memory regions to grub memory management and add the
> >> needed mmap iterate code.
> >
> > I am missing a few words why this patch is needed. Especially why
> > grub_machine_mmap_iterate() has to belong to this patch. However,
> > I think that it should be introduced by patch in which
> > grub_machine_mmap_iterate() is used at some point.
>
> That would again lead to one giant PVH patch which you didn't like.
>
> grub_machine_mmap_iterate() is being used by grub common code like
> grub-core/lib/relocator.c or grub-core/mmap/mmap.c
>
> grub_machine_mmap_iterate() belongs into this patch as it is the
> main user of the memory map introduced here.

OK, let's leave it here. Though commit message has to be updated accordingly.

Daniel

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

[Xen-devel] [ovmf test] 128927: all pass - PUSHED

[osstest service owner]

flight 128927 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128927/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 073891a3e74059e996258e32b56b3f0770c6fe55
baseline version:
 ovmf d28daaddb3e732468e930a809d3d3943a5de9558

Last test of basis   128924  2018-10-22 05:38:30 Z0 days
Testing same since   128927  2018-10-22 07:40:41 Z0 days1 attempts


People who touched revisions under test:
  Zhaozh1x 
  ZhiqiangX Zhao 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  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 :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   d28daaddb3..073891a3e7  073891a3e74059e996258e32b56b3f0770c6fe55 -> 
xen-tested-master

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

[Xen-devel] [xen-unstable-smoke test] 128931: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-xl-xsm   7 xen-boot fail REGR. vs. 128884
 test-armhf-armhf-xl   7 xen-boot fail REGR. vs. 128884

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

version targeted for testing:
 xen  d7ccb75b9623e8cca4fec718539c32412a3b8b6d
baseline version:
 xen  62aa9e7f1b8ef64b8c7c1dacb1122351cb9fd132

Last test of basis   128884  2018-10-19 20:00:41 Z2 days
Testing same since   128931  2018-10-22 10:00:40 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Wei Liu 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  fail
 test-arm64-arm64-xl-xsm  fail
 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


Not pushing.


commit d7ccb75b9623e8cca4fec718539c32412a3b8b6d
Author: Wei Liu 
Date:   Fri Oct 19 15:28:38 2018 +0100

x86: stub out PV only code in do_debug

When PV is disabled those symbols won't be available. It is impossible
for Xen to hit #DB there.

Signed-off-by: Wei Liu 
Acked-by: Andrew Cooper 

commit ef72c93df9a8775faa5006516fbcc375dcb14a5d
Author: Wei Liu 
Date:   Fri Oct 19 15:28:34 2018 +0100

x86: connect guest creation with CONFIG_PV

This is a bit more complicated than the HVM case because system
domains have PV guest type. Leave them like that.

Signed-off-by: Wei Liu 
Reviewed-by: Andrew Cooper 

commit 6f407dc4fc943286d4843ce7aba265b94e2eb9c9
Author: Wei Liu 
Date:   Fri Oct 19 15:28:31 2018 +0100

x86/pv: make guest_io_{read,write} local functions

Signed-off-by: Wei Liu 
Reviewed-by: Andrew Cooper 

commit 29b0678b3cbc03c2acc738d503988eb523201317
Author: Wei Liu 
Date:   Fri Oct 19 15:28:30 2018 +0100

x86: make construct_dom0 build with !CONFIG_PV

Signed-off-by: Wei Liu 
Reviewed-by: Andrew Cooper 
(qemu changes not included)

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

[Xen-devel] [PATCH v2 5/5] xen/keyhandler: Drop keyhandler_scratch

[Andrew Cooper]

With almost all users of keyhandler_scratch gone, clean up the 3 remaining
users and drop the buffer.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 

v2:
 * Use a static __initdata buffer for EFI, rather than a stack variable.
 * Drop (int) casts for periodic timer printing.
---
 xen/arch/x86/numa.c  | 11 ---
 xen/common/efi/boot.c|  4 ++--
 xen/common/keyhandler.c  | 26 +++---
 xen/include/xen/keyhandler.h |  3 ---
 4 files changed, 13 insertions(+), 31 deletions(-)

diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
index 8e08173..b3c9c12 100644
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -372,7 +372,6 @@ static void dump_numa(unsigned char key)
 {
 s_time_t now = NOW();
 unsigned int i, j, n;
-int err;
 struct domain *d;
 struct page_info *page;
 unsigned int page_num_node[MAX_NUMNODES];
@@ -454,12 +453,10 @@ static void dump_numa(unsigned char key)
 {
 unsigned int start_cpu = ~0U;
 
-err = snprintf(keyhandler_scratch, 12, "%3u",
-vnuma->vnode_to_pnode[i]);
-if ( err < 0 || vnuma->vnode_to_pnode[i] == NUMA_NO_NODE )
-strlcpy(keyhandler_scratch, "???", sizeof(keyhandler_scratch));
-
-printk("   %3u: pnode %s,", i, keyhandler_scratch);
+if ( vnuma->vnode_to_pnode[i] == NUMA_NO_NODE )
+printk("   %3u: pnode ???,", i);
+else
+printk("   %3u: pnode %3u,", i, vnuma->vnode_to_pnode[i]);
 
 printk(" vcpus ");
 
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 2f49731..ef8c77c 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -487,6 +487,7 @@ static EFI_FILE_HANDLE __init 
get_parent_handle(EFI_LOADED_IMAGE *loaded_image,
 CHAR16 **leaf)
 {
 static EFI_GUID __initdata fs_protocol = SIMPLE_FILE_SYSTEM_PROTOCOL;
+static CHAR16 __initdata buffer[256];
 EFI_FILE_HANDLE dir_handle;
 EFI_DEVICE_PATH *dp;
 CHAR16 *pathend, *ptr;
@@ -506,8 +507,7 @@ static EFI_FILE_HANDLE __init 
get_parent_handle(EFI_LOADED_IMAGE *loaded_image,
 if ( ret != EFI_SUCCESS )
 PrintErrMesg(L"OpenVolume failure", ret);
 
-#define buffer ((CHAR16 *)keyhandler_scratch)
-#define BUFFERSIZE sizeof(keyhandler_scratch)
+#define BUFFERSIZE sizeof(buffer)
 for ( dp = loaded_image->FilePath, *buffer = 0;
   DevicePathType(dp) != END_DEVICE_PATH_TYPE;
   dp = (void *)dp + DevicePathNodeLength(dp) )
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index 4bb2643..7333f55 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -29,8 +29,6 @@ static keyhandler_fn_t show_handlers, dump_hwdom_registers,
 static irq_keyhandler_fn_t do_toggle_alt_key, dump_registers,
 reboot_machine, run_all_keyhandlers, do_debug_key;
 
-char keyhandler_scratch[1024];
-
 static struct keyhandler {
 union {
 keyhandler_fn_t *fn;
@@ -250,25 +248,11 @@ static void reboot_machine(unsigned char key, struct 
cpu_user_regs *regs)
 machine_restart(0);
 }
 
-static void periodic_timer_print(char *str, int size, uint64_t period)
-{
-if ( period == 0 )
-{
-strlcpy(str, "No periodic timer", size);
-return;
-}
-
-snprintf(str, size,
- "%u Hz periodic timer (period %u ms)",
- 10/(int)period, (int)period/100);
-}
-
 static void dump_domains(unsigned char key)
 {
 struct domain *d;
 struct vcpu   *v;
 s_time_t   now = NOW();
-#define tmpstr keyhandler_scratch
 
 printk("'%c' pressed -> dumping domain info (now = %"PRI_stime"\n", key,
now);
@@ -333,8 +317,13 @@ static void dump_domains(unsigned char key)
 printk("pause_count=%d pause_flags=%lx\n",
atomic_read(&v->pause_count), v->pause_flags);
 arch_dump_vcpu_info(v);
-periodic_timer_print(tmpstr, sizeof(tmpstr), v->periodic_period);
-printk("%s\n", tmpstr);
+
+if ( v->periodic_period == 0 )
+printk("No periodic timer\n");
+else
+printk("%"PRI_stime" Hz periodic timer (period %"PRI_stime" 
ms)\n",
+   10 / v->periodic_period,
+   v->periodic_period / 100);
 }
 }
 
@@ -355,7 +344,6 @@ static void dump_domains(unsigned char key)
 arch_dump_shared_mem_info();
 
 rcu_read_unlock(&domlist_read_lock);
-#undef tmpstr
 }
 
 static cpumask_t read_clocks_cpumask;
diff --git a/xen/include/xen/keyhandler.h b/xen/include/xen/keyhandler.h
index 06c05c8..5131e86 100644
--- a/xen/include/xen/keyhandler.h
+++ b/xen/include/xen/keyhandler.h
@@ -48,7 +48,4 @@ void register_irq_keyhandler(unsigned char key,
 /* Inject a keypress into the key-handling subsystem. */
 extern void handle_keypress(u

[Xen-devel] [PATCH v2 2/5] xen/common: Use %*pb[l] instead of {cpu, node}mask_scn{, list}printf()

[Andrew Cooper]

This removes all use of keyhandler_scratch as a bounce-buffer for the rendered
string.  In some cases, collapse combine adjacent printk()'s which are writing
parts of the same line.

No functional change.

Signed-off-by: Andrew Cooper 
Reviewed-by: Wei Liu 
Acked-by: Jan Beulich 
Acked-by: Juergen Gross 
---
CC: Roger Pau Monné 
CC: Stefano Stabellini 
CC: Julien Grall 

v2:
 * Use ->bits for cpumasks
---
 xen/common/cpupool.c   | 12 +++-
 xen/common/event_channel.c |  6 ++
 xen/common/keyhandler.c| 35 +--
 3 files changed, 14 insertions(+), 39 deletions(-)

diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
index 1e8edcb..121fcfc 100644
--- a/xen/common/cpupool.c
+++ b/xen/common/cpupool.c
@@ -732,12 +732,6 @@ int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op)
 return ret;
 }
 
-static void print_cpumap(const char *str, const cpumask_t *map)
-{
-cpulist_scnprintf(keyhandler_scratch, sizeof(keyhandler_scratch), map);
-printk("%s: %s\n", str, keyhandler_scratch);
-}
-
 void dump_runq(unsigned char key)
 {
 unsigned longflags;
@@ -751,17 +745,17 @@ void dump_runq(unsigned char key)
 sched_smt_power_savings? "enabled":"disabled");
 printk("NOW=%"PRI_stime"\n", now);
 
-print_cpumap("Online Cpus", &cpu_online_map);
+printk("Online Cpus: %*pbl\n", nr_cpu_ids, cpu_online_map.bits);
 if ( !cpumask_empty(&cpupool_free_cpus) )
 {
-print_cpumap("Free Cpus", &cpupool_free_cpus);
+printk("Free Cpus: %*pbl\n", nr_cpu_ids, cpupool_free_cpus.bits);
 schedule_dump(NULL);
 }
 
 for_each_cpupool(c)
 {
 printk("Cpupool %d:\n", (*c)->cpupool_id);
-print_cpumap("Cpus", (*c)->cpu_valid);
+printk("Cpus: %*pbl\n", nr_cpu_ids, (*c)->cpu_valid->bits);
 schedule_dump(*c);
 }
 
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 381f30e..f34d4f0 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1377,11 +1377,9 @@ static void domain_dump_evtchn_info(struct domain *d)
 unsigned int port;
 int irq;
 
-bitmap_scnlistprintf(keyhandler_scratch, sizeof(keyhandler_scratch),
- d->poll_mask, d->max_vcpus);
 printk("Event channel information for domain %d:\n"
-   "Polling vCPUs: {%s}\n"
-   "port [p/m/s]\n", d->domain_id, keyhandler_scratch);
+   "Polling vCPUs: {%*pbl}\n"
+   "port [p/m/s]\n", d->domain_id, d->max_vcpus, d->poll_mask);
 
 spin_lock(&d->event_lock);
 
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index 60bbeeb..4bb2643 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -250,22 +250,6 @@ static void reboot_machine(unsigned char key, struct 
cpu_user_regs *regs)
 machine_restart(0);
 }
 
-static void cpuset_print(char *set, int size, const cpumask_t *mask)
-{
-*set++ = '{';
-set += cpulist_scnprintf(set, size-2, mask);
-*set++ = '}';
-*set++ = '\0';
-}
-
-static void nodeset_print(char *set, int size, const nodemask_t *mask)
-{
-*set++ = '[';
-set += nodelist_scnprintf(set, size-2, mask);
-*set++ = ']';
-*set++ = '\0';
-}
-
 static void periodic_timer_print(char *str, int size, uint64_t period)
 {
 if ( period == 0 )
@@ -298,14 +282,14 @@ static void dump_domains(unsigned char key)
 process_pending_softirqs();
 
 printk("General information for domain %u:\n", d->domain_id);
-cpuset_print(tmpstr, sizeof(tmpstr), d->dirty_cpumask);
 printk("refcnt=%d dying=%d pause_count=%d\n",
atomic_read(&d->refcnt), d->is_dying,
atomic_read(&d->pause_count));
 printk("nr_pages=%d xenheap_pages=%d shared_pages=%u 
paged_pages=%u "
-   "dirty_cpus=%s max_pages=%u\n", d->tot_pages, d->xenheap_pages,
-atomic_read(&d->shr_pages), atomic_read(&d->paged_pages),
-tmpstr, d->max_pages);
+   "dirty_cpus={%*pbl} max_pages=%u\n",
+   d->tot_pages, d->xenheap_pages, atomic_read(&d->shr_pages),
+   atomic_read(&d->paged_pages), nr_cpu_ids, 
d->dirty_cpumask->bits,
+   d->max_pages);
 printk("handle=%02x%02x%02x%02x-%02x%02x-%02x%02x-"
"%02x%02x-%02x%02x%02x%02x%02x%02x vm_assist=%08lx\n",
d->handle[ 0], d->handle[ 1], d->handle[ 2], d->handle[ 3],
@@ -324,8 +308,8 @@ static void dump_domains(unsigned char key)
 
 dump_pageframe_info(d);
 
-nodeset_print(tmpstr, sizeof(tmpstr), &d->node_affinity);
-printk("NODE affinity for domain %d: %s\n", d->domain_id, tmpstr);
+printk("NODE affinity for domain %d: [%*pbl]\n",
+   d->domain_id, MAX_NUMNODES, d->node_affinity.bits);
 
 printk("VCPU information and callbacks for domain %u:\n",
d->domain_id);
@@ -343,10 +327,9 @@ static void dump_domains(unsi

[Xen-devel] [PATCH v2 3/5] xen/x86: Use %*pb[l] instead of cpumask_scn{, list}printf()

[Andrew Cooper]

This removes all use of keyhandler_scratch as a bounce-buffer for the rendered
string.

No functional change.

Signed-off-by: Andrew Cooper 
Reviewed-by: Wei Liu 
Reviewed-by: Jan Beulich 
---
v2:
 * Fix %pd typo
 * Use ->bits for cpumasks
---
 xen/arch/x86/cpu/mcheck/mce.c | 9 ++---
 xen/arch/x86/crash.c  | 7 ++-
 xen/arch/x86/irq.c| 7 ++-
 3 files changed, 10 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 1eec631..c4835be 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -535,9 +535,12 @@ void mcheck_cmn_handler(const struct cpu_user_regs *regs)
 mc_panic("MCE: No CPU found valid MCE, need reset");
 if ( !cpumask_empty(&mce_fatal_cpus) )
 {
-char *ebufp, ebuf[96] = "MCE: Fatal error happened on CPUs ";
-ebufp = ebuf + strlen(ebuf);
-cpumask_scnprintf(ebufp, 95 - strlen(ebuf), &mce_fatal_cpus);
+char ebuf[96];
+
+snprintf(ebuf, sizeof(ebuf),
+ "MCE: Fatal error happened on CPUs %*pb",
+ nr_cpu_ids, mce_fatal_cpus.bits);
+
 mc_panic(ebuf);
 }
 atomic_set(&found_error, 0);
diff --git a/xen/arch/x86/crash.c b/xen/arch/x86/crash.c
index 8d74258..81bb296 100644
--- a/xen/arch/x86/crash.c
+++ b/xen/arch/x86/crash.c
@@ -159,11 +159,8 @@ static void nmi_shootdown_cpus(void)
 if ( cpumask_empty(&waiting_to_crash) )
 printk("Shot down all CPUs\n");
 else
-{
-cpulist_scnprintf(keyhandler_scratch, sizeof keyhandler_scratch,
-  &waiting_to_crash);
-printk("Failed to shoot down CPUs {%s}\n", keyhandler_scratch);
-}
+printk("Failed to shoot down CPUs {%*pbl}\n",
+   nr_cpu_ids, waiting_to_crash.bits);
 
 /* Crash shutdown any IOMMU functionality as the crashdump kernel is not
  * happy when booting if interrupt/dma remapping is still enabled */
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 35e7de5..006bdc7 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -2302,11 +2302,8 @@ static void dump_irqs(unsigned char key)
 
 spin_lock_irqsave(&desc->lock, flags);
 
-cpumask_scnprintf(keyhandler_scratch, sizeof(keyhandler_scratch),
-  desc->affinity);
-printk("   IRQ:%4d affinity:%s vec:%02x type=%-15s"
-   " status=%08x ",
-   irq, keyhandler_scratch, desc->arch.vector,
+printk("   IRQ:%4d affinity:%*pb vec:%02x type=%-15s status=%08x ",
+   irq, nr_cpu_ids, desc->affinity->bits, desc->arch.vector,
desc->handler->typename, desc->status);
 
 if ( ssid )
-- 
2.1.4


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

[Xen-devel] [PATCH v2 0/5] xen: Use %*pb[l] for printing bitmaps

[Andrew Cooper]

I was trying to debug a cpumask problem, and got irritated with how awkard it
was to render and print the masks.  Luckily, the fix is quite simple and far
nicer to use.

The overall diffstat is to patch 4 is:

  add/remove: 0/4 grow/shrink: 2/11 up/down: 603/-1191 (-588)
  Function old new   delta
  vsnprintf   27753348+573
  dump_runq279 309 +30
  null_dump675 659 -16
  dump_irqs718 702 -16
  machine_crash_shutdown   594 570 -24
  csched_dump  527 503 -24
  rt_dump_vcpu.isra254 222 -32
  dump_evtchn_info 657 625 -32
  print_cpumap  55   - -55
  cpuset_print.constprop61   - -61
  csched_dump_pcpu 473 401 -72
  mcheck_cmn_handler  12241146 -78
  null_dump_pcpu   493 413 -80
  dump_domains11601064 -96
  csched2_dump15491389-160
  bitmap_scnprintf 193   --193
  bitmap_scnlistprintf 252   --252
  Total: Before=3295448, After=3294860, chg -0.02%

Only minor changes between this and v1.  See individual patches for details.

Andrew Cooper (5):
  xen/sched: Use %*pb[l] instead of cpumask_scn{,list}printf()
  xen/common: Use %*pb[l] instead of {cpu,node}mask_scn{,list}printf()
  xen/x86: Use %*pb[l] instead of cpumask_scn{,list}printf()
  xen/bitmap: Drop all bitmap_scn{,list}printf() infrastructure
  xen/keyhandler: Drop keyhandler_scratch

 xen/arch/x86/cpu/mcheck/mce.c |   9 ++--
 xen/arch/x86/crash.c  |   7 +--
 xen/arch/x86/irq.c|   7 +--
 xen/arch/x86/numa.c   |  11 ++---
 xen/common/bitmap.c   | 105 --
 xen/common/cpupool.c  |  12 ++---
 xen/common/efi/boot.c |   4 +-
 xen/common/event_channel.c|   6 +--
 xen/common/keyhandler.c   |  61 +++-
 xen/common/sched_credit.c |  17 ++-
 xen/common/sched_credit2.c|  27 ---
 xen/common/sched_null.c   |  15 ++
 xen/common/sched_rt.c |   5 +-
 xen/include/xen/bitmap.h  |   6 ---
 xen/include/xen/cpumask.h |  18 
 xen/include/xen/keyhandler.h  |   3 --
 xen/include/xen/nodemask.h|  34 --
 17 files changed, 59 insertions(+), 288 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH v2 1/5] xen/sched: Use %*pb[l] instead of cpumask_scn{, list}printf()

[Andrew Cooper]

This removes all use of keyhandler_scratch as a bounce-buffer for the rendered
string.  In some cases, collapse combine adjacent printk()'s which are writing
parts of the same line.

No functional change.

Signed-off-by: Andrew Cooper 
Acked-by: George Dunlap 
Acked-by: Dario Faggioli 
---
CC: Josh Whitehead 
CC: Robert VanVossen 
CC: Meng Xu 

v2:
 * Use ->bits for cpumasks
---
 xen/common/sched_credit.c  | 17 +
 xen/common/sched_credit2.c | 27 ++-
 xen/common/sched_null.c| 15 +--
 xen/common/sched_rt.c  |  5 ++---
 4 files changed, 22 insertions(+), 42 deletions(-)

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index 84e744b..4560ab6 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -2044,7 +2044,6 @@ csched_dump_pcpu(const struct scheduler *ops, int cpu)
 spinlock_t *lock;
 unsigned long flags;
 int loop;
-#define cpustr keyhandler_scratch
 
 /*
  * We need both locks:
@@ -2059,11 +2058,10 @@ csched_dump_pcpu(const struct scheduler *ops, int cpu)
 spc = CSCHED_PCPU(cpu);
 runq = &spc->runq;
 
-cpumask_scnprintf(cpustr, sizeof(cpustr), per_cpu(cpu_sibling_mask, cpu));
-printk("CPU[%02d] nr_run=%d, sort=%d, sibling=%s, ",
-   cpu, spc->nr_runnable, spc->runq_sort_last, cpustr);
-cpumask_scnprintf(cpustr, sizeof(cpustr), per_cpu(cpu_core_mask, cpu));
-printk("core=%s\n", cpustr);
+printk("CPU[%02d] nr_run=%d, sort=%d, sibling=%*pb, core=%*pb\n",
+   cpu, spc->nr_runnable, spc->runq_sort_last,
+   nr_cpu_ids, per_cpu(cpu_sibling_mask, cpu)->bits,
+   nr_cpu_ids, per_cpu(cpu_core_mask, cpu)->bits);
 
 /* current VCPU (nothing to say if that's the idle vcpu). */
 svc = CSCHED_VCPU(curr_on_cpu(cpu));
@@ -2086,7 +2084,6 @@ csched_dump_pcpu(const struct scheduler *ops, int cpu)
 
 pcpu_schedule_unlock(lock, cpu);
 spin_unlock_irqrestore(&prv->lock, flags);
-#undef cpustr
 }
 
 static void
@@ -2099,8 +2096,6 @@ csched_dump(const struct scheduler *ops)
 
 spin_lock_irqsave(&prv->lock, flags);
 
-#define idlers_buf keyhandler_scratch
-
 printk("info:\n"
"\tncpus  = %u\n"
"\tmaster = %u\n"
@@ -2127,8 +2122,7 @@ csched_dump(const struct scheduler *ops)
prv->ticks_per_tslice,
prv->vcpu_migr_delay/ MICROSECS(1));
 
-cpumask_scnprintf(idlers_buf, sizeof(idlers_buf), prv->idlers);
-printk("idlers: %s\n", idlers_buf);
+printk("idlers: %*pb\n", nr_cpu_ids, prv->idlers->bits);
 
 printk("active vcpus:\n");
 loop = 0;
@@ -2151,7 +2145,6 @@ csched_dump(const struct scheduler *ops)
 vcpu_schedule_unlock(lock, svc->vcpu);
 }
 }
-#undef idlers_buf
 
 spin_unlock_irqrestore(&prv->lock, flags);
 }
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 2b16bce..4adb6fc 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -3654,12 +3654,11 @@ dump_pcpu(const struct scheduler *ops, int cpu)
 {
 struct csched2_private *prv = csched2_priv(ops);
 struct csched2_vcpu *svc;
-#define cpustr keyhandler_scratch
 
-cpumask_scnprintf(cpustr, sizeof(cpustr), per_cpu(cpu_sibling_mask, cpu));
-printk("CPU[%02d] runq=%d, sibling=%s, ", cpu, c2r(cpu), cpustr);
-cpumask_scnprintf(cpustr, sizeof(cpustr), per_cpu(cpu_core_mask, cpu));
-printk("core=%s\n", cpustr);
+printk("CPU[%02d] runq=%d, sibling=%*pb, core=%*pb\n",
+   cpu, c2r(cpu),
+   nr_cpu_ids, per_cpu(cpu_sibling_mask, cpu)->bits,
+   nr_cpu_ids, per_cpu(cpu_core_mask, cpu)->bits);
 
 /* current VCPU (nothing to say if that's the idle vcpu) */
 svc = csched2_vcpu(curr_on_cpu(cpu));
@@ -3668,7 +3667,6 @@ dump_pcpu(const struct scheduler *ops, int cpu)
 printk("\trun: ");
 csched2_dump_vcpu(prv, svc);
 }
-#undef cpustr
 }
 
 static void
@@ -3678,7 +3676,6 @@ csched2_dump(const struct scheduler *ops)
 struct csched2_private *prv = csched2_priv(ops);
 unsigned long flags;
 unsigned int i, j, loop;
-#define cpustr keyhandler_scratch
 
 /*
  * We need the private scheduler lock as we access global
@@ -3696,29 +3693,26 @@ csched2_dump(const struct scheduler *ops)
 
 fraction = (prv->rqd[i].avgload * 100) >> prv->load_precision_shift;
 
-cpulist_scnprintf(cpustr, sizeof(cpustr), &prv->rqd[i].active);
 printk("Runqueue %d:\n"
"\tncpus  = %u\n"
-   "\tcpus   = %s\n"
+   "\tcpus   = %*pbl\n"
"\tmax_weight = %u\n"
"\tpick_bias  = %u\n"
"\tinstload   = %d\n"
"\taveload= %"PRI_stime" (~%"PRI_stime"%%)\n",
i,
cpumask_weight(&prv->rqd[i].active),
-   cpustr,
+   nr_cpu_ids, prv->rqd[i].active.

[Xen-devel] [PATCH v2 4/5] xen/bitmap: Drop all bitmap_scn{, list}printf() infrastructure

[Andrew Cooper]

All callers have been convered to using %*pb[l].  In the unlikely case that
future code wants to retain this functionaly, it can be replicated in a more
convenient fashon with snprintf().

Signed-off-by: Andrew Cooper 
Acked-by: Wei Liu 
Reviewed-by: Dario Faggioli 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: George Dunlap 
---
 xen/common/bitmap.c| 105 -
 xen/include/xen/bitmap.h   |   6 ---
 xen/include/xen/cpumask.h  |  18 
 xen/include/xen/nodemask.h |  34 ---
 4 files changed, 163 deletions(-)

diff --git a/xen/common/bitmap.c b/xen/common/bitmap.c
index f498ee6..34de387 100644
--- a/xen/common/bitmap.c
+++ b/xen/common/bitmap.c
@@ -300,111 +300,6 @@ int __bitmap_weight(const unsigned long *bitmap, int bits)
 #endif
 EXPORT_SYMBOL(__bitmap_weight);
 
-/*
- * Bitmap printing & parsing functions: first version by Bill Irwin,
- * second version by Paul Jackson, third by Joe Korty.
- */
-
-#define CHUNKSZ32
-#define nbits_to_hold_value(val)   fls(val)
-#define roundup_power2(val,modulus)(((val) + (modulus) - 1) & ~((modulus) 
- 1))
-#define unhex(c)   (isdigit(c) ? (c - '0') : (toupper(c) - 
'A' + 10))
-#define BASEDEC 10 /* fancier cpuset lists input in decimal */
-
-/**
- * bitmap_scnprintf - convert bitmap to an ASCII hex string.
- * @buf: byte buffer into which string is placed
- * @buflen: reserved size of @buf, in bytes
- * @maskp: pointer to bitmap to convert
- * @nmaskbits: size of bitmap, in bits
- *
- * Exactly @nmaskbits bits are displayed.  Hex digits are grouped into
- * comma-separated sets of eight digits per set.
- */
-int bitmap_scnprintf(char *buf, unsigned int buflen,
-   const unsigned long *maskp, int nmaskbits)
-{
-   int i, word, bit, len = 0;
-   unsigned long val;
-   const char *sep = "";
-   int chunksz;
-   u32 chunkmask;
-
-   chunksz = nmaskbits & (CHUNKSZ - 1);
-   if (chunksz == 0)
-   chunksz = CHUNKSZ;
-
-   i = roundup_power2(nmaskbits, CHUNKSZ) - CHUNKSZ;
-   for (; i >= 0; i -= CHUNKSZ) {
-   chunkmask = ((1ULL << chunksz) - 1);
-   word = i / BITS_PER_LONG;
-   bit = i % BITS_PER_LONG;
-   val = (maskp[word] >> bit) & chunkmask;
-   len += scnprintf(buf+len, buflen-len, "%s%0*lx", sep,
-   (chunksz+3)/4, val);
-   chunksz = CHUNKSZ;
-   sep = ",";
-   }
-   return len;
-}
-EXPORT_SYMBOL(bitmap_scnprintf);
-
-/*
- * bscnl_emit(buf, buflen, rbot, rtop, bp)
- *
- * Helper routine for bitmap_scnlistprintf().  Write decimal number
- * or range to buf, suppressing output past buf+buflen, with optional
- * comma-prefix.  Return len of what would be written to buf, if it
- * all fit.
- */
-static inline int bscnl_emit(char *buf, int buflen, int rbot, int rtop, int 
len)
-{
-   if (len > 0)
-   len += scnprintf(buf + len, buflen - len, ",");
-   if (rbot == rtop)
-   len += scnprintf(buf + len, buflen - len, "%d", rbot);
-   else
-   len += scnprintf(buf + len, buflen - len, "%d-%d", rbot, rtop);
-   return len;
-}
-
-/**
- * bitmap_scnlistprintf - convert bitmap to list format ASCII string
- * @buf: byte buffer into which string is placed
- * @buflen: reserved size of @buf, in bytes
- * @maskp: pointer to bitmap to convert
- * @nmaskbits: size of bitmap, in bits
- *
- * Output format is a comma-separated list of decimal numbers and
- * ranges.  Consecutively set bits are shown as two hyphen-separated
- * decimal numbers, the smallest and largest bit numbers set in
- * the range.  Output format is compatible with the format
- * accepted as input by bitmap_parselist().
- *
- * The return value is the number of characters which were output,
- * excluding the trailing '\0'.
- */
-int bitmap_scnlistprintf(char *buf, unsigned int buflen,
-   const unsigned long *maskp, int nmaskbits)
-{
-   int len = 0;
-   /* current bit is 'cur', most recently seen range is [rbot, rtop] */
-   int cur, rbot, rtop;
-
-   rbot = cur = find_first_bit(maskp, nmaskbits);
-   while (cur < nmaskbits) {
-   rtop = cur;
-   cur = find_next_bit(maskp, nmaskbits, cur+1);
-   if (cur >= nmaskbits || cur > rtop + 1) {
-   len = bscnl_emit(buf, buflen, rbot, rtop, len);
-   rbot = cur;
-   }
-   }
-   if (!len && buflen)
-   *buf = 0;
-   return len;
-}
-EXPORT_SYMBOL(bitmap_scnlistprintf);
 
 /**
  * bitmap_find_free_region - find a contiguous aligned mem region
diff --git a/xen/include/xen/bitmap.h b/xen/include/xen/bitmap.h
index e2a3686..fe3c720 100644
--- a/xen/include/xen/bitmap.h
+++ b/xen/include/xen/bitmap.h
@@ -40,8 +40,6 @@
  * bitmap_weight(src, nbits) 

[Xen-devel] [qemu-mainline test] 128910: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 128873
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 128873
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 128873
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 128873
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 128873
 test-amd64-i386-xl-pvshim12 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-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-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-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail 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-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  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-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 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-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-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-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  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

version targeted for testing:
 qemuu31e213e30617b986a6e8ab4d9a0646eb4e6a4227
baseline version:
 qemuu77f7c747193662edfadeeb3118d63eed0eac51a6

Last test of basis   128873  2018-10-19 02:21:44 Z3 days
Testing same since   128910  2018-10-20 21:56:47 Z1 days1 attempts


People who touched revisions under test:
  Aleksandar Markovic 
  Alex Bennée 
  Dimitrije Nikolic 
  Emilio G. Cota 
  Fredrik Noring 
  Jason Wang 
  Laurent Vivier 
  Li Zhijian 
  liujunjie 
  Martin Wilck 
  Matthew Fortune 
  Peter Maydell 
  Philippe Mathieu-Daudé 
  Richard Henderson 
  Stefan Markovic 
  Thomas Huth 
  Yongbok Kim 
  Zhang Chen 
  Zhang Chen 
  zhanghailiang 

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

Re: [Xen-devel] per-domain configuration and inappropriate use of globals

[Andrew Cooper]

On 19/10/18 19:22, Juergen Gross wrote:
> On 19/10/2018 18:57, Andrew Cooper wrote:
>> In practice, having fine grain control of all the features like would be
>> excellent for testing purposes, because it allows you to boot two
>> otherwise-identical VMs with one configuration difference between them.
>>
>> In the spirit of the already in progress domaincreate work, options like
>> these should be selectable at domain creation time, and immutable
>> thereafter.
>>
>> That said, there is a plethora of tweakables, and I'm not sure how best
>> to expose them.  While most (all?) of these options are inherently
>> supported (as playing with them simulates what Xen would chose on
>> different hardware), I expect there will be ample opportunity for people
>> to break their systems if they tweak too much.
>>
>> Is there liable to be any provision in xl/libxl to have "unstable"
>> configuration, which is easily identified as "may stop working / cease
>> to exist / become invalid at any point in the future?"
>>
>> Alternatively, are there any other suggestions for alternative mechanisms?
> Per-domain parameters like in my series? You could guard the "dangerous"
> ones by a global parameter (boot-time or run-time settable).

I was hoping to separate the discussion of what information should be
configurable, from the mechanism we used to provide said information.

Using a text-based mechanism suffers from the same stable/unstable
issues as xl.cfg, so the same concern applies there.

(Also, I have a separate uneasy feeling about having yet more string
parsing in the hypervisor, but that is definitely unrelated).

~Andrew

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

[Xen-devel] [PATCH] arm: fix Dom0 creation after ef72c93df9

[Wei Liu]

ARM Dom0 creation was broken by the said commit because ARM neither
provided XEN_DOMCTL_CDF_hvm_guest nor had CONFIG_PV set.

Set XEN_DOMCTL_CDF_hvm_guest flag for ARM Dom0 to fix the issue. Also
set XEN_DOMCTL_CDF_hap while at it.

Signed-off-by: Wei Liu 
---
 xen/arch/arm/setup.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index ea2495a73b..80f00286d3 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -693,6 +693,7 @@ void __init start_xen(unsigned long boot_phys_offset,
 struct bootmodule *xen_bootmodule;
 struct domain *dom0;
 struct xen_domctl_createdomain dom0_cfg = {
+.flags = XEN_DOMCTL_CDF_hvm_guest | XEN_DOMCTL_CDF_hap,
 .max_evtchn_port = -1,
 .max_grant_frames = gnttab_dom0_frames(),
 .max_maptrack_frames = opt_max_maptrack_frames,
-- 
2.11.0


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

Re: [Xen-devel] [PATCH] arm: fix Dom0 creation after ef72c93df9

[Andrew Cooper]

On 22/10/18 14:40, Wei Liu wrote:
> ARM Dom0 creation was broken by the said commit because ARM neither
> provided XEN_DOMCTL_CDF_hvm_guest nor had CONFIG_PV set.
>
> Set XEN_DOMCTL_CDF_hvm_guest flag for ARM Dom0 to fix the issue. Also
> set XEN_DOMCTL_CDF_hap while at it.
>
> Signed-off-by: Wei Liu 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH] arm: fix Dom0 creation after ef72c93df9

[Julien Grall]

Hi Wei,

On 10/22/18 2:40 PM, Wei Liu wrote:

ARM Dom0 creation was broken by the said commit because ARM neither
provided XEN_DOMCTL_CDF_hvm_guest nor had CONFIG_PV set.

Set XEN_DOMCTL_CDF_hvm_guest flag for ARM Dom0 to fix the issue. Also
set XEN_DOMCTL_CDF_hap while at it.

Signed-off-by: Wei Liu 


Acked-by: Julien Grall 

Cheers,

--
Julien Grall

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

[Xen-devel] [ovmf baseline-only test] 75476: trouble: blocked/broken

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 75476 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75476/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm  broken
 build-i386   broken
 build-amd64-pvopsbroken
 build-i386-xsm   broken
 build-amd64  broken
 build-i386-pvops broken

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 build-i3864 host-install(4)   broken baseline untested
 build-amd64   4 host-install(4)   broken baseline untested
 build-i386-pvops  4 host-install(4)   broken baseline untested
 build-i386-xsm4 host-install(4)   broken baseline untested
 build-amd64-pvops 4 host-install(4)   broken baseline untested
 build-amd64-xsm   4 host-install(4)   broken baseline untested

version targeted for testing:
 ovmf 95aea2fac9117e95ead90378e6bb975e327d7da4
baseline version:
 ovmf 2c65efac570f14633c5001ce484dbffb8a11994a

Last test of basis75472  2018-10-21 19:22:49 Z0 days
Testing same since75476  2018-10-22 05:50:16 Z0 days1 attempts


People who touched revisions under test:
  Jiaxin Wu 
  Wu Jiaxin 

jobs:
 build-amd64-xsm  broken  
 build-i386-xsm   broken  
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



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.xensource.com/osstest/logs

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

broken-job build-amd64-xsm broken
broken-job build-i386 broken
broken-job build-amd64-pvops broken
broken-job build-i386-xsm broken
broken-job build-amd64 broken
broken-job build-i386-pvops broken
broken-step build-i386 host-install(4)
broken-step build-amd64 host-install(4)
broken-step build-i386-pvops host-install(4)
broken-step build-i386-xsm host-install(4)
broken-step build-amd64-pvops host-install(4)
broken-step build-amd64-xsm host-install(4)

Push not applicable.


commit 95aea2fac9117e95ead90378e6bb975e327d7da4
Author: Jiaxin Wu 
Date:   Fri Oct 12 16:00:57 2018 +0800

NetworkPkg/IpSecDxe: Fix issue to parse SA Payload.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1251

*v2: Correct the type of parameters in Ikev2ParseProposalData(), and refined
the corresponding description.

IpSecDxe failed to create the Child SA during parsing SA Payload, the issue
was caused by the below commit:

SHA-1: 1e0db7b11987d0ec93be7dfe26102a327860fdbd
* MdeModulePkg/NetworkPkg: Checking for NULL pointer before use.

In above commit, it changed the value of IsMatch in 
Ikev2ChildSaParseSaPayload()
to FALSE. That's correct but it exposed the potential bug in to match the 
correct
proposal Data, which will cause the issue happen.

Cc: Fu Siyuan 
Cc: Ye Ting 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Wu Jiaxin 
Reviewed-by: Ye Ting 

commit ddc6d41d128c57dec8e79a0ad1eae7a80ec0280b
Author: Jiaxin Wu 
Date:   Tue Oct 16 13:34:00 2018 +0800

NetworkPkg: Correct the time stamp and fix the integer overflow issue.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=883.

Cc: Fu Siyuan 
Cc: Ye Ting 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Wu Jiaxin 
Reviewed-by: Ye Ting 

commit 1682cc9353ecf688aa928fa102280c1d807ba3c5
Author: Jiaxin Wu 
Date:   Tue Oct 16 09:52:13 2018 +0800

NetworkPkg/Tl

Re: [Xen-devel] [PATCH 2/9] accel: register global_props like machine globals

[Igor Mammedov]

On Wed, 12 Sep 2018 16:55:24 +0400
Marc-André Lureau  wrote:

> global_props is only used for Xen xen_compat_props. It's a static
minor nit:
should be AccelClass::global_props

> array of GlobalProperty, like machine globals in SET_MACHINE_COMPAT().
> Let's register the globals the same way, without extra copy allocation.
> 
> Signed-off-by: Marc-André Lureau 
otherwise looks good to me, CCing xen folks since it concerns them.

Reviewed-by: Igor Mammedov 


> ---
>  include/hw/qdev-properties.h | 29 -
>  accel/accel.c|  9 -
>  hw/core/qdev-properties.c| 21 -
>  3 files changed, 8 insertions(+), 51 deletions(-)
> 
> diff --git a/include/hw/qdev-properties.h b/include/hw/qdev-properties.h
> index 4f60cc88f3..a95f4a73eb 100644
> --- a/include/hw/qdev-properties.h
> +++ b/include/hw/qdev-properties.h
> @@ -255,35 +255,6 @@ void qdev_prop_set_globals(DeviceState *dev);
>  void error_set_from_qdev_prop_error(Error **errp, int ret, DeviceState *dev,
>  Property *prop, const char *value);
>  
> -/**
> - * register_compat_prop:
> - *
> - * Register internal (not user-provided) global property, changing the
> - * default value of a given property in a device type.  This can be used
> - * for enabling machine-type compatibility or for enabling
> - * accelerator-specific defaults in devices.
> - *
> - * The property values set using this function must be always valid and
> - * never report setter errors, as the property will have
> - * GlobalProperty::errp set to &error_abort.
> - *
> - * User-provided global properties should override internal global
> - * properties, so callers of this function should ensure that it is
> - * called before user-provided global properties are registered.
> - *
> - * @driver: Device type to be affected
> - * @property: Property whose default value is going to be changed
> - * @value: New default value for the property
> - */
> -void register_compat_prop(const char *driver, const char *property,
> -  const char *value);
> -/*
> - * register_compat_props_array(): using register_compat_prop(), which
> - * only registers internal global properties (which has lower priority
> - * than user-provided global properties)
> - */
> -void register_compat_props_array(GlobalProperty *prop);
> -
>  /**
>   * qdev_property_add_static:
>   * @dev: Device to add the property to.
> diff --git a/accel/accel.c b/accel/accel.c
> index 966b2d8f53..3da26eb90f 100644
> --- a/accel/accel.c
> +++ b/accel/accel.c
> @@ -34,6 +34,7 @@
>  #include "qom/object.h"
>  #include "qemu/error-report.h"
>  #include "qemu/option.h"
> +#include "qapi/error.h"
>  
>  static const TypeInfo accel_type = {
>  .name = TYPE_ACCEL,
> @@ -121,7 +122,13 @@ void configure_accelerator(MachineState *ms)
>  void accel_register_compat_props(AccelState *accel)
>  {
>  AccelClass *class = ACCEL_GET_CLASS(accel);
> -register_compat_props_array(class->global_props);
> +GlobalProperty *prop = class->global_props;
> +
> +for (; prop && prop->driver; prop++) {
> +/* Any compat_props must never cause error */
> +prop->errp = &error_abort;
> +qdev_prop_register_global(prop);
> +}
>  }
>  
>  void accel_setup_post(MachineState *ms)
> diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c
> index 35072dec1e..ab61d502fd 100644
> --- a/hw/core/qdev-properties.c
> +++ b/hw/core/qdev-properties.c
> @@ -1180,27 +1180,6 @@ void qdev_prop_register_global(GlobalProperty *prop)
>  global_props = g_list_append(global_props, prop);
>  }
>  
> -void register_compat_prop(const char *driver,
> -  const char *property,
> -  const char *value)
> -{
> -GlobalProperty *p = g_new0(GlobalProperty, 1);
> -
> -/* Any compat_props must never cause error */
> -p->errp = &error_abort;
> -p->driver = driver;
> -p->property = property;
> -p->value = value;
> -qdev_prop_register_global(p);
> -}
> -
> -void register_compat_props_array(GlobalProperty *prop)
> -{
> -for (; prop && prop->driver; prop++) {
> -register_compat_prop(prop->driver, prop->property, prop->value);
> -}
> -}
> -
>  void qdev_prop_register_global_list(GlobalProperty *props)
>  {
>  int i;


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

Re: [Xen-devel] Ongoing/future speculative mitigation work

[Wei Liu]

On Thu, Oct 18, 2018 at 06:46:22PM +0100, Andrew Cooper wrote:
> Hello,
> 
> This is an accumulation and summary of various tasks which have been
> discussed since the revelation of the speculative security issues in
> January, and also an invitation to discuss alternative ideas.  They are
> x86 specific, but a lot of the principles are architecture-agnostic.
> 
> 1) A secrets-free hypervisor.
> 
> Basically every hypercall can be (ab)used by a guest, and used as an
> arbitrary cache-load gadget.  Logically, this is the first half of a
> Spectre SP1 gadget, and is usually the first stepping stone to
> exploiting one of the speculative sidechannels.
> 
> Short of compiling Xen with LLVM's Speculative Load Hardening (which is
> still experimental, and comes with a ~30% perf hit in the common case),
> this is unavoidable.  Furthermore, throwing a few array_index_nospec()
> into the code isn't a viable solution to the problem.
> 
> An alternative option is to have less data mapped into Xen's virtual
> address space - if a piece of memory isn't mapped, it can't be loaded
> into the cache.
> 
> An easy first step here is to remove Xen's directmap, which will mean
> that guests general RAM isn't mapped by default into Xen's address
> space.  This will come with some performance hit, as the
> map_domain_page() infrastructure will now have to actually
> create/destroy mappings, but removing the directmap will cause an
> improvement for non-speculative security as well (No possibility of
> ret2dir as an exploit technique).

I have looked into making the "separate xenheap domheap with partial
direct map" mode (see common/page_alloc.c) work but found it not as
straight forward as it should've been.

Before I spend more time on this, I would like some opinions on if there
is other approach which might be more useful than that mode.

> 
> Beyond the directmap, there are plenty of other interesting secrets in
> the Xen heap and other mappings, such as the stacks of the other pcpus. 
> Fixing this requires moving Xen to having a non-uniform memory layout,
> and this is much harder to change.  I already experimented with this as
> a meltdown mitigation around about a year ago, and posted the resulting
> series on Jan 4th,
> https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg00274.html,
> some trivial bits of which have already found their way upstream.
> 
> To have a non-uniform memory layout, Xen may not share L4 pagetables. 
> i.e. Xen must never have two pcpus which reference the same pagetable in
> %cr3.
> 
> This property already holds for 32bit PV guests, and all HVM guests, but
> 64bit PV guests are the sticking point.  Because Linux has a flat memory
> layout, when a 64bit PV guest schedules two threads from the same
> process on separate vcpus, those two vcpus have the same virtual %cr3,
> and currently, Xen programs the same real %cr3 into hardware.

Which bit of Linux code are you referring to? If you remember it off the
top of your head, it would save me some time digging around. If not,
never mind, I can look it up myself.

> 
> If we want Xen to have a non-uniform layout, are two options are:
> * Fix Linux to have the same non-uniform layout that Xen wants
> (Backwards compatibility for older 64bit PV guests can be achieved with
> xen-shim).
> * Make use XPTI algorithm (specifically, the pagetable sync/copy part)
> forever more in the future.
> 
> Option 2 isn't great (especially for perf on fixed hardware), but does
> keep all the necessary changes in Xen.  Option 1 looks to be the better
> option longterm.

What is the problem with 1+2 at the same time? I think XPTI can be
enabled / disabled on a per-guest basis?

Wei.

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

Re: [Xen-devel] Xen optimization

[Milan Boberic]

Hi,

> I think we want to fully understand how many other interrupts the
> baremetal guest is receiving. To do that, we can modify my previous
> patch to suppress any debug messages for virq=68. That way, we should
> only see the other interrupts. Ideally there would be none.
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 5a4f082..b7a8e17 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -577,7 +577,11 @@ void vgic_inject_irq(struct domain *d, struct vcpu *v, 
> unsigned int virq,
>  /* the irq is enabled */
>  if ( test_bit(GIC_IRQ_GUEST_ENABLED, &n->status) )
> +{
>  gic_raise_guest_irq(v, virq, priority);
> +if ( d->domain_id != 0 && virq != 68 )
> +printk("DEBUG virq=%d local=%d\n",virq,v == current);
> +}
>  list_for_each_entry ( iter, &v->arch.vgic.inflight_irqs, inflight )
>  {

when I apply this patch there are no prints nor debug messages in xl
dmesg. So bare-metal receives only interrupt 68, which is good.

> Next step would be to verify that there are no other physical interrupts
> interrupting the vcpu execution other the irq=68. We should be able to
> check that with the following debug patch:
>
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index e524ad5..b34c3e4 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -381,6 +381,13 @@ void gic_interrupt(struct cpu_user_regs *regs, int 
> is_fiq)
>  /* Reading IRQ will ACK it */
>  irq = gic_hw_ops->read_irq();
> +if (current->domain->domain_id > 0 && irq != 68)
> +{
> +local_irq_enable();
> +printk("DEBUG irq=%d\n",irq);
> +local_irq_disable();
> +}
> +
>  if ( likely(irq >= 16 && irq < 1020) )
>  {
>  local_irq_enable();

But when I apply this patch it prints forever:
(XEN) DEBUG irq=1023

Thanks in advance!

Milan

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

Re: [Xen-devel] Ongoing/future speculative mitigation work

[Woodhouse, David]

Adding Stefan to Cc.

Should we take this to the spexen or another mailing list?


On Mon, 2018-10-22 at 15:55 +0100, Wei Liu wrote:
> On Thu, Oct 18, 2018 at 06:46:22PM +0100, Andrew Cooper wrote:
> > Hello,
> > 
> > This is an accumulation and summary of various tasks which have been
> > discussed since the revelation of the speculative security issues in
> > January, and also an invitation to discuss alternative ideas.  They are
> > x86 specific, but a lot of the principles are architecture-agnostic.
> > 
> > 1) A secrets-free hypervisor.
> > 
> > Basically every hypercall can be (ab)used by a guest, and used as an
> > arbitrary cache-load gadget.  Logically, this is the first half of a
> > Spectre SP1 gadget, and is usually the first stepping stone to
> > exploiting one of the speculative sidechannels.
> > 
> > Short of compiling Xen with LLVM's Speculative Load Hardening (which is
> > still experimental, and comes with a ~30% perf hit in the common case),
> > this is unavoidable.  Furthermore, throwing a few array_index_nospec()
> > into the code isn't a viable solution to the problem.
> > 
> > An alternative option is to have less data mapped into Xen's virtual
> > address space - if a piece of memory isn't mapped, it can't be loaded
> > into the cache.
> > 
> > An easy first step here is to remove Xen's directmap, which will mean
> > that guests general RAM isn't mapped by default into Xen's address
> > space.  This will come with some performance hit, as the
> > map_domain_page() infrastructure will now have to actually
> > create/destroy mappings, but removing the directmap will cause an
> > improvement for non-speculative security as well (No possibility of
> > ret2dir as an exploit technique).
> 
> I have looked into making the "separate xenheap domheap with partial
> direct map" mode (see common/page_alloc.c) work but found it not as
> straight forward as it should've been.
> 
> Before I spend more time on this, I would like some opinions on if there
> is other approach which might be more useful than that mode.
> 
> > 
> > Beyond the directmap, there are plenty of other interesting secrets in
> > the Xen heap and other mappings, such as the stacks of the other pcpus. 
> > Fixing this requires moving Xen to having a non-uniform memory layout,
> > and this is much harder to change.  I already experimented with this as
> > a meltdown mitigation around about a year ago, and posted the resulting
> > series on Jan 4th,
> > https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg00274.html,
> > some trivial bits of which have already found their way upstream.
> > 
> > To have a non-uniform memory layout, Xen may not share L4 pagetables. 
> > i.e. Xen must never have two pcpus which reference the same pagetable in
> > %cr3.
> > 
> > This property already holds for 32bit PV guests, and all HVM guests, but
> > 64bit PV guests are the sticking point.  Because Linux has a flat memory
> > layout, when a 64bit PV guest schedules two threads from the same
> > process on separate vcpus, those two vcpus have the same virtual %cr3,
> > and currently, Xen programs the same real %cr3 into hardware.
> 
> Which bit of Linux code are you referring to? If you remember it off the
> top of your head, it would save me some time digging around. If not,
> never mind, I can look it up myself.
> 
> > 
> > If we want Xen to have a non-uniform layout, are two options are:
> > * Fix Linux to have the same non-uniform layout that Xen wants
> > (Backwards compatibility for older 64bit PV guests can be achieved with
> > xen-shim).
> > * Make use XPTI algorithm (specifically, the pagetable sync/copy part)
> > forever more in the future.
> > 
> > Option 2 isn't great (especially for perf on fixed hardware), but does
> > keep all the necessary changes in Xen.  Option 1 looks to be the better
> > option longterm.
> 
> What is the problem with 1+2 at the same time? I think XPTI can be
> enabled / disabled on a per-guest basis?
> 
> Wei.



smime.p7s
Description: S/MIME cryptographic signature



Amazon Development Centre (London) Ltd. Registered in England and Wales with 
registration number 04543232 with its registered office at 1 Principal Place, 
Worship Street, London EC2A 2FA, United Kingdom.


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

Re: [Xen-devel] Ongoing/future speculative mitigation work

[Andrew Cooper]

On 22/10/18 16:09, Woodhouse, David wrote:
> Adding Stefan to Cc.
>
> Should we take this to the spexen or another mailing list?

Now that L1TF is public, so is all of this.  I see no reason to continue
it in private.

~Andrew

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

[Xen-devel] [PATCH 2/2] automation: build with Ubuntu 18.04

[Wei Liu]

Signed-off-by: Wei Liu 
---
 .gitlab-ci.yml | 32 
 1 file changed, 32 insertions(+)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index bf6bf7d895..96d7e7f759 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -269,3 +269,35 @@ ubuntu-xenial-gcc-debug:
 CONTAINER: ubuntu:xenial
 debug: y
 XEN_TARGET_ARCH: x86_64
+
+ubuntu-bionic-clang:
+  <<: *build
+  variables:
+<<: *clang
+CONTAINER: ubuntu:bionic
+debug: n
+XEN_TARGET_ARCH: x86_64
+
+ubuntu-bionic-clang-debug:
+  <<: *build
+  variables:
+<<: *clang
+CONTAINER: ubuntu:bionic
+debug: y
+XEN_TARGET_ARCH: x86_64
+
+ubuntu-bionic-gcc:
+  <<: *build
+  variables:
+<<: *gcc
+CONTAINER: ubuntu:bionic
+debug: n
+XEN_TARGET_ARCH: x86_64
+
+ubuntu-bionic-gcc-debug:
+  <<: *build
+  variables:
+<<: *gcc
+CONTAINER: ubuntu:bionic
+debug: y
+XEN_TARGET_ARCH: x86_64
-- 
2.11.0


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

[Xen-devel] [PATCH 2/2] automation: build with Ubuntu 18.04

[Wei Liu]

Signed-off-by: Wei Liu 
---
 .gitlab-ci.yml | 32 
 1 file changed, 32 insertions(+)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index bf6bf7d895..96d7e7f759 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -269,3 +269,35 @@ ubuntu-xenial-gcc-debug:
 CONTAINER: ubuntu:xenial
 debug: y
 XEN_TARGET_ARCH: x86_64
+
+ubuntu-bionic-clang:
+  <<: *build
+  variables:
+<<: *clang
+CONTAINER: ubuntu:bionic
+debug: n
+XEN_TARGET_ARCH: x86_64
+
+ubuntu-bionic-clang-debug:
+  <<: *build
+  variables:
+<<: *clang
+CONTAINER: ubuntu:bionic
+debug: y
+XEN_TARGET_ARCH: x86_64
+
+ubuntu-bionic-gcc:
+  <<: *build
+  variables:
+<<: *gcc
+CONTAINER: ubuntu:bionic
+debug: n
+XEN_TARGET_ARCH: x86_64
+
+ubuntu-bionic-gcc-debug:
+  <<: *build
+  variables:
+<<: *gcc
+CONTAINER: ubuntu:bionic
+debug: y
+XEN_TARGET_ARCH: x86_64
-- 
2.11.0


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

[Xen-devel] [PATCH 1/2] automation: add dockerfile for Ubuntu 18.04

[Wei Liu]

Signed-off-by: Wei Liu 
---
 automation/build/ubuntu/bionic.dockerfile | 48 +++
 1 file changed, 48 insertions(+)
 create mode 100644 automation/build/ubuntu/bionic.dockerfile

diff --git a/automation/build/ubuntu/bionic.dockerfile 
b/automation/build/ubuntu/bionic.dockerfile
new file mode 100644
index 00..8de67ef14e
--- /dev/null
+++ b/automation/build/ubuntu/bionic.dockerfile
@@ -0,0 +1,48 @@
+FROM ubuntu:18.04
+LABEL maintainer.name="The Xen Project " \
+  maintainer.email="xen-devel@lists.xenproject.org"
+
+ENV DEBIAN_FRONTEND=noninteractive
+ENV USER root
+
+RUN mkdir /build
+WORKDIR /build
+
+# build depends
+RUN apt-get update && \
+apt-get --quiet --yes install \
+build-essential \
+zlib1g-dev \
+libncurses5-dev \
+libssl-dev \
+python2.7-dev \
+xorg-dev \
+uuid-dev \
+libyajl-dev \
+libaio-dev \
+libglib2.0-dev \
+clang \
+libpixman-1-dev \
+pkg-config \
+flex \
+bison \
+gettext \
+acpica-tools \
+bin86 \
+bcc \
+liblzma-dev \
+libc6-dev-i386 \
+libnl-3-dev \
+ocaml-nox \
+libfindlib-ocaml-dev \
+markdown \
+transfig \
+pandoc \
+checkpolicy \
+wget \
+git \
+nasm \
+&& \
+apt-get autoremove -y && \
+apt-get clean && \
+rm -rf /var/lib/apt/lists* /tmp/* /var/tmp/*
-- 
2.11.0


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

[Xen-devel] [PATCH 0/2] automation: build with Ubuntu 18.04

[Wei Liu]

Wei Liu (2):
  automation: add dockerfile for Ubuntu 18.04
  automation: build with Ubuntu 18.04

 .gitlab-ci.yml| 32 +
 automation/build/ubuntu/bionic.dockerfile | 48 +++
 2 files changed, 80 insertions(+)
 create mode 100644 automation/build/ubuntu/bionic.dockerfile

-- 
2.11.0


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

[Xen-devel] [PATCH 0/2] automation: build with Ubuntu 18.04

[Wei Liu]

Wei Liu (2):
  automation: add dockerfile for Ubuntu 18.04
  automation: build with Ubuntu 18.04

 .gitlab-ci.yml| 32 +
 automation/build/ubuntu/bionic.dockerfile | 48 +++
 2 files changed, 80 insertions(+)
 create mode 100644 automation/build/ubuntu/bionic.dockerfile

-- 
2.11.0


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

[Xen-devel] [PATCH 1/2] automation: add dockerfile for Ubuntu 18.04

[Wei Liu]

Signed-off-by: Wei Liu 
---
 automation/build/ubuntu/bionic.dockerfile | 48 +++
 1 file changed, 48 insertions(+)
 create mode 100644 automation/build/ubuntu/bionic.dockerfile

diff --git a/automation/build/ubuntu/bionic.dockerfile 
b/automation/build/ubuntu/bionic.dockerfile
new file mode 100644
index 00..8de67ef14e
--- /dev/null
+++ b/automation/build/ubuntu/bionic.dockerfile
@@ -0,0 +1,48 @@
+FROM ubuntu:18.04
+LABEL maintainer.name="The Xen Project " \
+  maintainer.email="xen-devel@lists.xenproject.org"
+
+ENV DEBIAN_FRONTEND=noninteractive
+ENV USER root
+
+RUN mkdir /build
+WORKDIR /build
+
+# build depends
+RUN apt-get update && \
+apt-get --quiet --yes install \
+build-essential \
+zlib1g-dev \
+libncurses5-dev \
+libssl-dev \
+python2.7-dev \
+xorg-dev \
+uuid-dev \
+libyajl-dev \
+libaio-dev \
+libglib2.0-dev \
+clang \
+libpixman-1-dev \
+pkg-config \
+flex \
+bison \
+gettext \
+acpica-tools \
+bin86 \
+bcc \
+liblzma-dev \
+libc6-dev-i386 \
+libnl-3-dev \
+ocaml-nox \
+libfindlib-ocaml-dev \
+markdown \
+transfig \
+pandoc \
+checkpolicy \
+wget \
+git \
+nasm \
+&& \
+apt-get autoremove -y && \
+apt-get clean && \
+rm -rf /var/lib/apt/lists* /tmp/* /var/tmp/*
-- 
2.11.0


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

Re: [Xen-devel] [PATCH 0/2] automation: build with Ubuntu 18.04

[Wei Liu]

On Mon, Oct 22, 2018 at 04:18:49PM +0100, Wei Liu wrote:
> Wei Liu (2):
>   automation: add dockerfile for Ubuntu 18.04
>   automation: build with Ubuntu 18.04

This is duplicate. Please ignore.

Wei.

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

[Xen-devel] [xen-unstable-smoke test] 128934: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-xl-xsm   7 xen-boot fail REGR. vs. 128884
 test-armhf-armhf-xl   7 xen-boot fail REGR. vs. 128884
 test-amd64-amd64-xl-qemuu-debianhvm-i386 16 guest-localmigrate/x10 fail REGR. 
vs. 128884

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

version targeted for testing:
 xen  8cd9500958d818e3deabdd0d4164ea6fe1623d7c
baseline version:
 xen  62aa9e7f1b8ef64b8c7c1dacb1122351cb9fd132

Last test of basis   128884  2018-10-19 20:00:41 Z2 days
Failing since128931  2018-10-22 10:00:40 Z0 days2 attempts
Testing same since   128934  2018-10-22 13:00:44 Z0 days1 attempts


People who touched revisions under test:
  
  Andrew Cooper 
  Wei Liu 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  fail
 test-arm64-arm64-xl-xsm  fail
 test-amd64-amd64-xl-qemuu-debianhvm-i386 fail
 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


Not pushing.


commit 8cd9500958d818e3deabdd0d4164ea6fe1623d7c
Author: Andrew Cooper 
Date:   Thu Sep 6 10:25:59 2018 +

xen/vsprintf: Introduce %*pb[l] for printing bitmaps

The format identifier is consistent with Linux.  The code is adapted from
bitmap_scn{,list}printf() but cleaned up.

This change allows all callers to avoid needing a secondary buffer to 
render a
cpumask/nodemask into.

Signed-off-by: Andrew Cooper 
Acked-by: Wei Liu 
Acked-by: 

commit 3528426cb93948e440da947963bd8163f186ef67
Author: Wei Liu 
Date:   Fri Oct 19 15:28:36 2018 +0100

x86: don't setup legacy syscall vector when !CONFIG_PV

The code snippet is to switch between SYS_DECS_trap_gate and
SYS_DESC_irq_gate depending on whether XPTI is used. When PV is
disabled there is no need to switch.

Signed-off-by: Wei Liu 
Reviewed-by: Andrew Cooper 

commit d7ccb75b9623e8cca4fec718539c32412a3b8b6d
Author: Wei Liu 
Date:   Fri Oct 19 15:28:38 2018 +0100

x86: stub out PV only code in do_debug

When PV is disabled those symbols won't be available. It is impossible
for Xen to hit #DB there.

Signed-off-by: Wei Liu 
Acked-by: Andrew Cooper 

commit ef72c93df9a8775faa5006516fbcc375dcb14a5d
Author: Wei Liu 
Date:   Fri Oct 19 15:28:34 2018 +0100

x86: connect guest creation with CONFIG_PV

This is a bit more complicated than the HVM case because system
domains have PV guest type. Leave them like that.

Signed-off-by: Wei Liu 
Reviewed-by: Andrew Cooper 

commit 6f407dc4fc943286d4843ce7aba265b94e2eb9c9
Author: Wei Liu 
Date:   Fri Oct 19 15:28:31 2018 +0100

x86/pv: make guest_io_{read,write} local functions

Signed-off-by: Wei Liu 
Reviewed-by: Andrew Cooper 

commit 29b0678b3cbc03c2acc738d503988eb523201317
Author: Wei Liu 
Date:   Fri Oct 19 15:28:30 2018 +0100

x86: make construct_dom0 build with !CONFIG_PV

Signed-off-by: Wei Liu 
Reviewed-by: Andrew Cooper 
(qemu changes not included)

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

Re: [Xen-devel] Intel Z270 support

[Aaron Gray]

On Sun, 21 Oct 2018 at 21:36, Aaron Gray  wrote:

> On Fri, 19 Oct 2018 at 19:58, Aaron Gray 
> wrote:
>
>> On Thu, 18 Oct 2018 at 23:42, Andrew Cooper 
>> wrote:
>>
>>> On 18/10/2018 19:45, Aaron Gray wrote:
>>>
>>> On Thu, 18 Oct 2018 at 19:11, Andrew Cooper 
>>> wrote:
>>>
 On 18/10/2018 18:57, Aaron Gray wrote:
 > I have two ASUS PRIME Z270-A machines based on Intel Z270 chipset and
 > am wondering about when support will be available for them and what I
 > can do to speed this up.
 >
 > But I have not done anything to do with kernel work since years ago
 > when I read a lot of the main parts of the Linux 2.4 Kernel. Also I
 > did code to get into and out of protected mode before this.
 >
 > Heres the datasheets that cover the chipset :-
 >
 >
 https://www.intel.com/content/www/us/en/chipsets/200-series-chipset-pch-datasheet-vol-1.html
 >
 https://www.intel.com/content/www/us/en/chipsets/200-series-chipset-pch-datasheet-vol-2.html
 >

 Xen doesn't have a list of individual support chips/systems, because
 kernels don't really work like that.  We work feature by feature, or
 device by device.

 You appear to have a Broadwell-era system.  Any recent Linux distro
 should work for you, including the provided Xen package.
>>>
>>>
>>> I tried installing Xen 4.9 provided with Fedora 28 but it did not work.
>>> Can I get support with this please ?
>>>
>>>
>>> What didn't work.  What went wrong?
>>>
>>> What logs do you have from the attempt?
>>>
>>> We're not mind readers.  Noone here can divine the cause of your failure
>>> from nothing.
>>>
>>
>> Sorry I will post a proper report over the weekend.
>>
>>
> Heres what I am getting now which is different from before with Xen 4.9 on
> F28. Before it was actually booting past the [U]EFI stage. And I am not
> sure why it is faultering oon this. I have turned off UEFI on the
> Motherboard.
>
> Loading Xen 4.10.2.config ...
> error: file `EFI/fedora/x86_64-efi/module.mod' not found.
> error: file `EFI/fedora/x86_64-efi/multiboot.mod' not found.
> error: can't find command `multiboot'.
> Loading Linux 4.16.3-301.fc28.x86_64 ...
> error: can't find command `module'.
> Loading initial ramdisk ...
> error: file `EFI/fedora/x86_64-efi/module.mod' not found.
> error: can't find command `module'.
>
> Loading Xen 4.10.2.config ...
> error: file `EFI/fedora/x86_64-efi/module3.mod' not found.
> error: file `EFI/fedora/x86_64-efi/multiboot3.mod' not found.
> error: can't find command `multiboot3'.
> Loading Linux 4.16.3-301.fc28.x86_64 ...
> error: can't find command `module3'.
> Loading initial ramdisk ...
> error: file `EFI/fedora/x86_64-efi/module3.mod' not found.
> error: can't find command `module2'.
>

Sorry this looks like a Fedora issue. I will take this over to the Fedora
mailing list, but if anyone is Fedora based I would appreciate help.

Regards,

Aaron
-- 
Aaron Gray

Independent Open Source Software Engineer, Computer Language Researcher,
Information Theorist, and amateur computer scientist.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [distros-debian-sid test] 75477: trouble: blocked/broken

[Platform Team regression test user]

flight 75477 distros-debian-sid real [real]
http://osstest.xensource.com/osstest/logs/75477/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvopsbroken
 build-i386   broken
 build-amd64-pvopsbroken
 build-armhf  broken
 build-amd64  broken
 build-i386-pvops broken
 build-armhf-pvops 5 capture-logsbroken REGR. vs. 75422
 build-armhf   5 capture-logsbroken REGR. vs. 75422
 build-armhf-pvops 3 syslog-serverrunning
 build-armhf   3 syslog-serverrunning

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-i386-sid-netboot-pygrub  1 build-check(1) blocked n/a
 test-amd64-i386-i386-sid-netboot-pvgrub  1 build-check(1)  blocked n/a
 test-armhf-armhf-armhf-sid-netboot-pygrub  1 build-check(1)blocked n/a
 test-amd64-i386-amd64-sid-netboot-pygrub  1 build-check(1) blocked n/a
 test-amd64-amd64-amd64-sid-netboot-pvgrub  1 build-check(1)blocked n/a
 build-armhf-pvops 4 host-install(4)  broken like 75422
 build-armhf   4 host-install(4)  broken like 75422
 build-amd64-pvops 4 host-install(4)  broken like 75422
 build-amd64   4 host-install(4)  broken like 75422
 build-i3864 host-install(4)  broken like 75422
 build-i386-pvops  4 host-install(4)  broken like 75422

baseline version:
 flight   75422

jobs:
 build-amd64  broken  
 build-armhf  broken  
 build-i386   broken  
 build-amd64-pvopsbroken  
 build-armhf-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-amd64-sid-netboot-pvgrubblocked 
 test-amd64-i386-i386-sid-netboot-pvgrub  blocked 
 test-amd64-i386-amd64-sid-netboot-pygrub blocked 
 test-armhf-armhf-armhf-sid-netboot-pygrubblocked 
 test-amd64-amd64-i386-sid-netboot-pygrub blocked 



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.xensource.com/osstest/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.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen optimization

[Stefano Stabellini]

On Mon, 22 Oct 2018, Milan Boberic wrote:
> Hi,
> 
> > I think we want to fully understand how many other interrupts the
> > baremetal guest is receiving. To do that, we can modify my previous
> > patch to suppress any debug messages for virq=68. That way, we should
> > only see the other interrupts. Ideally there would be none.
> > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> > index 5a4f082..b7a8e17 100644
> > --- a/xen/arch/arm/vgic.c
> > +++ b/xen/arch/arm/vgic.c
> > @@ -577,7 +577,11 @@ void vgic_inject_irq(struct domain *d, struct vcpu *v, 
> > unsigned int virq,
> >  /* the irq is enabled */
> >  if ( test_bit(GIC_IRQ_GUEST_ENABLED, &n->status) )
> > +{
> >  gic_raise_guest_irq(v, virq, priority);
> > +if ( d->domain_id != 0 && virq != 68 )
> > +printk("DEBUG virq=%d local=%d\n",virq,v == current);
> > +}
> >  list_for_each_entry ( iter, &v->arch.vgic.inflight_irqs, inflight )
> >  {
> 
> when I apply this patch there are no prints nor debug messages in xl
> dmesg. So bare-metal receives only interrupt 68, which is good.

Yes, good!


> > Next step would be to verify that there are no other physical interrupts
> > interrupting the vcpu execution other the irq=68. We should be able to
> > check that with the following debug patch:
> >
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index e524ad5..b34c3e4 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -381,6 +381,13 @@ void gic_interrupt(struct cpu_user_regs *regs, int 
> > is_fiq)
> >  /* Reading IRQ will ACK it */
> >  irq = gic_hw_ops->read_irq();
> > +if (current->domain->domain_id > 0 && irq != 68)
> > +{
> > +local_irq_enable();
> > +printk("DEBUG irq=%d\n",irq);
> > +local_irq_disable();
> > +}
> > +
> >  if ( likely(irq >= 16 && irq < 1020) )
> >  {
> >  local_irq_enable();
> 
> But when I apply this patch it prints forever:
> (XEN) DEBUG irq=1023
> 
> Thanks in advance!

I know why! It's because we always loop around until we read the
spurious interrupt. Just add an && irq != 1023 to the if check.

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  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

version targeted for testing:
 xen  76bfbcec423e83c4ed975645ebf5a9a4ad2494f7
baseline version:
 xen  62aa9e7f1b8ef64b8c7c1dacb1122351cb9fd132

Last test of basis   128884  2018-10-19 20:00:41 Z2 days
Failing since128931  2018-10-22 10:00:40 Z0 days3 attempts
Testing same since   128937  2018-10-22 16:00:24 Z0 days1 attempts


People who touched revisions under test:
  
  Andrew Cooper 
  Julien Grall 
  Wei Liu 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  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 :

To xenbits.xen.org:/home/xen/git/xen.git
   62aa9e7f1b..76bfbcec42  76bfbcec423e83c4ed975645ebf5a9a4ad2494f7 -> smoke

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

[Xen-devel] [GIT PULL] (xen) stable/for-jens-4.20

[Konrad Rzeszutek Wilk]

Hi Jens,

Please git pull the following branch:

git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git 
stable/for-jens-4.20

which has exactly one tiny patch fixing an NULL pointer issue (also has stable 
tree CCed).

Thank you!

drivers/block/xen-blkfront.c | 3 +++
 1 file changed, 3 insertions(+)

Vasilis Liaskovitis (2):
  xen/blkfront: avoid NULL blkfront_info dereference on device removal



signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [GIT PULL] (xen-swiotlb) stable/for-linus-4.20

[Konrad Rzeszutek Wilk]

Hi Linus,

Please git pull the following branch:

 git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git 
stable/for-linus-4.20

which has one tiny fix for the Xen SWIOTLB mechanism that occasionally happened 
with
devices that didn't allocate size in power of two but rather some odd
sizes. We neglected to make the memory coherent leading to all kinds of fun 
crashes.

Thank you!

 drivers/xen/swiotlb-xen.c | 6 ++
 1 file changed, 6 insertions(+)

Joe Jin (1):
  xen-swiotlb: use actually allocated size on check physical continuous



signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 13/23] xen/arm: implement construct_domU

[Stefano Stabellini]

On Sat, 20 Oct 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 10/19/18 11:53 PM, Stefano Stabellini wrote:
> > On Mon, 15 Oct 2018, Julien Grall wrote:
> > > Hi,
> > > 
> > > On 05/10/2018 19:47, Stefano Stabellini wrote:
> > > > Similar to construct_dom0, construct_domU creates a barebone DomU guest.
> > > > 
> > > > The device tree node passed as argument is compatible "xen,domain", see
> > > > docs/misc/arm/device-tree/booting.txt.
> > > > 
> > > > Add const to kernel_probe dt_device_node parameter.
> > > 
> > > This likely belongs to patch #7 where the parameter was added.
> > 
> > OK
> > 
> > 
> > > > 
> > > > Signed-off-by: Stefano Stabellini 
> > > > 
> > > > ---
> > > > Changes in v4:
> > > > - constify kernel_probe
> > > > - change title
> > > > - better error messages and printed info
> > > > - 64bit memory
> > > > 
> > > > Changes in v3:
> > > > - move setting type before allocate_memory
> > > > - add ifdef around it and a comment
> > > > 
> > > > Changes in v2:
> > > > - rename mem to memory
> > > > - make cpus and memory mandatory
> > > > - remove wront comment from commit message
> > > > - cpus and memory are read as integers
> > > > - read the vpl011 option
> > > > ---
> > > >xen/arch/arm/domain_build.c | 37
> > > > ++---
> > > >xen/arch/arm/kernel.c   |  3 ++-
> > > >xen/arch/arm/kernel.h   |  2 +-
> > > >3 files changed, 37 insertions(+), 5 deletions(-)
> > > > 
> > > > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > > > index 547b624..efb530a 100644
> > > > --- a/xen/arch/arm/domain_build.c
> > > > +++ b/xen/arch/arm/domain_build.c
> > > > @@ -369,7 +369,6 @@ static void __init allocate_memory_11(struct domain
> > > > *d,
> > > >}
> > > >}
> > > >-#if 0
> > > 
> > > Please add a word about this change in the commit message.
> > 
> > OK
> > 
> > 
> > > >static bool __init allocate_bank_memory(struct domain *d,
> > > >struct kernel_info *kinfo,
> > > >gfn_t sgfn,
> > > > @@ -450,7 +449,6 @@ fail:
> > > >(unsigned long)kinfo->unassigned_mem >> 10);
> > > >BUG();
> > > >}
> > > > -#endif
> > > >  static int __init write_properties(struct domain *d, struct
> > > > kernel_info
> > > > *kinfo,
> > > >   const struct dt_device_node *node)
> > > > @@ -2294,7 +2292,40 @@ static int __init __construct_domain(struct
> > > > domain
> > > > *d, struct kernel_info *kinfo
> > > >static int __init construct_domU(struct domain *d,
> > > > const struct dt_device_node *node)
> > > >{
> > > > -return -ENOSYS;
> > > > +struct kernel_info kinfo = {};
> > > > +int rc;
> > > > +u64 mem;
> > > > +
> > > > +rc = dt_property_read_u64(node, "memory", &mem);
> > > > +if ( !rc )
> > > > +{
> > > > +printk("Error building DomU: cannot read \"memory\"
> > > > property\n");
> > > > +return -EINVAL;
> > > > +}
> > > > +kinfo.unassigned_mem = (paddr_t)mem << 10;
> > > 
> > > I noticed I forgot to answer to:
> > > "KB() only works for numbers, it is defined as: (_AC(_kb, ULL) << 10)"
> > > 
> > > unsigned long long is always going to be bigger than paddr_t. Also, we
> > > already
> > > use MB(...) in similar situation. So I am not sure to understand your
> > > concern
> > > here.
> > 
> > I admit that my explanation was so bad that even I had to go back to
> > figure out what I meant :-)
> > 
> > What I wanted to say is that KB() only works for constants, not
> > variables. So KB(10) works, but KB(mem) does not.
> 
> Oh, that's annoying. Can you use mem * SZ_1K then?

OK

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

Re: [Xen-devel] Fix VGA logdirty related display freezes with altp2m

[Tamas K Lengyel]

On Thu, Oct 18, 2018 at 3:12 PM Razvan Cojocaru
 wrote:
>
> On 10/18/18 11:08 PM, Tamas K Lengyel wrote:
> > On Thu, Oct 18, 2018 at 4:09 AM Razvan Cojocaru
> >  wrote:
> >>
> >> Hello,
> >>
> >> This series aims to prevent the display from freezing when
> >> enabling altp2m and switching to a new view (and assorted problems
> >> when resizing the display).
> >>
> >> The first patch propagates ept.ad changes to all active altp2ms,
> >> and the second one allocates a new logdirty rangeset for each
> >> new altp2m, and propagates (under lock) changes to all p2ms.
> >>
> >> The first patch is the same as:
> >> [PATCH V4] x86/altp2m: propagate ept.ad changes to all active altp2ms
> >> but as it is now required for the second one to apply cleanly, it
> >> has been resent as part of this series.
> >>
> >> [PATCH 1/2] x86/altp2m: propagate ept.ad changes to all active altp2ms
> >> [PATCH 2/2] x86/altp2m: fix display frozen when switching to a new
> >
> > Hi Razvan,
> > I would be happy to give this a spin, can you push it as a git branch 
> > somewhere?
>
> Sure, here you go:
>
> https://github.com/razvan-cojocaru/xen/tree/altp2m-logdirty-take1

I ran into this crash when my config incorrectly pointed to a
non-valid disk location:

(XEN) Assertion 'p2m->sync.logdirty_ranges' failed at p2m-ept.c:1475
(XEN) [ Xen-4.12-unstable  x86_64  debug=y   Not tainted ]
(XEN) CPU:4
(XEN) RIP:e008:[] p2m_uninit_altp2m_ept+0x29/0x2b
(XEN) RFLAGS: 00010246   CONTEXT: hypervisor
(XEN) rax: 83046d27802c   rbx: 8304558dd880   rcx: 
(XEN) rdx: 83046d277fff   rsi: 004680c0   rdi: 
(XEN) rbp: 83046d277d60   rsp: 83046d277d50   r8:  82d0809304a0
(XEN) r9:  00455940   r10: 82e008d01000   r11: 0017
(XEN) r12: 8304558dd880   r13: 8304558df830   r14: 8304558df000
(XEN) r15: fff8   cr0: 8005003b   cr4: 003526e0
(XEN) cr3: 5da16000   cr2: 880456cd6e80
(XEN) fsb:    gsb: 880467f4   gss: 
(XEN) ds: 002b   es: 002b   fs:    gs:    ss: e010   cs: e008
(XEN) Xen code around  (p2m_uninit_altp2m_ept+0x29/0x2b):
(XEN)  00 48 83 c4 08 5b 5d c3 <0f> 0b 55 48 89 e5 41 56 41 55 41 54 53 48 8d 05
(XEN) Xen call trace:
(XEN)[] p2m_uninit_altp2m_ept+0x29/0x2b
(XEN)[] p2m.c#p2m_teardown_altp2m+0x36/0x52
(XEN)[] p2m_final_teardown+0x11/0x28
(XEN)[] paging_final_teardown+0x2e/0x3c
(XEN)[] arch_domain_destroy+0x50/0xa1
(XEN)[] domain.c#complete_domain_destroy+0x86/0x159
(XEN)[] rcupdate.c#rcu_process_callbacks+0xa5/0x1cf
(XEN)[] softirq.c#__do_softirq+0x71/0x9a
(XEN)[] do_softirq+0x13/0x15
(XEN)[] domain.c#idle_loop+0x63/0xb9
(XEN)
(XEN)
(XEN) 
(XEN) Panic on CPU 4:
(XEN) Assertion 'p2m->sync.logdirty_ranges' failed at p2m-ept.c:1475
(XEN) 

With the config fixed it boots but when I run DRAKVUF on the domain I
get the following crash:

(XEN) [ Xen-4.12-unstable  x86_64  debug=y   Not tainted ]
(XEN) CPU:0
(XEN) RIP:e008:[<7bdb630c>] 7bdb630c
(XEN) RFLAGS: 00010282   CONTEXT: hypervisor (d0v5)
(XEN) rax: ee138470   rbx:    rcx: 8000b098
(XEN) rdx: 0cf8   rsi:    rdi: 00046d2ef000
(XEN) rbp:    rsp: 83005da27a10   r8:  0cf8
(XEN) r9:  0cf8   r10: 83005da27ab8   r11: 83005da27a08
(XEN) r12:    r13:    r14: 0065
(XEN) r15: 05a7   cr0: 80050033   cr4: 00372660
(XEN) cr3: 00046d2ef000   cr2: ee138470
(XEN) fsb: 7fe46d97bbc0   gsb: 880467f4   gss: 
(XEN) ds:    es:    fs:    gs:    ss: e010   cs: e008
(XEN) Xen code around <7bdb630c> (7bdb630c):
(XEN)  80 74 0b 05 70 84 00 00  00 00 00 00 e0 80 3d 7a 34 00 00 00 75 64 48
(XEN) Xen stack trace from rsp=83005da27a10:(XEN) Xen stack trace
from rsp=83005da27a10:
(XEN) 0065 83005da27a50 82d08037aafc
(XEN)fffe 82d08037ae14  83005da27a90
(XEN)00372660 00046d2ef000 000393e91000 82d0809602b0
(XEN)00fe 82d0802a3b98  83005da27ab8
(XEN)83005da27b08 82d0802a3511 82d08046b028 83005da27b08
(XEN)82d0802a3511 83005da27fff 13880292 82d0808176a0
(XEN) 82d08023b889 0292 82d08046b028
(XEN)82d080451ac8 82d080454af2 05a7 83005da27b78
(XEN)82d080251d6f 82d080250fcd 0028 83005da27b88
(XEN)83005da27b38 e010 82d080454c73 82d080451ac8
(XEN)82d080454af2 05a7 0030 83005da27bf8

Re: [Xen-devel] Fix VGA logdirty related display freezes with altp2m

[Razvan Cojocaru]

On 10/22/18 11:48 PM, Tamas K Lengyel wrote:
> On Thu, Oct 18, 2018 at 3:12 PM Razvan Cojocaru
>  wrote:
>>
>> On 10/18/18 11:08 PM, Tamas K Lengyel wrote:
>>> On Thu, Oct 18, 2018 at 4:09 AM Razvan Cojocaru
>>>  wrote:

 Hello,

 This series aims to prevent the display from freezing when
 enabling altp2m and switching to a new view (and assorted problems
 when resizing the display).

 The first patch propagates ept.ad changes to all active altp2ms,
 and the second one allocates a new logdirty rangeset for each
 new altp2m, and propagates (under lock) changes to all p2ms.

 The first patch is the same as:
 [PATCH V4] x86/altp2m: propagate ept.ad changes to all active altp2ms
 but as it is now required for the second one to apply cleanly, it
 has been resent as part of this series.

 [PATCH 1/2] x86/altp2m: propagate ept.ad changes to all active altp2ms
 [PATCH 2/2] x86/altp2m: fix display frozen when switching to a new
>>>
>>> Hi Razvan,
>>> I would be happy to give this a spin, can you push it as a git branch 
>>> somewhere?
>>
>> Sure, here you go:
>>
>> https://github.com/razvan-cojocaru/xen/tree/altp2m-logdirty-take1
> 
> I ran into this crash when my config incorrectly pointed to a
> non-valid disk location:
> 
> (XEN) Assertion 'p2m->sync.logdirty_ranges' failed at p2m-ept.c:1475
> (XEN) [ Xen-4.12-unstable  x86_64  debug=y   Not tainted ]
> (XEN) CPU:4
> (XEN) RIP:e008:[] p2m_uninit_altp2m_ept+0x29/0x2b
> (XEN) RFLAGS: 00010246   CONTEXT: hypervisor
> (XEN) rax: 83046d27802c   rbx: 8304558dd880   rcx: 
> (XEN) rdx: 83046d277fff   rsi: 004680c0   rdi: 
> (XEN) rbp: 83046d277d60   rsp: 83046d277d50   r8:  82d0809304a0
> (XEN) r9:  00455940   r10: 82e008d01000   r11: 0017
> (XEN) r12: 8304558dd880   r13: 8304558df830   r14: 8304558df000
> (XEN) r15: fff8   cr0: 8005003b   cr4: 003526e0
> (XEN) cr3: 5da16000   cr2: 880456cd6e80
> (XEN) fsb:    gsb: 880467f4   gss: 
> (XEN) ds: 002b   es: 002b   fs:    gs:    ss: e010   cs: e008
> (XEN) Xen code around  (p2m_uninit_altp2m_ept+0x29/0x2b):
> (XEN)  00 48 83 c4 08 5b 5d c3 <0f> 0b 55 48 89 e5 41 56 41 55 41 54 53 48 8d 
> 05
> (XEN) Xen call trace:
> (XEN)[] p2m_uninit_altp2m_ept+0x29/0x2b
> (XEN)[] p2m.c#p2m_teardown_altp2m+0x36/0x52
> (XEN)[] p2m_final_teardown+0x11/0x28
> (XEN)[] paging_final_teardown+0x2e/0x3c
> (XEN)[] arch_domain_destroy+0x50/0xa1
> (XEN)[] domain.c#complete_domain_destroy+0x86/0x159
> (XEN)[] rcupdate.c#rcu_process_callbacks+0xa5/0x1cf
> (XEN)[] softirq.c#__do_softirq+0x71/0x9a
> (XEN)[] do_softirq+0x13/0x15
> (XEN)[] domain.c#idle_loop+0x63/0xb9
> (XEN)
> (XEN)
> (XEN) 
> (XEN) Panic on CPU 4:
> (XEN) Assertion 'p2m->sync.logdirty_ranges' failed at p2m-ept.c:1475
> (XEN) 

Right, that one I've also come across now, that will be fixed in the
next series as a result of doing what Andrew has suggested, which is to say:

"Please make all destroy functions idempotent.  i.e.

if ( p2m->sync.logdirty_ranges )
{
rangeset_destroy(p2m->sync.logdirty_ranges);
p2m->sync.logdirty_ranges = NULL;
}

and use this destroy function in the cleanup path of init()."

> With the config fixed it boots but when I run DRAKVUF on the domain I
> get the following crash:
> 
> (XEN) [ Xen-4.12-unstable  x86_64  debug=y   Not tainted ]
> (XEN) CPU:0
> (XEN) RIP:e008:[<7bdb630c>] 7bdb630c
> (XEN) RFLAGS: 00010282   CONTEXT: hypervisor (d0v5)
> (XEN) rax: ee138470   rbx:    rcx: 8000b098
> (XEN) rdx: 0cf8   rsi:    rdi: 00046d2ef000
> (XEN) rbp:    rsp: 83005da27a10   r8:  0cf8
> (XEN) r9:  0cf8   r10: 83005da27ab8   r11: 83005da27a08
> (XEN) r12:    r13:    r14: 0065
> (XEN) r15: 05a7   cr0: 80050033   cr4: 00372660
> (XEN) cr3: 00046d2ef000   cr2: ee138470
> (XEN) fsb: 7fe46d97bbc0   gsb: 880467f4   gss: 
> (XEN) ds:    es:    fs:    gs:    ss: e010   cs: e008
> (XEN) Xen code around <7bdb630c> (7bdb630c):
> (XEN)  80 74 0b 05 70 84 00 00  00 00 00 00 e0 80 3d 7a 34 00 00 00 75 64 
> 48
> (XEN) Xen stack trace from rsp=83005da27a10:(XEN) Xen stack trace
> from rsp=83005da27a10:
> (XEN) 0065 83005da27a50 82d08037aafc
> (XEN)fffe 82d08037ae14  83005da27a90
> (XEN)00372660 00046d2ef000 000393e91000 82d0809602b0
> (XEN)00fe 82d0802a3b98 f

Re: [Xen-devel] Fix VGA logdirty related display freezes with altp2m

[Andrew Cooper]

On 22/10/2018 22:17, Razvan Cojocaru wrote:
> On 10/22/18 11:48 PM, Tamas K Lengyel wrote:
>> On Thu, Oct 18, 2018 at 3:12 PM Razvan Cojocaru
>>  wrote:
>>> On 10/18/18 11:08 PM, Tamas K Lengyel wrote:
 On Thu, Oct 18, 2018 at 4:09 AM Razvan Cojocaru
  wrote:
> Hello,
>
> This series aims to prevent the display from freezing when
> enabling altp2m and switching to a new view (and assorted problems
> when resizing the display).
>
> The first patch propagates ept.ad changes to all active altp2ms,
> and the second one allocates a new logdirty rangeset for each
> new altp2m, and propagates (under lock) changes to all p2ms.
>
> The first patch is the same as:
> [PATCH V4] x86/altp2m: propagate ept.ad changes to all active altp2ms
> but as it is now required for the second one to apply cleanly, it
> has been resent as part of this series.
>
> [PATCH 1/2] x86/altp2m: propagate ept.ad changes to all active altp2ms
> [PATCH 2/2] x86/altp2m: fix display frozen when switching to a new
 Hi Razvan,
 I would be happy to give this a spin, can you push it as a git branch 
 somewhere?
>>> Sure, here you go:
>>>
>>> https://github.com/razvan-cojocaru/xen/tree/altp2m-logdirty-take1
>> I ran into this crash when my config incorrectly pointed to a
>> non-valid disk location:
>>
>> (XEN) Assertion 'p2m->sync.logdirty_ranges' failed at p2m-ept.c:1475
>> (XEN) [ Xen-4.12-unstable  x86_64  debug=y   Not tainted ]
>> (XEN) CPU:4
>> (XEN) RIP:e008:[] p2m_uninit_altp2m_ept+0x29/0x2b
>> (XEN) RFLAGS: 00010246   CONTEXT: hypervisor
>> (XEN) rax: 83046d27802c   rbx: 8304558dd880   rcx: 
>> (XEN) rdx: 83046d277fff   rsi: 004680c0   rdi: 
>> (XEN) rbp: 83046d277d60   rsp: 83046d277d50   r8:  82d0809304a0
>> (XEN) r9:  00455940   r10: 82e008d01000   r11: 0017
>> (XEN) r12: 8304558dd880   r13: 8304558df830   r14: 8304558df000
>> (XEN) r15: fff8   cr0: 8005003b   cr4: 003526e0
>> (XEN) cr3: 5da16000   cr2: 880456cd6e80
>> (XEN) fsb:    gsb: 880467f4   gss: 
>> (XEN) ds: 002b   es: 002b   fs:    gs:    ss: e010   cs: e008
>> (XEN) Xen code around  (p2m_uninit_altp2m_ept+0x29/0x2b):
>> (XEN)  00 48 83 c4 08 5b 5d c3 <0f> 0b 55 48 89 e5 41 56 41 55 41 54 53 48 
>> 8d 05
>> (XEN) Xen call trace:
>> (XEN)[] p2m_uninit_altp2m_ept+0x29/0x2b
>> (XEN)[] p2m.c#p2m_teardown_altp2m+0x36/0x52
>> (XEN)[] p2m_final_teardown+0x11/0x28
>> (XEN)[] paging_final_teardown+0x2e/0x3c
>> (XEN)[] arch_domain_destroy+0x50/0xa1
>> (XEN)[] domain.c#complete_domain_destroy+0x86/0x159
>> (XEN)[] rcupdate.c#rcu_process_callbacks+0xa5/0x1cf
>> (XEN)[] softirq.c#__do_softirq+0x71/0x9a
>> (XEN)[] do_softirq+0x13/0x15
>> (XEN)[] domain.c#idle_loop+0x63/0xb9
>> (XEN)
>> (XEN)
>> (XEN) 
>> (XEN) Panic on CPU 4:
>> (XEN) Assertion 'p2m->sync.logdirty_ranges' failed at p2m-ept.c:1475
>> (XEN) 
> Right, that one I've also come across now, that will be fixed in the
> next series as a result of doing what Andrew has suggested, which is to say:
>
> "Please make all destroy functions idempotent.  i.e.
>
> if ( p2m->sync.logdirty_ranges )
> {
> rangeset_destroy(p2m->sync.logdirty_ranges);
> p2m->sync.logdirty_ranges = NULL;
> }
>
> and use this destroy function in the cleanup path of init()."

Indeed.

>
>> With the config fixed it boots but when I run DRAKVUF on the domain I
>> get the following crash:
>>
>> (XEN) [ Xen-4.12-unstable  x86_64  debug=y   Not tainted ]
>> (XEN) CPU:0
>> (XEN) RIP:e008:[<7bdb630c>] 7bdb630c
>> (XEN) RFLAGS: 00010282   CONTEXT: hypervisor (d0v5)
>> (XEN) rax: ee138470   rbx:    rcx: 8000b098
>> (XEN) rdx: 0cf8   rsi:    rdi: 00046d2ef000
>> (XEN) rbp:    rsp: 83005da27a10   r8:  0cf8
>> (XEN) r9:  0cf8   r10: 83005da27ab8   r11: 83005da27a08
>> (XEN) r12:    r13:    r14: 0065
>> (XEN) r15: 05a7   cr0: 80050033   cr4: 00372660
>> (XEN) cr3: 00046d2ef000   cr2: ee138470
>> (XEN) fsb: 7fe46d97bbc0   gsb: 880467f4   gss: 
>> (XEN) ds:    es:    fs:    gs:    ss: e010   cs: e008
>> (XEN) Xen code around <7bdb630c> (7bdb630c):
>> (XEN)  80 74 0b 05 70 84 00 00  00 00 00 00 e0 80 3d 7a 34 00 00 00 75 
>> 64 48
>> (XEN) Xen stack trace from rsp=83005da27a10:(XEN) Xen stack trace
>> from rsp=83005da27a10:
>> (XEN) 0065 83005da27a50 82d08037aafc
>> (XEN)fffe 82d08037ae14 00

Re: [Xen-devel] Fix VGA logdirty related display freezes with altp2m

[Tamas K Lengyel]

On Mon, Oct 22, 2018 at 3:22 PM Andrew Cooper  wrote:
>
> On 22/10/2018 22:17, Razvan Cojocaru wrote:
> > On 10/22/18 11:48 PM, Tamas K Lengyel wrote:
> >> On Thu, Oct 18, 2018 at 3:12 PM Razvan Cojocaru
> >>  wrote:
> >>> On 10/18/18 11:08 PM, Tamas K Lengyel wrote:
>  On Thu, Oct 18, 2018 at 4:09 AM Razvan Cojocaru
>   wrote:
> > Hello,
> >
> > This series aims to prevent the display from freezing when
> > enabling altp2m and switching to a new view (and assorted problems
> > when resizing the display).
> >
> > The first patch propagates ept.ad changes to all active altp2ms,
> > and the second one allocates a new logdirty rangeset for each
> > new altp2m, and propagates (under lock) changes to all p2ms.
> >
> > The first patch is the same as:
> > [PATCH V4] x86/altp2m: propagate ept.ad changes to all active altp2ms
> > but as it is now required for the second one to apply cleanly, it
> > has been resent as part of this series.
> >
> > [PATCH 1/2] x86/altp2m: propagate ept.ad changes to all active altp2ms
> > [PATCH 2/2] x86/altp2m: fix display frozen when switching to a new
>  Hi Razvan,
>  I would be happy to give this a spin, can you push it as a git branch 
>  somewhere?
> >>> Sure, here you go:
> >>>
> >>> https://github.com/razvan-cojocaru/xen/tree/altp2m-logdirty-take1
> >> I ran into this crash when my config incorrectly pointed to a
> >> non-valid disk location:
> >>
> >> (XEN) Assertion 'p2m->sync.logdirty_ranges' failed at p2m-ept.c:1475
> >> (XEN) [ Xen-4.12-unstable  x86_64  debug=y   Not tainted ]
> >> (XEN) CPU:4
> >> (XEN) RIP:e008:[] p2m_uninit_altp2m_ept+0x29/0x2b
> >> (XEN) RFLAGS: 00010246   CONTEXT: hypervisor
> >> (XEN) rax: 83046d27802c   rbx: 8304558dd880   rcx: 
> >> (XEN) rdx: 83046d277fff   rsi: 004680c0   rdi: 
> >> (XEN) rbp: 83046d277d60   rsp: 83046d277d50   r8:  82d0809304a0
> >> (XEN) r9:  00455940   r10: 82e008d01000   r11: 0017
> >> (XEN) r12: 8304558dd880   r13: 8304558df830   r14: 8304558df000
> >> (XEN) r15: fff8   cr0: 8005003b   cr4: 003526e0
> >> (XEN) cr3: 5da16000   cr2: 880456cd6e80
> >> (XEN) fsb:    gsb: 880467f4   gss: 
> >> (XEN) ds: 002b   es: 002b   fs:    gs:    ss: e010   cs: e008
> >> (XEN) Xen code around  (p2m_uninit_altp2m_ept+0x29/0x2b):
> >> (XEN)  00 48 83 c4 08 5b 5d c3 <0f> 0b 55 48 89 e5 41 56 41 55 41 54 53 48 
> >> 8d 05
> >> (XEN) Xen call trace:
> >> (XEN)[] p2m_uninit_altp2m_ept+0x29/0x2b
> >> (XEN)[] p2m.c#p2m_teardown_altp2m+0x36/0x52
> >> (XEN)[] p2m_final_teardown+0x11/0x28
> >> (XEN)[] paging_final_teardown+0x2e/0x3c
> >> (XEN)[] arch_domain_destroy+0x50/0xa1
> >> (XEN)[] domain.c#complete_domain_destroy+0x86/0x159
> >> (XEN)[] rcupdate.c#rcu_process_callbacks+0xa5/0x1cf
> >> (XEN)[] softirq.c#__do_softirq+0x71/0x9a
> >> (XEN)[] do_softirq+0x13/0x15
> >> (XEN)[] domain.c#idle_loop+0x63/0xb9
> >> (XEN)
> >> (XEN)
> >> (XEN) 
> >> (XEN) Panic on CPU 4:
> >> (XEN) Assertion 'p2m->sync.logdirty_ranges' failed at p2m-ept.c:1475
> >> (XEN) 
> > Right, that one I've also come across now, that will be fixed in the
> > next series as a result of doing what Andrew has suggested, which is to say:
> >
> > "Please make all destroy functions idempotent.  i.e.
> >
> > if ( p2m->sync.logdirty_ranges )
> > {
> > rangeset_destroy(p2m->sync.logdirty_ranges);
> > p2m->sync.logdirty_ranges = NULL;
> > }
> >
> > and use this destroy function in the cleanup path of init()."
>
> Indeed.
>
> >
> >> With the config fixed it boots but when I run DRAKVUF on the domain I
> >> get the following crash:
> >>
> >> (XEN) [ Xen-4.12-unstable  x86_64  debug=y   Not tainted ]
> >> (XEN) CPU:0
> >> (XEN) RIP:e008:[<7bdb630c>] 7bdb630c
> >> (XEN) RFLAGS: 00010282   CONTEXT: hypervisor (d0v5)
> >> (XEN) rax: ee138470   rbx:    rcx: 8000b098
> >> (XEN) rdx: 0cf8   rsi:    rdi: 00046d2ef000
> >> (XEN) rbp:    rsp: 83005da27a10   r8:  0cf8
> >> (XEN) r9:  0cf8   r10: 83005da27ab8   r11: 83005da27a08
> >> (XEN) r12:    r13:    r14: 0065
> >> (XEN) r15: 05a7   cr0: 80050033   cr4: 00372660
> >> (XEN) cr3: 00046d2ef000   cr2: ee138470
> >> (XEN) fsb: 7fe46d97bbc0   gsb: 880467f4   gss: 
> >> (XEN) ds:    es:    fs:    gs:    ss: e010   cs: e008
> >> (XEN) Xen code around <7bdb630c> (7bdb630c):
> >> (XEN)  80 74 0b 05 70 84 00 00  00 00 00 00 e0 80 3d 7a 34 00 00 00 

Re: [Xen-devel] [GIT PULL] (xen) stable/for-jens-4.20

[Jens Axboe]

On 10/22/18 1:31 PM, Konrad Rzeszutek Wilk wrote:
> 
> Hi Jens,
> 
> Please git pull the following branch:
> 
> git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git 
> stable/for-jens-4.20
> 
> which has exactly one tiny patch fixing an NULL pointer issue (also has 
> stable tree CCed).
> 
> Thank you!
> 
> drivers/block/xen-blkfront.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> Vasilis Liaskovitis (2):
>   xen/blkfront: avoid NULL blkfront_info dereference on device removal

Pulled, thanks.

-- 
Jens Axboe


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

[Xen-devel] [qemu-mainline baseline-only test] 75479: trouble: blocked/broken

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 75479 qemu-mainline real [real]
http://osstest.xensource.com/osstest/logs/75479/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64  broken
 build-i386   broken
 build-armhf-pvopsbroken
 build-i386-xsm   broken
 build-amd64-xsm  broken
 build-amd64-pvopsbroken
 build-i386-pvops broken
 build-armhf  broken

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-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-midway1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  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-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  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-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  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-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   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-armhf-armhf-xl   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-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-chec

Re: [Xen-devel] Fix VGA logdirty related display freezes with altp2m

[Razvan Cojocaru]

 With the config fixed it boots but when I run DRAKVUF on the domain I
 get the following crash:

 (XEN) [ Xen-4.12-unstable  x86_64  debug=y   Not tainted ]
 (XEN) CPU:0
 (XEN) RIP:e008:[<7bdb630c>] 7bdb630c
 (XEN) RFLAGS: 00010282   CONTEXT: hypervisor (d0v5)
 (XEN) rax: ee138470   rbx:    rcx: 8000b098
 (XEN) rdx: 0cf8   rsi:    rdi: 00046d2ef000
 (XEN) rbp:    rsp: 83005da27a10   r8:  0cf8
 (XEN) r9:  0cf8   r10: 83005da27ab8   r11: 83005da27a08
 (XEN) r12:    r13:    r14: 0065
 (XEN) r15: 05a7   cr0: 80050033   cr4: 00372660
 (XEN) cr3: 00046d2ef000   cr2: ee138470
 (XEN) fsb: 7fe46d97bbc0   gsb: 880467f4   gss: 
 (XEN) ds:    es:    fs:    gs:    ss: e010   cs: e008
 (XEN) Xen code around <7bdb630c> (7bdb630c):
 (XEN)  80 74 0b 05 70 84 00 00  00 00 00 00 e0 80 3d 7a 34 00 00 00 75 
 64 48
 (XEN) Xen stack trace from rsp=83005da27a10:(XEN) Xen stack trace
 from rsp=83005da27a10:
 (XEN) 0065 83005da27a50 
 82d08037aafc
 (XEN)fffe 82d08037ae14  
 83005da27a90
 (XEN)00372660 00046d2ef000 000393e91000 
 82d0809602b0
 (XEN)00fe 82d0802a3b98  
 83005da27ab8
 (XEN)83005da27b08 82d0802a3511 82d08046b028 
 83005da27b08
 (XEN)82d0802a3511 83005da27fff 13880292 
 82d0808176a0
 (XEN) 82d08023b889 0292 
 82d08046b028
 (XEN)82d080451ac8 82d080454af2 05a7 
 83005da27b78
 (XEN)82d080251d6f 82d080250fcd 0028 
 83005da27b88
 (XEN)83005da27b38 e010 82d080454c73 
 82d080451ac8
 (XEN)82d080454af2 05a7 0030 
 83005da27bf8
 (XEN)82d080454c73 83005da27be8 82d0802aaebc 
 82d08033f3dc
 (XEN)82d080451ac8 82d08037d969 82d08037d95d 
 82d08037d969
 (XEN)0b0f82d08037d95d 82d08037d969 83005fe5b000 
 
 (XEN) 83005da27fff  
 7cffa25d83e7
 (XEN)82d08037da2d deadbeefdeadf00d 83018caf2530 
 83005da27d38
 (XEN)83040a492830 83005da27cc8 83040bab2880 
 
 (XEN) deadbeefdeadf00d deadbeefdeadf00d 
 
 (XEN) 830451835000  
 83040a492000
 (XEN)0006 82d08033f3da e008 
 00010282
 (XEN) Xen call trace:
 (XEN)[<7bdb630c>] 7bdb630c
 (XEN)
 (XEN) Pagetable walk from ee138470:
 (XEN)  L4[0x000] = 00046d2ee063 
 (XEN)  L3[0x003] = 5da11063 
 (XEN)  L2[0x170] =  
 (XEN)
 (XEN) 
 (XEN) Panic on CPU 0:
 (XEN) FATAL PAGE FAULT
 (XEN) [error_code=0002]
 (XEN) Faulting linear address: ee138470
 (XEN) 
 (XEN)
 (XEN) Reboot in five seconds...
>>> This one I'm not sure about. What does your introspection agent do at
>>> that point?
>>
>> This crash is bizarre.  Xen has most likely followed a corrupt function
>> pointer, because none of Xen's .text section live just below the 2G boundary
>>
> 
> It's reproducible and happens immediately after a successful call to
> xc_altp2m_set_domain_state to enable altp2m.

That can't be all that's needed. I assure you I've tested this with much
more that just calling xc_altp2m_set_domain_state() with no crashes at
all. Something else must happen as well.

Could you write a simple C test application that does the minimum
ammount of work needed to produce this crash?


Thanks,
Razvan

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

Re: [Xen-devel] Fix VGA logdirty related display freezes with altp2m

[Tamas K Lengyel]

On Mon, Oct 22, 2018 at 4:15 PM Razvan Cojocaru
 wrote:
>
>  With the config fixed it boots but when I run DRAKVUF on the domain I
>  get the following crash:
> 
>  (XEN) [ Xen-4.12-unstable  x86_64  debug=y   Not tainted ]
>  (XEN) CPU:0
>  (XEN) RIP:e008:[<7bdb630c>] 7bdb630c
>  (XEN) RFLAGS: 00010282   CONTEXT: hypervisor (d0v5)
>  (XEN) rax: ee138470   rbx:    rcx: 
>  8000b098
>  (XEN) rdx: 0cf8   rsi:    rdi: 
>  00046d2ef000
>  (XEN) rbp:    rsp: 83005da27a10   r8:  
>  0cf8
>  (XEN) r9:  0cf8   r10: 83005da27ab8   r11: 
>  83005da27a08
>  (XEN) r12:    r13:    r14: 
>  0065
>  (XEN) r15: 05a7   cr0: 80050033   cr4: 
>  00372660
>  (XEN) cr3: 00046d2ef000   cr2: ee138470
>  (XEN) fsb: 7fe46d97bbc0   gsb: 880467f4   gss: 
>  
>  (XEN) ds:    es:    fs:    gs:    ss: e010   cs: e008
>  (XEN) Xen code around <7bdb630c> (7bdb630c):
>  (XEN)  80 74 0b 05 70 84 00 00  00 00 00 00 e0 80 3d 7a 34 00 00 00 
>  75 64 48
>  (XEN) Xen stack trace from rsp=83005da27a10:(XEN) Xen stack trace
>  from rsp=83005da27a10:
>  (XEN) 0065 83005da27a50 
>  82d08037aafc
>  (XEN)fffe 82d08037ae14  
>  83005da27a90
>  (XEN)00372660 00046d2ef000 000393e91000 
>  82d0809602b0
>  (XEN)00fe 82d0802a3b98  
>  83005da27ab8
>  (XEN)83005da27b08 82d0802a3511 82d08046b028 
>  83005da27b08
>  (XEN)82d0802a3511 83005da27fff 13880292 
>  82d0808176a0
>  (XEN) 82d08023b889 0292 
>  82d08046b028
>  (XEN)82d080451ac8 82d080454af2 05a7 
>  83005da27b78
>  (XEN)82d080251d6f 82d080250fcd 0028 
>  83005da27b88
>  (XEN)83005da27b38 e010 82d080454c73 
>  82d080451ac8
>  (XEN)82d080454af2 05a7 0030 
>  83005da27bf8
>  (XEN)82d080454c73 83005da27be8 82d0802aaebc 
>  82d08033f3dc
>  (XEN)82d080451ac8 82d08037d969 82d08037d95d 
>  82d08037d969
>  (XEN)0b0f82d08037d95d 82d08037d969 83005fe5b000 
>  
>  (XEN) 83005da27fff  
>  7cffa25d83e7
>  (XEN)82d08037da2d deadbeefdeadf00d 83018caf2530 
>  83005da27d38
>  (XEN)83040a492830 83005da27cc8 83040bab2880 
>  
>  (XEN) deadbeefdeadf00d deadbeefdeadf00d 
>  
>  (XEN) 830451835000  
>  83040a492000
>  (XEN)0006 82d08033f3da e008 
>  00010282
>  (XEN) Xen call trace:
>  (XEN)[<7bdb630c>] 7bdb630c
>  (XEN)
>  (XEN) Pagetable walk from ee138470:
>  (XEN)  L4[0x000] = 00046d2ee063 
>  (XEN)  L3[0x003] = 5da11063 
>  (XEN)  L2[0x170] =  
>  (XEN)
>  (XEN) 
>  (XEN) Panic on CPU 0:
>  (XEN) FATAL PAGE FAULT
>  (XEN) [error_code=0002]
>  (XEN) Faulting linear address: ee138470
>  (XEN) 
>  (XEN)
>  (XEN) Reboot in five seconds...
> >>> This one I'm not sure about. What does your introspection agent do at
> >>> that point?
> >>
> >> This crash is bizarre.  Xen has most likely followed a corrupt function
> >> pointer, because none of Xen's .text section live just below the 2G 
> >> boundary
> >>
> >
> > It's reproducible and happens immediately after a successful call to
> > xc_altp2m_set_domain_state to enable altp2m.
>
> That can't be all that's needed. I assure you I've tested this with much
> more that just calling xc_altp2m_set_domain_state() with no crashes at
> all. Something else must happen as well.
>
> Could you write a simple C test application that does the minimum
> ammount of work needed to produce this crash?

Not the same error but another crash when just using xen-access with
altp2m_exec:

(XEN) Assertion '!p2m->sync.logdirty_ranges' failed at p2m-ept.c:1447
(XEN) [ Xen-4.12-unstable  x86_64  debug=y   Not tainted ]
(XEN) CPU:7
(XEN) RIP:e008:[] p2m_init_altp2m_ept+0xf8/0x101
(XEN) RFLAGS: 00010282   CONTEXT: hypervisor (d0v1)
(XEN) rax: 0

[Xen-devel] [RFC PATCH 2/2] xen/arm: Add MESON UART driver for Amlogic S905 SoC

[André Przywara]

On 8/7/18 6:07 PM, Amit Singh Tomar wrote:

Hi,

> This patch adds driver for UART controller present on Amlogic S905
> SoC.
> https://dn.odroid.com/S905/DataSheet/S905_Public_Datasheet_V1.1.4.pdf
> 
> Signed-off-by: Amit Singh Tomar 
> ---
>  xen/drivers/char/Kconfig  |   8 ++
>  xen/drivers/char/Makefile |   1 +
>  xen/drivers/char/meson-uart.c | 290
> ++ 3 files changed, 299
> insertions(+) create mode 100644 xen/drivers/char/meson-uart.c
> 
> diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
> index cc78ec3..b9fee4e 100644
> --- a/xen/drivers/char/Kconfig
> +++ b/xen/drivers/char/Kconfig
> @@ -20,6 +20,14 @@ config HAS_MVEBU
> This selects the Marvell MVEBU UART. If you have a ARMADA
> 3700 based board, say Y.
>  
> +config HAS_MESON
> +bool
> +default y
> +depends on ARM_64
> +help
> +  This selects the Marvell MESON UART. If you have a Amlogic S905
> +  based board, say Y.

It seems this UART driver supports all Amlogic SoCs (905X, 805X, 912,
...), not just the S905. So please either remove the number or make it
clear that it's just an example.
And it's not a Marvell UART ;-)

> +
>  config HAS_PL011
>   bool
>   default y
> diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
> index b68c330..7c646d7 100644
> --- a/xen/drivers/char/Makefile
> +++ b/xen/drivers/char/Makefile
> @@ -3,6 +3,7 @@ obj-$(CONFIG_HAS_NS16550) += ns16550.o
>  obj-$(CONFIG_HAS_CADENCE_UART) += cadence-uart.o
>  obj-$(CONFIG_HAS_PL011) += pl011.o
>  obj-$(CONFIG_HAS_EXYNOS4210) += exynos4210-uart.o
> +obj-$(CONFIG_HAS_MESON) += meson-uart.o
>  obj-$(CONFIG_HAS_MVEBU) += mvebu-uart.o
>  obj-$(CONFIG_HAS_OMAP) += omap-uart.o
>  obj-$(CONFIG_HAS_SCIF) += scif-uart.o
> diff --git a/xen/drivers/char/meson-uart.c
> b/xen/drivers/char/meson-uart.c new file mode 100644
> index 000..8fe7e62
> --- /dev/null
> +++ b/xen/drivers/char/meson-uart.c
> @@ -0,0 +1,290 @@
> +/*
> + * xen/drivers/char/meson-uart.c
> + *
> + * Driver for Amlogic MESON UART
> + *
> + * Copyright (c) 2018, Amit Singh Tomar .
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms and conditions of the GNU General Public
> + * License, version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public
> + * License along with this program; If not, see
> .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Register offsets */
> +#define UART_WFIFO  0x00
> +#define UART_RFIFO  0x04
> +#define UART_CONTROL0x08
> +#define UART_STATUS 0x0c
> +#define UART_MISC   0x10
> +#define UART_REG5   0x14
> +
> +/* UART_CONTROL bits */
> +#define UART_TX_EN  BIT(12)
> +#define UART_RX_EN  BIT(13)

You don't seem to use them in the code? This seems somewhat wrong, you
shouldn't rely on those bits being set by previous boot stages.

> +#define UART_TX_RST BIT(22)
> +#define UART_RX_RST BIT(23)
> +#define UART_CLEAR_ERR  BIT(24)
> +#define UART_RX_INT_EN  BIT(27)
> +#define UART_TX_INT_EN  BIT(28)
> +
> +/* UART_STATUS bits */
> +#define UART_PARITY_ERR BIT(16)
> +#define UART_FRAME_ERR  BIT(17)
> +#define UART_TX_FIFO_WERR   BIT(18)

You don't use those, so I don't see a need to define them.

> +#define UART_RX_EMPTY   BIT(20)
> +#define UART_TX_FULLBIT(21)
> +#define UART_TX_EMPTY   BIT(22)

Might be worth to add FIFO_ in those names.

> +#define UART_TX_CNT_MASKGENMASK(14, 8)
> +
> +
> +#define UART_XMIT_IRQ_CNT_MASK  GENMASK(15, 8)
> +#define UART_RECV_IRQ_CNT_MASK  GENMASK(7, 0)
> +
> +#define TX_FIFO_SIZE64
> +
> +static struct meson_s905_uart {
> +unsigned int irq;
> +void __iomem *regs;
> +struct irqaction irqaction;
> +struct vuart_info vuart;
> +} meson_s905_com = {0};
> +
> +#define meson_s905_read(uart, off)  readl((uart)->regs + off)
> +#define meson_s905_write(uart, off, val) writel(val, (uart->regs) + off)

I was wondering whether a clrsetbit helper would be more useful than
these very thin wrappers.

> +static void meson_s905_uart_interrupt(int irq, void *data,
> +struct cpu_user_regs *regs)
> +{
> +struct serial_port *port = data;
> +struct meson_s905_uart *uart = port->uart;
> +uint32_t st = meson_s905_read(uart, UART_STATUS);
> +
> +if ( !(st & UART_RX_EMPTY) )
> +{
> +serial_rx_in

[Xen-devel] [RFC PATCH 1/2] xen/arm: Add Amlogic S905 SoC early printk support

[André Przywara]

On 8/7/18 6:07 PM, Amit Singh Tomar wrote:

Hi,

commit message?

> Signed-off-by: Amit Singh Tomar 
> ---
>  docs/misc/arm/early-printk.txt |  1 +
>  xen/arch/arm/Rules.mk  |  1 +
>  xen/arch/arm/arm64/debug-meson.inc | 50
> ++ 3 files changed, 52
> insertions(+) create mode 100644 xen/arch/arm/arm64/debug-meson.inc
> 
> diff --git a/docs/misc/arm/early-printk.txt
> b/docs/misc/arm/early-printk.txt index f765f59..2aa9528 100644
> --- a/docs/misc/arm/early-printk.txt
> +++ b/docs/misc/arm/early-printk.txt
> @@ -41,6 +41,7 @@ the name of the machine:
>- juno: printk with pl011 on Juno platform
>- lager: printk with SCIF0 on Renesas R-Car H2 processors
>- midway: printk with the pl011 on Calxeda Midway processors
> +  - meson: printk with the MESON for Amlogic S905 SoCs
>- mvebu: printk with the MVEBU for Marvell Armada 3700 SoCs
>- omap5432: printk with UART3 on TI OMAP5432 processors
>- rcar3: printk with SCIF2 on Renesas R-Car Gen3 processors
> diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
> index f264592..d4fabdc 100644
> --- a/xen/arch/arm/Rules.mk
> +++ b/xen/arch/arm/Rules.mk
> @@ -36,6 +36,7 @@ EARLY_PRINTK_hikey960   := pl011,0xfff32000
>  EARLY_PRINTK_juno   := pl011,0x7ff8
>  EARLY_PRINTK_lager  := scif,0xe6e6
>  EARLY_PRINTK_midway := pl011,0xfff36000
> +EARLY_PRINTK_meson  := meson,0xc81004c0
>  EARLY_PRINTK_mvebu  := mvebu,0xd0012000
>  EARLY_PRINTK_omap5432   := 8250,0x4802,2
>  EARLY_PRINTK_rcar3  := scif,0xe6e88000
> diff --git a/xen/arch/arm/arm64/debug-meson.inc
> b/xen/arch/arm/arm64/debug-meson.inc new file mode 100644
> index 000..d5507d3
> --- /dev/null
> +++ b/xen/arch/arm/arm64/debug-meson.inc
> @@ -0,0 +1,50 @@
> +/*
> + * xen/arch/arm/arm64/debug-meson.inc
> + *
> + * MESON specific debug code.
> + *
> + * Copyright (c) 2018, Amit Singh Tomar .
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms and conditions of the GNU General Public
> + * License, version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public
> + * License along with this program; If not, see
> .
> + */
> +
> +#define UART_STATUS_REG 0x0c
> +#define UART_TX_REG 0x00

As Julien mentioned, please stick to the manual names and be consistent
with the proper Xen driver. Also, please sort by offset.

> +
> +/*
> + * MESON UART wait UART to be ready to transmit
> + * xb: register which contains the UART base address
> + * c: scratch register
> + */
> +.macro early_uart_ready xb c
> +1:
> +ldrh   w\c, [\xb, #UART_STATUS_REG] /* status register */

Why ldrh? This is a 32-bit register, actually you can't be sure that the
device supports a 16-bit access. Besides: the bit you are after is in
the upper half, so you actually will never see the bit set. I wonder if
you are loosing characters here.

> +tstw\c, #(1 << 21)  /* Check TXFIFO FULL bit
> */
> +b.ne   1b   /* Wait for the UART to
> be ready */

You can use "tbnz" to replace those two instructions.

> +.endm
> +
> +/*
> + * MESON UART transmit character
> + * xb: register which contains the UART base address
> + * wt: register which contains the character to transmit
> + */
> +.macro early_uart_transmit xb wt
> + strb  \wt, [\xb, #UART_TX_REG]

TX_WFIFO is a 32-bit register, so you should rather use a 32-bit
accessor.

Cheers,
Andre.


> +.endm
> +
> +/*
> + * Local variables:
> + * mode: ASM
> + * indent-tabs-mode: nil
> + * End:
> + */
> 


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

Re: [Xen-devel] [PATCH v4 21/23] xen/vpl011: buffer out chars when the backend is xen

[Stefano Stabellini]

On Sat, 20 Oct 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 10/20/18 12:20 AM, Stefano Stabellini wrote:
> > On Mon, 8 Oct 2018, Jan Beulich wrote:
> > > > > > On 05.10.18 at 20:47,  wrote:
> > > > --- a/xen/drivers/char/console.c
> > > > +++ b/xen/drivers/char/console.c
> > > > @@ -406,6 +406,13 @@ static void dump_console_ring_key(unsigned char
> > > > key)
> > > >*/
> > > >   static unsigned int __read_mostly console_rx = 0;
> > > >   +struct domain *console_input_domain(void)
> > > > +{
> > > > +if ( console_rx == 0 )
> > > > +return NULL;
> > > > +return get_domain_by_id(console_rx - 1);
> > > 
> > > This acquires a domain reference, yet I can't see that reference
> > > getting dropped anywhere in the caller.
> > 
> > Well spotted!
> > 
> > I'll add a comment here as a reminder, and I'll drop the domain
> > reference in the caller (xen/arch/arm/vpl011.c:vpl011_write_data_xen).
> 
> Why do you use get_domain_by_id() and not rcu_lock_domain_by_id()? The latter
> is recommend for short live reference.

Yes, you are right, that is a better solution. I'll change it to use
rcu_lock_domain_by_id. We still need the corresponding rcu_unlock_domain
call, so I'll still add a new comment and the corresponding unlock call.

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

Re: [Xen-devel] [PATCH v4 10/23] xen/arm: introduce allocate_memory

[Stefano Stabellini]

On Sat, 20 Oct 2018, Julien Grall wrote:
> > > > +
> > > > +pg = alloc_domheap_pages(d, order, 0);
> > > 
> > > So here you impose the memory to be contiguously allocated for a given
> > > bank.
> > > There are quite a few case where you may not have enough memory to
> > > allocate
> > > contiguously.
> > > 
> > > So more likely you want to add loop in this code to allocate until order
> > > is
> > > reached.
> > 
> > This case is not handled today for dom0.
> 
> I am afraid this is slightly untrue. Dom0 memory is direct mapped, Xen will
> first try to allocate the using the biggest order. If it fails, the order will
> be decreased until the size is suitable. We will always try to allocate the
> maximum of memory.
> 
> There are three major problems with your code:
>   1) There may not be enough contiguous space in the host memory for a
> 4GB region.
>   2) The memory specify by the user may not be in power of 2 pages. For
> instance, a user can specify 40KB. With your algo, we will end to allocate
> 32KB in the first bank and 8KB in the second bank. However what we want is
> allocate 40KB in a single bank.
>   3) You don't check whether the leftover memory is bigger than the size
> of the second bank.
> 
> In the case where the memory is not direct mapped, we should be able to
> allocate the whole region with multiple non-contiguous memory. I think the
> algorithm in used in libxc (see populate_guest_memory) is working quite well
> for this purpose.
> 
> It is also possible to have a simpler solution within the hypervisor. I
> quickly wrote a patch (not compiled, nor tested) that should address the 3
> problems above. See: https://pastebin.com/FQ9k9CbL

Thank you for your help. Actually I had already written something
along the same lines, I don't know why I didn't say it in my reply... I
double checked the implementation with yours here and they look
equivalent. Good.

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

Re: [Xen-devel] [PATCH v4 03/23] xen/arm: document dom0less

[Stefano Stabellini]

On Tue, 16 Oct 2018, Lars Kurth wrote:
> Hi Stefano,
> 
> > On 9 Oct 2018, at 12:52, Julien Grall  wrote:
> > 
> > Hi Stefano,
> > 
> > On 05/10/2018 19:47, Stefano Stabellini wrote:
> >> Add a new document to provide information on how to use dom0less related
> >> features and their current limitations.
> >> Signed-off-by: Stefano Stabellini 
> >> ---
> >> Changes in v4:
> >> - rename to .txt
> >> - improve wording
> >> Changes in v3:
> >> - add patch
> >> ---
> >>  docs/misc/arm/dom0less.txt | 47 
> >> ++
> > 
> > As said on the previous version, you likely need to add an entry in 
> > docs/INDEX.
> 
> Agreed. Also, it may be worthwhile encoding the doc in markdown (it's not 
> that much text) and using the .markdown extension
> Also, it seems to me that docs/features is maybe a better place for this 
> document. Not sure whether docs in this folder get picked up automatically 
> though

I can move it to docs/features and I am OK with changing it to markdown.
But please don't ask me to convert it to pandoc (all other docs under
docs/features are pandoc).

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

Re: [Xen-devel] [PATCH v4 03/23] xen/arm: document dom0less

[Stefano Stabellini]

On Tue, 9 Oct 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 05/10/2018 19:47, Stefano Stabellini wrote:
> > Add a new document to provide information on how to use dom0less related
> > features and their current limitations.
> > 
> > Signed-off-by: Stefano Stabellini 
> > 
> > ---
> > Changes in v4:
> > - rename to .txt
> > - improve wording
> > 
> > Changes in v3:
> > - add patch
> > ---
> >   docs/misc/arm/dom0less.txt | 47
> > ++
> 
> As said on the previous version, you likely need to add an entry in
> docs/INDEX.

OK

> >   1 file changed, 47 insertions(+)
> >   create mode 100644 docs/misc/arm/dom0less.txt
> > 
> > diff --git a/docs/misc/arm/dom0less.txt b/docs/misc/arm/dom0less.txt
> > new file mode 100644
> > index 000..df96b41
> > --- /dev/null
> > +++ b/docs/misc/arm/dom0less.txt
> > @@ -0,0 +1,47 @@
> > +Dom0less
> > +
> > +
> > +"Dom0less" is a set of Xen features that enable the deployment of a Xen
> > +system without an hardware domain (often referred to as "dom0").
> I realize I suggested the wording hardware domain. But reading this again, it
> feels that "control domain" may be the best wording here. Indeed what we avoid
> is the toolstack and domain control the domains.

OK


> You begin the document writing "it is a set of Xen featueres that enable
> deployment of a Xen system without an hardware domain". I understand this
> sentence as there would be no "hardware domain". But then you write "create a
> set of DomU alongside Dom0".
> 
> Furthermore, at some point the control domain would disappear and the DomID 0
> may be allocated to a DomUs. Adding further confusion to a user seen the ID
> would be 0.
> 
> So I still think that using "Dom0" within the document is misleading and also
> the feature name. I don't have a good suggestion for the feature name. But at
> very least I would avoid the word "Dom0" everywhere in that document.
 
I'll reword the document to avoid "Dom0"

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

Re: [Xen-devel] [PATCH v2] devicetree, xen: add xen, shared-memory binding

[Rob Herring]

On Mon, Oct 22, 2018 at 11:27:23AM +0100, Julien Grall wrote:
> Hi Stefano,
> 
> On 18/10/2018 23:10, Stefano Stabellini wrote:
> > From: Stefano Stabellini 
> > 
> > Introduce a device tree binding for Xen reserved-memory regions. They
> > are used to share memory across VMs from the VM config files. (See
> > static_shm config option.)
> > 
> > Signed-off-by: Stefano Stabellini 
> > ---
> > Changes in v2:
> > - fix Author line
> > - add versioning
> > - xen,id instead of id
> > ---
> >   .../bindings/reserved-memory/xen,shared-memory.txt   | 20 
> > 
> >   1 file changed, 20 insertions(+)
> >   create mode 100644 
> > Documentation/devicetree/bindings/reserved-memory/xen,shared-memory.txt
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/reserved-memory/xen,shared-memory.txt 
> > b/Documentation/devicetree/bindings/reserved-memory/xen,shared-memory.txt
> > new file mode 100644
> > index 000..9078fb7
> > --- /dev/null
> > +++ 
> > b/Documentation/devicetree/bindings/reserved-memory/xen,shared-memory.txt
> > @@ -0,0 +1,20 @@
> > +* Xen hypervisor reserved-memory binding
> > +
> > +Expose one or more memory regions as reserved-memory to the guest
> > +virtual machine. Typically, a region is configured at VM creation time
> > +to be a shared memory area across multiple virtual machines for
> > +communication among them.
> > +
> > +For each of these pre-shared memory regions, a range is exposed under
> > +the /reserved-memory node as a child node. Each range sub-node is named
> > +xen-shmem@ and has the following properties:
> > +
> > +- compatible:
> > +   compatible = "xen,shared-memory-v1", "xen,shared-memory"
> 
> Do we need to specify the two compatibles?

I'd just drop the fallback as version seems to be just in case.

Rob

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

[Xen-devel] [ovmf baseline-only test] 75480: trouble: blocked/broken

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 75480 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75480/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm  broken
 build-i386   broken
 build-amd64-pvopsbroken
 build-i386-xsm   broken
 build-amd64  broken
 build-i386-pvops broken

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 build-i3864 host-install(4)   broken baseline untested
 build-amd64   4 host-install(4)   broken baseline untested
 build-i386-pvops  4 host-install(4)   broken baseline untested
 build-i386-xsm4 host-install(4)   broken baseline untested
 build-amd64-pvops 4 host-install(4)   broken baseline untested
 build-amd64-xsm   4 host-install(4)   broken baseline untested

version targeted for testing:
 ovmf 073891a3e74059e996258e32b56b3f0770c6fe55
baseline version:
 ovmf 95aea2fac9117e95ead90378e6bb975e327d7da4

Last test of basis75476  2018-10-22 05:50:16 Z0 days
Testing same since75480  2018-10-22 14:20:46 Z0 days1 attempts


People who touched revisions under test:
  Eric Dong 
  Laszlo Ersek 
  Zhaozh1x 
  ZhiqiangX Zhao 

jobs:
 build-amd64-xsm  broken  
 build-i386-xsm   broken  
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



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.xensource.com/osstest/logs

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

broken-job build-amd64-xsm broken
broken-job build-i386 broken
broken-job build-amd64-pvops broken
broken-job build-i386-xsm broken
broken-job build-amd64 broken
broken-job build-i386-pvops broken
broken-step build-i386 host-install(4)
broken-step build-amd64 host-install(4)
broken-step build-i386-pvops host-install(4)
broken-step build-i386-xsm host-install(4)
broken-step build-amd64-pvops host-install(4)
broken-step build-amd64-xsm host-install(4)

Push not applicable.


commit 073891a3e74059e996258e32b56b3f0770c6fe55
Author: Zhaozh1x 
Date:   Thu Oct 18 10:42:34 2018 +0800

BaseTools: Convert "Unicode string" to "byte array" if value type diff

V2:
Fixed 3 typo.
Use startswith(('L"',"L'")) to check if a string is Unicode string.
Use a set PcdValueTypeSet instead of a list PcdValueTypeList to save
memory.

V1:
For the same one VOID* pcd, if the default value type of one SKU is
"Unicode string", the other SKUs are "OtherVOID*"(ASCII string or
byte array),Then convert "Unicode string" to "byte array".

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: ZhiqiangX Zhao 
Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Bob Feng 
Reviewed-by: Bob Feng 

commit 32be12235d68c0bf20337f8eed9386c4835d408a
Author: Zhaozh1x 
Date:   Wed Oct 10 16:27:02 2018 +0800

BaseTool: Support different PCDs that refers to the same EFI variable.

V2:
Make the code of patch both compatible for Python2 and Python3.

V1:
If different PCDs refer to the same EFI variable, then do EFI variable
combination, according to the VariableOffset of different PCDS.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: ZhiqiangX Zhao 
Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Bob Feng 
Reviewed-by: Bob Feng 

commit d28daaddb3e732468e930a809d3d3943a5de9558
Author: Eric Dong 
Date:   Wed Oct 17 09:24:05 2018 +08

Re: [Xen-devel] [PATCH v4 05/23] xen/arm: introduce bootcmdlines

[Stefano Stabellini]

On Tue, 9 Oct 2018, Julien Grall wrote:
> On 05/10/2018 19:47, Stefano Stabellini wrote:
> > Introduce a new array to store the cmdline of each boot module. It is
> > separate from struct bootmodules. Remove the cmdline field from struct
> > boot_module. This way, kernels and initrds with the same address in
> > memory can share struct bootmodule (important because we want them to be
> > free'd only once), but they can still have their separate bootcmdline
> > entries.
> > 
> > Add a dt_name field to struct bootcmdline to make it easier to find the
> > correct entry. Store the name of the "xen,domain" compatible node (for
> > example "Dom1"). This is a better choice compared to the name of the
> > "multiboot,kernel" compatible node, because their names are not unique.
> > For instance there can be more than one "module@0x4c00" in the
> > system, but there can only be one "/chosen/Dom1".
> > 
> > Add a pointer to struct kernel_info to point to the cmdline for a given
> > kernel.
> > 
> > Signed-off-by: Stefano Stabellini 
> > 
> > ---
> > 
> > Changes in v4:
> > - check that the multiboot node is under /chosen
> > - use cmd and cmds as variable names for struct bootcmdline and struct
> >bootcmdline*
> > - fix printk
> > - use ASSERT instea of panic
> > - do not add empty cmdline entries
> > - add more debug printks to early_print_info
> > - code style fixes
> > - add comment on DT_MAX_NAME
> > - increase DT_MAX_NAME to 41
> > - make nr_mods unsigned int
> > 
> > Changes in v3:
> > - introduce bootcmdlines
> > - do not modify boot_fdt_cmdline
> > - add comments
> > 
> > Changes in v2:
> > - new patch
> > ---
> >   xen/arch/arm/bootfdt.c  | 82
> > +
> >   xen/arch/arm/domain_build.c |  8 +++--
> >   xen/arch/arm/kernel.h   |  1 +
> >   xen/arch/arm/setup.c| 24 +
> >   xen/include/asm-arm/setup.h | 17 --
> >   5 files changed, 99 insertions(+), 33 deletions(-)
> > 
> > diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
> > index 8eba42c..273032b 100644
> > --- a/xen/arch/arm/bootfdt.c
> > +++ b/xen/arch/arm/bootfdt.c
> > @@ -163,6 +163,37 @@ static void __init process_memory_node(const void *fdt,
> > int node,
> >   }
> >   }
> >   +static void __init add_boot_cmdline(const void *fdt, int node,
> > +const char *name, bootmodule_kind kind)
> > +{
> > +struct bootcmdlines *cmds = &bootinfo.cmdlines;
> > +struct bootcmdline *cmd;
> > +const struct fdt_property *prop;
> > +int len;
> > +const char *cmdline;
> > +
> > +if ( cmds->nr_mods == MAX_MODULES )
> > +{
> > +printk("Ignoring %s cmdline (too many)\n", name);
> > +return;
> > +}
> > +
> > +prop = fdt_get_property(fdt, node, "bootargs", &len);
> > +if ( !prop )
> > +return;
> > +
> > +cmd = &cmds->cmdline[cmds->nr_mods++];
> > +cmd->kind = kind;
> > +
> > +ASSERT(strlen(name) <= DT_MAX_NAME);
> > +safe_strcpy(cmd->dt_name, name);
> > +
> > +if ( len > BOOTMOD_MAX_CMDLINE )
> > +panic("module %s command line too long\n", name);
> > +cmdline = prop->data;
> > +safe_strcpy(cmd->cmdline, cmdline);
> > +}
> > +
> >   static void __init process_multiboot_node(const void *fdt, int node,
> > const char *name,
> > u32 address_cells, u32
> > size_cells)
> > @@ -172,8 +203,20 @@ static void __init process_multiboot_node(const void
> > *fdt, int node,
> >   const __be32 *cell;
> >   bootmodule_kind kind;
> >   paddr_t start, size;
> > -const char *cmdline;
> > -int len;
> > +int len = sizeof("/chosen");
> > +char path[8]; /* sizeof "/chosen" */
> > +int parent_node;
> > +
> > +parent_node = fdt_parent_offset(fdt, node);
> > +ASSERT(parent_node >= 0);
> > +
> > +/* Check that the node is under "chosen" */
> > +fdt_get_path(fdt, node, path, len);
> 
> It would be good if you test the code with wrong node. For instance
> fdt_get_path may not fill path (i.e if the buffer is too short). So path will
> contain garbage.

I'll do


> > +if ( strncmp(path, "/chosen", len - 1) )
> > +{
> > +printk("DEBUG %s %s\n",name,path);
> 
> This looks like a left-over from your debug.

I'll remove


> > +return;
> > +}
> As I said in the previous patch, this needs to be fixed first. By that I meant
> this should be a separate patch so it could be backported.

I'll separate it out


> Also, with this patch you change correctly the behavior to deny node not in
> chosen. But you don't explain in the commit message that it affects the
> current multiboot node.

I'll mention it.


> However, I still don't think this code is correct. You would allow the
> following path /chosen/foo/bar/multiboot. The parent would be "bar" and there
> are no guarantee it would be uniq (it is not under /chosen). I think th

[Xen-devel] [PATCH v5 05/25] xen/arm: check for multiboot nodes only under /chosen

[Stefano Stabellini]

Make sure to only look for multiboot compatible nodes only under
/chosen, not under any other paths (depth <= 3).

Signed-off-by: Stefano Stabellini 

---

Changes in v5:
- add patch
- add check on return value of fdt_get_path
---
 xen/arch/arm/bootfdt.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 8eba42c..a314aca 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -173,7 +173,14 @@ static void __init process_multiboot_node(const void *fdt, 
int node,
 bootmodule_kind kind;
 paddr_t start, size;
 const char *cmdline;
-int len;
+int len = sizeof("/chosen");
+char path[8]; /* sizeof "/chosen" */
+int ret;
+
+/* Check that the node is under "chosen" */
+ret = fdt_get_path(fdt, node, path, len);
+if ( ret == 0 && strncmp(path, "/chosen", len - 1) )
+return;
 
 prop = fdt_get_property(fdt, node, "reg", &len);
 if ( !prop )
@@ -286,8 +293,8 @@ static int __init early_scan_node(const void *fdt,
 {
 if ( device_tree_node_matches(fdt, node, "memory") )
 process_memory_node(fdt, node, name, address_cells, size_cells);
-else if ( device_tree_node_compatible(fdt, node, "xen,multiboot-module" ) 
||
-  device_tree_node_compatible(fdt, node, "multiboot,module" ))
+else if ( depth <= 3 && (device_tree_node_compatible(fdt, node, 
"xen,multiboot-module" ) ||
+  device_tree_node_compatible(fdt, node, "multiboot,module" )))
 process_multiboot_node(fdt, node, name, address_cells, size_cells);
 else if ( depth == 1 && device_tree_node_matches(fdt, node, "chosen") )
 process_chosen_node(fdt, node, name, address_cells, size_cells);
-- 
1.9.1


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

[Xen-devel] [PATCH v5 02/25] xen/arm: extend device tree based multiboot protocol

[Stefano Stabellini]

Extend the existing device tree based multiboot protocol to include
information regarding multiple domains to boot.

Signed-off-by: Stefano Stabellini 

---
Changes in v4:
- memory is 64bit

Changes in v3:
- remove "xen,initial-domain" for now
- make vpl011 an empty property
- memory in KBs

Changes in v2:
- lower case kernel
- rename mem to memory
- mandate cpus and memory
- replace domU-kernel with kernel and domU-ramdisk with ramdisk
- rename xen,domU with xen,domain
- add info about dom0
- switch memory and cpus to integers
- remove defaults
- add vpl011
---
 docs/misc/arm/device-tree/booting.txt | 107 ++
 1 file changed, 107 insertions(+)

diff --git a/docs/misc/arm/device-tree/booting.txt 
b/docs/misc/arm/device-tree/booting.txt
index ce2d0dc..317a9e9 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -119,3 +119,110 @@ For those you would hardcode the Xen commandline in the 
DTB under
 line by writing bootargs (as for native Linux).
 A Xen-aware bootloader would set xen,xen-bootargs for Xen, xen,dom0-bootargs
 for Dom0 and bootargs for native Linux.
+
+
+Creating Multiple Domains directly from Xen
+===
+
+It is possible to have Xen create other domains, in addition to dom0,
+out of the information provided via device tree. A kernel and initrd
+(optional) need to be specified for each guest.
+
+For each domain to be created there needs to be one node under /chosen
+with the following properties:
+
+- compatible
+
+For domUs: "xen,domain"
+
+- memory
+
+   A 64-bit integer specifying the amount of kilobytes of RAM to
+allocate to the guest.
+
+- cpus
+
+An integer specifying the number of vcpus to allocate to the guest.
+
+- vpl011
+
+An empty property to enable/disable a virtual pl011 for the guest to use.
+
+- #address-cells and #size-cells
+
+Both #address-cells and #size-cells need to be specified because
+both sub-nodes (described shortly) have reg properties.
+
+Under the "xen,domain" compatible node, one or more sub-nodes are present
+for the DomU kernel and ramdisk.
+
+The kernel sub-node has the following properties:
+
+- compatible
+
+"multiboot,kernel"
+
+- reg
+
+Specifies the physical address of the kernel in RAM and its
+length.
+
+- bootargs (optional)
+
+Command line parameters for the guest kernel.
+
+The ramdisk sub-node has the following properties:
+
+- compatible
+
+"multiboot,ramdisk"
+
+- reg
+
+Specifies the physical address of the ramdisk in RAM and its
+length.
+
+
+Example
+===
+
+chosen {
+domU1 {
+compatible = "xen,domain";
+#address-cells = <0x2>;
+#size-cells = <0x1>;
+memory = <0 131072>;
+cpus = <2>;
+vpl011;
+
+module@0x4a00 {
+compatible = "multiboot,kernel";
+reg = <0x0 0x4a00 0xff>;
+bootargs = "console=ttyAMA0 init=/bin/sh";
+};
+
+module@0x4b00 {
+compatible = "multiboot,ramdisk";
+reg = <0x0 0x4b00 0xff>;
+};
+};
+
+domU2 {
+compatible = "xen,domain";
+#address-cells = <0x2>;
+#size-cells = <0x1>;
+memory = <0 65536>;
+cpus = <1>;
+
+module@0x4c00 {
+compatible = "multiboot,kernel";
+reg = <0x0 0x4c00 0xff>;
+bootargs = "console=ttyAMA0 init=/bin/sh";
+};
+
+module@0x4d00 {
+compatible = "multiboot,ramdisk";
+reg = <0x0 0x4d00 0xff>;
+};
+};
+};
-- 
1.9.1


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

[Xen-devel] [PATCH v5 03/25] xen/arm: document dom0less

[Stefano Stabellini]

Add a new document to provide information on how to use dom0less related
features and their current limitations.

Signed-off-by: Stefano Stabellini 

---
Changes in v5:
- convert to markdown
- move to docs/features
- add entry to docs/INDEX

Changes in v4:
- rename to .txt
- improve wording

Changes in v3:
- add patch
---
 docs/INDEX  |  1 +
 docs/features/dom0less.markdown | 49 +
 2 files changed, 50 insertions(+)
 create mode 100644 docs/features/dom0less.markdown

diff --git a/docs/INDEX b/docs/INDEX
index 868ab1f..e673edd 100644
--- a/docs/INDEX
+++ b/docs/INDEX
@@ -25,3 +25,4 @@ misc/arm/early-printk Enabling early printk on ARM
 misc/arm/passthrough   Passthrough a device described in the Device 
Tree to a guest
 misc/arm/device-tree/booting   Device tree bindings to boot Xen
 misc/arm/device-tree/passthrough   Device tree binding to passthrough a 
device
+features/dom0less.markdown Boot multiple domains from Xen in parallel
diff --git a/docs/features/dom0less.markdown b/docs/features/dom0less.markdown
new file mode 100644
index 000..4e342b7
--- /dev/null
+++ b/docs/features/dom0less.markdown
@@ -0,0 +1,49 @@
+Dom0less
+
+
+"Dom0less" is a set of Xen features that enable the deployment of a Xen
+system without an control domain (often referred to as "dom0"). Each
+feature can be used independently from the others, unless otherwise
+stated.
+
+Booting Multiple Domains from Device Tree
+-
+
+This feature enables Xen to create a set of DomUs at boot time.
+Information about the DomUs to be created by Xen is passed to the
+hypervisor via Device Tree. Specifically, the existing Device Tree based
+Multiboot specification has been extended to allow for multiple domains
+to be passed to Xen. See docs/misc/arm/device-tree/booting.txt for more
+information about the Multiboot specification and how to use it.
+
+Currently, a control domain ("dom0") is still required, but in the
+future it will become unnecessary when all domains are created
+directly from Xen. Instead of waiting for the control domain to be fully
+booted and the Xen tools to become available, domains created by Xen
+this way are started right away in parallel. Hence, their boot time is
+typically much shorter.
+
+Domains started by Xen at boot time currently have the following
+limitations:
+
+- They cannot be properly shutdown or rebooted using xl. If one of them
+  crashes, the whole platform should be rebooted.
+
+- Some xl operations might not work as expected. xl is meant to be used
+  with domains that have been created by it. Using xl with domains
+  started by Xen at boot might not work as expected.
+
+- The GIC version is the native version. In absence of other
+  information, the GIC version exposed to the domains started by Xen at
+  boot is the same as the native GIC version.
+
+- No PV drivers. There is no support for PV devices at the moment. All
+  devices need to be statically assigned to guests.
+
+- Pinning vCPUs of domains started by Xen at boot can be
+  done from the control domain, using `xl vcpu-pin` as usual. It is not
+  currently possible to configure vCPU pinning without a control domain.
+  However, the NULL scheduler can be selected by passing `sched=null` to
+  the Xen command line. The NULL scheduler automatically assigns and
+  pins vCPUs to pCPUs, but the vCPU-pCPU assignments cannot be
+  configured.
-- 
1.9.1


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

[Xen-devel] [PATCH v5 08/25] xen/arm: probe domU kernels and initrds

[Stefano Stabellini]

Find addresses, sizes on device tree from kernel_probe.
Find the cmdline from the bootcmdlines array.

Introduce a new boot_module_find_by_addr_and_kind function to match not
just on boot module kind, but also by address so that we can support
multiple domains.

Introduce a boot_cmdline_find_by_name function to find the right struct
cmdline based on the device tree node name of the "xen,domain"
compatible node.

Set command line for dom0 too for consistency.

Signed-off-by: Stefano Stabellini 
---
Changes in v5:
- constify kernel_probe
- add ASSERT and comment in kernel_probe
- limit variable scope
- fix printk message
- int/unsigned int
- set cmdline for dom0 too
- improve code readability

Changes in v3:
- retrieve cmdline from bootcmdlines array

Changes in v2:
- fix indentation
- unify kernel_probe with kernel_probe_domU
- find cmdline on device_tree from kernel_probe
---
 xen/arch/arm/domain_build.c |  2 +-
 xen/arch/arm/kernel.c   | 64 -
 xen/arch/arm/kernel.h   |  2 +-
 xen/arch/arm/setup.c| 31 ++
 xen/include/asm-arm/setup.h |  3 +++
 5 files changed, 93 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 8977397..8faf252 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2135,7 +2135,7 @@ int __init construct_dom0(struct domain *d)
 kinfo.unassigned_mem = dom0_mem;
 kinfo.d = d;
 
-rc = kernel_probe(&kinfo);
+rc = kernel_probe(&kinfo, NULL);
 if ( rc < 0 )
 return rc;
 
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index da8410e..d56f776 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -421,22 +421,72 @@ static int __init kernel_zimage32_probe(struct 
kernel_info *info,
 return 0;
 }
 
-int __init kernel_probe(struct kernel_info *info)
+int __init kernel_probe(struct kernel_info *info,
+const struct dt_device_node *domain)
 {
-struct bootmodule *mod = boot_module_find_by_kind(BOOTMOD_KERNEL);
+struct bootmodule *mod = NULL;
+struct bootcmdline *cmd = NULL;
+struct dt_device_node *node;
+u64 kernel_addr, initrd_addr, size;
 int rc;
 
+/* domain is NULL only for the hardware_domain */
+if ( domain == NULL )
+{
+ASSERT(is_hardware_domain(info->d));
+
+mod = boot_module_find_by_kind(BOOTMOD_KERNEL);
+
+info->kernel_bootmodule = mod;
+info->initrd_bootmodule = boot_module_find_by_kind(BOOTMOD_RAMDISK);
+
+cmd = boot_cmdline_find_by_kind(BOOTMOD_KERNEL);
+if ( cmd )
+info->cmdline = &cmd->cmdline[0];
+}
+else
+{
+const char *name = NULL;
+
+dt_for_each_child_node(domain, node)
+{
+if ( dt_device_is_compatible(node, "multiboot,kernel") )
+{
+u32 len;
+const __be32 *val;
+
+val = dt_get_property(node, "reg", &len);
+dt_get_range(&val, node, &kernel_addr, &size);
+mod = boot_module_find_by_addr_and_kind(
+BOOTMOD_KERNEL, kernel_addr);
+info->kernel_bootmodule = mod;
+}
+else if ( dt_device_is_compatible(node, "multiboot,ramdisk") )
+{
+u32 len;
+const __be32 *val;
+
+val = dt_get_property(node, "reg", &len);
+dt_get_range(&val, node, &initrd_addr, &size);
+info->initrd_bootmodule = boot_module_find_by_addr_and_kind(
+BOOTMOD_RAMDISK, initrd_addr);
+}
+else
+continue;
+}
+name = dt_node_name(domain);
+cmd = boot_cmdline_find_by_name(name);
+if ( cmd )
+info->cmdline = &cmd->cmdline[0];
+}
 if ( !mod || !mod->size )
 {
 printk(XENLOG_ERR "Missing kernel boot module?\n");
 return -ENOENT;
 }
 
-info->kernel_bootmodule = mod;
-
-printk("Loading kernel from boot module @ %"PRIpaddr"\n", mod->start);
-
-info->initrd_bootmodule = boot_module_find_by_kind(BOOTMOD_RAMDISK);
+printk("Loading Dom%d kernel from boot module @ %"PRIpaddr"\n",
+   info->d->domain_id, info->kernel_bootmodule->start);
 if ( info->initrd_bootmodule )
 printk("Loading ramdisk from boot module @ %"PRIpaddr"\n",
info->initrd_bootmodule->start);
diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
index 39b7828..4320f72 100644
--- a/xen/arch/arm/kernel.h
+++ b/xen/arch/arm/kernel.h
@@ -55,7 +55,7 @@ struct kernel_info {
  *  ->type
  *  ->load hook, and sets loader specific variables ->zimage
  */
-int kernel_probe(struct kernel_info *info);
+int kernel_probe(struct kernel_info *info, const struct dt_device_node 
*domain);
 
 /*
  * Loads the kernel into guest RAM.
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c

[Xen-devel] [PATCH v5 14/25] xen/arm: introduce create_domUs

[Stefano Stabellini]

Call a new function, "create_domUs", from setup_xen to start DomU VMs.

Introduce support for the "xen,domain" compatible node on device tree.
Create new DomU VMs based on the information found on device tree under
"xen,domain". Call construct_domU for each domain.

Introduce a simple global variable named max_init_domid to keep track of
the initial allocated domids. It holds the max domid among the initial
domains.

Move the discard_initial_modules after DomUs have been built.

First create domUs, then start dom0 -- no point in trying to start dom0
when the cpu is busy.

Signed-off-by: Stefano Stabellini 
Acked-by: Jan Beulich 
CC: andrew.coop...@citrix.com
CC: jbeul...@suse.com
---
Changes in v5:
- use dt_property_read_bool
- improve commit message
- code style
- use dt_find_node_by_path instead of dt_find_node_by_name
- use true with is_console

Changes in v4:
- constify parameters
- nr_spis to 0 or  GUEST_VPL011_SPI - 32 + 1 depending on vpl011
- remove pointless initializer
- remove change to domain_create for dom0 (useless)
- make construct_domU return error

Changes in v3:
- move patch earlier and introduce empty construct_domU to fix bisection
  builds
- fix max_init_domid to actually hold the max domid among initial
  domains (instead of max_domid + 1)
- move domain_unpause_by_systemcontroller(dom0) after creating domUs

Changes in v2:
- coding style
- set nr_spis to 32
- introduce create_domUs
---
 xen/arch/arm/domain_build.c | 50 +
 xen/arch/arm/setup.c|  5 +
 xen/include/asm-arm/setup.h |  3 +++
 xen/include/asm-x86/setup.h |  2 ++
 4 files changed, 56 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d1dab5a..93e9510 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2304,6 +2305,50 @@ static int __init construct_domain(struct domain *d, 
struct kernel_info *kinfo)
 return 0;
 }
 
+static int __init construct_domU(struct domain *d,
+ const struct dt_device_node *node)
+{
+return -ENOSYS;
+}
+
+void __init create_domUs(void)
+{
+struct dt_device_node *node;
+const struct dt_device_node *chosen = dt_find_node_by_path("/chosen");
+
+BUG_ON(chosen == NULL);
+dt_for_each_child_node(chosen, node)
+{
+struct domain *d;
+struct xen_domctl_createdomain d_cfg = {
+.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE,
+.arch.nr_spis = 0,
+.max_vcpus = 1,
+.max_evtchn_port = -1,
+.max_grant_frames = 64,
+.max_maptrack_frames = 1024,
+};
+
+if ( !dt_device_is_compatible(node, "xen,domain") )
+continue;
+
+if ( dt_property_read_bool(node, "vpl011") )
+d_cfg.arch.nr_spis = GUEST_VPL011_SPI - 32 + 1;
+dt_property_read_u32(node, "cpus", &d_cfg.max_vcpus);
+
+d = domain_create(++max_init_domid, &d_cfg, false);
+if ( IS_ERR(d) )
+panic("Error creating domain %s", dt_node_name(node));
+
+d->is_console = true;
+
+if ( construct_domU(d, node) != 0 )
+panic("Could not set up domain %s", dt_node_name(node));
+
+domain_unpause_by_systemcontroller(d);
+}
+}
+
 int __init construct_dom0(struct domain *d)
 {
 const struct bootcmdline *kernel = 
boot_cmdline_find_by_kind(BOOTMOD_KERNEL);
@@ -2356,10 +2401,7 @@ int __init construct_dom0(struct domain *d)
 if ( rc < 0 )
 return rc;
 
-rc = construct_domain(d, &kinfo);
-discard_initial_modules();
-
-return rc;
+return construct_domain(d, &kinfo);
 }
 
 /*
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index f3dc96c..43eb208 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -64,11 +64,14 @@ static unsigned long opt_xenheap_megabytes __initdata;
 integer_param("xenheap_megabytes", opt_xenheap_megabytes);
 #endif
 
+domid_t __read_mostly max_init_domid;
+
 static __used void init_done(void)
 {
 /* Must be done past setting system_state. */
 unregister_init_virtual_region();
 
+discard_initial_modules();
 free_init_memory();
 startup_cpu_idle_loop();
 }
@@ -958,6 +961,8 @@ void __init start_xen(unsigned long boot_phys_offset,
 
 system_state = SYS_STATE_active;
 
+create_domUs();
+
 domain_unpause_by_systemcontroller(dom0);
 
 /* Switch on to the dynamically allocated stack for the idle vcpu
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 33fb04e..3071ba8 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -74,6 +74,8 @@ struct bootinfo {
 
 extern struct bootinfo bootinfo;
 
+extern domid_t max_init_domid;
+
 void arch_init_memory(void);
 
 void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
@@ -90,6 +92,7 @@ void acpi_create

[Xen-devel] [PATCH v5 01/25] xen: allow console_io hypercalls from certain DomUs

[Stefano Stabellini]

Introduce an is_console option to allow certain classes of domUs to use
the Xen console. Specifically, it will be used to give console access to
all domUs started from Xen from information on device tree.

Signed-off-by: Stefano Stabellini 
Acked-by: Daniel De Graaf 
CC: andrew.coop...@citrix.com
CC: george.dun...@eu.citrix.com
CC: ian.jack...@eu.citrix.com
CC: jbeul...@suse.com
CC: konrad.w...@oracle.com
CC: t...@xen.org
CC: wei.l...@citrix.com
CC: dgde...@tycho.nsa.gov
---
Changes in v3:
- remove changes to hooks.c

Changes in v2:
- introduce is_console
- remove #ifdefs
---
 xen/include/xen/sched.h | 2 ++
 xen/include/xsm/dummy.h | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 0ba80cb..abcc74e 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -379,6 +379,8 @@ struct domain
 bool auto_node_affinity;
 /* Is this guest fully privileged (aka dom0)? */
 bool is_privileged;
+/* Can this guest access the Xen console? */
+bool is_console;
 /* Is this a xenstore domain (not dom0)? */
 bool is_xenstore;
 /* Domain's VCPUs are pinned 1:1 to physical CPUs? */
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index b0ac1f6..29d7b50 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -230,6 +230,8 @@ static XSM_INLINE int 
xsm_memory_stat_reservation(XSM_DEFAULT_ARG struct domain
 static XSM_INLINE int xsm_console_io(XSM_DEFAULT_ARG struct domain *d, int cmd)
 {
 XSM_ASSERT_ACTION(XSM_OTHER);
+if ( d->is_console )
+return xsm_default_action(XSM_HOOK, d, NULL);
 #ifdef CONFIG_VERBOSE_DEBUG
 if ( cmd == CONSOLEIO_write )
 return xsm_default_action(XSM_HOOK, d, NULL);
-- 
1.9.1


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

[Xen-devel] [PATCH v5 22/25] xen/arm: Allow vpl011 to be used by DomU

[Stefano Stabellini]

Make vpl011 being able to be used without a userspace component in Dom0.
In that case, output is printed to the Xen serial and input is received
from the Xen serial one character at a time.

Call domain_vpl011_init during construct_domU if vpl011 is enabled.

Introduce a new ring struct with only the ring array to avoid a waste of
memory. Introduce separate read_data and write_data functions for
initial domains: vpl011_write_data_xen is very simple and just writes
to the console, while vpl011_read_data_xen is a duplicate of
vpl011_read_data. Although textually almost identical, we are forced to
duplicate the functions because the struct layout is different.

Output characters are printed one by one, potentially leading to
intermixed output of different domains on the console. A follow-up patch
will solve the issue by introducing buffering.

Signed-off-by: Stefano Stabellini 
Acked-by: Julien Grall 
---
Changes in v5:
- renable call to vpl011_rx_char_xen from console.c

Changes in v4:
- code style

Changes in v3:
- add in-code comments
- improve existing comments
- remove ifdef around domain_vpl011_init in construct_domU
- add ASSERT
- use SBSA_UART_FIFO_SIZE for in buffer size
- rename ring_enable to backend_in_domain
- rename struct xencons_in to struct vpl011_xen_backend
- rename inring field to xen
- rename helper functions accordingly
- remove unnecessary stub implementation of vpl011_rx_char
- move vpl011_rx_char_xen within the file to avoid the need of a forward
  declaration of vpl011_data_avail
- fix small bug in vpl011_rx_char_xen: increment in_prod before using it
  to check xencons_queued.

Changes in v2:
- only init if vpl011
- rename vpl011_read_char to vpl011_rx_char
- remove spurious change
- fix coding style
- use different ring struct
- move the write_data changes to their own function
  (vpl011_write_data_noring)
- duplicate vpl011_read_data
---
 xen/arch/arm/domain_build.c  |   9 +-
 xen/arch/arm/vpl011.c| 200 +--
 xen/drivers/char/console.c   |   2 +-
 xen/include/asm-arm/vpl011.h |   8 ++
 4 files changed, 193 insertions(+), 26 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 6026b77..9ffd919 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2629,7 +2629,14 @@ static int __init construct_domU(struct domain *d,
 if ( rc < 0 )
 return rc;
 
-return construct_domain(d, &kinfo);
+rc = construct_domain(d, &kinfo);
+if ( rc < 0 )
+return rc;
+
+if ( kinfo.vpl011 )
+rc = domain_vpl011_init(d, NULL);
+
+return rc;
 }
 
 void __init create_domUs(void)
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 68452a8..131507e 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -77,6 +77,91 @@ static void vpl011_update_interrupt_status(struct domain *d)
 #endif
 }
 
+/*
+ * vpl011_write_data_xen writes chars from the vpl011 out buffer to the
+ * console. Only to be used when the backend is Xen.
+ */
+static void vpl011_write_data_xen(struct domain *d, uint8_t data)
+{
+unsigned long flags;
+struct vpl011 *vpl011 = &d->arch.vpl011;
+
+VPL011_LOCK(d, flags);
+
+printk("%c", data);
+if (data == '\n')
+printk("DOM%u: ", d->domain_id);
+
+vpl011->uartris |= TXI;
+vpl011->uartfr &= ~TXFE;
+vpl011_update_interrupt_status(d);
+
+VPL011_UNLOCK(d, flags);
+}
+
+/*
+ * vpl011_read_data_xen reads data when the backend is xen. Characters
+ * are added to the vpl011 receive buffer by vpl011_rx_char_xen.
+ */
+static uint8_t vpl011_read_data_xen(struct domain *d)
+{
+unsigned long flags;
+uint8_t data = 0;
+struct vpl011 *vpl011 = &d->arch.vpl011;
+struct vpl011_xen_backend *intf = vpl011->backend.xen;
+XENCONS_RING_IDX in_cons, in_prod;
+
+VPL011_LOCK(d, flags);
+
+in_cons = intf->in_cons;
+in_prod = intf->in_prod;
+
+smp_rmb();
+
+/*
+ * It is expected that there will be data in the ring buffer when this
+ * function is called since the guest is expected to read the data register
+ * only if the TXFE flag is not set.
+ * If the guest still does read when TXFE bit is set then 0 will be 
returned.
+ */
+if ( xencons_queued(in_prod, in_cons, sizeof(intf->in)) > 0 )
+{
+unsigned int fifo_level;
+
+data = intf->in[xencons_mask(in_cons, sizeof(intf->in))];
+in_cons += 1;
+smp_mb();
+intf->in_cons = in_cons;
+
+fifo_level = xencons_queued(in_prod, in_cons, sizeof(intf->in));
+
+/* If the FIFO is now empty, we clear the receive timeout interrupt. */
+if ( fifo_level == 0 )
+{
+vpl011->uartfr |= RXFE;
+vpl011->uartris &= ~RTI;
+}
+
+/* If the FIFO is more than half empty, we clear the RX interrupt. */
+if ( fifo_level < sizeof(intf->in) - SBSA_UART_FIFO_LEVEL )
+vpl011->uartris &= ~RXI;
+
+

[Xen-devel] [PATCH v5 18/25] xen/arm: generate vpl011 node on device tree for domU

[Stefano Stabellini]

Introduce vpl011 support to guests started from Xen: it provides a
simple way to print output from a guest, as most guests come with a
pl011 driver. It is also able to provide a working console with
interrupt support.

The UART exposed to the guest is a SBSA compatible UART and not a PL011.
SBSA UART is a subset of PL011 r1p5. A full PL011 implementation in Xen
would just be too difficult, so guests may require some drivers changes.

Enable vpl011 conditionally if the user requested it.

Signed-off-by: Stefano Stabellini 
---
Changes in v5:
- use dt_property_read_bool

Changes in v4:
- move rename set_interrupt_ppi and making set_interrupt_ppi generic to
  a separate patch
- properly name the vpl011 device node name
- code style
- use #define for addrcells and sizecells

Changes in v3:
- use bool
- retain BUG_ON(irq < 16)
- add vpl011 bool to kinfo
- return error of vpl011 is required but CONFIG_SBSA_VUART_CONSOLE is
  missing

Changes in v2:
- code style fixes
- make set_interrupt_ppi generic
- rename set_interrupt_ppi to set_interrupt
- only make the vpl011 node if the option was enabled
---
 xen/arch/arm/domain_build.c | 60 +
 xen/arch/arm/kernel.h   |  3 +++
 2 files changed, 63 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index a7fd4f1..6026b77 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1620,6 +1620,54 @@ static int __init make_timer_domU_node(const struct 
domain *d, void *fdt)
 return res;
 }
 
+#ifdef CONFIG_SBSA_VUART_CONSOLE
+static int __init make_vpl011_uart_node(const struct domain *d, void *fdt)
+{
+int res;
+gic_interrupt_t intr;
+__be32 reg[GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS];
+__be32 *cells;
+
+res = fdt_begin_node(fdt, "sbsa-uart@"__stringify(GUEST_PL011_BASE));
+if ( res )
+return res;
+
+res = fdt_property_string(fdt, "compatible", "arm,sbsa-uart");
+if ( res )
+return res;
+
+cells = ®[0];
+dt_child_set_range(&cells, GUEST_ROOT_ADDRESS_CELLS,
+   GUEST_ROOT_SIZE_CELLS, GUEST_PL011_BASE,
+   GUEST_PL011_SIZE);
+if ( res )
+return res;
+res = fdt_property(fdt, "reg", reg, sizeof(reg));
+if ( res )
+return res;
+
+set_interrupt(intr, GUEST_VPL011_SPI, 0xf, DT_IRQ_TYPE_LEVEL_HIGH);
+
+res = fdt_property(fdt, "interrupts", intr, sizeof (intr));
+if ( res )
+return res;
+
+res = fdt_property_cell(fdt, "interrupt-parent",
+GUEST_PHANDLE_GIC);
+if ( res )
+return res;
+
+/* Use a default baud rate of 115200. */
+fdt_property_u32(fdt, "current-speed", 115200);
+
+res = fdt_end_node(fdt);
+if ( res )
+return res;
+
+return 0;
+}
+#endif
+
 /*
  * The max size for DT is 2MB. However, the generated DT is small, 4KB
  * are enough for now, but we might have to increase it in the future.
@@ -1681,6 +1729,16 @@ static int __init prepare_dtb_domU(struct domain *d, 
struct kernel_info *kinfo)
 if ( ret )
 goto err;
 
+if ( kinfo->vpl011 )
+{
+ret = -EINVAL;
+#ifdef CONFIG_SBSA_VUART_CONSOLE
+ret = make_vpl011_uart_node(d, kinfo->fdt);
+#endif
+if ( ret )
+goto err;
+}
+
 ret = fdt_end_node(kinfo->fdt);
 if ( ret < 0 )
 goto err;
@@ -2549,6 +2607,8 @@ static int __init construct_domU(struct domain *d,
 
 printk("*** LOADING DOMU cpus=%u memory=%luKB ***\n", d->max_vcpus, mem);
 
+kinfo.vpl011 = dt_property_read_bool(node, "vpl011");
+
 if ( vcpu_create(d, 0, 0) == NULL )
 return -ENOMEM;
 d->max_pages = ~0U;
diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
index 4320f72..33f3e72 100644
--- a/xen/arch/arm/kernel.h
+++ b/xen/arch/arm/kernel.h
@@ -33,6 +33,9 @@ struct kernel_info {
 paddr_t dtb_paddr;
 paddr_t initrd_paddr;
 
+/* Enable pl011 emulation */
+bool vpl011;
+
 /* loader to use for this kernel */
 void (*load)(struct kernel_info *info);
 /* loader specific state */
-- 
1.9.1


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

[Xen-devel] [PATCH v5 00/25] dom0less step1: boot multiple domains from device tree

[Stefano Stabellini]

Hi all,

This is first step toward "dom0less" as discussed in the various
certifications related threads and discussions.

The goal of this series is to enable Xen to boot multiple domains in
parallel, in addition to dom0, out of information found on device tree.

The device tree based boot protocol is extended to carry information
about DomUs. Based on that information, Xen creates and starts one or
more DomUs. DomUs created this way don't have access to xenstore for the
moment. This is actually OK, because this is meant for mission critical
applications that typically only access directly assigned devices. They
cannot tolerate interference or increased IRQ latency due to PV
protocols. Device assignment is not actually covered by this series, it
will be added later.

DomUs can print to the Xen serial using the CONSOLEIO hypercalls. A
virtual PL011 is also emulated for them so that they can use their
regular PL011 driver. This allows unmodified guests to run as Xen on ARM
guests -- no Xen support needed at all. Console input also comes from
the Xen serial: the Ctrl-AAA switching mechanism is extended to switch
among domUs, dom0, and Xen.

In this version of the series, I reordered the patches to make sure they
are all bisectable.


Cheers,

Stefano



The following changes since commit 359970fd8b781fac2ddcbc84dd5b890075fa08ef:

  tools/libxl: Switch Arm guest type to PVH (2018-10-03 15:58:02 +0100)

are available in the git repository at:

  http://xenbits.xenproject.org/git-http/people/sstabellini/xen-unstable.git 
dom0less-v5

for you to fetch changes up to b97df820bf3687dccf6401fb8174f5e4d8d2d8c3:

  xen/arm: split domain_build.c (2018-10-22 18:59:12 -0700)


Stefano Stabellini (25):
  xen: allow console_io hypercalls from certain DomUs
  xen/arm: extend device tree based multiboot protocol
  xen/arm: document dom0less
  xen/arm: increase MAX_MODULES
  xen/arm: check for multiboot nodes only under /chosen
  xen/arm: introduce bootcmdlines
  xen/arm: don't add duplicate boot modules, introduce domU flag
  xen/arm: probe domU kernels and initrds
  xen/arm: rename get_11_allocation_size to get_allocation_size
  xen/arm: rename allocate_memory to allocate_memory_11
  xen/arm: introduce allocate_memory
  xen/arm: refactor construct_dom0
  xen/arm: move unregister_init_virtual_region to init_done
  xen/arm: introduce create_domUs
  xen/arm: implement construct_domU
  xen/arm: generate a simple device tree for domUs
  xen/arm: make set_interrupt_ppi able to handle non-PPI
  xen/arm: generate vpl011 node on device tree for domU
  xen/arm: introduce a union in vpl011
  xen/arm: refactor vpl011_data_avail
  xen: support console_switching between Dom0 and DomUs on ARM
  xen/arm: Allow vpl011 to be used by DomU
  xen/vpl011: buffer out chars when the backend is xen
  xen/arm: move kernel.h to asm-arm/
  xen/arm: split domain_build.c

 docs/INDEX |1 +
 docs/features/dom0less.markdown|   49 ++
 docs/misc/arm/device-tree/booting.txt  |  107 +++
 xen/arch/arm/acpi/Makefile |1 +
 xen/arch/arm/acpi/domain_build.c   |  592 +++
 xen/arch/arm/bootfdt.c |   57 +-
 xen/arch/arm/domain_build.c| 1101 +---
 xen/arch/arm/kernel.c  |   67 +-
 xen/arch/arm/setup.c   |  107 ++-
 xen/arch/arm/vpl011.c  |  296 ++--
 xen/drivers/char/console.c |   87 ++-
 xen/include/asm-arm/domain_build.h |   31 +
 xen/{arch/arm => include/asm-arm}/kernel.h |6 +-
 xen/include/asm-arm/setup.h|   35 +-
 xen/include/asm-arm/vpl011.h   |   20 +-
 xen/include/asm-x86/setup.h|2 +
 xen/include/xen/console.h  |2 +
 xen/include/xen/sched.h|2 +
 xen/include/xsm/dummy.h|2 +
 19 files changed, 1855 insertions(+), 710 deletions(-)
 create mode 100644 docs/features/dom0less.markdown
 create mode 100644 xen/arch/arm/acpi/domain_build.c
 create mode 100644 xen/include/asm-arm/domain_build.h
 rename xen/{arch/arm => include/asm-arm}/kernel.h (91%)

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

[Xen-devel] [PATCH v5 12/25] xen/arm: refactor construct_dom0

[Stefano Stabellini]

Move generic initializations out of construct_dom0 so that they can be
reused.

Rename prepare_dtb to prepare_dtb_hwdom to avoid confusion.

No functional changes in this patch.

Signed-off-by: Stefano Stabellini 

---
Changes in v5:
- rename __construct_domain to construct_domain

Changes in v4:
- newline and style changes

Changes in v3:
- move setting type before allocate_memory
- add ifdef around it and a comment

Changes in v2:
- move discard_initial_modules() after __construct_domain()
- remove useless blank line
- leave safety BUG_ONs in __construct_domain
- rename prepare_dtb to prepare_dtb_hwdom
---
 xen/arch/arm/domain_build.c | 126 
 1 file changed, 68 insertions(+), 58 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 146d81e..d1dab5a 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1470,7 +1470,7 @@ static int __init handle_node(struct domain *d, struct 
kernel_info *kinfo,
 return res;
 }
 
-static int __init prepare_dtb(struct domain *d, struct kernel_info *kinfo)
+static int __init prepare_dtb_hwdom(struct domain *d, struct kernel_info 
*kinfo)
 {
 const p2m_type_t default_p2mt = p2m_mmio_direct_c;
 const void *fdt;
@@ -2205,75 +2205,29 @@ static void __init find_gnttab_region(struct domain *d,
kinfo->gnttab_start, kinfo->gnttab_start + kinfo->gnttab_size);
 }
 
-int __init construct_dom0(struct domain *d)
+static int __init construct_domain(struct domain *d, struct kernel_info *kinfo)
 {
-const struct bootcmdline *kernel = 
boot_cmdline_find_by_kind(BOOTMOD_KERNEL);
-struct kernel_info kinfo = {};
 struct vcpu *saved_current;
-int rc, i, cpu;
-
+int i, cpu;
 struct vcpu *v = d->vcpu[0];
 struct cpu_user_regs *regs = &v->arch.cpu_info->guest_cpu_user_regs;
 
-/* Sanity! */
-BUG_ON(d->domain_id != 0);
 BUG_ON(d->vcpu[0] == NULL);
 BUG_ON(v->is_initialised);
 
-printk("*** LOADING DOMAIN 0 ***\n");
-if ( dom0_mem <= 0 )
-{
-warning_add("PLEASE SPECIFY dom0_mem PARAMETER - USING 512M FOR 
NOW\n");
-dom0_mem = MB(512);
-}
-
-
-iommu_hwdom_init(d);
-
-d->max_pages = ~0U;
-
-kinfo.unassigned_mem = dom0_mem;
-kinfo.d = d;
-
-rc = kernel_probe(&kinfo, NULL);
-if ( rc < 0 )
-return rc;
-
 #ifdef CONFIG_ARM_64
 /* if aarch32 mode is not supported at EL1 do not allow 32-bit domain */
-if ( !(cpu_has_el1_32) && kinfo.type == DOMAIN_32BIT )
+if ( !(cpu_has_el1_32) && kinfo->type == DOMAIN_32BIT )
 {
 printk("Platform does not support 32-bit domain\n");
 return -EINVAL;
 }
-d->arch.type = kinfo.type;
 
 if ( is_64bit_domain(d) )
 vcpu_switch_to_aarch64_mode(v);
 
 #endif
 
-kinfo.cmdline = kernel != NULL ? &kernel->cmdline[0] : NULL;
-allocate_memory_11(d, &kinfo);
-find_gnttab_region(d, &kinfo);
-
-/* Map extra GIC MMIO, irqs and other hw stuffs to dom0. */
-rc = gic_map_hwdom_extra_mappings(d);
-if ( rc < 0 )
-return rc;
-
-rc = platform_specific_mapping(d);
-if ( rc < 0 )
-return rc;
-
-if ( acpi_disabled )
-rc = prepare_dtb(d, &kinfo);
-else
-rc = prepare_acpi(d, &kinfo);
-
-if ( rc < 0 )
-return rc;
-
 /*
  * The following loads use the domain's p2m and require current to
  * be a vcpu of the domain, temporarily switch
@@ -2286,20 +2240,18 @@ int __init construct_dom0(struct domain *d)
  * kernel_load will determine the placement of the kernel as well
  * as the initrd & fdt in RAM, so call it first.
  */
-kernel_load(&kinfo);
+kernel_load(kinfo);
 /* initrd_load will fix up the fdt, so call it before dtb_load */
-initrd_load(&kinfo);
-dtb_load(&kinfo);
+initrd_load(kinfo);
+dtb_load(kinfo);
 
 /* Now that we are done restore the original p2m and current. */
 set_current(saved_current);
 p2m_restore_state(saved_current);
 
-discard_initial_modules();
-
 memset(regs, 0, sizeof(*regs));
 
-regs->pc = (register_t)kinfo.entry;
+regs->pc = (register_t)kinfo->entry;
 
 if ( is_32bit_domain(d) )
 {
@@ -2317,14 +2269,14 @@ int __init construct_dom0(struct domain *d)
  */
 regs->r0 = 0; /* SBZ */
 regs->r1 = 0x; /* We use DTB therefore no machine id */
-regs->r2 = kinfo.dtb_paddr;
+regs->r2 = kinfo->dtb_paddr;
 }
 #ifdef CONFIG_ARM_64
 else
 {
 regs->cpsr = PSR_GUEST64_INIT;
 /* From linux/Documentation/arm64/booting.txt */
-regs->x0 = kinfo.dtb_paddr;
+regs->x0 = kinfo->dtb_paddr;
 regs->x1 = 0; /* Reserved for future use */
 regs->x2 = 0; /* Reserved for future use */
 regs->x3 = 0; /* Reserved for future use */
@@ -2352,6 +2304,64 @@ int __init construct_dom0(struct domain *d)
 return 0;
 }
 
+int __init construct_dom0(struct

[Xen-devel] [PATCH v5 10/25] xen/arm: rename allocate_memory to allocate_memory_11

[Stefano Stabellini]

allocate_memory only deals with directly mapped memory. Rename it to
allocate_memory_11.

Signed-off-by: Stefano Stabellini 
Acked-by: Julien Grall 

---
Changes in v3:
- add patch
---
 xen/arch/arm/domain_build.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index c4ae39b..c61a27f 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -243,7 +243,8 @@ fail:
  * (as described above) we allow higher allocations and continue until
  * that runs out (or we have allocated sufficient dom0 memory).
  */
-static void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
+static void __init allocate_memory_11(struct domain *d,
+  struct kernel_info *kinfo)
 {
 const unsigned int min_low_order =
 get_order_from_bytes(min_t(paddr_t, dom0_mem, MB(128)));
@@ -2154,7 +2155,7 @@ int __init construct_dom0(struct domain *d)
 #endif
 
 kinfo.cmdline = kernel != NULL ? &kernel->cmdline[0] : NULL;
-allocate_memory(d, &kinfo);
+allocate_memory_11(d, &kinfo);
 find_gnttab_region(d, &kinfo);
 
 /* Map extra GIC MMIO, irqs and other hw stuffs to dom0. */
-- 
1.9.1


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

[Xen-devel] [PATCH v5 17/25] xen/arm: make set_interrupt_ppi able to handle non-PPI

[Stefano Stabellini]

also rename it to set_interrupt.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Julien Grall 
---
 xen/arch/arm/domain_build.c | 29 +++--
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 4a6ed23..a7fd4f1 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -592,19 +592,20 @@ static int __init write_properties(struct domain *d, 
struct kernel_info *kinfo,
 
 typedef __be32 gic_interrupt_t[3];
 
-static void __init set_interrupt_ppi(gic_interrupt_t interrupt,
- unsigned int irq,
- unsigned int cpumask,
- unsigned int level)
+static void __init set_interrupt(gic_interrupt_t interrupt,
+ unsigned int irq,
+ unsigned int cpumask,
+ unsigned int level)
 {
 __be32 *cells = interrupt;
+bool is_ppi = !!(irq < 32);
 
 BUG_ON(irq < 16);
-BUG_ON(irq >= 32);
+irq -= (is_ppi) ? 16: 32; /* PPIs start at 16, SPIs at 32 */
 
 /* See linux 
Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt */
-dt_set_cell(&cells, 1, 1); /* is a PPI */
-dt_set_cell(&cells, 1, irq - 16); /* PPIs start at 16 */
+dt_set_cell(&cells, 1, is_ppi); /* is a PPI? */
+dt_set_cell(&cells, 1, irq);
 dt_set_cell(&cells, 1, (cpumask << 8) | level);
 }
 
@@ -727,7 +728,7 @@ static int __init make_hypervisor_node(struct domain *d,
  *  - All CPUs
  *  TODO: Handle properly the cpumask;
  */
-set_interrupt_ppi(intr, d->arch.evtchn_irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intr, d->arch.evtchn_irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
 res = fdt_property_interrupts(fdt, &intr, 1);
 if ( res )
 return res;
@@ -1004,15 +1005,15 @@ static int __init make_timer_node(const struct domain 
*d, void *fdt,
 
 irq = timer_get_irq(TIMER_PHYS_SECURE_PPI);
 dt_dprintk("  Secure interrupt %u\n", irq);
-set_interrupt_ppi(intrs[0], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[0], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
 
 irq = timer_get_irq(TIMER_PHYS_NONSECURE_PPI);
 dt_dprintk("  Non secure interrupt %u\n", irq);
-set_interrupt_ppi(intrs[1], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[1], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
 
 irq = timer_get_irq(TIMER_VIRT_PPI);
 dt_dprintk("  Virt interrupt %u\n", irq);
-set_interrupt_ppi(intrs[2], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[2], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
 
 res = fdt_property_interrupts(fdt, intrs, 3);
 if ( res )
@@ -1601,9 +1602,9 @@ static int __init make_timer_domU_node(const struct 
domain *d, void *fdt)
 return res;
 }
 
-set_interrupt_ppi(intrs[0], GUEST_TIMER_PHYS_S_PPI, 0xf, 
DT_IRQ_TYPE_LEVEL_LOW);
-set_interrupt_ppi(intrs[1], GUEST_TIMER_PHYS_NS_PPI, 0xf, 
DT_IRQ_TYPE_LEVEL_LOW);
-set_interrupt_ppi(intrs[2], GUEST_TIMER_VIRT_PPI, 0xf, 
DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[0], GUEST_TIMER_PHYS_S_PPI, 0xf, 
DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[1], GUEST_TIMER_PHYS_NS_PPI, 0xf, 
DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[2], GUEST_TIMER_VIRT_PPI, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
 
 res = fdt_property(fdt, "interrupts", intrs, sizeof (intrs[0]) * 3);
 if ( res )
-- 
1.9.1


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

[Xen-devel] [PATCH v5 11/25] xen/arm: introduce allocate_memory

[Stefano Stabellini]

Introduce an allocate_memory function able to allocate memory for DomUs
and map it at the right guest addresses, according to the guest memory
map: GUEST_RAM0_BASE and GUEST_RAM1_BASE.

This is under #if 0 as not used for now.

Signed-off-by: Stefano Stabellini 
---
Changes in v5:
- improve commit message
- code style
- remove unneeded local var
- while loop in allocate_bank_memory to allocate memory so that it
  doesn't have to be contiguos
- combile while loops in allocate_memory

Changes in v4:
- move earlier, add #if 0
- introduce allocate_bank_memory, remove insert_bank
- allocate_bank_memory allocate memory and inserts the bank, while
  allocate_memory specifies where to do that

Changes in v3:
- new patch
---
 xen/arch/arm/domain_build.c | 99 +
 1 file changed, 99 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index c61a27f..146d81e 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -368,6 +368,105 @@ static void __init allocate_memory_11(struct domain *d,
 }
 }
 
+#if 0
+static bool __init allocate_bank_memory(struct domain *d,
+struct kernel_info *kinfo,
+gfn_t sgfn,
+unsigned int order)
+{
+int res;
+struct page_info *pg;
+struct membank *bank;
+paddr_t size = pfn_to_paddr(1UL << order);
+gfn_t _sgfn = sgfn;
+gfn_t _egfn = gfn_add(sgfn, 1UL << order);
+
+while ( gfn_x(_sgfn) < gfn_x(_egfn) )
+{
+pg = alloc_domheap_pages(d, order, 0);
+if ( pg != NULL )
+{
+res = guest_physmap_add_page(d, _sgfn, page_to_mfn(pg), order);
+if ( res )
+{
+dprintk(XENLOG_ERR, "Failed map pages to DOMU: %d", res);
+goto fail;
+}
+_sgfn = gfn_add(_sgfn, 1UL << order);
+}
+else
+{
+order--;
+if ( order == 0 )
+{
+dprintk(XENLOG_ERR, "Failed to allocated DOMU memory");
+goto fail;
+}
+}
+}
+
+bank = &kinfo->mem.bank[kinfo->mem.nr_banks];
+bank->start = gfn_to_gaddr(sgfn);
+bank->size = size;
+kinfo->mem.nr_banks++;
+kinfo->unassigned_mem -= size;
+
+return true;
+
+fail:
+/*
+ * Fatal failure, don't attempt to free memory.
+ */
+return false;
+}
+
+static void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
+{
+unsigned int order = get_allocation_size(kinfo->unassigned_mem);
+unsigned int order_req;
+unsigned int i;
+
+dprintk(XENLOG_INFO, "Allocating mappings totalling %ldMB for dom%d:\n",
+/* Don't want format this as PRIpaddr (16 digit hex) */
+(unsigned long)(kinfo->unassigned_mem >> 20), d->domain_id);
+
+kinfo->mem.nr_banks = 0;
+
+order = get_allocation_size(kinfo->unassigned_mem);
+if ( order > get_order_from_bytes(GUEST_RAM0_SIZE) )
+order_req = get_order_from_bytes(GUEST_RAM0_SIZE);
+else
+order_req = order;
+if ( !allocate_bank_memory(d, kinfo, gaddr_to_gfn(GUEST_RAM0_BASE), 
order_req) )
+goto fail;
+
+order -= order_req;
+if ( order > 0 &&
+ !allocate_bank_memory(d, kinfo, gaddr_to_gfn(GUEST_RAM1_BASE), order) 
)
+goto fail;
+
+for( i = 0; i < kinfo->mem.nr_banks; i++ )
+{
+dprintk(XENLOG_INFO, "Dom%d BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" 
(%ldMB)\n",
+d->domain_id,
+i,
+kinfo->mem.bank[i].start,
+kinfo->mem.bank[i].start + kinfo->mem.bank[i].size,
+/* Don't want format this as PRIpaddr (16 digit hex) */
+(unsigned long)(kinfo->mem.bank[i].size >> 20));
+}
+
+return;
+
+fail:
+dprintk(XENLOG_ERR, "Failed to allocate requested domain memory."
+/* Don't want format this as PRIpaddr (16 digit hex) */
+" %ldKB unallocated. Fix the VMs configurations.\n",
+(unsigned long)kinfo->unassigned_mem >> 10);
+BUG();
+}
+#endif
+
 static int __init write_properties(struct domain *d, struct kernel_info *kinfo,
const struct dt_device_node *node)
 {
-- 
1.9.1


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

[Xen-devel] [PATCH v5 07/25] xen/arm: don't add duplicate boot modules, introduce domU flag

[Stefano Stabellini]

Don't add duplicate boot modules (same kind and same start address),
they are freed later, we don't want to introduce double-free errors.

Introduce a domU flag in struct bootmodule and struct bootcmdline. Set
it for kernels and ramdisks of "xen,domain" nodes to avoid getting
confused in kernel_probe, where we try to guess which is the dom0 kernel
and initrd to be compatible with all versions of the multiboot spec.

boot_module_find_by_kind and boot_cmdline_find_by_kind automatically
check for !domU entries (they are only used for non-domU modules).

Signed-off-by: Stefano Stabellini 

---
Changes in v5:
- improve commit message
- add in-code comments

Changes in v4:
- use unsigned int
- better commit message
- introduce domU flag and usage

Changes in v2:
- new patch
---
 xen/arch/arm/bootfdt.c  | 11 +++
 xen/arch/arm/setup.c| 30 +-
 xen/include/asm-arm/setup.h | 12 ++--
 3 files changed, 42 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index cb6f77d..c325b6e 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -175,6 +175,7 @@ static void __init process_multiboot_node(const void *fdt, 
int node,
 int len = sizeof("/chosen");
 char path[8]; /* sizeof "/chosen" */
 int parent_node, ret;
+bool domU;
 
 parent_node = fdt_parent_offset(fdt, node);
 ASSERT(parent_node >= 0);
@@ -229,12 +230,14 @@ static void __init process_multiboot_node(const void 
*fdt, int node,
 kind = BOOTMOD_XSM;
 }
 
-add_boot_module(kind, start, size);
+domU = fdt_node_check_compatible(fdt, parent_node, "xen,domain") == 0;
+add_boot_module(kind, start, size, domU);
 
 prop = fdt_get_property(fdt, node, "bootargs", &len);
 if ( !prop )
 return;
-add_boot_cmdline(fdt_get_name(fdt, parent_node, &len), prop->data, kind);
+add_boot_cmdline(fdt_get_name(fdt, parent_node, &len), prop->data,
+ kind, domU);
 }
 
 static void __init process_chosen_node(const void *fdt, int node,
@@ -280,7 +283,7 @@ static void __init process_chosen_node(const void *fdt, int 
node,
 
 printk("Initrd %"PRIpaddr"-%"PRIpaddr"\n", start, end);
 
-add_boot_module(BOOTMOD_RAMDISK, start, end-start);
+add_boot_module(BOOTMOD_RAMDISK, start, end-start, false);
 }
 
 static int __init early_scan_node(const void *fdt,
@@ -351,7 +354,7 @@ size_t __init boot_fdt_info(const void *fdt, paddr_t paddr)
 if ( ret < 0 )
 panic("No valid device tree\n");
 
-add_boot_module(BOOTMOD_FDT, paddr, fdt_totalsize(fdt));
+add_boot_module(BOOTMOD_FDT, paddr, fdt_totalsize(fdt), false);
 
 device_tree_for_each_node((void *)fdt, early_scan_node, NULL);
 early_print_info();
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 2098591..72b12f9 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -201,10 +201,12 @@ void __init dt_unreserved_regions(paddr_t s, paddr_t e,
 }
 
 struct bootmodule __init *add_boot_module(bootmodule_kind kind,
-  paddr_t start, paddr_t size)
+  paddr_t start, paddr_t size,
+  bool domU)
 {
 struct bootmodules *mods = &bootinfo.modules;
 struct bootmodule *mod;
+unsigned int i;
 
 if ( mods->nr_mods == MAX_MODULES )
 {
@@ -212,15 +214,29 @@ struct bootmodule __init *add_boot_module(bootmodule_kind 
kind,
boot_module_kind_as_string(kind), start, start + size);
 return NULL;
 }
+for ( i = 0 ; i < mods->nr_mods ; i++ )
+{
+mod = &mods->module[i];
+if ( mod->kind == kind && mod->start == start )
+{
+if ( !domU )
+mod->domU = false;
+return mod;
+}
+}
 
 mod = &mods->module[mods->nr_mods++];
 mod->kind = kind;
 mod->start = start;
 mod->size = size;
+mod->domU = domU;
 
 return mod;
 }
 
+/*
+ * This function is only used to find dom0 modules, so check for !mod->domU
+ */
 struct bootmodule * __init boot_module_find_by_kind(bootmodule_kind kind)
 {
 struct bootmodules *mods = &bootinfo.modules;
@@ -229,14 +245,14 @@ struct bootmodule * __init 
boot_module_find_by_kind(bootmodule_kind kind)
 for (i = 0 ; i < mods->nr_mods ; i++ )
 {
 mod = &mods->module[i];
-if ( mod->kind == kind )
+if ( mod->kind == kind && !mod->domU )
 return mod;
 }
 return NULL;
 }
 
 void __init add_boot_cmdline(const char *name, const char *cmdline,
- bootmodule_kind kind)
+ bootmodule_kind kind, bool domU)
 {
 struct bootcmdlines *cmds = &bootinfo.cmdlines;
 struct bootcmdline *cmd;
@@ -249,6 +265,7 @@ void __init add_boot_cmdline(const char *name, const char 
*cmdline,
 
 cmd = &cmds->cmdline[cmds->nr_mods++];
 cmd->kind = kind;
+ 

[Xen-devel] [PATCH v5 15/25] xen/arm: implement construct_domU

[Stefano Stabellini]

Similar to construct_dom0, construct_domU creates a barebone DomU guest.

The device tree node passed as argument is compatible "xen,domain", see
docs/misc/arm/device-tree/booting.txt.

Remove #if 0 from allocate_memory as this patch will start using it.

Signed-off-by: Stefano Stabellini 

---
Changes in v5:
- move changes to kernel_probe prototype to previous patch
- improve commit message
- remove superflous allocation of d->vcpu
- use mem * SZ_1K

Changes in v4:
- constify kernel_probe
- change title
- better error messages and printed info
- 64bit memory

Changes in v3:
- move setting type before allocate_memory
- add ifdef around it and a comment

Changes in v2:
- rename mem to memory
- make cpus and memory mandatory
- remove wront comment from commit message
- cpus and memory are read as integers
- read the vpl011 option
---
 xen/arch/arm/domain_build.c | 35 ---
 1 file changed, 32 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 93e9510..4bb0db8 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -369,7 +370,6 @@ static void __init allocate_memory_11(struct domain *d,
 }
 }
 
-#if 0
 static bool __init allocate_bank_memory(struct domain *d,
 struct kernel_info *kinfo,
 gfn_t sgfn,
@@ -466,7 +466,6 @@ fail:
 (unsigned long)kinfo->unassigned_mem >> 10);
 BUG();
 }
-#endif
 
 static int __init write_properties(struct domain *d, struct kernel_info *kinfo,
const struct dt_device_node *node)
@@ -2308,7 +2307,37 @@ static int __init construct_domain(struct domain *d, 
struct kernel_info *kinfo)
 static int __init construct_domU(struct domain *d,
  const struct dt_device_node *node)
 {
-return -ENOSYS;
+struct kernel_info kinfo = {};
+int rc;
+u64 mem;
+
+rc = dt_property_read_u64(node, "memory", &mem);
+if ( !rc )
+{
+printk("Error building DomU: cannot read \"memory\" property\n");
+return -EINVAL;
+}
+kinfo.unassigned_mem = (paddr_t)mem * SZ_1K;
+
+printk("*** LOADING DOMU cpus=%u memory=%luKB ***\n", d->max_vcpus, mem);
+
+if ( vcpu_create(d, 0, 0) == NULL )
+return -ENOMEM;
+d->max_pages = ~0U;
+
+kinfo.d = d;
+
+rc = kernel_probe(&kinfo, node);
+if ( rc < 0 )
+return rc;
+
+#ifdef CONFIG_ARM_64
+/* type must be set before allocate memory */
+d->arch.type = kinfo.type;
+#endif
+allocate_memory(d, &kinfo);
+
+return construct_domain(d, &kinfo);
 }
 
 void __init create_domUs(void)
-- 
1.9.1


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

[Xen-devel] [PATCH v5 13/25] xen/arm: move unregister_init_virtual_region to init_done

[Stefano Stabellini]

Move unregister_init_virtual_region to init_done. Follow the same path
as x86. It is also useful to move it later so that create_domUs can be
called before that in following patches.

Signed-off-by: Stefano Stabellini 
---
 xen/arch/arm/setup.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 49f2fef..f3dc96c 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -66,6 +66,9 @@ integer_param("xenheap_megabytes", opt_xenheap_megabytes);
 
 static __used void init_done(void)
 {
+/* Must be done past setting system_state. */
+unregister_init_virtual_region();
+
 free_init_memory();
 startup_cpu_idle_loop();
 }
@@ -955,9 +958,6 @@ void __init start_xen(unsigned long boot_phys_offset,
 
 system_state = SYS_STATE_active;
 
-/* Must be done past setting system_state. */
-unregister_init_virtual_region();
-
 domain_unpause_by_systemcontroller(dom0);
 
 /* Switch on to the dynamically allocated stack for the idle vcpu
-- 
1.9.1


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

[Xen-devel] [PATCH v5 04/25] xen/arm: increase MAX_MODULES

[Stefano Stabellini]

Xen boot modules need to account not just for Dom0 but also for a few
potential DomUs, each of them coming with their own kernel and initrd.
Increase MAX_MODULES to 32 to allow for more DomUs.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Doug Goldstein 
---
 xen/include/asm-arm/setup.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 0cc3330..f1e4a3f 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -8,7 +8,7 @@
 
 #define NR_MEM_BANKS 128
 
-#define MAX_MODULES 5 /* Current maximum useful modules */
+#define MAX_MODULES 32 /* Current maximum useful modules */
 
 typedef enum {
 BOOTMOD_XEN,
-- 
1.9.1


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

[Xen-devel] [PATCH v5 16/25] xen/arm: generate a simple device tree for domUs

[Stefano Stabellini]

Introduce functions to generate a basic domU device tree, similar to the
existing functions in tools/libxl/libxl_arm.c.

Signed-off-by: Stefano Stabellini 
Acked-by: Julien Grall 
---
Changes in v5:
- use d->arch.vgic.version

Changes in v4:
- code style
- two separate functions for gicv2 and gicv3
- remove useless local variables
- fix typos
- do not use host address and size cells for the guest DT
- use #define for addrcells and sizecells

Changes in v3:
- remove CONFIG_ACPI for make_chosen_node
- remove make_hypervisor_node until all Xen related functionalities
  (evtchns, grant table, etc.) work correctly

Changes in v2:
- move prepare_dtb rename to previous patch
- use switch for the gic version
- use arm,gic-400 instead of arm,cortex-a15-gic
- add @unit-address in the gic node name
- add comment on DOMU_DTB_SIZE
---
 xen/arch/arm/domain_build.c | 235 +++-
 1 file changed, 233 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 4bb0db8..4a6ed23 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1032,7 +1032,6 @@ static int __init make_timer_node(const struct domain *d, 
void *fdt,
 return res;
 }
 
-#ifdef CONFIG_ACPI
 /*
  * This function is used as part of the device tree generation for Dom0
  * on ACPI systems, and DomUs started directly from Xen based on device
@@ -1078,7 +1077,6 @@ static int __init make_chosen_node(const struct 
kernel_info *kinfo)
 
 return res;
 }
-#endif
 
 static int __init map_irq_to_domain(struct domain *d, unsigned int irq,
 bool need_mapping, const char *devname)
@@ -1470,6 +1468,235 @@ static int __init handle_node(struct domain *d, struct 
kernel_info *kinfo,
 return res;
 }
 
+static int __init make_gicv2_domU_node(const struct domain *d, void *fdt)
+{
+int res = 0;
+__be32 reg[(GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) * 2];
+__be32 *cells;
+
+res = fdt_begin_node(fdt, 
"interrupt-controller@"__stringify(GUEST_GICD_BASE));
+if ( res )
+return res;
+
+res = fdt_property_cell(fdt, "#address-cells", 0);
+if ( res )
+return res;
+
+res = fdt_property_cell(fdt, "#interrupt-cells", 3);
+if ( res )
+return res;
+
+res = fdt_property(fdt, "interrupt-controller", NULL, 0);
+if ( res )
+return res;
+
+res = fdt_property_string(fdt, "compatible", "arm,gic-400");
+if ( res )
+return res;
+
+cells = ®[0];
+dt_child_set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
+   GUEST_GICD_BASE, GUEST_GICD_SIZE);
+dt_child_set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
+   GUEST_GICC_BASE, GUEST_GICC_SIZE);
+
+res = fdt_property(fdt, "reg", reg, sizeof(reg));
+if (res)
+return res;
+
+res = fdt_property_cell(fdt, "linux,phandle", GUEST_PHANDLE_GIC);
+if (res)
+return res;
+
+res = fdt_property_cell(fdt, "phandle", GUEST_PHANDLE_GIC);
+if (res)
+return res;
+
+res = fdt_end_node(fdt);
+
+return res;
+}
+
+static int __init make_gicv3_domU_node(const struct domain *d, void *fdt)
+{
+int res = 0;
+__be32 reg[(GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) * 2];
+__be32 *cells;
+
+res = fdt_begin_node(fdt, 
"interrupt-controller@"__stringify(GUEST_GICV3_GICD_BASE));
+if ( res )
+return res;
+
+res = fdt_property_cell(fdt, "#address-cells", 0);
+if ( res )
+return res;
+
+res = fdt_property_cell(fdt, "#interrupt-cells", 3);
+if ( res )
+return res;
+
+res = fdt_property(fdt, "interrupt-controller", NULL, 0);
+if ( res )
+return res;
+
+res = fdt_property_string(fdt, "compatible", "arm,gic-v3");
+if ( res )
+return res;
+
+cells = ®[0];
+dt_child_set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
+   GUEST_GICV3_GICD_BASE, GUEST_GICV3_GICD_SIZE);
+dt_child_set_range(&cells, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
+   GUEST_GICV3_GICR0_BASE, GUEST_GICV3_GICR0_SIZE);
+
+res = fdt_property(fdt, "reg", reg, sizeof(reg));
+if (res)
+return res;
+
+res = fdt_property_cell(fdt, "linux,phandle", GUEST_PHANDLE_GIC);
+if (res)
+return res;
+
+res = fdt_property_cell(fdt, "phandle", GUEST_PHANDLE_GIC);
+if (res)
+return res;
+
+res = fdt_end_node(fdt);
+
+return res;
+}
+
+static int __init make_gic_domU_node(const struct domain *d, void *fdt)
+{
+switch ( d->arch.vgic.version )
+{
+case GIC_V3:
+return make_gicv3_domU_node(d, fdt);
+case GIC_V2:
+return make_gicv2_domU_node(d, fdt);
+default:
+panic("Unsupported GIC version");
+}
+}
+
+static int __init make_timer_domU_node(const struct domain *d, void *fdt)
+{
+int res;
+

[Xen-devel] [PATCH v5 23/25] xen/vpl011: buffer out chars when the backend is xen

[Stefano Stabellini]

To avoid mixing the output of different domains on the console, buffer
the output chars and print line by line. Unless the domain has input
from the serial, in which case we want to print char by char for a
smooth user experience.

The size of SBSA_UART_OUT_BUF_SIZE is arbitrary, choose the same size
as VUART_BUT_SIZE used in vuart.c.

Export a function named console_input_domain() to allow others to know
which domains has input at a given time.

Signed-off-by: Stefano Stabellini 
CC: andrew.coop...@citrix.com
CC: george.dun...@eu.citrix.com
CC: ian.jack...@eu.citrix.com
CC: jbeul...@suse.com
CC: konrad.w...@oracle.com
CC: t...@xen.org
CC: wei.l...@citrix.com
---
XXX: merge this patch with "xen/arm: Allow vpl011 to be used by DomU" on
 commit

Changes in v5:
- use rcu_lock in console_input_domain
- rcu_unlock at the end of vpl011_write_data_xen
- add a comment on top of console_input_domain as a reminder that the
  caller needs to rcu_unlock

Changes in v4:
- make SBSA_UART_OUT_BUF_SIZE the same size of VUART_BUT_SIZE
- rearrange the code to be clearer input and != input cases
- code style
- add \n when printing the out buffer because is full
- don't print prefix for input domain
---
 xen/arch/arm/vpl011.c| 36 +---
 xen/drivers/char/console.c   |  8 
 xen/include/asm-arm/vpl011.h |  4 
 xen/include/xen/console.h|  2 ++
 4 files changed, 47 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 131507e..f7db18b 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -85,18 +86,47 @@ static void vpl011_write_data_xen(struct domain *d, uint8_t 
data)
 {
 unsigned long flags;
 struct vpl011 *vpl011 = &d->arch.vpl011;
+struct vpl011_xen_backend *intf = vpl011->backend.xen;
+struct domain *input = console_input_domain();
 
 VPL011_LOCK(d, flags);
 
-printk("%c", data);
-if (data == '\n')
-printk("DOM%u: ", d->domain_id);
+intf->out[intf->out_prod++] = data;
+if ( d == input )
+{
+if ( intf->out_prod == 1 )
+{
+printk("%c", data);
+intf->out_prod = 0;
+}
+else
+{
+if ( data != '\n' )
+intf->out[intf->out_prod++] = '\n';
+intf->out[intf->out_prod++] = '\0';
+printk("%s", intf->out);
+intf->out_prod = 0;
+}
+}
+else
+{
+if ( intf->out_prod == SBSA_UART_OUT_BUF_SIZE - 2 ||
+ data == '\n' )
+{
+if ( data != '\n' )
+intf->out[intf->out_prod++] = '\n';
+intf->out[intf->out_prod++] = '\0';
+printk("DOM%u: %s", d->domain_id, intf->out);
+intf->out_prod = 0;
+}
+}
 
 vpl011->uartris |= TXI;
 vpl011->uartfr &= ~TXFE;
 vpl011_update_interrupt_status(d);
 
 VPL011_UNLOCK(d, flags);
+rcu_unlock_domain(input);
 }
 
 /*
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 990c51c..eb1cc1b 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -406,6 +406,14 @@ static void dump_console_ring_key(unsigned char key)
  */
 static unsigned int __read_mostly console_rx = 0;
 
+/* Make sure to rcu_unlock_domain after use */
+struct domain *console_input_domain(void)
+{
+if ( console_rx == 0 )
+return NULL;
+return rcu_lock_domain_by_id(console_rx - 1);
+}
+
 static void switch_serial_input(void)
 {
 if ( console_rx++ == max_init_domid + 1 )
diff --git a/xen/include/asm-arm/vpl011.h b/xen/include/asm-arm/vpl011.h
index 5eb6d25..ab6fd79 100644
--- a/xen/include/asm-arm/vpl011.h
+++ b/xen/include/asm-arm/vpl011.h
@@ -30,9 +30,13 @@
 #define VPL011_UNLOCK(d,flags) spin_unlock_irqrestore(&(d)->arch.vpl011.lock, 
flags)
 
 #define SBSA_UART_FIFO_SIZE 32
+/* Same size as VUART_BUT_SIZE, used in vuart.c */
+#define SBSA_UART_OUT_BUF_SIZE 128
 struct vpl011_xen_backend {
 char in[SBSA_UART_FIFO_SIZE];
+char out[SBSA_UART_OUT_BUF_SIZE];
 XENCONS_RING_IDX in_cons, in_prod;
+XENCONS_RING_IDX out_prod;
 };
 
 struct vpl011 {
diff --git a/xen/include/xen/console.h b/xen/include/xen/console.h
index 70c9911..c5a85c8 100644
--- a/xen/include/xen/console.h
+++ b/xen/include/xen/console.h
@@ -31,6 +31,8 @@ void console_end_sync(void);
 void console_start_log_everything(void);
 void console_end_log_everything(void);
 
+struct domain *console_input_domain(void);
+
 /*
  * Steal output from the console. Returns +ve identifier, else -ve error.
  * Takes the handle of the serial line to steal, and steal callback function.
-- 
1.9.1


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

[Xen-devel] [PATCH v5 24/25] xen/arm: move kernel.h to asm-arm/

[Stefano Stabellini]

It will be #included by a file in a xen/arch/arm subdirectory.

Signed-off-by: Stefano Stabellini 
---
 xen/arch/arm/domain_build.c  |  2 +-
 xen/arch/arm/kernel.c|  3 +-
 xen/arch/arm/kernel.h| 86 
 xen/include/asm-arm/kernel.h | 86 
 4 files changed, 88 insertions(+), 89 deletions(-)
 delete mode 100644 xen/arch/arm/kernel.h
 create mode 100644 xen/include/asm-arm/kernel.h

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 9ffd919..6f47832 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -25,7 +26,6 @@
 
 #include 
 #include 
-#include "kernel.h"
 
 static unsigned int __initdata opt_dom0_max_vcpus;
 integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index d56f776..d10c03a 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -16,8 +16,7 @@
 #include 
 
 #include 
-
-#include "kernel.h"
+#include 
 
 #define UIMAGE_MAGIC  0x27051956
 #define UIMAGE_NMLEN  32
diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
deleted file mode 100644
index 33f3e72..000
--- a/xen/arch/arm/kernel.h
+++ /dev/null
@@ -1,86 +0,0 @@
-/*
- * Kernel image loading.
- *
- * Copyright (C) 2011 Citrix Systems, Inc.
- */
-#ifndef __ARCH_ARM_KERNEL_H__
-#define __ARCH_ARM_KERNEL_H__
-
-#include 
-#include 
-
-struct kernel_info {
-#ifdef CONFIG_ARM_64
-enum domain_type type;
-#endif
-
-struct domain *d;
-
-void *fdt; /* flat device tree */
-paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
-struct meminfo mem;
-
-/* kernel entry point */
-paddr_t entry;
-
-/* grant table region */
-paddr_t gnttab_start;
-paddr_t gnttab_size;
-
-/* boot blob load addresses */
-const struct bootmodule *kernel_bootmodule, *initrd_bootmodule;
-const char* cmdline;
-paddr_t dtb_paddr;
-paddr_t initrd_paddr;
-
-/* Enable pl011 emulation */
-bool vpl011;
-
-/* loader to use for this kernel */
-void (*load)(struct kernel_info *info);
-/* loader specific state */
-union {
-struct {
-paddr_t kernel_addr;
-paddr_t len;
-#ifdef CONFIG_ARM_64
-paddr_t text_offset; /* 64-bit Image only */
-#endif
-paddr_t start; /* 32-bit zImage only */
-} zimage;
-};
-};
-
-/*
- * Probe the kernel to detemine its type and select a loader.
- *
- * Sets in info:
- *  ->type
- *  ->load hook, and sets loader specific variables ->zimage
- */
-int kernel_probe(struct kernel_info *info, const struct dt_device_node 
*domain);
-
-/*
- * Loads the kernel into guest RAM.
- *
- * Expects to be set in info when called:
- *  ->mem
- *  ->fdt
- *
- * Sets in info:
- *  ->entry
- *  ->dtb_paddr
- *  ->initrd_paddr
- */
-void kernel_load(struct kernel_info *info);
-
-#endif /* #ifdef __ARCH_ARM_KERNEL_H__ */
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/include/asm-arm/kernel.h b/xen/include/asm-arm/kernel.h
new file mode 100644
index 000..33f3e72
--- /dev/null
+++ b/xen/include/asm-arm/kernel.h
@@ -0,0 +1,86 @@
+/*
+ * Kernel image loading.
+ *
+ * Copyright (C) 2011 Citrix Systems, Inc.
+ */
+#ifndef __ARCH_ARM_KERNEL_H__
+#define __ARCH_ARM_KERNEL_H__
+
+#include 
+#include 
+
+struct kernel_info {
+#ifdef CONFIG_ARM_64
+enum domain_type type;
+#endif
+
+struct domain *d;
+
+void *fdt; /* flat device tree */
+paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
+struct meminfo mem;
+
+/* kernel entry point */
+paddr_t entry;
+
+/* grant table region */
+paddr_t gnttab_start;
+paddr_t gnttab_size;
+
+/* boot blob load addresses */
+const struct bootmodule *kernel_bootmodule, *initrd_bootmodule;
+const char* cmdline;
+paddr_t dtb_paddr;
+paddr_t initrd_paddr;
+
+/* Enable pl011 emulation */
+bool vpl011;
+
+/* loader to use for this kernel */
+void (*load)(struct kernel_info *info);
+/* loader specific state */
+union {
+struct {
+paddr_t kernel_addr;
+paddr_t len;
+#ifdef CONFIG_ARM_64
+paddr_t text_offset; /* 64-bit Image only */
+#endif
+paddr_t start; /* 32-bit zImage only */
+} zimage;
+};
+};
+
+/*
+ * Probe the kernel to detemine its type and select a loader.
+ *
+ * Sets in info:
+ *  ->type
+ *  ->load hook, and sets loader specific variables ->zimage
+ */
+int kernel_probe(struct kernel_info *info, const struct dt_device_node 
*domain);
+
+/*
+ * Loads the kernel into guest RAM.
+ *
+ * Expects to be set in info when called:
+ *  ->mem
+ *  ->fdt
+ *
+ * Sets in info:
+ *  ->entry
+ *  ->dtb_paddr
+ *  ->initrd_paddr
+

[Xen-devel] [PATCH v5 09/25] xen/arm: rename get_11_allocation_size to get_allocation_size

[Stefano Stabellini]

No functional changes.

Signed-off-by: Stefano Stabellini 
Acked-by: Julien Grall 

---

Changes in v3:
- no change in print messages
- do not remove BUG_ON

Changes in v2:
- new patch
---
 xen/arch/arm/domain_build.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 8faf252..c4ae39b 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -77,7 +77,7 @@ struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
 return vcpu_create(dom0, 0, 0);
 }
 
-static unsigned int __init get_11_allocation_size(paddr_t size)
+static unsigned int __init get_allocation_size(paddr_t size)
 {
 /*
  * get_order_from_bytes returns the order greater than or equal to
@@ -249,7 +249,7 @@ static void __init allocate_memory(struct domain *d, struct 
kernel_info *kinfo)
 get_order_from_bytes(min_t(paddr_t, dom0_mem, MB(128)));
 const unsigned int min_order = get_order_from_bytes(MB(4));
 struct page_info *pg;
-unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
+unsigned int order = get_allocation_size(kinfo->unassigned_mem);
 int i;
 
 bool lowmem = true;
@@ -301,7 +301,7 @@ static void __init allocate_memory(struct domain *d, struct 
kernel_info *kinfo)
  * If we failed to allocate bank0 under 4GB, continue allocating
  * memory from above 4GB and fill in banks.
  */
-order = get_11_allocation_size(kinfo->unassigned_mem);
+order = get_allocation_size(kinfo->unassigned_mem);
 while ( kinfo->unassigned_mem && kinfo->mem.nr_banks < NR_MEM_BANKS )
 {
 pg = alloc_domheap_pages(d, order, lowmem ? MEMF_bits(32) : 0);
@@ -312,7 +312,7 @@ static void __init allocate_memory(struct domain *d, struct 
kernel_info *kinfo)
 if ( lowmem && order < min_low_order)
 {
 D11PRINT("Failed at min_low_order, allow high allocations\n");
-order = get_11_allocation_size(kinfo->unassigned_mem);
+order = get_allocation_size(kinfo->unassigned_mem);
 lowmem = false;
 continue;
 }
@@ -332,7 +332,7 @@ static void __init allocate_memory(struct domain *d, struct 
kernel_info *kinfo)
 if ( lowmem )
 {
 D11PRINT("Allocation below bank 0, allow high allocations\n");
-order = get_11_allocation_size(kinfo->unassigned_mem);
+order = get_allocation_size(kinfo->unassigned_mem);
 lowmem = false;
 continue;
 }
@@ -347,7 +347,7 @@ static void __init allocate_memory(struct domain *d, struct 
kernel_info *kinfo)
  * Success, next time around try again to get the largest order
  * allocation possible.
  */
-order = get_11_allocation_size(kinfo->unassigned_mem);
+order = get_allocation_size(kinfo->unassigned_mem);
 }
 
 if ( kinfo->unassigned_mem )
-- 
1.9.1


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

[Xen-devel] [PATCH v5 19/25] xen/arm: introduce a union in vpl011

[Stefano Stabellini]

Introduce a union in struct vpl011 to contain the console ring members.
A later patch will add another member of the union for the case where
the backend is in Xen.

Signed-off-by: Stefano Stabellini 
Acked-by: Julien Grall 
---
Changes in v4:
- name union "backend"

Changes in v3:
- rename ring field to dom

Changes in v2:
- new patch
---
 xen/arch/arm/vpl011.c| 22 --
 xen/include/asm-arm/vpl011.h |  8 ++--
 2 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index a281eab..ebc045e 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -82,7 +82,7 @@ static uint8_t vpl011_read_data(struct domain *d)
 unsigned long flags;
 uint8_t data = 0;
 struct vpl011 *vpl011 = &d->arch.vpl011;
-struct xencons_interface *intf = vpl011->ring_buf;
+struct xencons_interface *intf = vpl011->backend.dom.ring_buf;
 XENCONS_RING_IDX in_cons, in_prod;
 
 VPL011_LOCK(d, flags);
@@ -145,7 +145,7 @@ static uint8_t vpl011_read_data(struct domain *d)
 static void vpl011_update_tx_fifo_status(struct vpl011 *vpl011,
  unsigned int fifo_level)
 {
-struct xencons_interface *intf = vpl011->ring_buf;
+struct xencons_interface *intf = vpl011->backend.dom.ring_buf;
 unsigned int fifo_threshold = sizeof(intf->out) - SBSA_UART_FIFO_LEVEL;
 
 BUILD_BUG_ON(sizeof(intf->out) < SBSA_UART_FIFO_SIZE);
@@ -164,7 +164,7 @@ static void vpl011_write_data(struct domain *d, uint8_t 
data)
 {
 unsigned long flags;
 struct vpl011 *vpl011 = &d->arch.vpl011;
-struct xencons_interface *intf = vpl011->ring_buf;
+struct xencons_interface *intf = vpl011->backend.dom.ring_buf;
 XENCONS_RING_IDX out_cons, out_prod;
 
 VPL011_LOCK(d, flags);
@@ -382,7 +382,7 @@ static void vpl011_data_avail(struct domain *d)
 {
 unsigned long flags;
 struct vpl011 *vpl011 = &d->arch.vpl011;
-struct xencons_interface *intf = vpl011->ring_buf;
+struct xencons_interface *intf = vpl011->backend.dom.ring_buf;
 XENCONS_RING_IDX in_cons, in_prod, out_cons, out_prod;
 XENCONS_RING_IDX in_fifo_level, out_fifo_level;
 
@@ -459,14 +459,14 @@ int domain_vpl011_init(struct domain *d, struct 
vpl011_init_info *info)
 int rc;
 struct vpl011 *vpl011 = &d->arch.vpl011;
 
-if ( vpl011->ring_buf )
+if ( vpl011->backend.dom.ring_buf )
 return -EINVAL;
 
 /* Map the guest PFN to Xen address space. */
 rc =  prepare_ring_for_helper(d,
   gfn_x(info->gfn),
-  &vpl011->ring_page,
-  &vpl011->ring_buf);
+  &vpl011->backend.dom.ring_page,
+  &vpl011->backend.dom.ring_buf);
 if ( rc < 0 )
 goto out;
 
@@ -495,7 +495,8 @@ out2:
 vgic_free_virq(d, GUEST_VPL011_SPI);
 
 out1:
-destroy_ring_for_helper(&vpl011->ring_buf, vpl011->ring_page);
+destroy_ring_for_helper(&vpl011->backend.dom.ring_buf,
+   vpl011->backend.dom.ring_page);
 
 out:
 return rc;
@@ -505,11 +506,12 @@ void domain_vpl011_deinit(struct domain *d)
 {
 struct vpl011 *vpl011 = &d->arch.vpl011;
 
-if ( !vpl011->ring_buf )
+if ( !vpl011->backend.dom.ring_buf )
 return;
 
 free_xen_event_channel(d, vpl011->evtchn);
-destroy_ring_for_helper(&vpl011->ring_buf, vpl011->ring_page);
+destroy_ring_for_helper(&vpl011->backend.dom.ring_buf,
+   vpl011->backend.dom.ring_page);
 }
 
 /*
diff --git a/xen/include/asm-arm/vpl011.h b/xen/include/asm-arm/vpl011.h
index db95ff8..42d7a24 100644
--- a/xen/include/asm-arm/vpl011.h
+++ b/xen/include/asm-arm/vpl011.h
@@ -31,8 +31,12 @@
 #define SBSA_UART_FIFO_SIZE 32
 
 struct vpl011 {
-void *ring_buf;
-struct page_info *ring_page;
+union {
+struct {
+void *ring_buf;
+struct page_info *ring_page;
+} dom;
+} backend;
 uint32_tuartfr; /* Flag register */
 uint32_tuartcr; /* Control register */
 uint32_tuartimsc;   /* Interrupt mask register*/
-- 
1.9.1


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