Re: [Xen-devel] [Help] Trigger Watchdog when adding an IPI in vcpu_wake

[Wei Yang]

On Thu, Sep 22, 2016 at 11:12:15AM +0200, Dario Faggioli wrote:
>On Sat, 2016-09-17 at 03:30 +, Wei Yang wrote:
>> Dario,
>> 
>Hey, hi again, and sorry for the in getting back at this particular
>part of the conversation.
>

Sure, I was busy with other stuffs these days :-(

>> Just get chance to look into this. This is interesting and I am
>> trying to
>> understand the problem you want to solve first.
>> 
>:-)
>
>> vcpu_wake() is a _special_ case who has to turn off the irq, because
>> SCHED_OP(wake, v) would not only enqueue the vcpu but also tickle
>> pcpu to pick
>> up the queued vcpu. And the tickling part needd the irq to be turned
>> off.
>> 
>_Almost_ correct. However, the problem is more that vcpu_wake() can
>happen in response to an IRQ, and when you grab a spinlock in IRQ
>context, you need to disable IRQs.
>

_start:
jmp 1f
2:

Ok, now I have a question to this sentence.

I have checked some posts which says in the interrupt handling, irq would be
disabled. Well, this really depends on the implementation.

This means in Xen, irq is still enabled during interrupt handling? Because of
this, we have to disable IRQ when we need to grab the spin lock?

jmp $$

>There is a good explanation of why, here:
>
>
>> I don't get the this part. Why we have to turn off the irq for
>> tickling pcpu?
>> 
>We don't. The point here is that, in Xen, we wants spinlocks to either
>_always_ be taken with IRQs disabled or _always_ be taken with IRQs
>enabled. Well, since we now take the scheduler's runqueue lock in
>vcpu_wake() (and as said that must be done with IRQs disabled), this
>implies that the scheduler's runqueue lock needs to always be taken
>with IRQs disabled, even when leaving them enabled would not actually
>be an issue, for being consistent with the locking rule.
>
>So, if we manage to avoid taking the scheduler's runqueue lock in vcpu_wake(), 
>we will manage to put ourself in the opposite situation, wrt the locking 
>consistency rule, i.e., we can _always_ take the scheduler's runqueue lock 
>with IRQs enabled.
>
>This is, broadly speaking, the problem we wanted to solve, and how we thought 
>about solving it.

1:

Looks I almost get every thing. Let me do a summary to see whether I have got
your words.

   (spinlock usage convention in Xen)  &  (vcpu_wake() may happen in an IRQ)

=>

   (irq all disabled || irq all enabled) & (disable irq on grabbing spinlock)

=>

   should grab schedule lock with IRQ disabled

jmp 2b

>
>> And by enabling irq in schedule handlers benefits the performance? or
>> ? The
>> motivation behind this is?
>> 
>As I said to you about your modification, here too it is not super-easy 
>to tell in advance whether, and if yes, by how much, we'll see a boost
>in performance.
>
>In this case, the idea is that, in general, keeping IRQs disabled is
>bad. It is bad for concurrency, it is bad for latency in both
>scheduling and when it comes to reacting to external event. And it has
>been profiled that the scheduler is one of the component that keeps the
>IRQs disabled for long chunks of time.
>
>I honestly did expect things to improve a bit, especially on certain
>workloads, but of course, as usual, benchmarks will tell. :-)
>
>> Didn't look into your code yet. 
>>
>Ok. 
>Even if/when you look at it, bear in mind it's still only a stub.
>
>> From the description from Andrew, I comes with
>> several questions:
>> 1. which per-cpu list you want to queue the vcpu? v->processor?
>>
>ISTR having thought, and even given a try, to both v->processor (where
>v is the waking vcpu) and the current cpu (where for 'current cpu' I
>meant the cpu where the wake-up is occurring).
>
>I think I decided to use the current cpu (mostly for the same reasons
>why I don't think there is much advantage in what you are trying to do
>:-P)
>
>> 2. SCHEDULE_WAKE_SOFTIRQ would do runqueue insert and tickle?
>>
>It would call what is now vcpu_wake(). So, yes, for most scheduler that
>means inserting and tickling, but it's really schedulere specific.
>
>> 3. purpose is so that schedule softirq could run with irq enabled
>>
>Purpose is that scheduling functions can be executed with IRQs enabled,
>yes.
>
>> 4. the schedule softirq would do the jobs currently in vcpu_wake()?
>> 
>Err... not sure what you mean (but maybe I've already answered at point
>2.?).
>
>> Took the per-cpu branch as an example, I see several commits. The top
>> 6 are
>> related ones, right?
>> 
>The top 4 (I told you it's a stub :-P).
>
>Regards,
>Dario
>-- 
><> (Raistlin Majere)
>-
>Dario Faggioli, Ph.D, http://about.me/dario.faggioli
>Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


-- 
Richard Yang\nHelp you, Help me

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-qcow2  6 xen-boot   fail REGR. vs. 101123

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 101123
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101123
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101123
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101123

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass

version targeted for testing:
 qemuu3b71ec8516bb50e9a743645bf139571de0b39f61
baseline version:
 qemuue678c56f169bb576b607cda2a39c0b626ebfb221

Last test of basis   101123  2016-09-23 11:18:37 Z0 days
Testing same since   101129  2016-09-23 19:45:22 Z0 days1 attempts


People who touched revisions under test:
  Alberto Garcia 
  Aleksandar Markovic 
  Aleksandar Rikalo 
  Alexey Kardashevskiy 
  André Draszik 
  Benjamin Herrenschmidt 
  Bharata B Rao 
  Cédric Le Goater 
  Daniel P. Berrange 
  David Gibson 
  Denis V. Lunev 
  Dr. David Alan Gilbert 
  Eduardo Habkost 
  Eric Blake 
  Fam Zheng 
  Greg Kurz 
  He Rongguang 
  Herongguang (Stephen) 
  John Arbuckle 
  Kevin Wolf 
  Laurent Vivier 
  Leon Alrae 
  Lin Ma 
  Michael Walle 
  Miodrag Dinic 
  Nathan Whitehorn 
  Nikunj A Dadhania 
  Paolo Bonzini 
  Peter Maydell 
  Rajalakshmi Srinivasaraghavan 
  Ravi Bangoria 
  Riku Voipio 
  Thomas Huth 

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

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

[Stefano Stabellini]

On Fri, 23 Sep 2016, Dario Faggioli wrote:
> On Fri, 2016-09-23 at 11:15 +0100, Julien Grall wrote:
> > On 23/09/16 11:05, Peng Fan wrote:
> > > If cluster is not prefered, cpuclass maybe a choice, but I
> > > personally perfer
> > > "cluster" split for ARM.
> > > 
> > > Thanks,
> > > Peng.
> > > 
> > > [1] https://en.wikipedia.org/wiki/ARM_big.LITTLE
> > 
> > Please try to have a think on all the use case and not only yours.
> > 
> This last line is absolutely true and very important!
> 
> That being said, I am a bit lost.
> 
> So, AFAICT, in order to act properly when the user asks for:
> 
>  vcpuclass = ["1,2:foo", "0,3:bar"]
> 
> we need to decide what "foo" and "bar" are at the xl and libxl level,
> and whether they are the same all the way down to Xen (and if not,
> what's the mapping).

I think "foo" and "bar" need to be "big" and "LITTLE" at the xl level.

Given that Xen is the one with the information about which core is big
and which is LITTLE, I think the hypervisor should provide the mapping
between labels and cpu and cluster indexes.


> We also said it would be nice to support:
> 
>  xl cpupool-split --feature=foobar
> 
> and hence we also need to decide what's foobar, whether it is in the
> same namespace of foo and bar (i.e., it can be foobar==foo, or
> foobar==bar, etc), or it is something else, or both.

I would be consistent and always use foobar=bigLITTLE at the xl level.


> Can someone list what are the various alternative approaches on the
> table?

The info available is:
http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/arm/cpus.txt
plus:
http://marc.info/?l=linux-arm-kernel&m=147308556729426&w=2

We have cpu and cluster indexes. We have cpu compatible strings which
tell us whether a cpu is an "a53" or an "a15". We have
an optional property that tells us the cpu "capacity". Higher capacity
means "big", lower capacity means "LITTLE".

Xen could always deal with cpu and cluster indexes, but provide
convenient labels to libxl.

For example:

cpus {
#size-cells = <0>;
#address-cells = <1>;

cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x0>;
capacity-dmips-mhz = <1024>;
};

cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x1>;
capacity-dmips-mhz = <1024>;
};

cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x100>;
capacity-dmips-mhz = <512>;
};

cpu@101 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x101>;
capacity-dmips-mhz = <512>;
};
};

The reg property encodes cpu number and cluster number and matches the
value in the MPIDR register. That is what Xen could take as parameter.

The mapping between reg and "big" or "LITTLE" and the cpu compatible
name, such as "a7", could be returned by an hypercall such as
xen_arch_domainconfig.___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [qemu-mainline baseline-only test] 67756: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67756 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67756/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail blocked 
in 67753
 test-amd64-amd64-amd64-pvgrub 10 guest-start fail blocked in 67753

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 qemuue678c56f169bb576b607cda2a39c0b626ebfb221
baseline version:
 qemuu430da7a81d356e368ccd88dcca60f38da9aa5b9a

Last test of basis67753  2016-09-23 11:16:05 Z0 days
Testing same since67756  2016-09-23 19:16:49 Z0 days1 attempts


People who touched revisions under test:
  Alistair Francis 
  Andrey Yurovsky 
  Cédric Le Goater 
  Dmitry Osipenko 
  Dr. David Alan Gilbert 
  Nathan Rossi 
  Peter Maydell 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-q

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

[Stefano Stabellini]

On Thu, 22 Sep 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 22/09/2016 18:31, Stefano Stabellini wrote:
> > On Thu, 22 Sep 2016, Julien Grall wrote:
> > > Hello Peng,
> > > 
> > > On 22/09/16 10:27, Peng Fan wrote:
> > > > On Thu, Sep 22, 2016 at 10:50:23AM +0200, Dario Faggioli wrote:
> > > > > On Thu, 2016-09-22 at 14:49 +0800, Peng Fan wrote:
> > > > > > On Wed, Sep 21, 2016 at 08:11:43PM +0100, Julien Grall wrote:
> > > > > A feature like `xl cpupool-biglittle-split' can still be interesting,
> > > > 
> > > > "cpupool-cluster-split" maybe a better name?
> > > 
> > > You seem to assume that a cluster, from the MPIDR point of view, can only
> > > contain the same set of CPUs. I don't think this is part of the
> > > architecture,
> > > so this may not be true in the future.
> > 
> > Interesting. I also understood that a cluster can only have one kind if
> > cpus. Honestly it would be a little insane for it to be otherwise :-)
> 
> I don't think this is insane (or maybe I am insane :)). Cluster usually
> doesn't share all L2 cache (assuming L1 is local to each core) and L3 cache
> may not be present, so if you move a task from one cluster to another you will
> add latency because the new L2 cache has to be refilled.
> 
> The use case of big.LITTLE is big cores are used for short period of burst and
> little core are used for the rest (e.g listening audio, fetching mail...). If
> you want to reduce latency when switch between big and little CPUs, you may
> want to put them within the same cluster.
> 
> Also, as mentioned in another thread, you may have a platform with the same
> micro-architecture (e.g Cortex A-53) but different silicon implementation (e.g
> to have a different frequency, power efficiency). Here the concept of
> big.LITTLE is more blurred.

Different frequency is fine, we have been able to set per core frequency
on x86 cpus for a long time now. If they are cores of the same
micro-architecture, it doesn't matter the cpu frequency, we can deal
with them as usual.

To me big.LITTLE means: it is technically possible, but very difficult
(currently unimplemented), and slower than than usual to move a vcpu
across big and LITTLE pcpus. That's why they need to be dealt with in a
different way.

If we had big.LITTLE cores in the same cluster, sharing L2 caches, with
the same cache line sizes, maybe we could also deal with them as usual
because it wouldn't be much of an issue to migrate a vcpu across big and
LITTLE cores. If/when we come across such an architecture we'll deal
with it.


> That's why I am quite reluctant to name (even if it may be more handy to the
> user) "big" and "little" the different CPU set.
 
Technically you might be right, but "big.LITTLE" is how the architecture
has been advertized to people, so unfortunately we are stuck with the
name. We have to deal with it in those terms at least at the xl level.
Of course in Xen we are free to do whatever we want.

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

[Xen-devel] [xen-unstable test] 101128: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 101102
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101121
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101121
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101121
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101121
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101121

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 xen  a75f34462612a05547fc43d192705a9c31cad7fb
baseline version:
 xen  b106f15efbfc99f52ccb94ab8ca7fdb21fcf

Last test of basis   101121  2016-09-23 08:18:27 Z0 days
Testing same since   101128  2016-09-23 19:15:01 Z0 days1 attempts


People who touched revisions under test:
  Boris Ostrovsky 
  Jan Beulich 
  Jan Beulich  [for directory]
  Jan Beulich  [relevant parts]
  Jan Beulich  [x86 parts]
  Joao Martins 
  Julien Grall  [arm change]
  Konrad Rzeszutek Wilk 
  Ross Lagerwall 

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

Re: [Xen-devel] [PATCH v2] x86/apicv: fix RTC periodic timer and apicv issue

[Xuquan (Euler)]

On September 24, 2016 7:34 AM, Tian Kevin < kevin.t...@intel.com > wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Friday, September 23, 2016 11:34 PM
>>
>> >>> On 20.09.16 at 15:30,  wrote:
>> > --- a/xen/arch/x86/hvm/vlapic.c
>> > +++ b/xen/arch/x86/hvm/vlapic.c
>> > @@ -433,6 +433,12 @@ void vlapic_EOI_set(struct vlapic *vlapic)
>> > void vlapic_handle_EOI(struct vlapic *vlapic, u8 vector)  {
>> >  struct domain *d = vlapic_domain(vlapic);
>> > +struct vcpu *v = vlapic_vcpu(vlapic);
>> > +struct hvm_intack pt_intack;
>> > +
>> > +pt_intack.vector = vector;
>> > +pt_intack.source = hvm_intsrc_lapic;
>> > +pt_intr_post(v, pt_intack);
>>
>> This also sits on the EOI LAPIC register write path, i.e. the change
>> then also affects non-apicv environments.
>
>The new logic should be entered only when EOI-induced exit happens.
>

Yes, more that the EOI-induced exit is conditional, specifically, the bitmap is 
set by vmx_set_eoi_exit_bitmap().
Jan, what do you think? While I recall from v1 discussion, you have the same 
comment. We can dig it deep..

>>
>> Furthermore - don't we have the same problem as with v1 again then?
>> What prevents multiple EOIs to come here before the timer interrupt
>> actually gets handled? You'd then clear ->irq_issued each time,
>> rendering your change to pt_update_irq() ineffective.
>
>based on this patch, one irq_issued should cause only one EOI on related pt
>vector and this EOI exit clears irq_issued then next EOI would be seen only 
>upon
>another injection when irq_issued is set again... However there might be an
>issue if this pt vector is shared with another device interrupt, which 
>although is
>not a typical case...
>
Agreed.

>>
>> In any event please use hvm_intack_lapic() instead of open coding it
>> (and then I don't think you need a local variable at all).
>>

Indeed.

>> > --- a/xen/arch/x86/hvm/vmx/intr.c
>> > +++ b/xen/arch/x86/hvm/vmx/intr.c
>> > @@ -333,8 +333,6 @@ void vmx_intr_assist(void)
>
>> >  clear_bit(i, &v->arch.hvm_vmx.eoi_exitmap_changed);
>> >  __vmwrite(EOI_EXIT_BITMAP(i),
>v->arch.hvm_vmx.eoi_exit_bitmap[i]);
>> >  }
>> > -
>> > -pt_intr_post(v, intack);
>> >  }
>>
>> I'll defer to the VMX maintainers to determine whether removing this
>> but not the other one is correct.
>
>This is correct. The other one is for non-apicv scenario.
>
>>
>> > --- a/xen/arch/x86/hvm/vpt.c
>> > +++ b/xen/arch/x86/hvm/vpt.c
>> > @@ -252,7 +252,8 @@ int pt_update_irq(struct vcpu *v)
>> >  }
>> >  else
>> >  {
>> > -if ( (pt->last_plt_gtime + pt->period) < max_lag )
>> > +if ( (pt->last_plt_gtime + pt->period) < max_lag &&
>> > + !pt->irq_issued )
>> >  {
>> >  max_lag = pt->last_plt_gtime + pt->period;
>> >  earliest_pt = pt;
>>
>> Looking at the rest of the code I really wonder why this check hadn't
>> been there from the beginning. Tim, do recall whether this was
>> intentional (as opposed to simply having been an oversight)?
>>
>
>Possibly simplify the emulation by relying on IRR/ISR to handling pending
>situation?

I think IRR is enough. But there is a challenge that the pt interrupt is 
__not_only__ handled by LAPIC ( see the bottom of pt_update_irq() )..

Quan






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

[Xen-devel] Question about next_module() function

[조현권]

Hi

I am experimenting Xen with my embedded system environment and got a
question in next_module() function.

*static paddr_t __init next_module(paddr_t s, paddr_t *end)*
*{*
*struct bootmodules *mi = &bootinfo.modules;*
*paddr_t lowest = ~(paddr_t)0;*
*int i;*

*for ( i = 0; i < mi->nr_mods; i++ )*
*{*
*paddr_t mod_s = mi->module[i].start;*
*paddr_t mod_e = mod_s + mi->module[i].size;*

*if ( !mi->module[i].size )*
*continue;*

*if ( mod_s < s )*
*continue;*
*if ( mod_s > lowest )*
*continue;*
*if ( mod_s > *end )*
*continue;*
*lowest = mod_s;*
**end = min(*end, mod_e);*
*}*
*return lowest;*
*}*

The job of next_module() function is excluding module exist RAM range
between s and *end and finding empty space which can be heap space.

But Its function does not work if module range is bigger than s and *end
range.
(Case when module range is mod_s <= s and mod_e >= *end)

*if ( mod_s < s )*
*continue;*

Above condition passes the case and xen consider range s and *end is free
space.

Is it expected result or mistake?

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

[Xen-devel] [ovmf baseline-only test] 67757: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67757 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67757/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf ea317c0658b013659e064ba0323d1da8294acf4e
baseline version:
 ovmf 8b4ca351dded404f992504c45e358572c4d236f9

Last test of basis67755  2016-09-23 16:18:41 Z0 days
Testing same since67757  2016-09-23 19:17:25 Z0 days1 attempts


People who touched revisions under test:
  Tapan Shah 

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.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

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

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


Push not applicable.


commit ea317c0658b013659e064ba0323d1da8294acf4e
Author: Tapan Shah 
Date:   Fri Sep 23 09:10:28 2016 -0700

ShellPkg: Update help output for disconnect command

Minor changes to match help output notes for disconnect command
with UEFI Shell 2.2 specification document.

Few other formatting changes to fit the help output in 80x25 screen size.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Tapan Shah 
Reviewed-by: Jaben Carsey 

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

Re: [Xen-devel] [PATCH RFC v7 07/14] efi: create new early memory allocator

[Julien Grall]

Hi Daniel,

On 23/09/2016 22:47, Daniel Kiper wrote:

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 38eb888..2085f35 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -66,6 +67,7 @@ integer_param("xenheap_megabytes", opt_xenheap_megabytes);

 static __used void init_done(void)
 {
+free_ebmalloc_unused_mem();


I said no to this on the previous version. And I think Jan suggested a 
per-arch way to do it. So why is it here?


As mentioned, the EFI stub is standalone and should stay as it for now. 
With this solution, you break this assumption. I explained why it should 
not be done, and the issue you will run into by doing that.


So please don't call a function on ARM where it is known that it will 
not work.


Also, the EFI is not mandatory on ARM, for instance this code will not 
build on ARM32.


I much prefer a TODO comment (around the #ifdef CONFIG_ARM) to say what 
needs to be done for the time being.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2] x86/apicv: fix RTC periodic timer and apicv issue

[Tian, Kevin]

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, September 23, 2016 11:34 PM
> 
> >>> On 20.09.16 at 15:30,  wrote:
> > --- a/xen/arch/x86/hvm/vlapic.c
> > +++ b/xen/arch/x86/hvm/vlapic.c
> > @@ -433,6 +433,12 @@ void vlapic_EOI_set(struct vlapic *vlapic)
> >  void vlapic_handle_EOI(struct vlapic *vlapic, u8 vector)
> >  {
> >  struct domain *d = vlapic_domain(vlapic);
> > +struct vcpu *v = vlapic_vcpu(vlapic);
> > +struct hvm_intack pt_intack;
> > +
> > +pt_intack.vector = vector;
> > +pt_intack.source = hvm_intsrc_lapic;
> > +pt_intr_post(v, pt_intack);
> 
> This also sits on the EOI LAPIC register write path, i.e. the change
> then also affects non-apicv environments.

The new logic should be entered only when EOI-induced exit happens.

> 
> Furthermore - don't we have the same problem as with v1 again
> then? What prevents multiple EOIs to come here before the timer
> interrupt actually gets handled? You'd then clear ->irq_issued
> each time, rendering your change to pt_update_irq() ineffective.

based on this patch, one irq_issued should cause only one EOI on
related pt vector and this EOI exit clears irq_issued then next EOI
would be seen only upon another injection when irq_issued is set
again... However there might be an issue if this pt vector is shared 
with another device interrupt, which although is not a typical case...

> 
> In any event please use hvm_intack_lapic() instead of open
> coding it (and then I don't think you need a local variable at all).
> 
> > --- a/xen/arch/x86/hvm/vmx/intr.c
> > +++ b/xen/arch/x86/hvm/vmx/intr.c
> > @@ -333,8 +333,6 @@ void vmx_intr_assist(void)
> >  clear_bit(i, &v->arch.hvm_vmx.eoi_exitmap_changed);
> >  __vmwrite(EOI_EXIT_BITMAP(i), 
> > v->arch.hvm_vmx.eoi_exit_bitmap[i]);
> >  }
> > -
> > -pt_intr_post(v, intack);
> >  }
> 
> I'll defer to the VMX maintainers to determine whether removing this
> but not the other one is correct.

This is correct. The other one is for non-apicv scenario.

> 
> > --- a/xen/arch/x86/hvm/vpt.c
> > +++ b/xen/arch/x86/hvm/vpt.c
> > @@ -252,7 +252,8 @@ int pt_update_irq(struct vcpu *v)
> >  }
> >  else
> >  {
> > -if ( (pt->last_plt_gtime + pt->period) < max_lag )
> > +if ( (pt->last_plt_gtime + pt->period) < max_lag &&
> > + !pt->irq_issued )
> >  {
> >  max_lag = pt->last_plt_gtime + pt->period;
> >  earliest_pt = pt;
> 
> Looking at the rest of the code I really wonder why this check
> hadn't been there from the beginning. Tim, do recall whether
> this was intentional (as opposed to simply having been an
> oversight)?
> 

Possibly simplify the emulation by relying on IRR/ISR to handling pending
situation?

Thanks
Kevin

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

Re: [Xen-devel] [PATCH] VMX: don't bypass vmx_update_secondary_exec_control()

[Tian, Kevin]

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, September 20, 2016 9:04 PM
> 
> While putting together another patch modifying the secondary exec
> controls I noticed that vmx_vcpu_update_vmfunc_ve() does a raw VMWRITE
> instead of going through the designated function. I assume that is not
> how it should be.
> 
> Signed-off-by: Jan Beulich 
> 

Acked-by: Kevin Tian 

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

[Xen-devel] [PATCH v7 06/14] efi: build xen.gz with EFI code

[Daniel Kiper]

Build xen.gz with EFI code. We need this to support multiboot2
protocol on EFI platforms.

If we wish to load non-ELF file using multiboot (v1) or multiboot2 then
it must contain "linear" (or "flat") representation of code and data.
This is requirement of both boot protocols. Currently, PE file contains
many sections which are not "linear" (one after another without any holes)
or even do not have representation in a file (e.g. BSS). From EFI point
of view everything is OK and works. However, this file layout cannot be
properly interpreted by multiboot protocols family. In theory there is
a chance that we could build proper PE file (from multiboot protocols POV)
using current build system. However, it means that xen.efi further diverge
from Xen ELF file (in terms of contents and build method). On the other
hand ELF has all needed properties. So, it means that this is good starting
point for further development. Additionally, I think that this is also good
starting point for further xen.efi code and build optimizations. It looks
that there is a chance that finally we can generate xen.efi directly from
Xen ELF using just simple objcopy or other tool. This way we will have one
Xen binary which can be loaded by three boot protocols: EFI native loader,
multiboot (v1) and multiboot2.

Signed-off-by: Daniel Kiper 
Acked-by: Jan Beulich 
---
v6 - suggestions/fixes:
   - improve efi_enabled() checks in efi_runtime_call()
 (suggested by Jan Beulich).

v5 - suggestions/fixes:
   - properly calculate efi symbol address in
 xen/arch/x86/xen.lds.S (I hope that this
 change does not invalidate Jan's ACK).

v4 - suggestions/fixes:
   - functions should return -ENOSYS instead
 of -EOPNOTSUPP if EFI runtime services
 are not available
 (suggested by Jan Beulich),
   - remove stale bits from xen/arch/x86/Makefile
 (suggested by Jan Beulich).

v3 - suggestions/fixes:
   - check for EFI platform in EFI code
 (suggested by Jan Beulich),
   - fix Makefiles
 (suggested by Jan Beulich),
   - improve commit message
 (suggested by Jan Beulich).

v2 - suggestions/fixes:
   - build EFI code only if it is supported in a given build environment
 (suggested by Jan Beulich).
---
 xen/arch/x86/Makefile |2 +-
 xen/arch/x86/efi/Makefile |   12 
 xen/arch/x86/xen.lds.S|4 ++--
 xen/common/efi/boot.c |3 +++
 xen/common/efi/runtime.c  |9 +
 5 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index c3a8920..49d7e59 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -223,7 +223,7 @@ efi/mkreloc: efi/mkreloc.c
 clean::
rm -f asm-offsets.s *.lds boot/*.o boot/*~ boot/core boot/mkelf32
rm -f $(BASEDIR)/.xen-syms.[0-9]* boot/.*.d
-   rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.o efi/.*.d efi/*.efi 
efi/disabled efi/mkreloc
+   rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.efi efi/disabled efi/mkreloc
rm -f boot/reloc.S boot/reloc.lnk boot/reloc.bin
rm -f note.o
$(MAKE) -f $(BASEDIR)/Rules.mk -C test clean
diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
index ad3fdf7..442f3fc 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -1,18 +1,14 @@
 CFLAGS += -fshort-wchar
 
-obj-y += stub.o
-
-create = test -e $(1) || touch -t 19990101 $(1)
-
 efi := y$(shell rm -f disabled)
 efi := $(if $(efi),$(shell $(CC) $(filter-out $(CFLAGS-y) .%.d,$(CFLAGS)) -c 
check.c 2>disabled && echo y))
 efi := $(if $(efi),$(shell $(LD) -mi386pep --subsystem=10 -o check.efi check.o 
2>disabled && echo y))
-efi := $(if $(efi),$(shell rm disabled)y,$(shell $(call create,boot.init.o); 
$(call create,runtime.o)))
-
-extra-$(efi) += boot.init.o relocs-dummy.o runtime.o compat.o buildid.o
+efi := $(if $(efi),$(shell rm disabled)y)
 
 %.o: %.ihex
$(OBJCOPY) -I ihex -O binary $< $@
 
-stub.o: $(extra-y)
+obj-y := stub.o
+obj-$(efi) := boot.init.o compat.o relocs-dummy.o runtime.o
+extra-$(efi) += buildid.o
 nogcov-$(efi) += stub.o
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 9adb2f3..38baea3 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -267,8 +267,6 @@ SECTIONS
 *(.reloc)
   } :text
   . = ALIGN(__section_alignment__);
-#else
-  efi = .;
 #endif
 
   /* Trick the linker into setting the image size to exactly 16Mb. */
@@ -277,6 +275,8 @@ SECTIONS
 __end_of_image__ = .;
   } :text
 
+  efi = DEFINED(efi) ? efi : .;
+
   /* Sections to be discarded */
   /DISCARD/ : {
*(.exit.text)
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 56544dc..1ef5d0b 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1251,6 +1251,9 @@ void __init efi_init_memory(void)
 } *extra, *extra_head = NULL;
 #endif
 
+if ( !efi_enabled(EFI_BOOT) )
+return;
+
 printk(XENLOG_INFO "EFI memory map:%s\n",
map_bs ? " (mapping BootServices)" : "");
 

[Xen-devel] [PATCH v7 12/14] x86: make Xen early boot code relocatable

[Daniel Kiper]

Every multiboot protocol (regardless of version) compatible image must
specify its load address (in ELF or multiboot header). Multiboot protocol
compatible loader have to load image at specified address. However, there
is no guarantee that the requested memory region (in case of Xen it starts
at 2 MiB and ends at ~5 MiB) where image should be loaded initially is a RAM
and it is free (legacy BIOS platforms are merciful for Xen but I found at
least one EFI platform on which Xen load address conflicts with EFI boot
services; it is Dell PowerEdge R820 with latest firmware). To cope with that
problem we must make Xen early boot code relocatable and help boot loader to
relocate image in proper way by suggesting, not requesting specific load
addresses as it is right now, allowed address ranges. This patch does former.
It does not add multiboot2 protocol interface which is done in "x86: add
multiboot2 protocol support for relocatable images" patch.

This patch changes following things:
  - %esi and %r15d registers are used as a storage for Xen image load base
address (%r15d shortly because %rsi is used for EFI SystemTable address
in 64-bit code); both registers are (%esi is mostly) unused in early
boot code and preserved during C functions calls (%esi in 32-bit code
and %r15d in 64-bit code),
  - %fs is used as base for Xen data relative addressing in 32-bit code
if it is possible; %esi is used for that thing during error printing
because it is not always possible to properly and efficiently
initialize %fs.

Signed-off-by: Daniel Kiper 
---
v6 - suggestions/fixes:
   - leave static mapping of first
 16 MiB in l2_identmap as is
 (suggested by Jan Beulich),
   - use xen_phys_start instead of xen_img_load_base_addr
 (suggested by Daniel Kiper and Jan Beulich),
   - simplify BOOT_FS segment descriptor
 base address initialization
 (suggested by Jan Beulich),
   - fix BOOT_FS segment limit
 (suggested by Jan Beulich),
   - do not rename sym_phys in this patch
 (suggested by Jan Beulich),
   - rename esi_offset/fs_offset to
 sym_esi/sym_fs respectively
 (suggested by Jan Beulich),
   - use add instead of lea in assembly
 error printing code
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - improve commit message
 (suggested by Jan Beulich),
   - various minor cleanups and fixes
 (suggested by Jan Beulich).

v4 - suggestions/fixes:
   - do not relocate Xen image if boot loader did work for us
 (suggested by Andrew Cooper and Jan Beulich),
   - initialize xen_img_load_base_addr in EFI boot code too,
   - properly initialize trampoline_xen_phys_start,
   - calculate Xen image load base address in
 x86_64 code ourselves,
 (suggested by Jan Beulich),
   - change how and when Xen image base address is printed,
   - use %fs instead of %esi for relative addressing
 (suggested by Andrew Cooper and Jan Beulich),
   - create esi_offset and fs_offset() macros in assembly,
   - calculate  mkelf32 argument automatically,
   - optimize and cleanup code,
   - improve comments,
   - improve commit message.

v3 - suggestions/fixes:
   - improve segment registers initialization
 (suggested by Jan Beulich),
   - simplify Xen image load base address calculation
 (suggested by Jan Beulich),
   - use %esi and %r15d instead of %ebp to store
 Xen image load base address,
   - use %esi instead of %fs for relative addressing;
 this way we get shorter and simpler code,
   - rename some variables and constants
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Konrad Rzeszutek Wilk),
   - improve commit message
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/head.S  |  163 +
 xen/arch/x86/boot/trampoline.S|5 ++
 xen/arch/x86/boot/x86_64.S|   26 +++---
 xen/arch/x86/setup.c  |   14 ++--
 xen/arch/x86/x86_64/asm-offsets.c |3 +
 xen/include/asm-x86/page.h|2 +-
 6 files changed, 157 insertions(+), 56 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index c301464..9b1fd0e 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -13,12 +13,15 @@
 .code32
 
 #define sym_phys(sym) ((sym) - __XEN_VIRT_START)
+#define sym_esi(sym)  sym_phys(sym)(%esi)
+#define sym_fs(sym)   %fs:sym_phys(sym)
 
 #define BOOT_CS320x0008
 #define BOOT_CS640x0010
 #define BOOT_DS  0x0018
 #define BOOT_PSEUDORM_CS 0x0020
 #define BOOT_PSEUDORM_DS 0x0028
+#define BOOT_FS  0x0030
 
 #define MB2_HT(name)  (MULTIBOOT2_HEADER_TAG_##name)
 #define MB2_TT(name)  (MULTIBOOT2_TAG_TYPE_##name)
@@ -105,7 +108,8 @@ multiboot2_header_start:
 
 .word   0
 gdt_boot_descr:
-.word   6*8-1
+.word   7*8-1
+gdt_boot_base:
 .long   sym_phys(trampoline_gdt)
 .long   0 /* Needed for 64-bit lgdt 

[Xen-devel] [PATCH v7 09/14] x86/boot: implement early command line parser in C

[Daniel Kiper]

Current early command line parser implementation in assembler
is very difficult to change to relocatable stuff using segment
registers. This requires a lot of changes in very weird and
fragile code. So, reimplement this functionality in C. This
way code will be relocatable out of the box (without playing
with segment registers) and much easier to maintain.

Additionally, put all common cmdline.c and reloc.c definitions
into defs.h header. This way we do not duplicate needlessly
some stuff.

And finally remove unused xen/include/asm-x86/config.h
header from reloc.c dependencies.

Suggested-by: Andrew Cooper 
Signed-off-by: Daniel Kiper 
---
v7 - suggestions/fixes:
   - add min() macro
 (suggested by Jan Beulich),
   - add padding to early_boot_opts_t
 in more standard way
 (suggested by Jan Beulich),
   - simplify defs.h dependencies
 (suggested by Jan Beulich).

v6 - suggestions/fixes:
   - put common cmdline.c and reloc.c
 definitions into defs.h header
 (suggested by Jan Beulich),
   - use xen/include/xen/stdbool.h
 and bool type from it instead
 of own defined bool_t
 (suggested by Jan Beulich),
   - define delim_chars as constant
 (suggested by Jan Beulich),
   - properly align trampoline.S:early_boot_opts struct
 (suggested by Jan Beulich),
   - fix overflow check in strtoui()
 (suggested by Jan Beulich),
   - remove unused xen/include/asm-x86/config.h
 header from reloc.c dependencies,
   - improve commit message.

v4 - suggestions/fixes:
   - move to stdcall calling convention
 (suggested by Jan Beulich),
   - define bool_t and use it properly
 (suggested by Jan Beulich),
   - put list of delimiter chars into
 static const char[]
 (suggested by Jan Beulich),
   - use strlen() instead of strlen_opt()
 (suggested by Jan Beulich),
   - change strtoi() to strtoui() and
 optimize it a bit
 (suggested by Jan Beulich),
   - define strchr() and use it in strtoui()
 (suggested by Jan Beulich),
   - optimize vga_parse()
 (suggested by Jan Beulich),
   - move !cmdline check from assembly to C
 (suggested by Jan Beulich),
   - remove my name from copyright (Oracle requirement)
 (suggested by Konrad Rzeszutek Wilk).

v3 - suggestions/fixes:
   - optimize some code
 (suggested by Jan Beulich),
   - put VESA data into early_boot_opts_t members
 (suggested by Jan Beulich),
   - rename some functions and variables
 (suggested by Jan Beulich),
   - move around video.h include in xen/arch/x86/boot/trampoline.S
 (suggested by Jan Beulich),
   - fix coding style
 (suggested by Jan Beulich),
   - fix build with older GCC
 (suggested by Konrad Rzeszutek Wilk),
   - remove redundant comments
 (suggested by Jan Beulich),
   - add some comments
   - improve commit message
 (suggested by Jan Beulich).
---
 .gitignore |5 +-
 xen/arch/x86/Makefile  |2 +-
 xen/arch/x86/boot/Makefile |   11 +-
 xen/arch/x86/boot/build32.mk   |2 +
 xen/arch/x86/boot/cmdline.S|  367 
 xen/arch/x86/boot/cmdline.c|  340 +
 xen/arch/x86/boot/defs.h   |   58 +++
 xen/arch/x86/boot/edd.S|3 -
 xen/arch/x86/boot/head.S   |8 +
 xen/arch/x86/boot/reloc.c  |   13 +-
 xen/arch/x86/boot/trampoline.S |   15 ++
 xen/arch/x86/boot/video.S  |7 -
 12 files changed, 437 insertions(+), 394 deletions(-)
 delete mode 100644 xen/arch/x86/boot/cmdline.S
 create mode 100644 xen/arch/x86/boot/cmdline.c
 create mode 100644 xen/arch/x86/boot/defs.h

diff --git a/.gitignore b/.gitignore
index cc64fc9..9aa47a1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -247,9 +247,10 @@ xen/arch/arm/xen.lds
 xen/arch/x86/asm-offsets.s
 xen/arch/x86/boot/mkelf32
 xen/arch/x86/xen.lds
+xen/arch/x86/boot/cmdline.S
 xen/arch/x86/boot/reloc.S
-xen/arch/x86/boot/reloc.bin
-xen/arch/x86/boot/reloc.lnk
+xen/arch/x86/boot/*.bin
+xen/arch/x86/boot/*.lnk
 xen/arch/x86/efi.lds
 xen/arch/x86/efi/check.efi
 xen/arch/x86/efi/disabled
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 49d7e59..7d37728 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -224,6 +224,6 @@ clean::
rm -f asm-offsets.s *.lds boot/*.o boot/*~ boot/core boot/mkelf32
rm -f $(BASEDIR)/.xen-syms.[0-9]* boot/.*.d
rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.efi efi/disabled efi/mkreloc
-   rm -f boot/reloc.S boot/reloc.lnk boot/reloc.bin
+   rm -f boot/cmdline.S boot/reloc.S boot/*.lnk boot/*.bin
rm -f note.o
$(MAKE) -f $(BASEDIR)/Rules.mk -C test clean
diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index 06893d8..c6246c8 100644
--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -1,9 +1,16 @@
 obj-bin-y += head.o
 
-RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h 
$(BASEDIR)/include/xen/multiboot.h \
+DEFS_H_DEPS = defs.h $(BASEDIR)/incl

[Xen-devel] [PATCH v7 00/14] x86: multiboot2 protocol support

[Daniel Kiper]

Hi,

I am sending seventh version of multiboot2 protocol support for
legacy BIOS and EFI platforms. This patch series release contains
fixes for all known issues.

The final goal is xen.efi binary file which could be loaded by EFI
loader, multiboot (v1) protocol (only on legacy BIOS platforms) and
multiboot2 protocol. This way we will have:
  - smaller Xen code base,
  - one code base for xen.gz and xen.efi,
  - one build method for xen.gz and xen.efi;
xen.efi will be extracted from xen(-syms)
file using objcopy or special custom tool,
  - xen.efi build will not so strongly depend
on a given GCC and binutils version.

Here is short list of changes since v6:
  - new patches: 01,
  - changed patches: 02-04, 07-10,
  - RFC patches: 07.

Patches 12-14 were reviewed by nobody last time.

Julien Grall raised some concerns in regards to EFI boot allocator
implementation on ARM. So, I marked patch #07 which introduces it
as RFC. Hence, I am asking ARM guys to review it and suggest needed
changes. If you have any questions please drop me a line.

I hope that (at least some) features provided by this patch series
will be included in Xen 4.8 release in one way or another.

If you are not interested in this patch series at all please
drop me a line and I will remove you from distribution list.

Daniel

 .gitignore|5 +-
 xen/arch/arm/setup.c  |2 +
 xen/arch/x86/Makefile |8 +-
 xen/arch/x86/Rules.mk |3 +
 xen/arch/x86/boot/Makefile|   12 +-
 xen/arch/x86/boot/build32.mk  |2 +
 xen/arch/x86/boot/cmdline.S   |  367 

 xen/arch/x86/boot/cmdline.c   |  340 

 xen/arch/x86/boot/defs.h  |   58 +
 xen/arch/x86/boot/edd.S   |3 -
 xen/arch/x86/boot/head.S  |  539 
++
 xen/arch/x86/boot/reloc.c |  151 +--
 xen/arch/x86/boot/trampoline.S|   22 +++-
 xen/arch/x86/boot/video.S |7 --
 xen/arch/x86/boot/wakeup.S|4 +-
 xen/arch/x86/boot/x86_64.S|   44 +++
 xen/arch/x86/dmi_scan.c   |4 +-
 xen/arch/x86/domain_page.c|2 +-
 xen/arch/x86/efi/Makefile |   12 +-
 xen/arch/x86/efi/efi-boot.h   |   60 --
 xen/arch/x86/efi/stub.c   |   48 +++-
 xen/arch/x86/mpparse.c|4 +-
 xen/arch/x86/setup.c  |   36 +++---
 xen/arch/x86/shutdown.c   |5 +-
 xen/arch/x86/time.c   |2 +-
 xen/arch/x86/x86_64/asm-offsets.c |   15 +++
 xen/arch/x86/xen.lds.S|   16 +--
 xen/common/efi/boot.c |   71 ++-
 xen/common/efi/runtime.c  |   23 +++-
 xen/common/version.c  |2 +-
 xen/drivers/acpi/osl.c|2 +-
 xen/include/asm-x86/page.h|2 +-
 xen/include/xen/efi.h |9 +-
 xen/include/xen/multiboot2.h  |  182 
 34 files changed, 1522 insertions(+), 540 deletions(-)

Daniel Kiper (14):
  x86: move xen ELF end of image to 16 MiB
  x86: properly calculate xen ELF end of image address
  x86: add multiboot2 protocol support
  efi: create efi_enabled()
  x86: allow EFI reboot method neither on EFI platforms...
  efi: build xen.gz with EFI code
  efi: create new early memory allocator
  x86: add multiboot2 protocol support for EFI platforms
  x86/boot: implement early command line parser in C
  x86: change default load address from 1 MiB to 2 MiB
  x86/setup: use XEN_IMG_OFFSET instead of...
  x86: make Xen early boot code relocatable
  x86/boot: rename sym_phys() to sym_offs()
  x86: add multiboot2 protocol support for relocatable images


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

[Xen-devel] [PATCH v7 14/14] x86: add multiboot2 protocol support for relocatable images

[Daniel Kiper]

Add multiboot2 protocol support for relocatable images. Only GRUB2 with
"multiboot2: Add support for relocatable images" patch understands
that feature. Older multiboot protocol (regardless of version)
compatible loaders ignore it and everything works as usual.

Signed-off-by: Daniel Kiper 
---
v4 - suggestions/fixes:
   - do not get Xen image load base address from
 multiboot2 information in x86_64 code
 (suggested by Jan Beulich),
   - improve label names
 (suggested by Jan Beulich),
   - improve comments,
 (suggested by Jan Beulich).

v3 - suggestions/fixes:
   - use %esi and %r15d instead of %ebp to store
 Xen image load base address,
   - rename some types and constants,
   - reformat xen/include/xen/multiboot2.h
 (suggested by Konrad Rzeszutek Wilk),
   - improve comments,
   - improve commit message
 (suggested by Konrad Rzeszutek Wilk).
---
 xen/arch/x86/boot/head.S  |   19 ++-
 xen/arch/x86/x86_64/asm-offsets.c |1 +
 xen/include/xen/multiboot2.h  |   13 +
 3 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 76090eb..b743092 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -82,6 +82,13 @@ multiboot2_header_start:
 /* Align modules at page boundry. */
 mb2ht_init MB2_HT(MODULE_ALIGN), MB2_HT(REQUIRED)
 
+/* Load address preference. */
+mb2ht_init MB2_HT(RELOCATABLE), MB2_HT(OPTIONAL), \
+   sym_offs(start), /* Min load address. */ \
+   0x, /* The end of image max load address (4 GiB - 
1). */ \
+   0x20, /* Load address alignment (2 MiB). */ \
+   MULTIBOOT2_LOAD_PREFERENCE_HIGH
+
 /* Console flags tag. */
 mb2ht_init MB2_HT(CONSOLE_FLAGS), MB2_HT(OPTIONAL), \
MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED
@@ -383,10 +390,19 @@ __start:
 cmp %edi,MB2_fixed_total_size(%ebx)
 jbe trampoline_bios_setup
 
+/* Get Xen image load base address from Multiboot2 information. */
+cmpl$MULTIBOOT2_TAG_TYPE_LOAD_BASE_ADDR,MB2_tag_type(%ecx)
+jne 1f
+
+mov MB2_load_base_addr(%ecx),%esi
+sub $XEN_IMG_OFFSET,%esi
+jmp 9f
+
+1:
 /* Get mem_lower from Multiboot2 information. */
 cmpl$MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,MB2_tag_type(%ecx)
 cmove   MB2_mem_lower(%ecx),%edx
-je  trampoline_bios_setup
+je  9f
 
 /* EFI IA-32 platforms are not supported. */
 cmpl$MULTIBOOT2_TAG_TYPE_EFI32,MB2_tag_type(%ecx)
@@ -400,6 +416,7 @@ __start:
 cmpl$MULTIBOOT2_TAG_TYPE_END,MB2_tag_type(%ecx)
 je  trampoline_bios_setup
 
+9:
 /* Go to next Multiboot2 information tag. */
 add MB2_tag_size(%ecx),%ecx
 add $(MULTIBOOT2_TAG_ALIGN-1),%ecx
diff --git a/xen/arch/x86/x86_64/asm-offsets.c 
b/xen/arch/x86/x86_64/asm-offsets.c
index 5d7a8e5..beac5ca 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -174,6 +174,7 @@ void __dummy__(void)
 OFFSET(MB2_fixed_total_size, multiboot2_fixed_t, total_size);
 OFFSET(MB2_tag_type, multiboot2_tag_t, type);
 OFFSET(MB2_tag_size, multiboot2_tag_t, size);
+OFFSET(MB2_load_base_addr, multiboot2_tag_load_base_addr_t, 
load_base_addr);
 OFFSET(MB2_mem_lower, multiboot2_tag_basic_meminfo_t, mem_lower);
 OFFSET(MB2_efi64_st, multiboot2_tag_efi64_t, pointer);
 OFFSET(MB2_efi64_ih, multiboot2_tag_efi64_ih_t, pointer);
diff --git a/xen/include/xen/multiboot2.h b/xen/include/xen/multiboot2.h
index 8dd5800..feb4297 100644
--- a/xen/include/xen/multiboot2.h
+++ b/xen/include/xen/multiboot2.h
@@ -59,11 +59,17 @@
 #define MULTIBOOT2_HEADER_TAG_EFI_BS   7
 #define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI32  8
 #define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI64  9
+#define MULTIBOOT2_HEADER_TAG_RELOCATABLE  10
 
 /* Header tag flags. */
 #define MULTIBOOT2_HEADER_TAG_REQUIRED 0
 #define MULTIBOOT2_HEADER_TAG_OPTIONAL 1
 
+/* Where image should be loaded (suggestion not requirement). */
+#define MULTIBOOT2_LOAD_PREFERENCE_NONE0
+#define MULTIBOOT2_LOAD_PREFERENCE_LOW 1
+#define MULTIBOOT2_LOAD_PREFERENCE_HIGH2
+
 /* Header console tag console_flags. */
 #define MULTIBOOT2_CONSOLE_FLAGS_CONSOLE_REQUIRED  1
 #define MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED2
@@ -90,6 +96,7 @@
 #define MULTIBOOT2_TAG_TYPE_EFI_BS 18
 #define MULTIBOOT2_TAG_TYPE_EFI32_IH   19
 #define MULTIBOOT2_TAG_TYPE_EFI64_IH   20
+#define MULTIBOOT2_TAG_TYPE_LOAD_BASE_ADDR 21
 
 /* Multiboot 2 tag alignment. */
 #define MULTIBOOT2_TAG_ALIGN   8
@@ -120,

[Xen-devel] [PATCH v7 11/14] x86/setup: use XEN_IMG_OFFSET instead of...

[Daniel Kiper]

..calculating its value during runtime.

Signed-off-by: Daniel Kiper 
Acked-by: Jan Beulich 
---
 xen/arch/x86/setup.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index f19af6e..ca1a97a 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -901,7 +901,6 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 l4_pgentry_t *pl4e;
 l3_pgentry_t *pl3e;
 l2_pgentry_t *pl2e;
-uint64_t load_start;
 int i, j, k;
 
 /* Select relocation address. */
@@ -915,9 +914,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
  * with a barrier(). After this we must *not* modify static/global
  * data until after we have switched to the relocated pagetables!
  */
-load_start = (unsigned long)_start - XEN_VIRT_START;
 barrier();
-move_memory(e + load_start, load_start, _end - _start, 1);
+move_memory(e + XEN_IMG_OFFSET, XEN_IMG_OFFSET, _end - _start, 1);
 
 /* Walk initial pagetables, relocating page directory entries. */
 pl4e = __va(__pa(idle_pg_table));
-- 
1.7.10.4


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

[Xen-devel] [PATCH RFC v7 07/14] efi: create new early memory allocator

[Daniel Kiper]

There is a problem with place_string() which is used as early memory
allocator. It gets memory chunks starting from start symbol and goes
down. Sadly this does not work when Xen is loaded using multiboot2
protocol because then the start lives on 1 MiB address and we should
not allocate a memory from below of it. So, I tried to use mem_lower
address calculated by GRUB2. However, this solution works only on some
machines. There are machines in the wild (e.g. Dell PowerEdge R820)
which uses first ~640 KiB for boot services code or data... :-(((
Hence, we need new memory allocator for Xen EFI boot code which is
quite simple and generic and could be used by place_string() and
efi_arch_allocate_mmap_buffer(). I think about following solutions:

1) We could use native EFI allocation functions (e.g. AllocatePool()
   or AllocatePages()) to get memory chunk. However, later (somewhere
   in __start_xen()) we must copy its contents to safe place or reserve
   it in e820 memory map and map it in Xen virtual address space. This
   means that the code referring to Xen command line, loaded modules and
   EFI memory map, mostly in __start_xen(), will be further complicated
   and diverge from legacy BIOS cases. Additionally, both former things
   have to be placed below 4 GiB because their addresses are stored in
   multiboot_info_t structure which has 32-bit relevant members.

2) We may allocate memory area statically somewhere in Xen code which
   could be used as memory pool for early dynamic allocations. Looks
   quite simple. Additionally, it would not depend on EFI at all and
   could be used on legacy BIOS platforms if we need it. However, we
   must carefully choose size of this pool. We do not want increase Xen
   binary size too much and waste too much memory but also we must fit
   at least memory map on x86 EFI platforms. As I saw on small machine,
   e.g. IBM System x3550 M2 with 8 GiB RAM, memory map may contain more
   than 200 entries. Every entry on x86-64 platform is 40 bytes in size.
   So, it means that we need more than 8 KiB for EFI memory map only.
   Additionally, if we use this memory pool for Xen and modules command
   line storage (it would be used when xen.efi is executed as EFI application)
   then we should add, I think, about 1 KiB. In this case, to be on safe
   side, we should assume at least 64 KiB pool for early memory allocations.
   Which is about 4 times of our earlier calculations. However, during
   discussion on Xen-devel Jan Beulich suggested that just in case we should
   use 1 MiB memory pool like it is in original place_string() implementation.
   So, let's use 1 MiB as it was proposed. If we think that we should not
   waste unallocated memory in the pool on running system then we can mark
   this region as __initdata and move all required data to dynamically
   allocated places somewhere in __start_xen().

2a) We could put memory pool into .bss.page_aligned section. Then allocate
memory chunks starting from the lowest address. After init phase we can
free unused portion of the memory pool as in case of .init.text or 
.init.data
sections. This way we do not need to allocate any space in image file and
freeing of unused area in the memory pool is very simple.

Now #2a solution is implemented because it is quite simple and requires
limited number of changes, especially in __start_xen().

New allocator is quite generic and can be used on ARM platforms too.
So, let's enable most of its machinery on them.

Signed-off-by: Daniel Kiper 
---
v7 - suggestions/fixes:
   - enable most of ebmalloc machinery on ARM platforms
 (suggested by Jan Beulich),
   - remove unneeded cast
 (suggested by Jan Beulich),
   - wrap long line
 (suggested by Jan Beulich),
   - improve commit message.

v6 - suggestions/fixes:
   - optimize ebmalloc allocator,
   - move ebmalloc machinery to xen/common/efi/boot.c
 (suggested by Jan Beulich),
   - enforce PAGE_SIZE ebmalloc_mem alignment
 (suggested by Jan Beulich),
   - ebmalloc() must allocate properly
 aligned memory regions
 (suggested by Jan Beulich),
   - printk() should use XENLOG_INFO
 (suggested by Jan Beulich).

v4 - suggestions/fixes:
   - move from #2 solution to #2a solution,
   - improve commit message.
---
 xen/arch/arm/setup.c|2 ++
 xen/arch/x86/efi/efi-boot.h |   11 +++
 xen/arch/x86/efi/stub.c |2 ++
 xen/arch/x86/setup.c|5 +++--
 xen/common/efi/boot.c   |   38 ++
 xen/include/xen/efi.h   |1 +
 6 files changed, 49 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 38eb888..2085f35 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -66,6 +67,7 @@ integer_param("xenheap_megabytes", opt_xenheap_megabytes);
 
 static __used void init_done(void)
 {
+free_ebmall

[Xen-devel] [PATCH v7 03/14] x86: add multiboot2 protocol support

[Daniel Kiper]

Add multiboot2 protocol support. Alter min memory limit handling as we
now may not find it from either multiboot (v1) or multiboot2.

This way we are laying the foundation for EFI + GRUB2 + Xen development.

Signed-off-by: Daniel Kiper 
---
v7 - suggestions/fixes:
   - rename mbi_mbi/mbi2_mbi to mbi_reloc/mbi2_reloc respectively
 (suggested by Jan Beulich),
   - initialize mbi_out->flags using "|=" instead of "="
 (suggested by Jan Beulich),
   - use sizeof(*mmap_dst) instead of sizeof(memory_map_t)
 if it makes sense
 (suggested by Jan Beulich).

v6 - suggestions/fixes:
   - properly index multiboot2_tag_mmap_t.entries[]
 (suggested by Jan Beulich),
   - do not index mbi_out_mods[] beyond its end
 (suggested by Andrew Cooper),
   - reduce number of casts
 (suggested by Andrew Cooper and Jan Beulich),
   - add braces to increase code readability
 (suggested by Andrew Cooper).

v5 - suggestions/fixes:
   - check multiboot2_tag_mmap_t.entry_size before
 multiboot2_tag_mmap_t.entries[] use
 (suggested by Jan Beulich),
   - properly index multiboot2_tag_mmap_t.entries[]
 (suggested by Jan Beulich),
   - use "type name[]" instad of "type name[0]"
 in xen/include/xen/multiboot2.h
 (suggested by Jan Beulich),
   - remove unneeded comment
 (suggested by Jan Beulich).

v4 - suggestions/fixes:
   - avoid assembly usage in xen/arch/x86/boot/reloc.c,
   - fix boundary check issue and optimize
 for() loops in mbi2_mbi(),
   - move to stdcall calling convention,
   - remove unneeded typeof() from ALIGN_UP() macro
 (suggested by Jan Beulich),
   - add and use NULL definition in xen/arch/x86/boot/reloc.c
 (suggested by Jan Beulich),
   - do not read data beyond the end of multiboot2
 information in xen/arch/x86/boot/head.S
 (suggested by Jan Beulich),
   - add :req to some .macro arguments
 (suggested by Jan Beulich),
   - use cmovcc if possible,
   - add .L to multiboot2_header_end label
 (suggested by Jan Beulich),
   - add .L to multiboot2_proto label
 (suggested by Jan Beulich),
   - improve label names
 (suggested by Jan Beulich).

v3 - suggestions/fixes:
   - reorder reloc() arguments
 (suggested by Jan Beulich),
   - remove .L from multiboot2 header labels
 (suggested by Andrew Cooper, Jan Beulich and Konrad Rzeszutek Wilk),
   - take into account alignment when skipping multiboot2 fixed part
 (suggested by Konrad Rzeszutek Wilk),
   - create modules data if modules count != 0
 (suggested by Jan Beulich),
   - improve macros
 (suggested by Jan Beulich),
   - reduce number of casts
 (suggested by Jan Beulich),
   - use const if possible
 (suggested by Jan Beulich),
   - drop static and __used__ attribute from reloc()
 (suggested by Jan Beulich),
   - remove isolated/stray __packed attribute from
 multiboot2_memory_map_t type definition
 (suggested by Jan Beulich),
   - reformat xen/include/xen/multiboot2.h
 (suggested by Konrad Rzeszutek Wilk),
   - improve comments
 (suggested by Konrad Rzeszutek Wilk),
   - remove hard tabs
 (suggested by Jan Beulich and Konrad Rzeszutek Wilk).

v2 - suggestions/fixes:
   - generate multiboot2 header using macros
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - simplify assembly in xen/arch/x86/boot/head.S
 (suggested by Jan Beulich),
   - do not include include/xen/compiler.h
 in xen/arch/x86/boot/reloc.c
 (suggested by Jan Beulich),
   - do not read data beyond the end of multiboot2 information
 (suggested by Jan Beulich).

v2 - not fixed yet:
   - dynamic dependency generation for xen/arch/x86/boot/reloc.S;
 this requires more work; I am not sure that it pays because
 potential patch requires more changes than addition of just
 multiboot2.h to Makefile
 (suggested by Jan Beulich),
   - isolated/stray __packed attribute usage for multiboot2_memory_map_t
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/Makefile|3 +-
 xen/arch/x86/boot/head.S  |  107 ++-
 xen/arch/x86/boot/reloc.c |  148 ++--
 xen/arch/x86/x86_64/asm-offsets.c |9 ++
 xen/include/xen/multiboot2.h  |  169 +
 5 files changed, 426 insertions(+), 10 deletions(-)
 create mode 100644 xen/include/xen/multiboot2.h

diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index 5fdb5ae..06893d8 100644
--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -1,6 +1,7 @@
 obj-bin-y += head.o
 
-RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h 
$(BASEDIR)/include/xen/multiboot.h
+RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h 
$(BASEDIR)/include/xen/multiboot.h \
+$(BASEDIR)/include/xen/multiboot2.h
 
 head.o: reloc.S
 
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 6f2c668..383ff79 100644
--- a/xen/arch/x86/boot/head.S
+++ 

[Xen-devel] [PATCH v7 02/14] x86: properly calculate xen ELF end of image address

[Daniel Kiper]

Currently xen ELF end of image address is calculated using first line from
"nm -nr xen/xen-syms" output. However, sometimes it may contain random
symbol address not related to the end of image in any way. It can happen
if a symbol is introduced with address larger than __end_of_image__ symbol
address. Such situation encountered when I linked xen ELF binary with
xen/arch/x86/efi/relocs-dummy.S. Then first line from "nm -nr xen/xen-syms"
contained "82d0c000 A ALT_START" and xen ELF image memory size
was silently set to 1023 MiB. This issue happened because there is no
check which symbol address is used to calculate end of image address. So,
let's fix it and take ELF end of image address by reading __end_of_image__
symbol address from nm output. This way xen ELF image build process is
not prone to changes in order of nm output.

Signed-off-by: Daniel Kiper 
---
v7 - suggestions/fixes:
   - use sed instead of awk
 (suggested by Jan Beulich),
   - improve commit message
 (suggested by Jan Beulich).
---
 xen/arch/x86/Makefile |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index d3875c5..c3a8920 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -91,7 +91,7 @@ endif
 
 $(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
./boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TARGET) 0x10 \
-   `$(NM) -nr $(TARGET)-syms | head -n 1 | sed -e 's/^\([^ ]*\).*/0x\1/'`
+   `$(NM) $(TARGET)-syms | sed -ne 's/^\([^ ]*\) . 
__end_of_image__$$/0x\1/p'`
 
 .PHONY: tests
 tests:
-- 
1.7.10.4


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

[Xen-devel] [PATCH v7 10/14] x86: change default load address from 1 MiB to 2 MiB

[Daniel Kiper]

Subsequent patches introducing relocatable early boot code play with
page tables using 2 MiB huge pages. If load address is not aligned at
2 MiB then code touching such page tables must have special cases for
start and end of Xen image memory region. So, let's make life easier
and move default load address from 1 MiB to 2 MiB. This way page table
code will be nice and easy. Hence, there is a chance that it will be
less error prone too... :-)))

Signed-off-by: Daniel Kiper 
Acked-by: Jan Beulich 
---
v7 - suggestions/fixes:
   - minor cleanups
 (suggested by Jan Beulich).
---
 xen/arch/x86/Makefile  |2 +-
 xen/arch/x86/Rules.mk  |3 +++
 xen/arch/x86/setup.c   |3 ++-
 xen/arch/x86/xen.lds.S |2 +-
 4 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 7d37728..04cc59f 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -90,7 +90,7 @@ all_symbols =
 endif
 
 $(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
-   ./boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TARGET) 0x10 \
+   ./boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TARGET) 
$(XEN_IMG_OFFSET) \
`$(NM) $(TARGET)-syms | sed -ne 's/^\([^ ]*\) . 
__end_of_image__$$/0x\1/p'`
 
 .PHONY: tests
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 42be4bc..36e6386 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -1,9 +1,12 @@
 
 # x86-specific definitions
 
+XEN_IMG_OFFSET := 0x20
+
 CFLAGS += -I$(BASEDIR)/include
 CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-generic
 CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-default
+CFLAGS += -DXEN_IMG_OFFSET=$(XEN_IMG_OFFSET)
 CFLAGS += '-D__OBJECT_LABEL__=$(subst /,$$,$(subst -,_,$(subst 
$(BASEDIR)/,,$(CURDIR))/$@))'
 
 # Prevent floating-point variables from creeping into Xen.
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 5b17783..f19af6e 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -957,7 +957,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
  * Undo the temporary-hooking of the l1_identmap.  __2M_text_start
  * is contained in this PTE.
  */
-BUG_ON(l2_table_offset((unsigned long)_erodata) ==
+BUG_ON(using_2M_mapping() &&
+   l2_table_offset((unsigned long)_erodata) ==
l2_table_offset((unsigned long)_stext));
 *pl2e++ = l2e_from_pfn(xen_phys_start >> PAGE_SHIFT,
PAGE_HYPERVISOR_RX | _PAGE_PSE);
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index f4b4e99..d9561e5 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -55,7 +55,7 @@ SECTIONS
   __2M_text_start = .; /* Start of 2M superpages, mapped RX. */
 #endif
 
-  . = __XEN_VIRT_START + MB(1);
+  . = __XEN_VIRT_START + XEN_IMG_OFFSET;
   _start = .;
   .text : {
 _stext = .;/* Text and read-only data */
-- 
1.7.10.4


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

[Xen-devel] [PATCH v7 01/14] x86: move xen ELF end of image to 16 MiB

[Daniel Kiper]

It seems that from xen ELF image POV _end symbol properly determine
image end. However, taking into account that initial Xen image mapping
covers 16 MiB it looks that it is not sufficient. Currently bootloader
potentially may load xen ELF image at 1 MiB and let's say put Linux
kernel or initrd at 8 MiB. Nothing forbids it. This means that initially
Xen image mapping may cover not only Xen image but also loaded modules.
So, let's move end of xen ELF image to 16 MiB. This way we avoid above
mentioned issue because bootloader will be forced to allocate 15 MiB
memory region for image. Then it (bootloader) would not be able to put
in this place anything else because from its POV simply this memory
region will be allocated and used.

This patch does not change xen ELF file size. It changes memory size
which should be allocated for the image during load.

Signed-off-by: Daniel Kiper 
---
 xen/arch/x86/xen.lds.S |   10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index d903c31..9adb2f3 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -266,14 +266,16 @@ SECTIONS
   .reloc : {
 *(.reloc)
   } :text
-  /* Trick the linker into setting the image size to exactly 16Mb. */
   . = ALIGN(__section_alignment__);
+#else
+  efi = .;
+#endif
+
+  /* Trick the linker into setting the image size to exactly 16Mb. */
   .pad : {
 . = ALIGN(MB(16));
+__end_of_image__ = .;
   } :text
-#else
-  efi = .;
-#endif
 
   /* Sections to be discarded */
   /DISCARD/ : {
-- 
1.7.10.4


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

[Xen-devel] [PATCH v7 08/14] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

This way Xen can be loaded on EFI platforms using GRUB2 and
other boot loaders which support multiboot2 protocol.

Signed-off-by: Daniel Kiper 
Acked-by: Jan Beulich 
---
v7 - suggestions/fixes:
   - do not allocate twice memory for trampoline if we were
 loaded via multiboot2 protocol on EFI platform,
   - wrap long line
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich).

v6 - suggestions/fixes:
   - improve label names in assembly
 error printing code
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - various minor cleanups and fixes
 (suggested by Jan Beulich).

v4 - suggestions/fixes:
   - remove redundant BSS alignment,
   - update BSS alignment check,
   - use __set_bit() instead of set_bit() if possible
 (suggested by Jan Beulich),
   - call efi_arch_cpu() from efi_multiboot2()
 even if the same work is done later in
 other place right now
 (suggested by Jan Beulich),
   - xen/arch/x86/efi/stub.c:efi_multiboot2()
 fail properly on EFI platforms,
   - do not read data beyond the end of multiboot2
 information in xen/arch/x86/boot/head.S
 (suggested by Jan Beulich),
   - use 32-bit registers in x86_64 code if possible
 (suggested by Jan Beulich),
   - multiboot2 information address is 64-bit
 in x86_64 code, so, treat it is as is
 (suggested by Jan Beulich),
   - use cmovcc if possible,
   - leave only one space between rep and stosq
 (suggested by Jan Beulich),
   - improve error handling,
   - improve early error messages,
 (suggested by Jan Beulich),
   - improve early error messages printing code,
   - improve label names
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - various minor cleanups.

v3 - suggestions/fixes:
   - take into account alignment when skipping multiboot2 fixed part
 (suggested by Konrad Rzeszutek Wilk),
   - improve segment registers initialization
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich and Konrad Rzeszutek Wilk),
   - improve commit message
 (suggested by Jan Beulich).

v2 - suggestions/fixes:
   - generate multiboot2 header using macros
 (suggested by Jan Beulich),
   - switch CPU to x86_32 mode before
 jumping to 32-bit code
 (suggested by Andrew Cooper),
   - reduce code changes to increase patch readability
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - ignore MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO tag on EFI platform
 and find on my own multiboot2.mem_lower value,
   - stop execution if EFI platform is detected
 in legacy BIOS path.
---
 xen/arch/x86/boot/head.S  |  258 ++---
 xen/arch/x86/efi/efi-boot.h   |   49 ++-
 xen/arch/x86/efi/stub.c   |   38 ++
 xen/arch/x86/x86_64/asm-offsets.c |2 +
 xen/arch/x86/xen.lds.S|4 +-
 xen/common/efi/boot.c |   11 ++
 6 files changed, 340 insertions(+), 22 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 383ff79..a371cde 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -89,6 +89,13 @@ multiboot2_header_start:
0, /* Number of the lines - no preference. */ \
0  /* Number of bits per pixel - no preference. */
 
+/* Inhibit bootloader from calling ExitBootServices(). */
+mb2ht_init MB2_HT(EFI_BS), MB2_HT(OPTIONAL)
+
+/* EFI64 entry point. */
+mb2ht_init MB2_HT(ENTRY_ADDRESS_EFI64), MB2_HT(OPTIONAL), \
+   sym_phys(__efi64_start)
+
 /* Multiboot2 header end tag. */
 mb2ht_init MB2_HT(END), MB2_HT(REQUIRED)
 .Lmultiboot2_header_end:
@@ -100,20 +107,49 @@ multiboot2_header_start:
 gdt_boot_descr:
 .word   6*8-1
 .long   sym_phys(trampoline_gdt)
+.long   0 /* Needed for 64-bit lgdt */
+
+cs32_switch_addr:
+.long   sym_phys(cs32_switch)
+.word   BOOT_CS32
+
+.align 4
+vga_text_buffer:
+.long   0xb8000
 
 .Lbad_cpu_msg: .asciz "ERR: Not a 64-bit CPU!"
 .Lbad_ldr_msg: .asciz "ERR: Not a Multiboot bootloader!"
+.Lbad_ldr_nbs: .asciz "ERR: Bootloader shutdown EFI x64 boot services!"
+.Lbad_ldr_nst: .asciz "ERR: EFI SystemTable is not provided by bootloader!"
+.Lbad_ldr_nih: .asciz "ERR: EFI ImageHandle is not provided by bootloader!"
+.Lbad_efi_msg: .asciz "ERR: EFI IA-32 platforms are not supported!"
 
 .section .init.text, "ax", @progbits
 
 bad_cpu:
 mov $(sym_phys(.Lbad_cpu_msg)),%esi # Error message
-jmp print_err
+jmp .Lget_vtb
 not_multiboot:
 mov $(sym_phys(.Lbad_ldr_msg)),%esi # Error message
-print_err:
-mov $0xB8000,%edi  # VGA framebuffer
-1:  mov (%esi),%bl
+jmp .Lget_vtb
+.Lmb2_no_st:
+mov $(sym_phys(.Lbad_ldr_nst)),%esi # Error message

[Xen-devel] [PATCH v7 13/14] x86/boot: rename sym_phys() to sym_offs()

[Daniel Kiper]

This way macro name better describes its function.

There is no functional change.

Suggested-by: Jan Beulich 
Signed-off-by: Daniel Kiper 
---
 xen/arch/x86/boot/head.S   |   40 
 xen/arch/x86/boot/trampoline.S |2 +-
 xen/arch/x86/boot/wakeup.S |4 ++--
 xen/arch/x86/boot/x86_64.S |   18 +-
 4 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 9b1fd0e..76090eb 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -12,9 +12,9 @@
 .text
 .code32
 
-#define sym_phys(sym) ((sym) - __XEN_VIRT_START)
-#define sym_esi(sym)  sym_phys(sym)(%esi)
-#define sym_fs(sym)   %fs:sym_phys(sym)
+#define sym_offs(sym) ((sym) - __XEN_VIRT_START)
+#define sym_esi(sym)  sym_offs(sym)(%esi)
+#define sym_fs(sym)   %fs:sym_offs(sym)
 
 #define BOOT_CS320x0008
 #define BOOT_CS640x0010
@@ -97,7 +97,7 @@ multiboot2_header_start:
 
 /* EFI64 entry point. */
 mb2ht_init MB2_HT(ENTRY_ADDRESS_EFI64), MB2_HT(OPTIONAL), \
-   sym_phys(__efi64_start)
+   sym_offs(__efi64_start)
 
 /* Multiboot2 header end tag. */
 mb2ht_init MB2_HT(END), MB2_HT(REQUIRED)
@@ -110,11 +110,11 @@ multiboot2_header_start:
 gdt_boot_descr:
 .word   7*8-1
 gdt_boot_base:
-.long   sym_phys(trampoline_gdt)
+.long   sym_offs(trampoline_gdt)
 .long   0 /* Needed for 64-bit lgdt */
 
 cs32_switch_addr:
-.long   sym_phys(cs32_switch)
+.long   sym_offs(cs32_switch)
 .word   BOOT_CS32
 
 .align 4
@@ -131,23 +131,23 @@ vga_text_buffer:
 .section .init.text, "ax", @progbits
 
 bad_cpu:
-add $sym_phys(.Lbad_cpu_msg),%esi   # Error message
+add $sym_offs(.Lbad_cpu_msg),%esi   # Error message
 jmp .Lget_vtb
 not_multiboot:
-add $sym_phys(.Lbad_ldr_msg),%esi   # Error message
+add $sym_offs(.Lbad_ldr_msg),%esi   # Error message
 jmp .Lget_vtb
 .Lmb2_no_st:
-add $sym_phys(.Lbad_ldr_nst),%esi   # Error message
+add $sym_offs(.Lbad_ldr_nst),%esi   # Error message
 jmp .Lget_vtb
 .Lmb2_no_ih:
-add $sym_phys(.Lbad_ldr_nih),%esi   # Error message
+add $sym_offs(.Lbad_ldr_nih),%esi   # Error message
 jmp .Lget_vtb
 .Lmb2_no_bs:
-add $sym_phys(.Lbad_ldr_nbs),%esi   # Error message
+add $sym_offs(.Lbad_ldr_nbs),%esi   # Error message
 xor %edi,%edi   # No VGA text buffer
 jmp .Lsend_chr
 .Lmb2_efi_ia_32:
-add $sym_phys(.Lbad_efi_msg),%esi   # Error message
+add $sym_offs(.Lbad_efi_msg),%esi   # Error message
 xor %edi,%edi   # No VGA text buffer
 jmp .Lsend_chr
 .Lget_vtb:
@@ -351,7 +351,7 @@ __start:
 cli
 
 /* Load default Xen image load base address. */
-mov $sym_phys(__image_base__),%esi
+mov $sym_offs(__image_base__),%esi
 
 /* Bootloaders may set multiboot{1,2}.mem_lower to a nonzero value. */
 xor %edx,%edx
@@ -502,8 +502,8 @@ trampoline_setup:
 jnz 1f
 
 /* Initialize BSS (no nasty surprises!). */
-mov $sym_phys(__bss_start),%edi
-mov $sym_phys(__bss_end),%ecx
+mov $sym_offs(__bss_start),%edi
+mov $sym_offs(__bss_end),%ecx
 push%fs
 pop %es
 sub %edi,%ecx
@@ -577,22 +577,22 @@ trampoline_setup:
 
 /* Apply relocations to bootstrap trampoline. */
 mov sym_fs(trampoline_phys),%edx
-mov $sym_phys(__trampoline_rel_start),%edi
+mov $sym_offs(__trampoline_rel_start),%edi
 1:
 mov %fs:(%edi),%eax
 add %edx,%fs:(%edi,%eax)
 add $4,%edi
-cmp $sym_phys(__trampoline_rel_stop),%edi
+cmp $sym_offs(__trampoline_rel_stop),%edi
 jb  1b
 
 /* Patch in the trampoline segment. */
 shr $4,%edx
-mov $sym_phys(__trampoline_seg_start),%edi
+mov $sym_offs(__trampoline_seg_start),%edi
 1:
 mov %fs:(%edi),%eax
 mov %dx,%fs:(%edi,%eax)
 add $4,%edi
-cmp $sym_phys(__trampoline_seg_stop),%edi
+cmp $sym_offs(__trampoline_seg_stop),%edi
 jb  1b
 
 /* Do not parse command line on EFI platform here. */
@@ -618,7 +618,7 @@ trampoline_setup:
 push%eax
 
 /* Copy bootstrap trampoline to low memory, below 1MB. */
-mov $sym_phys(trampoline_start),%esi
+mov $sym_offs(trampoline_start),%esi
 mov $((trampoline_end - trampoline_start) / 4),%ecx
 rep movsl %fs:(%esi),%es:(%edi)
 
diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/

[Xen-devel] [PATCH v7 05/14] x86: allow EFI reboot method neither on EFI platforms...

[Daniel Kiper]

..nor EFI platforms with runtime services enabled.

Suggested-by: Jan Beulich 
Signed-off-by: Daniel Kiper 
Acked-by: Jan Beulich 
---
v6 - suggestions/fixes:
   - move this commit behind "efi: create efi_enabled()" commit
 (suggested by Jan Beulich).

v5 - suggestions/fixes:
   - fix build error
 (suggested by Jan Beulich),
   - improve commit message.
---
 xen/arch/x86/shutdown.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/x86/shutdown.c b/xen/arch/x86/shutdown.c
index 54c2c79..b429fd0 100644
--- a/xen/arch/x86/shutdown.c
+++ b/xen/arch/x86/shutdown.c
@@ -80,6 +80,9 @@ static void __init set_reboot_type(char *str)
 break;
 str++;
 }
+
+if ( reboot_type == BOOT_EFI && !efi_enabled(EFI_RS) )
+reboot_type = BOOT_INVALID;
 }
 custom_param("reboot", set_reboot_type);
 
-- 
1.7.10.4


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

[Xen-devel] [PATCH v7 04/14] efi: create efi_enabled()

[Daniel Kiper]

First of all we need to differentiate between legacy BIOS
and EFI platforms during runtime, not during build, because
one image will have legacy and EFI code and can be executed
on both platforms. Additionally, we need more fine grained
knowledge about EFI environment and check for EFI platform
and EFI loader separately to properly support multiboot2
protocol. In general Xen loaded by this protocol uses memory
mappings and loaded modules in similar way to Xen loaded by
multiboot (v1) protocol. Hence, create efi_enabled() which
checks available features in efi_flags. This patch defines
EFI_BOOT, EFI_LOADER and EFI_RS features. EFI_BOOT is equal
to old efi_enabled == 1. EFI_RS ease control on runtime
services usage. EFI_LOADER tells that Xen was loaded
directly from EFI as PE executable.

Suggested-by: Jan Beulich 
Signed-off-by: Daniel Kiper 
Reviewed-by: Jan Beulich 
---
v7 - suggestions/fixes:
   - remove efi_enabled(EFI_RS) check from mapcache_current_vcpu()
 (suggested by Daniel Kiper and Jan Beulich),
   - remove BUG() from xen/arch/x86/efi/stub.c:efi_rs_using_pgtables()
 (suggested by Daniel Kiper and Jan Beulich).

v6 - suggestions/fixes:
   - define efi_enabled() as "bool efi_enabled(unsigned int feature)"
 instead of "bool_t efi_enabled(int feature)"
 (suggested by Jan Beulich),
   - define efi_flags as unsigned int
 (suggested by Jan Beulich),
   - various minor cleanups and fixes
 (suggested by Jan Beulich).

v5 - suggestions/fixes:
   - squash three patches into one
 (suggested by Jan Beulich),
   - introduce all features at once
 (suggested by Jan Beulich),
   - efi_enabled() returns bool_t
 instead of unsigned int
 (suggested by Jan Beulich),
   - update commit message.

v4 - suggestions/fixes:
   - rename EFI_PLATFORM to EFI_BOOT
 (suggested by Jan Beulich),
   - move EFI_BOOT definition to efi struct definition
 (suggested by Jan Beulich),
   - remove unneeded efi.flags initialization
 (suggested by Jan Beulich),
   - use __set_bit() instead of set_bit() if possible
 (suggested by Jan Beulich),
   - do efi_enabled() cleanup
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - improve commit message.

v3 - suggestions/fixes:
   - define efi struct in xen/arch/x86/efi/stub.c
 in earlier patch
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - improve commit message
 (suggested by Jan Beulich).
---
 xen/arch/x86/dmi_scan.c|4 ++--
 xen/arch/x86/domain_page.c |2 +-
 xen/arch/x86/efi/stub.c|8 
 xen/arch/x86/mpparse.c |4 ++--
 xen/arch/x86/setup.c   |   12 +++-
 xen/arch/x86/shutdown.c|2 +-
 xen/arch/x86/time.c|2 +-
 xen/common/efi/boot.c  |   19 +++
 xen/common/efi/runtime.c   |   14 --
 xen/common/version.c   |2 +-
 xen/drivers/acpi/osl.c |2 +-
 xen/include/xen/efi.h  |8 ++--
 12 files changed, 49 insertions(+), 30 deletions(-)

diff --git a/xen/arch/x86/dmi_scan.c b/xen/arch/x86/dmi_scan.c
index b049e31..8dcb640 100644
--- a/xen/arch/x86/dmi_scan.c
+++ b/xen/arch/x86/dmi_scan.c
@@ -238,7 +238,7 @@ const char *__init dmi_get_table(paddr_t *base, u32 *len)
 {
static unsigned int __initdata instance;
 
-   if (efi_enabled) {
+   if (efi_enabled(EFI_BOOT)) {
if (efi_smbios3_size && !(instance & 1)) {
*base = efi_smbios3_address;
*len = efi_smbios3_size;
@@ -696,7 +696,7 @@ static void __init dmi_decode(struct dmi_header *dm)
 
 void __init dmi_scan_machine(void)
 {
-   if ((!efi_enabled ? dmi_iterate(dmi_decode) :
+   if ((!efi_enabled(EFI_BOOT) ? dmi_iterate(dmi_decode) :
dmi_efi_iterate(dmi_decode)) == 0)
dmi_check_system(dmi_blacklist);
else
diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
index d86f8fe..a58ef8e 100644
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -36,7 +36,7 @@ static inline struct vcpu *mapcache_current_vcpu(void)
  * domain's page tables but current may point at another domain's VCPU.
  * Return NULL as though current is not properly set up yet.
  */
-if ( efi_enabled && efi_rs_using_pgtables() )
+if ( efi_rs_using_pgtables() )
 return NULL;
 
 /*
diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub.c
index 07c2bd0..4158124 100644
--- a/xen/arch/x86/efi/stub.c
+++ b/xen/arch/x86/efi/stub.c
@@ -4,9 +4,10 @@
 #include 
 #include 
 
-#ifndef efi_enabled
-const bool_t efi_enabled = 0;
-#endif
+bool efi_enabled(unsigned int feature)
+{
+return false;
+}
 
 void __init efi_init_memory(void) { }
 
@@ -14,7 +15,6 @@ void efi_update_l4_pgtable(unsigned int l4idx, l4_pgentry_t 
l4e) { }
 
 bool_t efi_rs_using_pgtables(void)
 {
-BUG();
 return 0;
 }
 
diff --git a/xen/arch/x86/mpparse.c b

Re: [Xen-devel] PCI passthrough with stubdomain

[Marek Marczykowski-Górecki]

On Fri, Sep 23, 2016 at 11:00:42PM +0200, Samuel Thibault wrote:
> Marek Marczykowski-Górecki, on Fri 23 Sep 2016 20:56:43 +0200, wrote:
> > 1. How to do this? ;) I.e. what synchronization primitives are available
> > in mini-os? Just pthread_mutex_lock/unlock?
> 
> pthread_mutex_lock are nops :o) because we don't have pthread_create.
> But for mini-os itself there are synchronization primitives, yes:
> there are also semaphores (./include/semaphore.h) and waitqueues
> (include/wait.h).

Ok, will take a look at this. Thanks.

> > 2. Wouldn't the same problem be with other stubdomain implementations?
> > Like Linux + qemu-xen or rumprun + qemu-xen? At least in Linux case
> > pcifront driver will also needs some time for initialization...
> 
> Possibly, I don't know about them, they didn't exist at the time ;)

Actually they don't exist even now ;) But hopefully will, in the near
future...

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


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

Re: [Xen-devel] PCI passthrough with stubdomain

[Samuel Thibault]

Marek Marczykowski-Górecki, on Fri 23 Sep 2016 20:56:43 +0200, wrote:
> 1. How to do this? ;) I.e. what synchronization primitives are available
> in mini-os? Just pthread_mutex_lock/unlock?

pthread_mutex_lock are nops :o) because we don't have pthread_create.
But for mini-os itself there are synchronization primitives, yes:
there are also semaphores (./include/semaphore.h) and waitqueues
(include/wait.h).

> 2. Wouldn't the same problem be with other stubdomain implementations?
> Like Linux + qemu-xen or rumprun + qemu-xen? At least in Linux case
> pcifront driver will also needs some time for initialization...

Possibly, I don't know about them, they didn't exist at the time ;)

Samuel

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

Re: [Xen-devel] Question about VPID during MOV-TO-CR3

[Tamas K Lengyel]

On Fri, Sep 23, 2016 at 9:50 AM, Tamas K Lengyel
 wrote:
> On Fri, Sep 23, 2016 at 9:39 AM, Jan Beulich  wrote:
> On 23.09.16 at 17:26,  wrote:
>>> On Fri, Sep 23, 2016 at 2:24 AM, Jan Beulich  wrote:
>>> On 22.09.16 at 19:18,  wrote:
> So I verified that when CPU-based load exiting is enabled, the TLB
> flush here is critical. Without it the guest kernel crashes at random
> points during boot. OTOH why does Xen trap every guest CR3 update
> unconditionally? While we have features such as the vm_event/monitor
> that may choose to subscribe to that event, Xen traps it even when
> that is not in use. Is that trapping necessary for something else?

 Where do you see this being unconditional? construct_vmcs()
 clearly avoids setting these intercepts when using EPT. Are you
 perhaps suffering from

 /* Trap CR3 updates if CR3 memory events are enabled. */
 if ( v->domain->arch.monitor.write_ctrlreg_enabled &
  monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3) )
 v->arch.hvm_vmx.exec_control |= CPU_BASED_CR3_LOAD_EXITING;

 in vmx_update_guest_cr()? That'll be rather something for you
 or Razvan to explain. Outside of nested VMX I don't see any
 other enabling of that intercept (didn't check AMD code on the
 assumption that you're working on Intel hardware).
>>>
>>> So there seems to be two separate paths that lead to the TLB flushing.
>>> One is indeed the above case you cited when we enable CR3 monitoring
>>> through the monitor interface. However, during domain boot I also see
>>> this path being called that is not related to the
>>> CPU_BASED_CR3_LOAD_EXITING:
>>>
>>> (XEN) hap.c:739:d1v0 hap_update_paging_modes is calling hap_update_cr3
>>> (XEN) hap.c:701:d1v0 HAP update cr3 called
>>> (XEN) /src/xen/xen/include/asm/hvm/hvm.h:344:d1v0 HVM update guest cr3 
>>> called
>>> (XEN) vmx.c:1549:d1v0 Update guest CR3 value=0x7a7c4000
>>>
>>> This path seems to de-activate once the domain is fully booted.
>>
>> This late? According to the CR0 handling in
>> vmx_update_guest_cr() I would understand it to be enabled only
>> while the guest is still in real mode (and even then only on old
>> hardware, i.e. without the Unrestricted Guest functionality).
>>
>
> Right, with unrestricted guest support I would assume none of this
> would get called - but it does, and quite frequently during domain
> boot. The CPU is a Intel(R) Xeon(R) CPU E5-2430.
>

So I experimented with selectively disabling the flushing such that
it's done only when coming from a path other then CPU-based CR3 load
exiting. I've added a bool to struct vcpu that gets set to 0 every
time vmx_vmexit_handler is called, and only gets set to 1 when
vmx_cr_access reports a MOV-TO-CR3. Then in the vmx_update_guest_cr
the flush only happens as such:

if ( !v->movtocr3 )
hvm_asid_flush_vcpu(v);

In the guest I run a test application that allocates a page at a fixed
VA, writes a magic value to it, and then keeps spinning on reading the
magic value back from the page, checking if it's the same as
originally supplied. I lunch this application twice with different
magic values, so that if the TLB invalidation is an issue one of the
test applications would read back the wrong magic value from the VA
using a stale TLB entry. I've verified that same VA in the two
applications point to different pages and that those PTEs are not
marked global and no PCID is used.

[  724] test (struct addr:88003730f330). PGD: 0x3731f000
VADDR 0x500 -> PADDR 0x73e35000. Global page: 0
[  727] test (struct addr:88003681ea20). PGD: 0x777a6000
VADDR 0x500 -> PADDR 0x75043000. Global page: 0

Both applications work as expected without the VPID flushing taking
place. So at least for CPU-based CR3 load exiting it seems that this
flush is not necessary. As for why this path gets called during domain
boot when the CPU supports Unrestricted Guest mode and it is properly
detecting when Xen boots, I'm not sure. However, as we use CPU-based
CR3 load exiting quite often when doing VMI, I would prefer to disable
this flushing at least for this case. Any thoughts?

Tamas

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

[Xen-devel] [xen-unstable baseline-only test] 67752: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67752 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67752/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail like 
67740
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install 
fail like 67740
 test-amd64-amd64-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail like 67740
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 67740
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 67740
 test-amd64-i386-xl-qemut-debianhvm-amd64  9 debian-hvm-install fail like 67740
 test-amd64-i386-qemut-rhel6hvm-intel  9 redhat-install fail like 67740
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67740
 test-amd64-amd64-amd64-pvgrub 10 guest-start  fail  like 67740
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail like 
67740
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  9 windows-installfail like 67740
 test-amd64-i386-xl-qemut-winxpsp3  9 windows-install   fail like 67740
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
like 67740

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-i386-rumprun5 rumprun-buildfail   never pass
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 xen  b106f15efbfc99f52ccb94ab8ca7fdb21fcf
baseline version:
 xen  a9c9600bb5b2f79058ce24f0ef51f22c78e89ba1

Last test of basis67740  2016-09-21 20:17:38 Z2 days
Testing same since67752  2016-09-23 08:14:24 Z0 days1 attempts


People who touched revisions under test:
  Dario Faggioli 
  George Dunlap 
  Jan Beulich 
  Julien Grall 
  Konrad R

[Xen-devel] [PATCH v6] acpi: Prevent GPL-only code from seeping into non-GPL binaries

[Boris Ostrovsky]

Some code (specifically, introduced by commit 801d469ad ("[HVM] ACPI
support patch 3 of 4: ACPI _PRT table.")) has only been licensed under
GPLv2. We want to prevent this code from showing up in non-GPL
binaries which might become possible after we make ACPI builder code
available to users other than hvmloader.

There are two pieces that we need to be careful about:
(1) A small chunk of code in dsdt.asl that implements _PIC method
(2) A chunk of ASL generator in mk_dsdt.c that describes with PCI
interrupt routing.

This code will now be generated by a GPL-only script which will be
invoked only when ACPI builder's Makefile is called with GPL variable
set.

We also strip license header from generated ASL files to prevent
inadverent use of those files with incorrect license.

Signed-off-by: Boris Ostrovsky 
---
Changes in v6:
* Replaced script's printf in most case with "here document" (for multi-line
  text) or echo for single line. Left printf for formatted output.
  (Note that in one case paramter expansion is necessary and so
   delimiter word is intentionally not quoted).
* Replaced bash arrays with ${string:index:size} syntax.
* Style adjustments as requested by Jan.

I am sending only this patch from series. A couple of patches are affected
by changes here. I will re-send the whole series if needed.

 tools/firmware/hvmloader/Makefile|   3 +
 tools/firmware/hvmloader/acpi/Makefile   |  14 ++-
 tools/firmware/hvmloader/acpi/dsdt.asl   |  14 ---
 tools/firmware/hvmloader/acpi/gpl/mk_dsdt_gpl.sh | 116 +++
 tools/firmware/hvmloader/acpi/mk_dsdt.c  |  68 +
 5 files changed, 131 insertions(+), 84 deletions(-)
 create mode 100755 tools/firmware/hvmloader/acpi/gpl/mk_dsdt_gpl.sh

diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index 9f7357f..a1844d0 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -65,6 +65,9 @@ ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
 ROMS += $(ROMBIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) $(ETHERBOOT_ROMS)
 endif
 
+# Certain parts of ACPI builder are GPL-only
+export GPL := y
+
 .PHONY: all
 all: subdirs-all
$(MAKE) hvmloader
diff --git a/tools/firmware/hvmloader/acpi/Makefile 
b/tools/firmware/hvmloader/acpi/Makefile
index f63e734..c23626d 100644
--- a/tools/firmware/hvmloader/acpi/Makefile
+++ b/tools/firmware/hvmloader/acpi/Makefile
@@ -17,7 +17,8 @@
 XEN_ROOT = $(CURDIR)/../../../..
 include $(XEN_ROOT)/tools/firmware/Rules.mk
 
-C_SRC = build.c dsdt_anycpu.c dsdt_15cpu.c static_tables.c 
dsdt_anycpu_qemu_xen.c
+C_SRC-$(GPL) = build.c dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
+C_SRC = build.c static_tables.c $(C_SRC-y)
 OBJS  = $(patsubst %.c,%.o,$(C_SRC))
 
 CFLAGS += $(CFLAGS_xeninclude)
@@ -36,18 +37,25 @@ ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
 mk_dsdt: mk_dsdt.c
$(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
 
-dsdt_anycpu_qemu_xen.asl: dsdt.asl dsdt_acpi_info.asl mk_dsdt
+ifeq ($(GPL),y)
+dsdt_anycpu_qemu_xen.asl: dsdt.asl dsdt_acpi_info.asl gpl/mk_dsdt_gpl.sh 
mk_dsdt
awk 'NR > 1 {print s} {s=$$0}' $< > $@.$(TMP_SUFFIX)
+   # Strip license comment
+   sed -i '1,/\*\//{/\/\*/,/\*\//d}' $@.$(TMP_SUFFIX)
+   $(SHELL) gpl/mk_dsdt_gpl.sh >> $@.$(TMP_SUFFIX)
cat dsdt_acpi_info.asl >> $@.$(TMP_SUFFIX)
./mk_dsdt --debug=$(debug) --dm-version qemu-xen >> $@.$(TMP_SUFFIX)
mv -f $@.$(TMP_SUFFIX) $@
 
 # NB. awk invocation is a portable alternative to 'head -n -1'
-dsdt_%cpu.asl: dsdt.asl dsdt_acpi_info.asl mk_dsdt
+dsdt_%cpu.asl: dsdt.asl dsdt_acpi_info.asl gpl/mk_dsdt_gpl.sh mk_dsdt
awk 'NR > 1 {print s} {s=$$0}' $< > $@.$(TMP_SUFFIX)
+   sed -i '1,/\*\//{/\/\*/,/\*\//d}' $@.$(TMP_SUFFIX)
+   $(SHELL) gpl/mk_dsdt_gpl.sh >> $@.$(TMP_SUFFIX)
cat dsdt_acpi_info.asl >> $@.$(TMP_SUFFIX)
./mk_dsdt --debug=$(debug) --maxcpu $*  >> $@.$(TMP_SUFFIX)
mv -f $@.$(TMP_SUFFIX) $@
+endif
 
 $(filter dsdt_%.c,$(C_SRC)): %.c: iasl %.asl
iasl -vs -p $* -tc $*.asl
diff --git a/tools/firmware/hvmloader/acpi/dsdt.asl 
b/tools/firmware/hvmloader/acpi/dsdt.asl
index 4f6db79..13811cf 100644
--- a/tools/firmware/hvmloader/acpi/dsdt.asl
+++ b/tools/firmware/hvmloader/acpi/dsdt.asl
@@ -26,20 +26,6 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, "Xen", "HVM", 0)
 Name (\APCL, 0x0001)
 Name (\PUID, 0x00)
 
-/* _S3 and _S4 are in separate SSDTs */
-Name (\_S5, Package (0x04)
-{
-0x00,  /* PM1a_CNT.SLP_TYP */
-0x00,  /* PM1b_CNT.SLP_TYP */
-0x00,  /* reserved */
-0x00   /* reserved */
-})
-
-Name(PICD, 0)
-Method(_PIC, 1)
-{
-Store(Arg0, PICD) 
-}
 
 Scope (\_SB)
 {
diff --git a/tools/firmware/hvmloader/acpi/gpl/mk_dsdt_gpl.sh 
b/tools/firmware/hvmloader/acpi/gpl/mk_dsdt_gpl.sh
new file mode 100755
index 000..28a0dd7
--- /dev/nu

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf ea317c0658b013659e064ba0323d1da8294acf4e
baseline version:
 ovmf 8b4ca351dded404f992504c45e358572c4d236f9

Last test of basis   101124  2016-09-23 13:46:33 Z0 days
Testing same since   101127  2016-09-23 17:45:24 Z0 days1 attempts


People who touched revisions under test:
  Tapan Shah 

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 :

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeatfail  like 101110
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101119
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101119
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101119

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass

version targeted for testing:
 qemuue678c56f169bb576b607cda2a39c0b626ebfb221
baseline version:
 qemuu430da7a81d356e368ccd88dcca60f38da9aa5b9a

Last test of basis   101119  2016-09-23 04:04:03 Z0 days
Testing same since   101123  2016-09-23 11:18:37 Z0 days1 attempts


People who touched revisions under test:
  Alistair Francis 
  Andrey Yurovsky 
  Cédric Le Goater 
  Dmitry Osipenko 
  Dr. David Alan Gilbert 
  Nathan Rossi 
  Peter Maydell 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   p

[Xen-devel] [ovmf baseline-only test] 67755: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67755 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67755/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 8b4ca351dded404f992504c45e358572c4d236f9
baseline version:
 ovmf fe882c01122e7e01e0e78ca8da64630faf9a7b5a

Last test of basis67754  2016-09-23 13:48:50 Z0 days
Testing same since67755  2016-09-23 16:18:41 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  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.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

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

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


Push not applicable.


commit 8b4ca351dded404f992504c45e358572c4d236f9
Author: Ard Biesheuvel 
Date:   Thu Sep 22 09:52:00 2016 +0100

MdePkg/BaseMemoryLibOptDxe ARM AARCH64: fix thinko in SetMem##

The new InternalMemSetMem##() implementations for ARM and AARCH64 in
BaseMemoryLibOptDxe fail to take into account that the 'length' argument
is not in bytes, but in number of items to be copied. So multiply by the
item size before proceeding.

Reported-by: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Liming Gao 
Tested-by: Laszlo Ersek 

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

Re: [Xen-devel] PCI passthrough with stubdomain

[Marek Marczykowski-Górecki]

On Fri, Sep 23, 2016 at 04:51:33PM +0200, Samuel Thibault wrote:
> Marek Marczykowski-Górecki, on Fri 23 Sep 2016 16:25:41 +0200, wrote:
> > Toolstack during (stub)domain startup setup two things, mostly
> > asynchronously:
> > 1. pciback/pcifront (through standard xenstore entries)
> > 2. instruct qemu to attach device (by writing "pci-ins" to
> > device-model/xxx/command)
> 
> Ah, since pcifront_watches runs in a separate thread, it may not have
> called init_pcifront before qemu calls libpci, i.e. pcifront_scan.

Yes, exactly.

> I'd say that's where the fix should be: make pcifront_scan wait for
> init_pcifront to be done.  It's however not so simple: we want to make
> pcifront_scan do nothing if no pciback is to be launched. My memory is
> rusty: is there something we are sure will show up in the xenstore when
> a pciback is to be launched?  If so, pcifront_scan could do this: wait
> for pcifront_watches to have checked for the potential presence of
> pciback. If pciback is not to be started, just do nothing; if pciback is
> to be started, wait for init_pcifront to have been called by
> pcifront_watches. Then it will find the devices.

Ok. So, two questions:
1. How to do this? ;) I.e. what synchronization primitives are available
in mini-os? Just pthread_mutex_lock/unlock?

2. Wouldn't the same problem be with other stubdomain implementations?
Like Linux + qemu-xen or rumprun + qemu-xen? At least in Linux case
pcifront driver will also needs some time for initialization...

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


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

[Xen-devel] [PATCH v3 2/4] Added document containing governance related todo list

[Lars Kurth]

Contains items that at some point need to be addressed.
The items do not directly affect governance.pandoc

Signed-off-by: Lars Kurth 
---
 governance.todo | 23 +++
 1 file changed, 23 insertions(+)
 create mode 100644 governance.todo

diff --git a/governance.todo b/governance.todo
new file mode 100644
index 000..81e068c
--- /dev/null
+++ b/governance.todo
@@ -0,0 +1,23 @@
+This document contains some governance related TODO items that at some point 
+need to be addressed. The items do not directly affect governance.pandoc
+
+### Maintainers
+
+CONSISTENCY ISSUES that probably ought to be cleaned up at some point
+- The xen.git MAINTAINERS file does not list our release managers and 
+  stable branch maintainers
+- We do have a number of repos without MAINTAINERS files, e.g. mini-os.git, 
+  osstest.git
+- For projects with many repositories (e.g. XAPI and Mirage OS), using 
MAINTAINERS 
+  files is not very practical. XAPI seems to sometimes use MAINTAINERS and 
README 
+  files at other times. We may need a more central place to state roles.
+
+### Project Leadership Team and Project Lead
+
+CONSISTENCY ISSUES that probably ought to be cleaned up at some point
+- XAPI and Mirage OS ought to decide who their leadership team is 
+  (I made some assumptions for now)
+
+### Per Sub-Project Governance Specialisation 
+
+- XAPI, WinPV and MirageOS need to provide this information, if they deviate
\ No newline at end of file
-- 
2.5.4 (Apple Git-61)


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

[Xen-devel] [PATCH v3 0/4] Significant changes to Xen Project Governance (governance.html)

[Lars Kurth]

I made some significant proposed changes to governance.html based on a number 
of issues that were raised in a number of surveys last year, and via other 
means, as well as in the recent discussions related to governance.html changes 
(the issue of too many committers in XAPI and XAPI being able to hijack the 
entire project).

In any case, the changes are expressed in 4 patches governance.pandoc,
which is the pandoc source for governance.html:

- Code motion changes to make real patches easier to read
  No content has been changed
  An index was added
  Fixed some minor typos and formatting issues

- Added document containing governance related todo list
  These do not affect this series and are basically a TODO list for myself

- Significant changes to decision making; some new roles; minor changes
  Introduces governance changes
  Adds some new roles
  Minor formatting changes, such as missing anchors, wrong 
  Deletes addressed open issues in comments 
  Add additional comments to raise questions or provide background info

  Note that the proposal so far seems to have broad agreement
  
- Addressed comments on quorum and security team members
  In particular this addresses
  
  https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg02160.html
  
  which exhibits a monotonicity failure due to the way how the quorum
  was expressed. An example of this failure can be found in 
  
  https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg02168.html
  
  Expressing the quorum in terms of "1/3 of +1 votes" instead of a quorum of 
  "50% of +1 or -1 votes" avoids the monotonicity failure without affecting 
  the voting arithmetic otherwise. The reason for this is 2/6 of +1 votes and
  1/6 of -1 votes equate to 50%. I am sure, Ian Jackson can expand if people 
  care. 

The patch series is based on git://xenbits.xen.org/people/larsk/governance.git

You can see the changes in my personal git repo at 
http://xenbits.xen.org/gitweb/
?p=people/larsk/governance.git;a=shortlog;h=refs/heads/2016-overhaul-v3b

Open Issues to be fixed (but these don't need to be reviewed)
- Fix up tables as these don't render properly as html
  Also see http://rapporter.github.io/pander/pandoc_table.html
  
---
Changes since v1
- Agreed and changed counting schemes for lazy consensus/votinh
- Added Community Decisions with Funding and Legal Implications
- Clarified AB role in last resort cases
- Removed comments where superceded by decisions we already made
- Adapted sections with dependencies

Changes since v2
- Fixed minor typographic issues
- Removed comments from the series, as these are distracting
  and make the document harder to review
- Broke out remaining comments that need addressing at some
  point into governance.todo
- Added an extra patch regarding quorum and security team
  members

-- 
2.5.4 (Apple Git-61)


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

[Xen-devel] [PATCH v3 3/4] Significant changes to decision making; some new roles and minor changes

[Lars Kurth]

Added RTC Policy
Added +2 ... -2 scheme for votes
Clarified lazy consensus (tallying and lazy voting)
Added Informal Votes/Surveys
Added Project Team Leadership role and Decision making
Added Community Decisions with Funding and Legal Implications
Changed Project Wide Decision making: per project based scheme
Clarified scope of Decision making

Modified sections which have dependencies on changes about
Fixed various typos

Signed-off-by: Lars Kurth 
---
 governance.pandoc | 606 ++
 1 file changed, 474 insertions(+), 132 deletions(-)

diff --git a/governance.pandoc b/governance.pandoc
index 2ce780c..051317b 100644
--- a/governance.pandoc
+++ b/governance.pandoc
@@ -1,5 +1,5 @@
 This document has come in effect in June 2011 and will be reviewed 
periodically 
-(see revision sections). The last modification has been made in July 2016.
+(see revision sections). The last modification has been made in September 2016.
 
 Content
 ---
@@ -11,8 +11,10 @@ Content
 -   [Making Contributions](#contributions)
 -   [Decision Making, Conflict Resolution, Role Nominations and 
 Elections](#decisions)
--   [Formal Votes](#formal-votes)
+-   [Project Wide Decision Making](#project-decisions)
+-   [Community Decisions with Funding and Legal 
Implications](#funding-and-legal)
 -   [Project Governance](#project-governance)
+-   [Per Sub-Project Governance Specialisations](#specialisations)
 
 Goals {#goals}
 -
@@ -54,7 +56,12 @@ The Xen Project is a meritocracy. The more you contribute 
the more
 responsibility you will earn. Leadership roles in Xen are also merit-based and 
 earned by peer acclaim.
 
-Xen Project Wide Roles {#roles-global}
+### Local Decision Making
+
+The Xen Project consists of a number of sub-projects: each sub-project makes 
+technical and other decisions that solely affect it locally.
+
+Xen Project Wide Roles {#roles-global} 
 --
 
 ### Sub-projects and Teams
@@ -64,9 +71,22 @@ the [Project Governance](#project-governance) (or Project 
Lifecycle) as
 outlined in this document. Sub-projects (sometimes simply referred to as 
 projects) are run by individuals and are often referred to as teams to 
 highlight the collaborative nature of development. For example, each 
-sub-project has a [team portal](/developers/teams.html) on Xenproject.org.
+sub-project has a [team portal](/developers/teams.html) on Xenproject.org. 
+Sub-projects own and are responsible for a collection of source repositories 
+and other resources (e.g. test infrastructure, CI infrastructure, ...), which 
+we call **sub-project assets** (or team assets) in this document.
+
+Sub-projects can either be **incubation projects** or **mature projects** as 
+outlined in [Basic Project Life Cycle](#project-governance). In line with the 
+meritocratic principle, mature projects have more influence than incubation 
+projects, on [project wide decisions](#project-decisions).
+
+### Community Manager
 
-### Xen Project Advisory Board
+The Xen Project has a community manager, whose primary role it is to support 
+the entire Xen Project Community.
+
+### Xen Project Advisory Board {#roles-ab}
 
 The [Xen Project Advisory Board](/join.html) consists of members who are 
 committed to steering the project to advance its market and technical success, 
@@ -76,7 +96,7 @@ shared project infrastructure, marketing and events, and 
managing the Xen
 Project trademark. The Advisory Board leaves all technical decisions to the 
 open source meritocracy.
 
-### The Linux Foundation
+### The Linux Foundation {#roles-lf}
 
 The Xen Project is a [Linux Foundation](/linux-foundation.html) Collaborative 
 Project. Collaborative Projects are independently funded software projects 
that 
@@ -95,21 +115,48 @@ members or other distinguished community members.
 ### Sponsor
 
 To form a new sub-project or team on Xenproject.org, we require a sponsor to 
-support the creation of the new project. A sponsor can be a project lead or 
-committer of a mature project, a member of the advisory board or the community 
-manager. This ensures that a distinguished community member supports the idea 
-behind the project.
+support the creation of the new project. A sponsor can be a member of the 
+project leadership team of a mature project, a member of the advisory board or 
+the community manager. This ensures that a distinguished community member 
+supports the idea behind the project.
 
 Project Team Roles {#roles-local}
 --
 
+Sub-projects or teams are driven by the people who volunteer for the job. This 
+functions well for most cases. This section lists the main roles which 
projects 
+use. This section lists the default roles, which are based on how the 
+Hypervisor project operates. Sub-projects can deviate from the default, but 
are 
+required to document deviations from the default and link to it from this 
+[document](#specialisations). The only exception is that each project is 
+req

[Xen-devel] [PATCH v3 4/4] Addressed comments on quorum and security team members

[Lars Kurth]

Main changes
Leadership team decisions: express quorum in terms of +1 votes
Security Team Members: election
Project Wide Decision Making: minor text changes

Signed-off-by: Lars Kurth 
---
 governance.pandoc | 45 ++---
 1 file changed, 30 insertions(+), 15 deletions(-)

diff --git a/governance.pandoc b/governance.pandoc
index 051317b..b1c5d87 100644
--- a/governance.pandoc
+++ b/governance.pandoc
@@ -410,18 +410,26 @@ resolution. There is no differentiation between **+1**/ 
**+2** and
 **-1**/**-2**: in other words a **+2** is counted as a vote for, a **-2** as a 
 vote against the resolution. The number of votes for and against a resolution 
 is called **active vote**. **0** votes **are not counted** as an active vote.
--   A **quorum of more than 50% of active votes** is required for a resolution 
-to pass. In other words, if the leadership team has 7 members, at least 4 
-active votes are required for a resolution to pass.
+-   A **quorum of at least 1/3 of +1 votes for a proposal** is required for a 
+resolution to pass. In other words, if the leadership team has 7 members, at 
+least 3 members need to vote for the resolution. 
 -   The resolution passes, if a 2/3 majority of active votes is in favour of 
 it. 
 
+The table below maps the number of leadership team members against the 
+required quorum:
+
+  --- --- -- -- -- -- -- -- -- --
+  **Leadership team members**  10  9  8  7  6  5  4  3  2
+  **+1 votes needed for quorum**4  3  3  3  2  2  2  1  1  
+  --- --- -- -- -- -- -- -- -- --
+
 The table below maps active votes against votes needed to pass:
 
-   --- -- -- -- -- -- -- -- --
-  **Active Votes**  10  9  8  7  6  5  4  3  2
-  **+1 votes needed to pass**7  6  6  5  4  4  3  2  2
-   --- -- -- -- -- -- -- -- --
+  --- --- -- -- -- -- -- -- -- --
+  **Active Votes (+1 or -1)**  10  9  8  7  6  5  4  3  2
+  **+1 votes needed to pass**   7  6  6  5  4  4  3  2  2
+  --- --- -- -- -- -- -- -- -- --
 
 ### Conflict Resolution {#conflict}
 
@@ -463,11 +471,11 @@ new maintainer. Discussion should happen on the mailing 
list using the normal
 decision making process. If there is disagreement or doubt, the decision is 
 handled by the project leadership.
 
- Committer, Security Team Member and other Project Leadership Elections
+ Committer and other Project Leadership Elections
 
 Developers who have earned the trust of committers in their project can 
through 
-election be promoted to Committer, Security Team Member or Project Leadership 
-(if not covered otherwise). A two stage mechanism is used
+election be promoted to Committer or Project Leadership (if not covered 
otherwise). 
+A two stage mechanism is used
 
 -   Nomination: Community members should nominate candidates by posting a 
 proposal to *appointments at xenproject dot org* explaining the candidate's 
@@ -479,7 +487,14 @@ nomination and publish suitable nominations on the 
project's public mailing
 list for wider community input.
 -   Election: A committer will be elected using the decision making process 
 outlined earlier. In other words, the decision is delegated to the [project 
-leadership team](#leadership).
+leadership team](#leadership). 
+
+ Security Team Members 
+
+Developers who have earned the trust of other security team members can 
+be promoted to be on the security team. Due to the specific needs of the 
+security team, promotions are typically made by the security team itself
+and confirmed by lazy consensus within the team.
 
  Project Lead Elections
 
@@ -553,10 +568,10 @@ as outlined below.
 -   Project leadership team members vote for or against a proposal (there is 
no 
 differentiation between **-1**/**-2** and **+1**/**+2**). A **0** vote is not 
 counted as a valid vote.
--   A **quorum of more than 50%** of each project's leadership team members is 
-required. In other words: if more than half of a project's leadership team 
+-   A **quorum of at least 50%** of each project's leadership team members is 
+required. In other words: if fewer than half of a project's leadership team 
 members do not vote or abstain, the entire sub-project's vote is not counted. 
-This avoids situations where only a minority of leadership team members votes, 
+This avoids situations where only a minority of leadership team members vote, 
 which would skew the overall result. If it becomes clear, that a sub-project 
is 
 not likely to meet the quorum, the voting deadline can be extended by the 
 community manager.
@@ -572,7 +587,7 @@ and 1 abstains, the share is 5/7th and 2/7th respectively).
 -   Votes in favour are averaged as percentages across all projects (say we 
 have per project figures of 50%, 80%, 70% in favour, then the total vote in 
 favour is 66.67%).
--   If the t

[Xen-devel] [PATCH v3 1/4] Code motion changes to make real patches easier to read

[Lars Kurth]

Added TOC
Re-arranged sections compared to previous version of document
Added new anchors where needed
Split Roles section into two sections

The actual content was not changed (with the exception of minor
typos that I spotted)

Signed-off-by: Lars Kurth 
---
 governance.pandoc | 207 +-
 1 file changed, 113 insertions(+), 94 deletions(-)

diff --git a/governance.pandoc b/governance.pandoc
index 60fc942..2ce780c 100644
--- a/governance.pandoc
+++ b/governance.pandoc
@@ -1,9 +1,20 @@
-
-This document has come in effect in June 2011 and will be 
-reviewed periodically (see revision sections). The last modification has been 
-made in May 2013.
-
-Goals
+This document has come in effect in June 2011 and will be reviewed 
periodically 
+(see revision sections). The last modification has been made in July 2016.
+
+Content
+---
+
+-   [Goals](#goals)
+-   [Principles](#principles)
+-   [Xen Project Wide Roles](#roles-global)
+-   [Project Team Roles](#roles-local)
+-   [Making Contributions](#contributions)
+-   [Decision Making, Conflict Resolution, Role Nominations and 
+Elections](#decisions)
+-   [Formal Votes](#formal-votes)
+-   [Project Governance](#project-governance)
+
+Goals {#goals}
 -
 
 The goals of Xen Project Governance are to:
@@ -22,7 +33,7 @@ going elsewhere
 -   Set clear expectations to vendors, upstream and downstream projects and 
 community members
 
-Principles
+Principles {#principles}
 --
 
 ### Openness
@@ -43,71 +54,8 @@ The Xen Project is a meritocracy. The more you contribute 
the more
 responsibility you will earn. Leadership roles in Xen are also merit-based and 
 earned by peer acclaim.
 
-### Consensus Decision Making
-
-Sub-projects or teams hosted on Xenproject.org are normally auto-governing and 
-driven by the people who volunteer for the job. This functions well for most 
-cases. When more formal decision making and coordination is required, 
decisions 
-are taken with a lazy consensus approach: a few positive votes with no 
negative 
-vote are enough to get going.
-
-Voting is done with numbers:
-
--   +1 : a positive vote
--   0 : abstain, have no opinion
--   -1 : a negative vote
-
-A negative vote should include an alternative proposal or a detailed 
-explanation of the reasons for the negative vote. The project community then 
-tries to gather consensus on an alternative proposal that resolves the issue. 
-In the great majority of cases, the concerns leading to the negative vote can 
-be addressed.
-
-### Conflict Resolution
-
- Refereeing
-
-Sub-projects and teams hosted on Xenproject.org are not democracies but 
-meritocracies. In situations where there is disagreement on issues related to 
-the day-to-day running of the project, Committers and Project Leads are 
-expected to act as referees and make a decision on behalf of the community. 
-Referees should however consider whether making a decision may be divisive and 
-damaging for the community. In such cases, the committer community of the 
-project can privately vote on an issue, giving the decision more weight.
-
- Last Resort
-
-In some rare cases, the lazy consensus approach may lead to the community 
being 
-paralyzed. Thus, as a last resort when consensus cannot be achieved on a 
-question internal to a project, the final decision will be made by a private 
-majority vote amongst the committers and project lead. If the vote is tied, 
the 
-project lead gets an extra vote to break the tie.
-
-For questions that affect several projects, committers and project leads of 
-mature projects will hold a private majority vote. If the vote is tied, the 
-[Xen Project Advisory Board](/join.html) will break the tie through a casting 
-vote.
-
-Roles
--
-
-### Maintainers
-
-Maintainers own one or several components in the Xen tree. A maintainer 
reviews 
-and approves changes that affect their components. It is a maintainer's prime 
-responsibility to review, comment on, co-ordinate and accept patches from 
other 
-community member's and to maintain the design cohesion of their components. 
-Maintainers are listed in a MAINTAINERS file in the root of the source tree.
-
-### Committers
-
-Committers are Maintainers that are allowed to commit changes into the source 
-code repository. The committer acts on the wishes of the maintainers and 
-applies changes that have been approved by the respective maintainer(s) to the 
-source tree. Due to their status in the community, committers can also act as 
-referees should disagreements amongst maintainers arise. Committers are listed 
-on the sub-project's team portal (e.g. [Hypervisor team 
-portal](/developers/teams/hypervisor.html)).
+Xen Project Wide Roles {#roles-global}
+--
 
 ### Sub-projects and Teams
 
@@ -118,16 +66,6 @@ projects) are run by individuals and are often referred to 
as teams to
 highlight the collaborative nature of development. For example, each 
 sub-projec

[Xen-devel] [PATCH v4 0/7] xen/arm: Add support for mapping mmio-sram nodes into dom0

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

This series adds support for mapping mmio-sram nodes into dom0
as normal uncached MEMORY with RW perms.

If the no-memory-wc prop is present in the DTB node, we create
DEVICE RW mappings instead.

Comments welcome!

Best regards,
Edgar

ChangeLog:

v3 -> v4:
* Rename p2m_mmio_direct_nc -> p2m_mmio_direct_dev
* Rename p2m_mem_nc p2m_mmio_direct_nc
* Make p2m_mmio_direct_nc non-executable to match p2m_mmio_direct_c
* Fix typos in comments regarding shareability
* Add reference to ARMv8 specs for outer sharability attr
* Add comment describing map_regions_p2mt
* Mention the p2m type inheritance in the commit msg of path #6

v2 -> v3:
* Drop RFC
* Add comment on outer-shareable choice for non-cached mem
* Spellfix existance -> existence
* Add comment on props usage
* Props matching now only supports a single property
* Dropped p2m_access in plumbing for mapping attributes
* Rename un/map_regions to un/map_regions_p2mt
* Add path to mmio-sram device-tree bindings docs in commit msg
* Add a comment on inheriting parent mem attributes
* Dropped the mmio-sram bus

v1 -> v2
* Replace the .map method with a list of match -> map attributes
* Handle no-memory-wc by mapping as DEVICE RW
* Generalize map_regions_rw_cache instead of adding new functions

Edgar E. Iglesias (7):
  xen/arm: p2m: Rename p2m_mmio_direct_nc -> p2m_mmio_direct_dev
  xen/arm: p2m: Add support for normal non-cacheable memory
  xen/arm: Rename and generalize un/map_regions_rw_cache
  xen/device-tree: Add __DT_MATCH macros without braces
  xen/device-tree: Make dt_match_node match props
  xen/arm: domain_build: Plumb for different mapping attributes
  xen/arm: Map mmio-sram nodes as un-cached memory

 xen/arch/arm/domain_build.c   | 90 +--
 xen/arch/arm/p2m.c| 42 ++--
 xen/common/device_tree.c  |  5 ++-
 xen/include/asm-arm/p2m.h | 24 +++-
 xen/include/asm-arm/page.h|  1 +
 xen/include/xen/device_tree.h | 20 --
 6 files changed, 136 insertions(+), 46 deletions(-)

-- 
2.7.4


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

[Xen-devel] [PATCH v4 2/7] xen/arm: p2m: Add support for normal non-cacheable memory

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

Add support for describing normal non-cacheable memory.

Signed-off-by: Edgar E. Iglesias 
---
 xen/arch/arm/p2m.c | 19 +++
 xen/include/asm-arm/p2m.h  |  1 +
 xen/include/asm-arm/page.h |  1 +
 3 files changed, 21 insertions(+)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index c3b1233..9912658 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -296,6 +296,7 @@ static void p2m_set_permission(lpae_t *e, p2m_type_t t, 
p2m_access_t a)
 case p2m_map_foreign:
 case p2m_grant_map_rw:
 case p2m_mmio_direct_dev:
+case p2m_mmio_direct_nc:
 case p2m_mmio_direct_c:
 e->p2m.xn = 1;
 e->p2m.write = 1;
@@ -376,6 +377,24 @@ static lpae_t mfn_to_p2m_entry(mfn_t mfn, p2m_type_t t, 
p2m_access_t a)
 e.p2m.sh = LPAE_SH_OUTER;
 break;
 
+/*
+ * ARM ARM: Overlaying the shareability attribute (DDI
+ * 0406C.b B3-1376 to 1377)
+ *
+ * A memory region with a resultant memory type attribute of Normal,
+ * and a resultant cacheability attribute of Inner Non-cacheable,
+ * Outer Non-cacheable, must have a resultant shareability attribute
+ * of Outer Shareable, otherwise shareability is UNPREDICTABLE.
+ *
+ * On ARMv8 shareability is ignored and explicitly treated as Outer
+ * Shareable for Normal Inner Non_cacheable, Outer Non-cacheable.
+ * See the note for table D4-40, in page 1788 of the ARM DDI 0487A.j.
+ */
+case p2m_mmio_direct_nc:
+e.p2m.mattr = MATTR_MEM_NC;
+e.p2m.sh = LPAE_SH_OUTER;
+break;
+
 default:
 e.p2m.mattr = MATTR_MEM;
 e.p2m.sh = LPAE_SH_INNER;
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index b342122..9708fdc 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -92,6 +92,7 @@ typedef enum {
 p2m_ram_rw, /* Normal read/write guest RAM */
 p2m_ram_ro, /* Read-only; writes are silently dropped */
 p2m_mmio_direct_dev,/* Read/write mapping of genuine Device MMIO area */
+p2m_mmio_direct_nc, /* Read/write mapping of genuine MMIO area 
non-cacheable */
 p2m_mmio_direct_c,  /* Read/write mapping of genuine MMIO area cacheable */
 p2m_map_foreign,/* Ram pages from foreign domain */
 p2m_grant_map_rw,   /* Read/write grant mapping */
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 015ed63..f50fe60 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -84,6 +84,7 @@
  *
  */
 #define MATTR_DEV 0x1
+#define MATTR_MEM_NC  0x5
 #define MATTR_MEM 0xf
 
 /* Flags for get_page_from_gva, gvirt_to_maddr etc */
-- 
2.7.4


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

[Xen-devel] [PATCH v4 1/7] xen/arm: p2m: Rename p2m_mmio_direct_nc -> p2m_mmio_direct_dev

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

Rename p2m_mmio_direct_nc to p2m_mmio_direct_dev to better
express that we are mapping device memory. This will allow us
to use p2m_mmio_direct_nc for Normal Non-Cached mappings.

No functional change.

Signed-off-by: Edgar E. Iglesias 
---
 xen/arch/arm/p2m.c| 6 +++---
 xen/include/asm-arm/p2m.h | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 5c5049f..c3b1233 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -295,7 +295,7 @@ static void p2m_set_permission(lpae_t *e, p2m_type_t t, 
p2m_access_t a)
 case p2m_iommu_map_rw:
 case p2m_map_foreign:
 case p2m_grant_map_rw:
-case p2m_mmio_direct_nc:
+case p2m_mmio_direct_dev:
 case p2m_mmio_direct_c:
 e->p2m.xn = 1;
 e->p2m.write = 1;
@@ -366,7 +366,7 @@ static lpae_t mfn_to_p2m_entry(mfn_t mfn, p2m_type_t t, 
p2m_access_t a)
 
 switch ( t )
 {
-case p2m_mmio_direct_nc:
+case p2m_mmio_direct_dev:
 e.p2m.mattr = MATTR_DEV;
 e.p2m.sh = LPAE_SH_OUTER;
 break;
@@ -1237,7 +1237,7 @@ int map_mmio_regions(struct domain *d,
  unsigned long nr,
  mfn_t mfn)
 {
-return p2m_insert_mapping(d, start_gfn, nr, mfn, p2m_mmio_direct_nc);
+return p2m_insert_mapping(d, start_gfn, nr, mfn, p2m_mmio_direct_dev);
 }
 
 int unmap_mmio_regions(struct domain *d,
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 6251b37..b342122 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -91,7 +91,7 @@ typedef enum {
 p2m_invalid = 0,/* Nothing mapped here */
 p2m_ram_rw, /* Normal read/write guest RAM */
 p2m_ram_ro, /* Read-only; writes are silently dropped */
-p2m_mmio_direct_nc, /* Read/write mapping of genuine MMIO area 
non-cacheable */
+p2m_mmio_direct_dev,/* Read/write mapping of genuine Device MMIO area */
 p2m_mmio_direct_c,  /* Read/write mapping of genuine MMIO area cacheable */
 p2m_map_foreign,/* Ram pages from foreign domain */
 p2m_grant_map_rw,   /* Read/write grant mapping */
-- 
2.7.4


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

[Xen-devel] [PATCH v4 5/7] xen/device-tree: Make dt_match_node match props

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

Make dt_match_node match for a single existing property.
We only search for the existence of the property, not
for specific values.

Acked-by: Julien Grall 
Signed-off-by: Edgar E. Iglesias 
---
 xen/common/device_tree.c  | 5 -
 xen/include/xen/device_tree.h | 7 +++
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index b39c8ca..1be074b 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -319,7 +319,7 @@ dt_match_node(const struct dt_device_match *matches,
 return NULL;
 
 while ( matches->path || matches->type ||
-matches->compatible || matches->not_available )
+matches->compatible || matches->not_available || matches->prop)
 {
 bool_t match = 1;
 
@@ -335,6 +335,9 @@ dt_match_node(const struct dt_device_match *matches,
 if ( matches->not_available )
 match &= !dt_device_is_available(node);
 
+if ( matches->prop )
+match &= dt_find_property(node, matches->prop, NULL) != NULL;
+
 if ( match )
 return matches;
 matches++;
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index da153a5..0aecbe0 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -29,6 +29,11 @@ struct dt_device_match {
 const char *type;
 const char *compatible;
 const bool_t not_available;
+/*
+ * Property name to search for. We only search for the property's
+ * existence.
+ */
+const char *prop;
 const void *data;
 };
 
@@ -36,11 +41,13 @@ struct dt_device_match {
 #define __DT_MATCH_TYPE(typ).type = typ
 #define __DT_MATCH_COMPATIBLE(compat)   .compatible = compat
 #define __DT_MATCH_NOT_AVAILABLE()  .not_available = 1
+#define __DT_MATCH_PROP(p)  .prop = p
 
 #define DT_MATCH_PATH(p){ __DT_MATCH_PATH(p) }
 #define DT_MATCH_TYPE(typ)  { __DT_MATCH_TYPE(typ) }
 #define DT_MATCH_COMPATIBLE(compat) { __DT_MATCH_COMPATIBLE(compat) }
 #define DT_MATCH_NOT_AVAILABLE(){ __DT_MATCH_NOT_AVAILABLE() }
+#define DT_MATCH_PROP(p){ __DT_MATCH_PROP(p) }
 
 typedef u32 dt_phandle;
 
-- 
2.7.4


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

[Xen-devel] [PATCH v4 3/7] xen/arm: Rename and generalize un/map_regions_rw_cache

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

Rename and generalize un/map_regions_rw_cache into
un/map_regions_p2mt. The new functions take the mapping
attributes as an argument.

No functional change.

Signed-off-by: Edgar E. Iglesias 
---
 xen/arch/arm/domain_build.c | 18 ++
 xen/arch/arm/p2m.c  | 19 ++-
 xen/include/asm-arm/p2m.h   | 23 ++-
 3 files changed, 34 insertions(+), 26 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 35ab08d..f022342 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1518,10 +1518,11 @@ static void acpi_map_other_tables(struct domain *d)
 {
 addr = acpi_gbl_root_table_list.tables[i].address;
 size = acpi_gbl_root_table_list.tables[i].length;
-res = map_regions_rw_cache(d,
-   _gfn(paddr_to_pfn(addr)),
-   DIV_ROUND_UP(size, PAGE_SIZE),
-   _mfn(paddr_to_pfn(addr)));
+res = map_regions_p2mt(d,
+   _gfn(paddr_to_pfn(addr)),
+   DIV_ROUND_UP(size, PAGE_SIZE),
+   _mfn(paddr_to_pfn(addr)),
+   p2m_mmio_direct_c);
 if ( res )
 {
  panic(XENLOG_ERR "Unable to map ACPI region 0x%"PRIx64
@@ -1874,10 +1875,11 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 acpi_create_efi_mmap_table(d, &kinfo->mem, tbl_add);
 
 /* Map the EFI and ACPI tables to Dom0 */
-rc = map_regions_rw_cache(d,
-  _gfn(paddr_to_pfn(d->arch.efi_acpi_gpa)),
-  PFN_UP(d->arch.efi_acpi_len),
-  
_mfn(paddr_to_pfn(virt_to_maddr(d->arch.efi_acpi_table;
+rc = map_regions_p2mt(d,
+  _gfn(paddr_to_pfn(d->arch.efi_acpi_gpa)),
+  PFN_UP(d->arch.efi_acpi_len),
+  
_mfn(paddr_to_pfn(virt_to_maddr(d->arch.efi_acpi_table))),
+  p2m_mmio_direct_c);
 if ( rc != 0 )
 {
 printk(XENLOG_ERR "Unable to map EFI/ACPI table 0x%"PRIx64
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 9912658..8e7eb68 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1235,18 +1235,19 @@ static inline int p2m_remove_mapping(struct domain *d,
  0, p2m_invalid, d->arch.p2m.default_access);
 }
 
-int map_regions_rw_cache(struct domain *d,
- gfn_t gfn,
- unsigned long nr,
- mfn_t mfn)
+int map_regions_p2mt(struct domain *d,
+ gfn_t gfn,
+ unsigned long nr,
+ mfn_t mfn,
+ p2m_type_t p2mt)
 {
-return p2m_insert_mapping(d, gfn, nr, mfn, p2m_mmio_direct_c);
+return p2m_insert_mapping(d, gfn, nr, mfn, p2mt);
 }
 
-int unmap_regions_rw_cache(struct domain *d,
-   gfn_t gfn,
-   unsigned long nr,
-   mfn_t mfn)
+int unmap_regions_p2mt(struct domain *d,
+   gfn_t gfn,
+   unsigned long nr,
+   mfn_t mfn)
 {
 return p2m_remove_mapping(d, gfn, nr, mfn);
 }
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 9708fdc..a684ed0 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -167,15 +167,20 @@ mfn_t p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t 
*t);
 /* Clean & invalidate caches corresponding to a region of guest address space 
*/
 int p2m_cache_flush(struct domain *d, gfn_t start, unsigned long nr);
 
-int map_regions_rw_cache(struct domain *d,
- gfn_t gfn,
- unsigned long nr,
- mfn_t mfn);
-
-int unmap_regions_rw_cache(struct domain *d,
-   gfn_t gfn,
-   unsigned long nr,
-   mfn_t mfn);
+/*
+ * Map a region in the guest p2m with a specific p2m type.
+ * The memory attributes will be derived from the p2m type.
+ */
+int map_regions_p2mt(struct domain *d,
+ gfn_t gfn,
+ unsigned long nr,
+ mfn_t mfn,
+ p2m_type_t p2mt);
+
+int unmap_regions_p2mt(struct domain *d,
+   gfn_t gfn,
+   unsigned long nr,
+   mfn_t mfn);
 
 int map_dev_mmio_region(struct domain *d,
 gfn_t gfn,
-- 
2.7.4


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

[Xen-devel] [PATCH v4 7/7] xen/arm: Map mmio-sram nodes as un-cached memory

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

Map mmio-sram nodes as un-cached memory. If the node
has set the no-memory-wc property, we map it as device.

The DTS bindings for mmio-sram nodes can be found in the
Linux tree under Documentation/devicetree/bindings/sram/sram.txt.

Signed-off-by: Edgar E. Iglesias 
---
 xen/arch/arm/domain_build.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 0c30121..f1c5526 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -48,6 +48,20 @@ struct map_range_data
 p2m_type_t p2mt;
 };
 
+static const struct dt_device_match dev_map_attrs[] __initconst =
+{
+{
+__DT_MATCH_COMPATIBLE("mmio-sram"),
+__DT_MATCH_PROP("no-memory-wc"),
+.data = (void *) (uintptr_t) p2m_mmio_direct_dev,
+},
+{
+__DT_MATCH_COMPATIBLE("mmio-sram"),
+.data = (void *) (uintptr_t) p2m_mmio_direct_nc,
+},
+{ /* sentinel */ },
+};
+
 //#define DEBUG_11_ALLOCATION
 #ifdef DEBUG_11_ALLOCATION
 # define D11PRINT(fmt, args...) printk(XENLOG_DEBUG fmt, ##args)
@@ -1145,6 +1159,21 @@ static int handle_device(struct domain *d, struct 
dt_device_node *dev,
 return 0;
 }
 
+static p2m_type_t lookup_map_attr(struct dt_device_node *node,
+  p2m_type_t parent_p2mt)
+{
+const struct dt_device_match *r;
+
+/* Search and if nothing matches, use the parent's attributes.  */
+r = dt_match_node(dev_map_attrs, node);
+
+/*
+ * If this node does not dictate specific mapping attributes,
+ * it inherits its parent's attributes.
+ */
+return r ? (uintptr_t) r->data : parent_p2mt;
+}
+
 static int handle_node(struct domain *d, struct kernel_info *kinfo,
struct dt_device_node *node,
p2m_type_t p2mt)
@@ -1234,6 +1263,7 @@ static int 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);
 
+p2mt = lookup_map_attr(node, p2mt);
 res = handle_device(d, node, p2mt);
 if ( res)
 return res;
-- 
2.7.4


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

[Xen-devel] [PATCH v4 6/7] xen/arm: domain_build: Plumb for different mapping attributes

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

Add plumbing for passing around mapping attributes.
Nodes that don't specifically state their type will inherit
their type from their parent.

This is in preparation for allowing us to differentiate the attributes
for specific device nodes.

We still use the same DEVICE mappings for all nodes so this
patch has no functional change.

Acked-by: Julien Grall 
Signed-off-by: Edgar E. Iglesias 
---
 xen/arch/arm/domain_build.c | 42 +-
 1 file changed, 29 insertions(+), 13 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index f022342..0c30121 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -42,6 +42,12 @@ static void __init parse_dom0_mem(const char *s)
 }
 custom_param("dom0_mem", parse_dom0_mem);
 
+struct map_range_data
+{
+struct domain *d;
+p2m_type_t p2mt;
+};
+
 //#define DEBUG_11_ALLOCATION
 #ifdef DEBUG_11_ALLOCATION
 # define D11PRINT(fmt, args...) printk(XENLOG_DEBUG fmt, ##args)
@@ -974,7 +980,8 @@ static int map_range_to_domain(const struct dt_device_node 
*dev,
u64 addr, u64 len,
void *data)
 {
-struct domain *d = data;
+struct map_range_data *mr_data = data;
+struct domain *d = mr_data->d;
 bool_t need_mapping = !dt_device_for_passthrough(dev);
 int res;
 
@@ -991,10 +998,12 @@ static int map_range_to_domain(const struct 
dt_device_node *dev,
 
 if ( need_mapping )
 {
-res = map_mmio_regions(d,
+res = map_regions_p2mt(d,
_gfn(paddr_to_pfn(addr)),
DIV_ROUND_UP(len, PAGE_SIZE),
-   _mfn(paddr_to_pfn(addr)));
+   _mfn(paddr_to_pfn(addr)),
+   mr_data->p2mt);
+
 if ( res < 0 )
 {
 printk(XENLOG_ERR "Unable to map 0x%"PRIx64
@@ -1005,7 +1014,8 @@ static int map_range_to_domain(const struct 
dt_device_node *dev,
 }
 }
 
-dt_dprintk("  - MMIO: %010"PRIx64" - %010"PRIx64"\n", addr, addr + len);
+dt_dprintk("  - MMIO: %010"PRIx64" - %010"PRIx64" P2MType=%x\n",
+   addr, addr + len, mr_data->p2mt);
 
 return 0;
 }
@@ -1016,8 +1026,10 @@ static int map_range_to_domain(const struct 
dt_device_node *dev,
  * the child resources available to domain 0.
  */
 static int map_device_children(struct domain *d,
-   const struct dt_device_node *dev)
+   const struct dt_device_node *dev,
+   p2m_type_t p2mt)
 {
+struct map_range_data mr_data = { .d = d, .p2mt = p2mt };
 int ret;
 
 if ( dt_device_type_is_equal(dev, "pci") )
@@ -1029,7 +1041,7 @@ static int map_device_children(struct domain *d,
 if ( ret < 0 )
 return ret;
 
-ret = dt_for_each_range(dev, &map_range_to_domain, d);
+ret = dt_for_each_range(dev, &map_range_to_domain, &mr_data);
 if ( ret < 0 )
 return ret;
 }
@@ -1045,7 +1057,8 @@ static int map_device_children(struct domain *d,
  *  - Assign the device to the guest if it's protected by an IOMMU
  *  - Map the IRQs and iomem regions to DOM0
  */
-static int handle_device(struct domain *d, struct dt_device_node *dev)
+static int handle_device(struct domain *d, struct dt_device_node *dev,
+ p2m_type_t p2mt)
 {
 unsigned int nirq;
 unsigned int naddr;
@@ -,6 +1124,7 @@ static int handle_device(struct domain *d, struct 
dt_device_node *dev)
 /* Give permission and map MMIOs */
 for ( i = 0; i < naddr; i++ )
 {
+struct map_range_data mr_data = { .d = d, .p2mt = p2mt };
 res = dt_device_get_address(dev, i, &addr, &size);
 if ( res )
 {
@@ -1119,12 +1133,12 @@ static int handle_device(struct domain *d, struct 
dt_device_node *dev)
 return res;
 }
 
-res = map_range_to_domain(dev, addr, size, d);
+res = map_range_to_domain(dev, addr, size, &mr_data);
 if ( res )
 return res;
 }
 
-res = map_device_children(d, dev);
+res = map_device_children(d, dev, p2mt);
 if ( res )
 return res;
 
@@ -1132,7 +1146,8 @@ static int handle_device(struct domain *d, struct 
dt_device_node *dev)
 }
 
 static int handle_node(struct domain *d, struct kernel_info *kinfo,
-   struct dt_device_node *node)
+   struct dt_device_node *node,
+   p2m_type_t p2mt)
 {
 static const struct dt_device_match skip_matches[] __initconst =
 {
@@ -1219,7 +1234,7 @@ static int 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);
 
-res = handle_device(d, node);
+res = handle_device(d, node, p2mt);

[Xen-devel] [PATCH v4 4/7] xen/device-tree: Add __DT_MATCH macros without braces

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

Add __DT_MATCH macros without braces to allow the creation
of match descriptors with multiple combined match options.

Acked-by: Julien Grall 
Signed-off-by: Edgar E. Iglesias 
---
 xen/include/xen/device_tree.h | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 3657ac2..da153a5 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -32,10 +32,15 @@ struct dt_device_match {
 const void *data;
 };
 
-#define DT_MATCH_PATH(p){ .path = p }
-#define DT_MATCH_TYPE(typ)  { .type = typ }
-#define DT_MATCH_COMPATIBLE(compat) { .compatible = compat }
-#define DT_MATCH_NOT_AVAILABLE(){ .not_available = 1 }
+#define __DT_MATCH_PATH(p)  .path = p
+#define __DT_MATCH_TYPE(typ).type = typ
+#define __DT_MATCH_COMPATIBLE(compat)   .compatible = compat
+#define __DT_MATCH_NOT_AVAILABLE()  .not_available = 1
+
+#define DT_MATCH_PATH(p){ __DT_MATCH_PATH(p) }
+#define DT_MATCH_TYPE(typ)  { __DT_MATCH_TYPE(typ) }
+#define DT_MATCH_COMPATIBLE(compat) { __DT_MATCH_COMPATIBLE(compat) }
+#define DT_MATCH_NOT_AVAILABLE(){ __DT_MATCH_NOT_AVAILABLE() }
 
 typedef u32 dt_phandle;
 
-- 
2.7.4


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

Re: [Xen-devel] PCI passthrough with stubdomain

[Marek Marczykowski-Górecki]

On Fri, Sep 23, 2016 at 11:35:27AM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 23, 2016 at 04:25:41PM +0200, Marek Marczykowski-Górecki wrote:
> > On Fri, Sep 23, 2016 at 03:27:07PM +0200, Samuel Thibault wrote:
> > > Marek Marczykowski-Górecki, on Fri 23 Sep 2016 10:48:14 +0200, wrote:
> > > > I'm still trying to get PCI passthrough working with stubdomain and
> > > > without qemu in dom0 (even for just vfb/vkbd backends). How is this
> > > > supposed to work?
> > > 
> > > Just as I recall from my memory:
> > > 
> > > > 1. Should xen-pcifront in the target domain be used (and consequently,
> > > > should xen-pciback be set for it)?
> > > 
> > > I guess that could work.
> > 
> > Could, or should? ;)
> > 
> > In the meantime, I've found this in xen-pcifront driver:
> > 
> > static int __init pcifront_init(void)
> > {
> > if (!xen_pv_domain() || xen_initial_domain())
> > return -ENODEV;
> > 
> > So, it looks like pcifront is not used in PV domain.
> 
> You mean in HVM domains.

Of course.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  a75f34462612a05547fc43d192705a9c31cad7fb
baseline version:
 xen  b106f15efbfc99f52ccb94ab8ca7fdb21fcf

Last test of basis   101083  2016-09-21 20:03:17 Z1 days
Testing same since   101126  2016-09-23 17:02:04 Z0 days1 attempts


People who touched revisions under test:
  Boris Ostrovsky 
  Jan Beulich 
  Jan Beulich  [for directory]
  Jan Beulich  [relevant parts]
  Jan Beulich  [x86 parts]
  Joao Martins 
  Julien Grall  [arm change]
  Konrad Rzeszutek Wilk 
  Ross Lagerwall 

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



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

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

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

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


Pushing revision :

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

[Xen-devel] [xen-unstable test] 101121: tolerable FAIL

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101116
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101116
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101116
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101116
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101116

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 xen  b106f15efbfc99f52ccb94ab8ca7fdb21fcf
baseline version:
 xen  b106f15efbfc99f52ccb94ab8ca7fdb21fcf

Last test of basis   101121  2016-09-23 08:18:27 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 17067 days0 attempts

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-prev pass
 build-i386-prev  

Re: [Xen-devel] [PATCH v3 1/6] xen/arm: p2m: Add support for normal non-cacheable memory

[Edgar E. Iglesias]

On Mon, Sep 19, 2016 at 05:22:27PM +0200, Julien Grall wrote:
> Hi Edgar,

Hi Julien,

Sorry for the late reply!

> 
> On 16/09/2016 18:17, Edgar E. Iglesias wrote:
> >On Fri, Sep 16, 2016 at 04:21:12PM +0200, Julien Grall wrote:
> >>Hi Edgar,
> >>
> >>On 07/09/2016 08:56, Edgar E. Iglesias wrote:
> >>>From: "Edgar E. Iglesias" 
> >>>
> >>>Add support for describing normal non-cacheable memory.
> >>>
> >>>Signed-off-by: Edgar E. Iglesias 
> >>>---
> >>>xen/arch/arm/p2m.c | 18 ++
> >>>xen/include/asm-arm/p2m.h  |  1 +
> >>>xen/include/asm-arm/page.h |  1 +
> >>>3 files changed, 20 insertions(+)
> >>>
> >>>diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> >>>index b648a9d..bfef77b 100644
> >>>--- a/xen/arch/arm/p2m.c
> >>>+++ b/xen/arch/arm/p2m.c
> >>>@@ -282,6 +282,7 @@ static void p2m_set_permission(lpae_t *e, p2m_type_t 
> >>>t, p2m_access_t a)
> >>>/* First apply type permissions */
> >>>switch ( t )
> >>>{
> >>>+case p2m_mem_nc:
> >>>case p2m_ram_rw:
> >>>e->p2m.xn = 0;
> >>>e->p2m.write = 1;
> >>>@@ -376,6 +377,23 @@ static lpae_t mfn_to_p2m_entry(mfn_t mfn, p2m_type_t 
> >>>t, p2m_access_t a)
> >>>e.p2m.sh = LPAE_SH_OUTER;
> >>>break;
> >>>
> >>>+/*
> >>>+ * ARM ARM: Overlaying the shareability attribute (DDI
> >>>+ * 0406C.b B3-1376 to 1377)
> >>>+ *
> >>>+ * A memory region with a resultant memory type attribute of Normal,
> >>>+ * and a resultant cacheability attribute of Inner Non-cacheable,
> >>>+ * Outer Non-cacheable, must have a resultant shareability attribute
> >>>+ * of Outer Shareable, otherwise shareability is UNPREDICTABLE.
> >>>+ *
> >>>+ * On ARMv8 sharability is ignored and explicitly treated as Outer
> >>
> >>I know you copied it from mfn_to_xen_entry, but can we fixed the copy with:
> >>
> >>s/sharability/shareability/
> >>
> >>>+ * Shareable for Normal Inner Non_cacheable, Outer Non-cacheable.
> >>
> >>s/_/-/
> >>
> >>Also I would like to see a spec reference for the ARMv8. I think it is the
> >>note in D4-1788 ARM DDI 0487A.j.
> >>
> >>>+ */
> >>>+case p2m_mem_nc:
> >>>+e.p2m.mattr = MATTR_MEM_NC;
> >>>+e.p2m.sh = LPAE_SH_OUTER;
> >>>+break;
> >>>+
> >>>default:
> >>>e.p2m.mattr = MATTR_MEM;
> >>>e.p2m.sh = LPAE_SH_INNER;
> >>>diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> >>>index 53c4d78..b012d50 100644
> >>>--- a/xen/include/asm-arm/p2m.h
> >>>+++ b/xen/include/asm-arm/p2m.h
> >>>@@ -93,6 +93,7 @@ typedef enum {
> >>>p2m_ram_ro, /* Read-only; writes are silently dropped */
> >>>p2m_mmio_direct_nc, /* Read/write mapping of genuine MMIO area 
> >>> non-cacheable */
> >>>p2m_mmio_direct_c,  /* Read/write mapping of genuine MMIO area 
> >>> cacheable */
> >>>+p2m_mem_nc, /* Read/write mapping of Non-cacheable Memory */
> >>
> >>I find the name a bit confusing. Technically p2m_mem_nc is p2m_mmio_direct_c
> >>version but non-cacheable.
> >>
> >>I have got the feeling that the naming I used on a recent patch is not
> >>correct. Because p2m_mmio_direct_nc is not doing what is expect (i.e mapping
> >>non-cacheable). It maps with the device memory attribute.
> >>
> >>Maybe we should rename p2m_mmio_direct_nc to p2m_mmio_direct_dev (because it
> >>will use the device memory attribute) and then use p2m_mmio_direct_nc for
> >>your purpose.
> >>
> >>Any opinions?
> >
> >
> >Something that shows up after doing the rename and otherwise keeping the
> >patch is that we treat the XN bit differently for p2m_mmio_direct_nc
> >and p2m_mmio_direct_c.
> >
> >Is there any reason why we can't allow execution for p2m_mmio_direct_c
> >mappings?
> >If so, perhaps that same reason also applies to p2m_mmio_direct_nc and
> >both should be non-executable.
> 
> I guess you mean your new p2m_mmio_direct_nc and not the current one. If so,
> I think it is more a safety. Until now, the p2m type was used to share ACPI
> tables which should not be executable.

Yes, I meant that it's a little strange to have them differ, e.g:

p2m_mmio_direct_nc   xn = 0
p2m_mmio_direct_cxn = 1

Because intuitively, when looking at those types I would expect
them to be identical except for the cacheability...


> I am not sure what would be the implication to unset the NX bit by default.
> The question to answer before any relaxation is could a potential misbehave
> guest harm the platform?

Agreed. I personally don't see a reason why normal memory would cause problems
but it may be a little late in the release cycle to risk anything. I can
make the new p2m_mmio_direct_nc XN=1 and we can discuss a relaxation for the
next release?

Cheers,
Edgar

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

Re: [Xen-devel] [PATCH 05/17] x86emul: add XOP decoding

[Andrew Cooper]

On 14/09/16 17:21, Jan Beulich wrote:

On 14.09.16 at 18:11,  wrote:

On 08/09/16 14:11, Jan Beulich wrote:

@@ -1580,6 +1586,9 @@ struct x86_emulate_state {
  ext_0f   = vex_0f,
  ext_0f38 = vex_0f38,
  ext_0f3a = vex_0f3a,
+ext_8f08 = 8,
+ext_8f09,
+ext_8f0a,

What is this = 8 for?  I presume you didn't slip it in accidentally, but
I still can't figure out why.

So I can use the value directly from vex.opcx, without further
adjustment.


Ok, but please leave a comment to that effect.

~Andrew

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

Re: [Xen-devel] [PATCH 04/17] x86emul: complete decoding of two-byte instructions

[Andrew Cooper]

On 14/09/16 16:05, Jan Beulich wrote:

On 14.09.16 at 16:22,  wrote:

On 08/09/16 14:10, Jan Beulich wrote:

This way we can at least size (and e.g. skip) them if needed, and we
also won't raise the wrong fault due to not having read all relevant
bytes.

What faults are you referring to?  #UD vs #GP from hitting the %cs limit?

Or #PF.


This at once adds correct raising of #UD for the three "ud" flavors
(Intel names only "ud2", but AMD names all three of them in their
opcode maps), as that may make a difference to callers compared to
getting back X86EMUL_UNHANDLEABLE.

Definitely a good improvement.  I have been meaning to do this for a while.

Intel does references 0FB9 in a footnote in the opcode map, but I can't
see any mention of 0FFF at all.

Check AMD's.


Note on opcodes 0FA6 and 0FA7: These are VIA's PadLock instructions,
which have a ModRM like byte where only register forms are valid. I.e.
we could also use SrcImmByte there, but ModRM is more likely to be
correct for a hypothetical extension allowing non-register operations.

Won't the use of ModRM possibly cause us to read too much if it end up
with SIB and displacement encoding?  OTOH, do we really care?

That's why I've added that paragraph: I'd be fine either way, but I
do think the intention is a ModRM byte. Which is then also in line with
these opcodes' uses in early 386 and 486 processors (xbts/ibts/
cmpxchg).


Note on opcode 0FB8: I think we're safe to ignore JMPE (which doesn't
take a ModRM byte, but an immediate).

It took a while to find out what this instruction is.  Mind indicating
that it is Itanium-specific in the commit message?

Sure.


POPCNT, the aliased instruction takes a full ModRM byte with no space to
distinguish.

Well, distinguishing them is possible in principle, as by the time we
process bytes past the main opcode one we already know whether
an F3 prefix was present. I simply think it's not worth trying to do
so.


It would be helpful if you listed all of the decoding modified.

From the looks of things, the instructions changed are:

LAR, LSL, CLTS, UD2, FEMMS, 3DNow!, a bunch of SSE instructions, RDPMC, 
GETSEC, more SSE/MMX, RSM, POPCNT, UD1, yet more SSE,



A couple of other misc points:

What is the point of having 0F3A specified with 
DstReg|SrcImmByte|ModRM?  Being a prefix, it shouldn't be treated like a 
plain operation.


0F6F was previously ImplicitOps|ModRM, but looks like it should be ModRM 
like the rest of 0F6x.  0F7F, 0FC7 and 0FE7 similarly.


~Andrew

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

Re: [Xen-devel] [PATCH v5 06/16] livepatch: ARM/x86: Check displacement of old_addr and new_addr

[Konrad Rzeszutek Wilk]

On Fri, Sep 23, 2016 at 11:37:27AM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 23, 2016 at 03:36:27PM +0100, Ross Lagerwall wrote:
> > On 09/21/2016 06:32 PM, Konrad Rzeszutek Wilk wrote:
> > > If the distance is too big we are in trouble - as our relocation
> > > distance can surely be clipped, or still have a valid width - but
> > > cause an overflow of distance.
> > > 
> > > On various architectures the maximum displacement for a unconditional
> > > branch/jump varies. ARM32 is +/- 32MB, ARM64 is +/- 128MB while x86
> > > for 32-bit relocations is +/- 2G.
> > > 
> > > Note: On x86 we could use the 64-bit jmpq instruction which
> > > would provide much bigger displacement to do a jump, but we would
> > > still have issues with the new function not being able to reach
> > > any of the old functions (as all the relocations would assume 32-bit
> > > displacement). And "furthermore would require an register or
> > > memory location to load/store the address to." (From Jan).
> > > 
> > > On ARM the conditional branch supports even a smaller displacement
> > > but fortunately we are not using that.
> > 
> > Wouldn't this be simpler as a BUILD_BUG_ON() in arch_livepatch_init()?
> > 
> > Something like BUILD_BUG_ON(((XEN_VIRT_END - NR_CPUS * PAGE_SIZE) -
> > XEN_VIRT_START) > ARCH_LIVEPATCH_RANGE)?
> > 
> > And BUILD_BUG_ON(((XEN_VIRT_END - NR_CPUS * PAGE_SIZE) - XEN_VIRT_START) >
> > ARCH_LIVEPATCH_RANGE)
> > 
> > And something similar for ARM...
> 
> What does that have to with the payload? The displacement calculations(checks)
> are done when we load the payload.

Ooh, you are thinking of just making sure that the displacement in virtual
addresses _should_ be OK.

And that BUILD_BUG_ON would certainly do it.

But my thinking was more of the payload either having some wacky relocations 
(say
having an initial addendum that along with the XEN_VIRT_START -> XEN_VIRT_END)
causes us to be way past the right place (especially with ARM32 where we only
have 32MB distance). And having this extra check makes me sleep better at night.

Adding the BUILD_BUG_ON as a futher check is fine, but as a different patch.

> > 
> > -- 
> > Ross Lagerwall

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

[Xen-devel] [qemu-mainline baseline-only test] 67753: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67753 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67753/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   5 xen-build fail REGR. vs. 67748

Tests which did not succeed, but are not blocking:
 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-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 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-libvirt-vhd  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-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-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-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail 

Re: [Xen-devel] [PATCH v5 15/16] livepatch, arm[32|64]: Share arch_livepatch_revert

[Konrad Rzeszutek Wilk]

> Same as previously, can this not be done with a simple memcpy?

Done!


From caaf99c75f28486737c21f1fc5f584b67e088f35 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Fri, 23 Sep 2016 11:25:12 -0400
Subject: [PATCH v6] livepatch, arm[32|64]: Share arch_livepatch_revert

It is exactly the same in both platforms.

No functional change.

Acked-by: Julien Grall 
Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Julien Grall 
Cc: Stefano Stabellini 

v3: New submission.
v4: s/arch_livepatch_insn_len/livepatch_insn_len/
s/PATCH_INSN_SIZE/ARCH_PATCH_INSN_SIZE/
v5: Added Julien's Acked-by.
Fixed comments.
  - Rebase on top "livepatch: Drop _jmp from arch_livepatch_[apply,revert]_jmp"
  - s/_jmp//
v6:
  - Rebase on top ARM64 and ARM32 implementations which now have
clean_and_invalidate_dcache_va_range on new_ptr.
---
 xen/arch/arm/arm32/livepatch.c | 13 +
 xen/arch/arm/arm64/livepatch.c | 13 +
 xen/arch/arm/livepatch.c   | 13 +
 3 files changed, 15 insertions(+), 24 deletions(-)

diff --git a/xen/arch/arm/arm32/livepatch.c b/xen/arch/arm/arm32/livepatch.c
index d9a8caa..a7fd5e2 100644
--- a/xen/arch/arm/arm32/livepatch.c
+++ b/xen/arch/arm/arm32/livepatch.c
@@ -75,18 +75,7 @@ void arch_livepatch_apply(struct livepatch_func *func)
 clean_and_invalidate_dcache_va_range(new_ptr, sizeof (*new_ptr) * len);
 }
 
-void arch_livepatch_revert(const struct livepatch_func *func)
-{
-uint32_t *new_ptr;
-unsigned int len;
-
-new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
-
-len = livepatch_insn_len(func);
-memcpy(new_ptr, func->opaque, len);
-
-clean_and_invalidate_dcache_va_range(new_ptr, len);
-}
+/* arch_livepatch_revert shared with ARM 32/ARM 64. */
 
 int arch_livepatch_verify_elf(const struct livepatch_elf *elf)
 {
diff --git a/xen/arch/arm/arm64/livepatch.c b/xen/arch/arm/arm64/livepatch.c
index 558acb9..dae64f5 100644
--- a/xen/arch/arm/arm64/livepatch.c
+++ b/xen/arch/arm/arm64/livepatch.c
@@ -62,18 +62,7 @@ void arch_livepatch_apply(struct livepatch_func *func)
 clean_and_invalidate_dcache_va_range(new_ptr, sizeof (*new_ptr) * len);
 }
 
-void arch_livepatch_revert(const struct livepatch_func *func)
-{
-uint32_t *new_ptr;
-unsigned int len;
-
-new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
-
-len = livepatch_insn_len(func);
-memcpy(new_ptr, func->opaque, len);
-
-clean_and_invalidate_dcache_va_range(new_ptr, len);
-}
+/* arch_livepatch_revert shared with ARM 32/ARM 64. */
 
 int arch_livepatch_verify_elf(const struct livepatch_elf *elf)
 {
diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index dfa285c..de95e54 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -69,6 +69,19 @@ int arch_livepatch_verify_func(const struct livepatch_func 
*func)
 return 0;
 }
 
+void arch_livepatch_revert(const struct livepatch_func *func)
+{
+uint32_t *new_ptr;
+unsigned int len;
+
+new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
+
+len = livepatch_insn_len(func);
+memcpy(new_ptr, func->opaque, len);
+
+clean_and_invalidate_dcache_va_range(new_ptr, len);
+}
+
 void arch_livepatch_post_action(void)
 {
 /* arch_livepatch_revive has nuked the instruction cache. */
-- 
2.4.11

> 
> -- 
> Ross Lagerwall

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

Re: [Xen-devel] [PATCH v5 08/16] livepatch/arm/x86: Check payload for for unwelcomed symbols.

[Konrad Rzeszutek Wilk]

> >  int arch_livepatch_perform_rel(struct livepatch_elf *elf,
> > const struct livepatch_elf_sec *base,
> > const struct livepatch_elf_sec *rela)
> > diff --git a/xen/common/livepatch_elf.c b/xen/common/livepatch_elf.c
> > index f46990e..ec74beb 100644
> > --- a/xen/common/livepatch_elf.c
> > +++ b/xen/common/livepatch_elf.c
> > @@ -251,6 +251,13 @@ static int elf_get_sym(struct livepatch_elf *elf, 
> > const void *data)
> > 
> >  sym[i].sym = s;
> >  sym[i].name = strtab_sec->data + delta;
> > +/* e.g. On ARM we should NEVER see $t* symbols. */
> 
> I'd prefer this comment in ARM's arch_livepatch_symbol_deny.

I removed the comment from common code. With the latest patch each architecture
has its own implementation of arch_livepatch_symbol_deny.

> 
> Either way,
> Reviewed-by: Ross Lagerwall 

Thanks.

Here is how the updated patch looks like:

From b84b478c4214f97e809f659fe348493c48a51d0c Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Tue, 13 Sep 2016 13:15:07 -0400
Subject: [PATCH v6] livepatch/arm/x86: Check payload for for unwelcomed
 symbols.

Certain platforms, such as ARM [32|64] add extra mapping symbols
such as $x (for ARM64 instructions), or more interesting to
this patch: $t (for Thumb instructions). These symbols are supposed
to help the final linker to make any adjustments (such as
add an veneer). But more importantly - we do not compile Xen
with any Thumb instructions (which are variable length) - and
if we find these mapping symbols we should disallow such payload.

Reviewed-by: Ross Lagerwall 
Reviewed-by: Julien Grall 
Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Konrad Rzeszutek Wilk 
Cc: Ross Lagerwall 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Andrew Cooper 

v3: New submission.
Use &sym[i] instead of sym (as that will always be NULL).
v4: Use bool instead of int for return
Update comment in common code about ARM odd symbols.
s/_check/_deny/ to make it more clear.
v5: Also check for $t.* wildcard.
Use Julien's variant where we roll the [2] check in the return.
v6: s/suppose/supposed/ in commit description.
Move arch_livepatch_symbol_deny in arm[32|64]/livepatch.c
Added Julien's Reviewed-by.
Added Ross's Reviewed-by.
Removed comment from common code talking about $t symbol.
---
 xen/arch/arm/arm32/livepatch.c | 13 +
 xen/arch/arm/arm64/livepatch.c |  7 +++
 xen/arch/x86/livepatch.c   |  7 +++
 xen/common/livepatch_elf.c |  6 ++
 xen/include/xen/livepatch.h|  2 ++
 5 files changed, 35 insertions(+)

diff --git a/xen/arch/arm/arm32/livepatch.c b/xen/arch/arm/arm32/livepatch.c
index 80f9646..5fc2e63 100644
--- a/xen/arch/arm/arm32/livepatch.c
+++ b/xen/arch/arm/arm32/livepatch.c
@@ -20,6 +20,19 @@ int arch_livepatch_verify_elf(const struct livepatch_elf 
*elf)
 return -EOPNOTSUPP;
 }
 
+bool arch_livepatch_symbol_deny(const struct livepatch_elf *elf,
+const struct livepatch_elf_sym *sym)
+{
+/*
+ * Xen does not use Thumb instructions - and we should not see any of
+ * them. If we do, abort.
+ */
+if ( sym->name && sym->name[0] == '$' && sym->name[1] == 't' )
+return ( !sym->name[2] || sym->name[2] == '.' );
+
+return false;
+}
+
 int arch_livepatch_perform_rela(struct livepatch_elf *elf,
 const struct livepatch_elf_sec *base,
 const struct livepatch_elf_sec *rela)
diff --git a/xen/arch/arm/arm64/livepatch.c b/xen/arch/arm/arm64/livepatch.c
index 774f845..f148927 100644
--- a/xen/arch/arm/arm64/livepatch.c
+++ b/xen/arch/arm/arm64/livepatch.c
@@ -90,6 +90,13 @@ int arch_livepatch_verify_elf(const struct livepatch_elf 
*elf)
 return 0;
 }
 
+bool arch_livepatch_symbol_deny(const struct livepatch_elf *elf,
+const struct livepatch_elf_sym *sym)
+{
+/* No special checks on ARM 64. */
+return false;
+}
+
 enum aarch64_reloc_op {
 RELOC_OP_NONE,
 RELOC_OP_ABS,
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index 7a369a0..9663ef6 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -131,6 +131,13 @@ bool arch_livepatch_symbol_ok(const struct livepatch_elf 
*elf,
 return true;
 }
 
+bool arch_livepatch_symbol_deny(const struct livepatch_elf *elf,
+const struct livepatch_elf_sym *sym)
+{
+/* No special checks on x86. */
+return false;
+}
+
 int arch_livepatch_perform_rel(struct livepatch_elf *elf,
const struct livepatch_elf_sec *base,
const struct livepatch_elf_sec *rela)
diff --git a/xen/common/livepatch_elf.c b/xen/common/livepatch_elf.c
index dec904a..c4a9633 100644
--- a/xen/common/livepatch_elf.c
+++ b/xen/common/livepatch_elf.c
@@ -251,6 +251,12 @@ static int elf_get_sym(struct livepatch_elf *elf, 

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 8b4ca351dded404f992504c45e358572c4d236f9
baseline version:
 ovmf fe882c01122e7e01e0e78ca8da64630faf9a7b5a

Last test of basis   101122  2016-09-23 09:49:15 Z0 days
Testing same since   101124  2016-09-23 13:46:33 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  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 :

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

Re: [Xen-devel] [PATCH v5 07/16] livepatch: ARM 32|64: Ignore mapping symbols: $[d, a, x]

[Konrad Rzeszutek Wilk]

> > +bool arch_livepatch_symbol_ok(const struct livepatch_elf *elf,
> > +  const struct livepatch_elf_sym *sym)
> > +{
> > +/*
> > + * - Mapping symbols - denote the "start of a sequence of bytes of the
> > + *   appropriate type" to mark certain features - such as start of 
> > region
> > + *   containing data ($d); ARM ($a), or A64 ($x) instructions.
> > + *   We ignore Thumb instructions ($t) as we shouldn't have them.
> > + *
> > + * The format is either short: '$x' or long: '$x.'. We do not
> > + * need this and more importantly - each payload will contain this
> > + * resulting in symbol collisions.
> > + */
> > +if ( *sym->name == '$' && sym->name[1] != '\0' )
> 
> This would be clear (IMO) as sym->name[0].
> 
> Either way,
> 
> Reviewed-by: Ross Lagerwall 

Updated it to be:

From e6cafccb4a869e3e649c2295c5003435299fb7df Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Fri, 12 Aug 2016 23:08:32 -0400
Subject: [PATCH v6] livepatch: ARM 32|64: Ignore mapping symbols: $[d,a,x]

Those symbols are used to help final linkers to replace insn.
The ARM ELF specification mandates that they are present
to denote the start of certain CPU features. There are two
variants of it - short and long format.

Either way - we can ignore these symbols.

Reviewed-by: Ross Lagerwall 
Acked-by: Julien Grall 
Reviewed-by: Andrew Cooper  [x86 bits]
Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Konrad Rzeszutek Wilk 
Cc: Ross Lagerwall 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Andrew Cooper 

v1: First submission
v2: Update the order of symbols, fix title
Add {} in after the first if - per Jan's recommendation.
v3: Add Andrew's Review tag
Make the function return an bool_t.
Skip check for '$t'
Fix spelling of comments.
s/arch_is_payload_symbol/arch_livepatch_symbol_ok/
v4: s/bool_t/bool/
v5: Removed an extra space in the conditional.
v6: Added Julien's Acked-by.
s/*sym-name/sym-name[0]/ on the NULL check.
Added Julien's Reviewed-by
---
 xen/arch/arm/livepatch.c| 33 +
 xen/arch/x86/livepatch.c|  7 +++
 xen/common/livepatch.c  |  2 +-
 xen/include/xen/livepatch.h |  2 ++
 4 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 679abf1..f467d9d 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -84,6 +84,39 @@ void arch_livepatch_unmask(void)
 local_abort_enable();
 }
 
+bool arch_livepatch_symbol_ok(const struct livepatch_elf *elf,
+  const struct livepatch_elf_sym *sym)
+{
+/*
+ * - Mapping symbols - denote the "start of a sequence of bytes of the
+ *   appropriate type" to mark certain features - such as start of region
+ *   containing data ($d); ARM ($a), or A64 ($x) instructions.
+ *   We ignore Thumb instructions ($t) as we shouldn't have them.
+ *
+ * The format is either short: '$x' or long: '$x.'. We do not
+ * need this and more importantly - each payload will contain this
+ * resulting in symbol collisions.
+ */
+if ( sym->name[0] == '$' && sym->name[1] != '\0' )
+{
+char p = sym->name[1];
+size_t len = strlen(sym->name);
+
+if ( (len >= 3 && (sym->name[2] == '.' )) || (len == 2) )
+{
+if ( p == 'd' ||
+#ifdef CONFIG_ARM_32
+ p == 'a'
+#else
+ p == 'x'
+#endif
+   )
+return false;
+}
+}
+return true;
+}
+
 int arch_livepatch_perform_rel(struct livepatch_elf *elf,
const struct livepatch_elf_sec *base,
const struct livepatch_elf_sec *rela)
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index b0d81d7..7a369a0 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -124,6 +124,13 @@ int arch_livepatch_verify_elf(const struct livepatch_elf 
*elf)
 return 0;
 }
 
+bool arch_livepatch_symbol_ok(const struct livepatch_elf *elf,
+  const struct livepatch_elf_sym *sym)
+{
+/* No special checks on x86. */
+return true;
+}
+
 int arch_livepatch_perform_rel(struct livepatch_elf *elf,
const struct livepatch_elf_sec *base,
const struct livepatch_elf_sec *rela)
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index 2d08c9a..fc8ef99 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -747,7 +747,7 @@ static bool_t is_payload_symbol(const struct livepatch_elf 
*elf,
  !strncmp(sym->name, ".L", 2) )
 return 0;
 
-return 1;
+return arch_livepatch_symbol_ok(elf, sym);
 }
 
 static int build_symbol_table(struct payload *payload,
diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h
index b7b84e7..e8c67d6 100644
--- a/xen/include/x

Re: [Xen-devel] Question about VPID during MOV-TO-CR3

[Tamas K Lengyel]

On Fri, Sep 23, 2016 at 9:39 AM, Jan Beulich  wrote:
 On 23.09.16 at 17:26,  wrote:
>> On Fri, Sep 23, 2016 at 2:24 AM, Jan Beulich  wrote:
>> On 22.09.16 at 19:18,  wrote:
 So I verified that when CPU-based load exiting is enabled, the TLB
 flush here is critical. Without it the guest kernel crashes at random
 points during boot. OTOH why does Xen trap every guest CR3 update
 unconditionally? While we have features such as the vm_event/monitor
 that may choose to subscribe to that event, Xen traps it even when
 that is not in use. Is that trapping necessary for something else?
>>>
>>> Where do you see this being unconditional? construct_vmcs()
>>> clearly avoids setting these intercepts when using EPT. Are you
>>> perhaps suffering from
>>>
>>> /* Trap CR3 updates if CR3 memory events are enabled. */
>>> if ( v->domain->arch.monitor.write_ctrlreg_enabled &
>>>  monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3) )
>>> v->arch.hvm_vmx.exec_control |= CPU_BASED_CR3_LOAD_EXITING;
>>>
>>> in vmx_update_guest_cr()? That'll be rather something for you
>>> or Razvan to explain. Outside of nested VMX I don't see any
>>> other enabling of that intercept (didn't check AMD code on the
>>> assumption that you're working on Intel hardware).
>>
>> So there seems to be two separate paths that lead to the TLB flushing.
>> One is indeed the above case you cited when we enable CR3 monitoring
>> through the monitor interface. However, during domain boot I also see
>> this path being called that is not related to the
>> CPU_BASED_CR3_LOAD_EXITING:
>>
>> (XEN) hap.c:739:d1v0 hap_update_paging_modes is calling hap_update_cr3
>> (XEN) hap.c:701:d1v0 HAP update cr3 called
>> (XEN) /src/xen/xen/include/asm/hvm/hvm.h:344:d1v0 HVM update guest cr3 called
>> (XEN) vmx.c:1549:d1v0 Update guest CR3 value=0x7a7c4000
>>
>> This path seems to de-activate once the domain is fully booted.
>
> This late? According to the CR0 handling in
> vmx_update_guest_cr() I would understand it to be enabled only
> while the guest is still in real mode (and even then only on old
> hardware, i.e. without the Unrestricted Guest functionality).
>

Right, with unrestricted guest support I would assume none of this
would get called - but it does, and quite frequently during domain
boot. The CPU is a Intel(R) Xeon(R) CPU E5-2430.

Tamas

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

Re: [Xen-devel] [PATCH v5 05/16] livepatch: Initial ARM64 support.

[Konrad Rzeszutek Wilk]

On Fri, Sep 23, 2016 at 02:38:57PM +0100, Ross Lagerwall wrote:
> On 09/21/2016 06:32 PM, Konrad Rzeszutek Wilk wrote:
> snip
> > +
> > +void arch_livepatch_revert(const struct livepatch_func *func)
> > +{
> > +uint32_t *new_ptr;
> > +unsigned int i, len;
> > +
> > +new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
> > +len = livepatch_insn_len(func) / sizeof(uint32_t);
> > +for ( i = 0; i < len; i++ )
> > +{
> > +uint32_t insn;
> > +
> > +memcpy(&insn, func->opaque + (i * sizeof(uint32_t)), 
> > ARCH_PATCH_INSN_SIZE);
> > +/* PATCH! */
> > +*(new_ptr + i) = insn;
> > +}
> 
> Why is this done in a loop? Can't we just memcpy livepatch_insn_len(func)
> bytes into *new_ptr?

It can be. 
> 
> > +}
> > +
> > +int arch_livepatch_verify_elf(const struct livepatch_elf *elf)
> > +{
> > +const Elf_Ehdr *hdr = elf->hdr;
> > +
> > +if ( hdr->e_machine != EM_AARCH64 ||
> > + hdr->e_ident[EI_CLASS] != ELFCLASS64 )
> > +{
> > +dprintk(XENLOG_ERR, LIVEPATCH "%s: Unsupported ELF Machine 
> > type!\n",
> > +elf->name);
> > +return -EOPNOTSUPP;
> > +}
> > +
> > +return 0;
> > +}
> > +
> snip
> >  int arch_livepatch_verify_func(const struct livepatch_func *func)
> >  {
> > -return -ENOSYS;
> > -}
> > +/* If NOPing only do up to maximum amount we can put in the ->opaque. 
> > */
> > +if ( !func->new_addr && func->new_size > sizeof(func->opaque) &&
> > + func->new_size % ARCH_PATCH_INSN_SIZE )
> > +return -EOPNOTSUPP;
> 
> Maybe I'm misunderstanding, but shouldn't this be ( !func->new_addr &&
> (func->new_size > sizeof(func->opaque) || func->new_size %
> ARCH_PATCH_INSN_SIZE) ) ?

Yes!

Here is the updated patch:
From deef8f6921c15a4d07209bfba1fc8697dbfeb605 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Mon, 19 Sep 2016 12:24:09 -0400
Subject: [PATCH v6] livepatch: Initial ARM64 support.

As compared to x86 the va of the hypervisor .text
is locked down - we cannot modify the running pagetables
to have the .ro flag unset. We borrow the same idea that
alternative patching has - which is to vmap the entire
.text region and use the alternative virtual address
for patching.

Since we are doing vmap we may fail, hence the
arch_livepatch_quiesce was changed (see "x86,arm:
Change arch_livepatch_quiesce() declaration") to return
an error value which will be bubbled in payload->rc and
provided to the user (along with messages in the ring buffer).

The livepatch virtual address space (where the new functions
are) needs to be close to the hypervisor virtual address
so that the trampoline can reach it. As such we re-use
the BOOT_RELOC_VIRT_START which is not used after bootup
(alternatively we can also use the space after the _end to
FIXMAP_ADDR(0), but that may be too small).

The ELF relocation engine at the start was coded from
the "ELF for the ARM 64-bit Architecture (AArch64)"
(http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B_aaelf64.pdf)
but after a while of trying to write the correct bit shifting
and masking from scratch I ended up borrowing from Linux, the
'reloc_insn_imm' (Linux v4.7 arch/arm64/kernel/module.c function.
See 257cb251925f854da435cbf79b140984413871ac "arm64: Loadable modules")

And while at it - we also utilize code from Linux to construct
the right branch instruction (see "arm64/insn: introduce
aarch64_insn_gen_{nop|branch_imm}() helper functions").

In the livepatch payload loading code we tweak the #ifdef to
only exclude ARM_32. The exceptions are not part of ARM 32/64 hence
they are still behind the #ifdef.

We also expand the MAINTAINERS file to include the arm64 and arm32
platform specific livepatch file.

Acked-by: Jan Beulich  [non-arm parts]
Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Ross Lagerwall 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc  Jan Beulich 
Cc: Andrew Cooper 

RFC: Wholy cow! It works!
v1: Finished the various TODOs and reviews outlined by Julien in RFC.
v2: Call check_for_livepatch_work in leave_hypervisor_tail not in
reset_stack_and_jump
   - Move ARM 32 components in other patch
   - Blacklist platform options in Kconfig
   - Added R_AARCH64_LDST128_ABS_LO12_NC, R_AARCH64_TSTBR14, and
 R_AARCH64_ADR_PREL_PG_HI21_NC
   - Added do_reloc and reloc_data along with overflow checks from Linux.
   - Use apply_alternatives without any #ifdef
   - Use leave_hypervisor_tail to call check_for_livepatch_work
   - Add ASSERT that isns is not AARCH64_BREAK_FAULT
   - Spun out arch_livepatch_quiesce changes in seperate patch.
   - Spun out changes to config.h (document ones) to seperate patch.
   - Move the livepatch.h to include/xen/asm-arm.
   - Add LIVEPATCH_VMAP_END and LIVEPATCH_VMAP_START in config.h
   - In arch_livepatch_secure use switch for va_type.
   - Drop the #ifndef CONFIG_ARM for .ex_table (see
 "arm/x86: Add HAS_ALTERNATIVE and HAS_EX_TABLE")
   - Piggyback on "x86: change modify_xe

Re: [Xen-devel] Question about VPID during MOV-TO-CR3

[Jan Beulich]

>>> On 23.09.16 at 17:26,  wrote:
> On Fri, Sep 23, 2016 at 2:24 AM, Jan Beulich  wrote:
> On 22.09.16 at 19:18,  wrote:
>>> So I verified that when CPU-based load exiting is enabled, the TLB
>>> flush here is critical. Without it the guest kernel crashes at random
>>> points during boot. OTOH why does Xen trap every guest CR3 update
>>> unconditionally? While we have features such as the vm_event/monitor
>>> that may choose to subscribe to that event, Xen traps it even when
>>> that is not in use. Is that trapping necessary for something else?
>>
>> Where do you see this being unconditional? construct_vmcs()
>> clearly avoids setting these intercepts when using EPT. Are you
>> perhaps suffering from
>>
>> /* Trap CR3 updates if CR3 memory events are enabled. */
>> if ( v->domain->arch.monitor.write_ctrlreg_enabled &
>>  monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3) )
>> v->arch.hvm_vmx.exec_control |= CPU_BASED_CR3_LOAD_EXITING;
>>
>> in vmx_update_guest_cr()? That'll be rather something for you
>> or Razvan to explain. Outside of nested VMX I don't see any
>> other enabling of that intercept (didn't check AMD code on the
>> assumption that you're working on Intel hardware).
> 
> So there seems to be two separate paths that lead to the TLB flushing.
> One is indeed the above case you cited when we enable CR3 monitoring
> through the monitor interface. However, during domain boot I also see
> this path being called that is not related to the
> CPU_BASED_CR3_LOAD_EXITING:
> 
> (XEN) hap.c:739:d1v0 hap_update_paging_modes is calling hap_update_cr3
> (XEN) hap.c:701:d1v0 HAP update cr3 called
> (XEN) /src/xen/xen/include/asm/hvm/hvm.h:344:d1v0 HVM update guest cr3 called
> (XEN) vmx.c:1549:d1v0 Update guest CR3 value=0x7a7c4000
> 
> This path seems to de-activate once the domain is fully booted.

This late? According to the CR0 handling in
vmx_update_guest_cr() I would understand it to be enabled only
while the guest is still in real mode (and even then only on old
hardware, i.e. without the Unrestricted Guest functionality).

Jan


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

Re: [Xen-devel] [PATCH v5 06/16] livepatch: ARM/x86: Check displacement of old_addr and new_addr

[Konrad Rzeszutek Wilk]

On Fri, Sep 23, 2016 at 03:36:27PM +0100, Ross Lagerwall wrote:
> On 09/21/2016 06:32 PM, Konrad Rzeszutek Wilk wrote:
> > If the distance is too big we are in trouble - as our relocation
> > distance can surely be clipped, or still have a valid width - but
> > cause an overflow of distance.
> > 
> > On various architectures the maximum displacement for a unconditional
> > branch/jump varies. ARM32 is +/- 32MB, ARM64 is +/- 128MB while x86
> > for 32-bit relocations is +/- 2G.
> > 
> > Note: On x86 we could use the 64-bit jmpq instruction which
> > would provide much bigger displacement to do a jump, but we would
> > still have issues with the new function not being able to reach
> > any of the old functions (as all the relocations would assume 32-bit
> > displacement). And "furthermore would require an register or
> > memory location to load/store the address to." (From Jan).
> > 
> > On ARM the conditional branch supports even a smaller displacement
> > but fortunately we are not using that.
> 
> Wouldn't this be simpler as a BUILD_BUG_ON() in arch_livepatch_init()?
> 
> Something like BUILD_BUG_ON(((XEN_VIRT_END - NR_CPUS * PAGE_SIZE) -
> XEN_VIRT_START) > ARCH_LIVEPATCH_RANGE)?
> 
> And BUILD_BUG_ON(((XEN_VIRT_END - NR_CPUS * PAGE_SIZE) - XEN_VIRT_START) >
> ARCH_LIVEPATCH_RANGE)
> 
> And something similar for ARM...

What does that have to with the payload? The displacement calculations(checks)
are done when we load the payload.
> 
> -- 
> Ross Lagerwall

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

Re: [Xen-devel] PCI passthrough with stubdomain

[Konrad Rzeszutek Wilk]

On Fri, Sep 23, 2016 at 04:25:41PM +0200, Marek Marczykowski-Górecki wrote:
> On Fri, Sep 23, 2016 at 03:27:07PM +0200, Samuel Thibault wrote:
> > Marek Marczykowski-Górecki, on Fri 23 Sep 2016 10:48:14 +0200, wrote:
> > > I'm still trying to get PCI passthrough working with stubdomain and
> > > without qemu in dom0 (even for just vfb/vkbd backends). How is this
> > > supposed to work?
> > 
> > Just as I recall from my memory:
> > 
> > > 1. Should xen-pcifront in the target domain be used (and consequently,
> > > should xen-pciback be set for it)?
> > 
> > I guess that could work.
> 
> Could, or should? ;)
> 
> In the meantime, I've found this in xen-pcifront driver:
> 
>   static int __init pcifront_init(void)
>   {
>   if (!xen_pv_domain() || xen_initial_domain())
>   return -ENODEV;
> 
> So, it looks like pcifront is not used in PV domain.

You mean in HVM domains.

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

[Xen-devel] [ovmf baseline-only test] 67754: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67754 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67754/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf fe882c01122e7e01e0e78ca8da64630faf9a7b5a
baseline version:
 ovmf 85b88deb18857af261c655dfa833de17b19d7163

Last test of basis67750  2016-09-23 02:47:15 Z0 days
Testing same since67754  2016-09-23 13:48:50 Z0 days1 attempts


People who touched revisions under test:
  Star Zeng 

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.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

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

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


Push not applicable.


commit fe882c01122e7e01e0e78ca8da64630faf9a7b5a
Author: Star Zeng 
Date:   Fri Sep 23 10:04:05 2016 +0800

SecurityPkg Tcg2Pei: Fix GCC build failure caused by 5919a9600e07

Cc: Jiewen Yao 
Cc: Chao B Zhang 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 

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

Re: [Xen-devel] [PATCH v2] x86/apicv: fix RTC periodic timer and apicv issue

[Jan Beulich]

>>> On 20.09.16 at 15:30,  wrote:
> --- a/xen/arch/x86/hvm/vlapic.c
> +++ b/xen/arch/x86/hvm/vlapic.c
> @@ -433,6 +433,12 @@ void vlapic_EOI_set(struct vlapic *vlapic)
>  void vlapic_handle_EOI(struct vlapic *vlapic, u8 vector)
>  {
>  struct domain *d = vlapic_domain(vlapic);
> +struct vcpu *v = vlapic_vcpu(vlapic);
> +struct hvm_intack pt_intack;
> +
> +pt_intack.vector = vector;
> +pt_intack.source = hvm_intsrc_lapic;
> +pt_intr_post(v, pt_intack);

This also sits on the EOI LAPIC register write path, i.e. the change
then also affects non-apicv environments.

Furthermore - don't we have the same problem as with v1 again
then? What prevents multiple EOIs to come here before the timer
interrupt actually gets handled? You'd then clear ->irq_issued
each time, rendering your change to pt_update_irq() ineffective.

In any event please use hvm_intack_lapic() instead of open
coding it (and then I don't think you need a local variable at all).

> --- a/xen/arch/x86/hvm/vmx/intr.c
> +++ b/xen/arch/x86/hvm/vmx/intr.c
> @@ -333,8 +333,6 @@ void vmx_intr_assist(void)
>  clear_bit(i, &v->arch.hvm_vmx.eoi_exitmap_changed);
>  __vmwrite(EOI_EXIT_BITMAP(i), 
> v->arch.hvm_vmx.eoi_exit_bitmap[i]);
>  }
> -
> -pt_intr_post(v, intack);
>  }

I'll defer to the VMX maintainers to determine whether removing this
but not the other one is correct.

> --- a/xen/arch/x86/hvm/vpt.c
> +++ b/xen/arch/x86/hvm/vpt.c
> @@ -252,7 +252,8 @@ int pt_update_irq(struct vcpu *v)
>  }
>  else
>  {
> -if ( (pt->last_plt_gtime + pt->period) < max_lag )
> +if ( (pt->last_plt_gtime + pt->period) < max_lag &&
> + !pt->irq_issued )
>  {
>  max_lag = pt->last_plt_gtime + pt->period;
>  earliest_pt = pt;

Looking at the rest of the code I really wonder why this check
hadn't been there from the beginning. Tim, do recall whether
this was intentional (as opposed to simply having been an
oversight)?

Jan


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

Re: [Xen-devel] Question about VPID during MOV-TO-CR3

[Tamas K Lengyel]

On Fri, Sep 23, 2016 at 2:24 AM, Jan Beulich  wrote:
 On 22.09.16 at 19:18,  wrote:
>> So I verified that when CPU-based load exiting is enabled, the TLB
>> flush here is critical. Without it the guest kernel crashes at random
>> points during boot. OTOH why does Xen trap every guest CR3 update
>> unconditionally? While we have features such as the vm_event/monitor
>> that may choose to subscribe to that event, Xen traps it even when
>> that is not in use. Is that trapping necessary for something else?
>
> Where do you see this being unconditional? construct_vmcs()
> clearly avoids setting these intercepts when using EPT. Are you
> perhaps suffering from
>
> /* Trap CR3 updates if CR3 memory events are enabled. */
> if ( v->domain->arch.monitor.write_ctrlreg_enabled &
>  monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3) )
> v->arch.hvm_vmx.exec_control |= CPU_BASED_CR3_LOAD_EXITING;
>
> in vmx_update_guest_cr()? That'll be rather something for you
> or Razvan to explain. Outside of nested VMX I don't see any
> other enabling of that intercept (didn't check AMD code on the
> assumption that you're working on Intel hardware).

So there seems to be two separate paths that lead to the TLB flushing.
One is indeed the above case you cited when we enable CR3 monitoring
through the monitor interface. However, during domain boot I also see
this path being called that is not related to the
CPU_BASED_CR3_LOAD_EXITING:

(XEN) hap.c:739:d1v0 hap_update_paging_modes is calling hap_update_cr3
(XEN) hap.c:701:d1v0 HAP update cr3 called
(XEN) /src/xen/xen/include/asm/hvm/hvm.h:344:d1v0 HVM update guest cr3 called
(XEN) vmx.c:1549:d1v0 Update guest CR3 value=0x7a7c4000

This path seems to de-activate once the domain is fully booted. So at
this point I'm still not sure if the CPU-based load exiting needs the
flush or not, as I couldn't get the domain to boot when the flush was
simply removed, as this other path does seem to require it. I'll do an
experiment with the tlb flush only happening if the monitor interface
for this is not enabled and see what happens.

Tamas

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

Re: [Xen-devel] [PATCH 02/17] x86emul: fetch all insn bytes during the decode phase

[Jan Beulich]

>>> On 23.09.16 at 16:48,  wrote:
> On 14/09/16 10:55, Jan Beulich wrote:
> On 13.09.16 at 20:44,  wrote:
>>> I would suggest leaving the generate_exception_if(mode_64bit(), EXC_UD,
>>> -1); after the ASSERT() so even if we do end up in a wonky state, we
>>> don't try to jump the guest to 0.
>> That would look really strange to a reader, I think, and hence I'd
>> rather not do this if I can get the patch accepted without.
> 
> It is conceptually no different to
> 
> default:
> ASSERT_UNREACHABLE();
> return;

Except that
- we don't always follow ASSERT_UNREACHABLE() with return (or
  whatever else),
- here we don't risk doing ourselves or the guest anything bad: We'll
  just produce undefined behavior, which is to be expected if we are
  in a "wonky state".

If leaving the exception generation in is the only way to get this
ack-ed, I'll do so, but I'd prefer if I wasn't required to.

Jan


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

Re: [Xen-devel] [PATCH v5 5/5] x86/time: extend "tsc" param with "stable:socket"

[Jan Beulich]

>>> On 23.09.16 at 12:42,  wrote:
> Extend the "tsc" boot parameter is to further relax TSC restrictions and
> allow it to be used on machines that guarantee reliable TSC across
> sockets. This is up to board manufacturers and there's no way for the OS
> to probe this property, therefore user needs to explicitly set this option.
> 
> Also make one style adjustment that is to remove the unnecessary
> parenthesis around clearing TSC_RELIABLE.
> 
> Signed-off-by: Joao Martins 

Reviewed-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v5 15/16] livepatch, arm[32|64]: Share arch_livepatch_revert

[Ross Lagerwall]

On 09/21/2016 06:32 PM, Konrad Rzeszutek Wilk wrote:

It is exactly the same in both platforms.

No functional change.

Acked-by: Julien Grall 
Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Julien Grall 
Cc: Stefano Stabellini 

v3: New submission.
v4: s/arch_livepatch_insn_len/livepatch_insn_len/
s/PATCH_INSN_SIZE/ARCH_PATCH_INSN_SIZE/
v5: Added Julien's Acked-by.
Fixed comments.
  - Rebase on top "livepatch: Drop _jmp from arch_livepatch_[apply,revert]_jmp"
  - s/_jmp//
---
 xen/arch/arm/arm32/livepatch.c | 17 +
 xen/arch/arm/arm64/livepatch.c | 17 +
 xen/arch/arm/livepatch.c   | 17 +
 3 files changed, 19 insertions(+), 32 deletions(-)

diff --git a/xen/arch/arm/arm32/livepatch.c b/xen/arch/arm/arm32/livepatch.c
index 3f47326..7e600f2 100644
--- a/xen/arch/arm/arm32/livepatch.c
+++ b/xen/arch/arm/arm32/livepatch.c
@@ -74,22 +74,7 @@ void arch_livepatch_apply(struct livepatch_func *func)
 clean_and_invalidate_dcache_va_range(func->new_addr, func->new_size);
 }

-void arch_livepatch_revert(const struct livepatch_func *func)
-{
-uint32_t *new_ptr;
-unsigned int i, len;
-
-new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
-len = livepatch_insn_len(func) / sizeof(uint32_t);
-for ( i = 0; i < len; i++ )
-{
-uint32_t insn;
-
-memcpy(&insn, func->opaque + (i * sizeof(uint32_t)), 
ARCH_PATCH_INSN_SIZE);
-/* PATCH! */
-*(new_ptr + i) = insn;
-}
-}
+/* arch_livepatch_revert shared with ARM 32/ARM 64. */

 int arch_livepatch_verify_elf(const struct livepatch_elf *elf)
 {
diff --git a/xen/arch/arm/arm64/livepatch.c b/xen/arch/arm/arm64/livepatch.c
index ea8044d..a7a292f 100644
--- a/xen/arch/arm/arm64/livepatch.c
+++ b/xen/arch/arm/arm64/livepatch.c
@@ -61,22 +61,7 @@ void arch_livepatch_apply(struct livepatch_func *func)
 clean_and_invalidate_dcache_va_range(func->new_addr, func->new_size);
 }

-void arch_livepatch_revert(const struct livepatch_func *func)
-{
-uint32_t *new_ptr;
-unsigned int i, len;
-
-new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
-len = livepatch_insn_len(func) / sizeof(uint32_t);
-for ( i = 0; i < len; i++ )
-{
-uint32_t insn;
-
-memcpy(&insn, func->opaque + (i * sizeof(uint32_t)), 
ARCH_PATCH_INSN_SIZE);
-/* PATCH! */
-*(new_ptr + i) = insn;
-}
-}
+/* arch_livepatch_revert shared with ARM 32/ARM 64. */

 int arch_livepatch_verify_elf(const struct livepatch_elf *elf)
 {
diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 6ee7081..2d62a24 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -69,6 +69,23 @@ int arch_livepatch_verify_func(const struct livepatch_func 
*func)
 return 0;
 }

+void arch_livepatch_revert(const struct livepatch_func *func)
+{
+uint32_t *new_ptr;
+unsigned int i, len;
+
+new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
+len = livepatch_insn_len(func) / sizeof(uint32_t);
+for ( i = 0; i < len; i++ )
+{
+uint32_t insn;
+
+memcpy(&insn, func->opaque + (i * sizeof(uint32_t)), 
ARCH_PATCH_INSN_SIZE);
+/* PATCH! */
+*(new_ptr + i) = insn;
+}
+}
+


Same as previously, can this not be done with a simple memcpy?

--
Ross Lagerwall

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

Re: [Xen-devel] [PATCH v5 3/5] x86/time: implement tsc as clocksource

[Jan Beulich]

>>> On 23.09.16 at 12:42,  wrote:
> Recent x86/time changes improved a lot of the monotonicity in xen
> timekeeping, making it much harder to observe time going backwards.
> Although platform timer can't be expected to be perfectly in sync with
> TSC and so get_s_time won't be guaranteed to always return
> monotonically increasing values across cpus. This is the case in some
> of the boxes I am testing with, observing sometimes ~100 warps (of
> very few nanoseconds each) after a few hours.
> 
> This patch introduces support for using TSC as platform time source
> which is the highest resolution time and most performant to get.
> Though there are also several problems associated with its usage, and
> there isn't a complete (and architecturally defined) guarantee that
> all machines will provide reliable and monotonic TSC in all cases (I
> believe Intel to be the only that can guarantee that?). For this reason
> it's not used unless administrator changes "clocksource" boot option
> to "tsc". Initializing TSC clocksource requires all CPUs up to have
> the tsc reliability checks performed. init_xen_time is called before
> all CPUs are up, so for example we would start with HPET (or ACPI,
> PIT) at boot time, and switch later to TSC. The switch then happens on
> verify_tsc_reliability initcall that is invoked when all CPUs are up.
> When attempting to initialize TSC we also check for time warps and if
> it has invariant TSC. Note that while we deem reliable a CONSTANT_TSC
> with no deep C-states, it might not always be the case, so we're
> conservative and allow TSC to be used as platform timer only with
> invariant TSC. Additionally we check if CPU Hotplug isn't meant to be
> performed on the host which will either be when max vcpus and
> num_present_cpu are the same. This is because a newly hotplugged CPU
> may not satisfy the condition of having all TSCs synchronized - so
> when having tsc clocksource being used we allow offlining CPUs but not
> onlining any ones back. Finally we prevent TSC from being used as
> clocksource on multiple sockets because it isn't guaranteed to be
> invariant. Further relaxing of this last requirement is added in a
> separate patch, such that we allow vendors with such guarantee to use
> TSC as clocksource. In case any of these conditions is not met, we
> keep the clocksource that was previously initialized on init_xen_time.
> 
> Since b64438c7c ("x86/time: use correct (local) time stamp in
> constant-TSC calibration fast path") updates to cpu time use local
> stamps, which means platform timer is only used to seed the initial
> cpu time. We further introduce a new rendezvous function
> (nop_rendezvous) which doesn't require synchronization between master
> and slave CPUS and just reads calibration_rendezvous struct and writes
> it down the stime and stamp to the cpu_calibration struct to be used
> later on. With clocksource=tsc there is no need to be in sync with
> another clocksource, so we reseed the local/master stamps to be values
> of TSC and update the platform time stamps accordingly. Time
> calibration is set to 1sec after we switch to TSC, thus these stamps
> are reseeded to also ensure monotonic returning values right after the
> point we switch to TSC. This is to remove the possibility of having
> inconsistent readings in this short period (i.e. until calibration
> fires).
> 
> Signed-off-by: Joao Martins 

Reviewed-by: Jan Beulich 

with one further adjustment (no need to re-send):

> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -264,9 +264,13 @@ minimum of 32M, subject to a suitably aligned and sized 
> contiguous
>  region of memory being available.
>  
>  ### clocksource
> -> `= pit | hpet | acpi`
> +> `= pit | hpet | acpi | tsc`
>  
>  If set, override Xen's default choice for the platform timer.
> +Having TSC as platform timer requires being explicitly set. This is because
> +TSC can only be safely used if CPU hotplug isn't performed on the system. In
> +some platforms, "maxcpus" parameter may require further adjustment to the
> +number of online cpus.

I think I'll re-write this last sentence to "On some platforms,
the "maxcpus" option may need to be used to further adjust the
number of allowed CPUs."

Jan

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

Re: [Xen-devel] [PATCH v5 09/16] livepatch: Move test-cases to their own sub-directory in test.

[Ross Lagerwall]

On 09/21/2016 06:32 PM, Konrad Rzeszutek Wilk wrote:

So they can be shared with ARM64 (but not yet, so they
are only built on x86).

No functional change.

We also need to tweak the MAINTAINERS and .gitignore file.

Also we need to update SUBDIRS to include the new 'test'
directory so 'cscope' can show the example livepatches.

Acked-by: Jan Beulich  [for directory]
Signed-off-by: Konrad Rzeszutek Wilk 



Reviewed-by: Ross Lagerwall 

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

Re: [Xen-devel] PCI passthrough with stubdomain

[Samuel Thibault]

Marek Marczykowski-Górecki, on Fri 23 Sep 2016 16:25:41 +0200, wrote:
> On Fri, Sep 23, 2016 at 03:27:07PM +0200, Samuel Thibault wrote:
> > Marek Marczykowski-Górecki, on Fri 23 Sep 2016 10:48:14 +0200, wrote:
> > > I'm still trying to get PCI passthrough working with stubdomain and
> > > without qemu in dom0 (even for just vfb/vkbd backends). How is this
> > > supposed to work?
> > 
> > Just as I recall from my memory:
> > 
> > > 1. Should xen-pcifront in the target domain be used (and consequently,
> > > should xen-pciback be set for it)?
> > 
> > I guess that could work.
> 
> Could, or should? ;)

I don't really remember, actually. I do remember doing some passthrough
tests, but I don't remember the exact conditions.

> In the meantime, I've found this in xen-pcifront driver:
> 
>   static int __init pcifront_init(void)
>   {
>   if (!xen_pv_domain() || xen_initial_domain())
>   return -ENODEV;
> 
> So, it looks like pcifront is not used in PV domain.

? I read it as disabling pcifront when used in an HVM or native domain,
i.e. precisely used in PV domains.

> > So the unfortunate thing is that when using stubdom, you'd have to set
> > the pciback either on the guest (to run a PV driver in it), or on the
> > stubdom (to run a plain driver in the guest, and let mini-os use PV to
> > let qemu pass the board through)
> 
> I've tried only on Linux HVM guest and as noted above xen-pcifront
> doesn't look to be involved. Is it any different on other OSes?

I don't know, perhaps it's different on windows. Or perhaps for windows
we just rely on the qemu pass-through.

> Toolstack during (stub)domain startup setup two things, mostly
> asynchronously:
> 1. pciback/pcifront (through standard xenstore entries)
> 2. instruct qemu to attach device (by writing "pci-ins" to
> device-model/xxx/command)

Ah, since pcifront_watches runs in a separate thread, it may not have
called init_pcifront before qemu calls libpci, i.e. pcifront_scan.

I'd say that's where the fix should be: make pcifront_scan wait for
init_pcifront to be done.  It's however not so simple: we want to make
pcifront_scan do nothing if no pciback is to be launched. My memory is
rusty: is there something we are sure will show up in the xenstore when
a pciback is to be launched?  If so, pcifront_scan could do this: wait
for pcifront_watches to have checked for the potential presence of
pciback. If pciback is not to be started, just do nothing; if pciback is
to be started, wait for init_pcifront to have been called by
pcifront_watches. Then it will find the devices.

Samuel

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

Re: [Xen-devel] [PATCH v5 08/16] livepatch/arm/x86: Check payload for for unwelcomed symbols.

[Ross Lagerwall]

On 09/21/2016 06:32 PM, Konrad Rzeszutek Wilk wrote:

Certain platforms, such as ARM [32|64] add extra mapping symbols
such as $x (for ARM64 instructions), or more interesting to
this patch: $t (for Thumb instructions). These symbols are suppose
to help the final linker to make any adjustments (such as
add an veneer). But more importantly - we do not compile Xen
with any Thumb instructions (which are variable length) - and
if we find these mapping symbols we should disallow such payload.

Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Konrad Rzeszutek Wilk 
Cc: Ross Lagerwall 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Andrew Cooper 

v3: New submission.
Use &sym[i] instead of sym (as that will always be NULL).
v4: Use bool instead of int for return
Update comment in common code about ARM odd symbols.
s/_check/_deny/ to make it more clear.
v5: Also check for $t.* wildcard.
Use Julien's variant where we roll the [2] check in the return.
---
 xen/arch/arm/livepatch.c| 16 
 xen/arch/x86/livepatch.c|  7 +++
 xen/common/livepatch_elf.c  |  7 +++
 xen/include/xen/livepatch.h |  2 ++
 4 files changed, 32 insertions(+)

diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 9959315..5a99ab5 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -117,6 +117,22 @@ bool arch_livepatch_symbol_ok(const struct livepatch_elf 
*elf,
 return true;
 }

+bool arch_livepatch_symbol_deny(const struct livepatch_elf *elf,
+const struct livepatch_elf_sym *sym)
+{
+#ifdef CONFIG_ARM_32
+/*
+ * Xen does not use Thumb instructions - and we should not see any of
+ * them. If we do, abort.
+ */
+if ( sym->name && sym->name[0] == '$' && sym->name[1] == 't' )
+{
+return ( !sym->name[2] || sym->name[2] == '.' );
+}
+#endif
+return false;
+}
+
 int arch_livepatch_perform_rel(struct livepatch_elf *elf,
const struct livepatch_elf_sec *base,
const struct livepatch_elf_sec *rela)
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index 7a369a0..9663ef6 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -131,6 +131,13 @@ bool arch_livepatch_symbol_ok(const struct livepatch_elf 
*elf,
 return true;
 }

+bool arch_livepatch_symbol_deny(const struct livepatch_elf *elf,
+const struct livepatch_elf_sym *sym)
+{
+/* No special checks on x86. */
+return false;
+}
+
 int arch_livepatch_perform_rel(struct livepatch_elf *elf,
const struct livepatch_elf_sec *base,
const struct livepatch_elf_sec *rela)
diff --git a/xen/common/livepatch_elf.c b/xen/common/livepatch_elf.c
index f46990e..ec74beb 100644
--- a/xen/common/livepatch_elf.c
+++ b/xen/common/livepatch_elf.c
@@ -251,6 +251,13 @@ static int elf_get_sym(struct livepatch_elf *elf, const 
void *data)

 sym[i].sym = s;
 sym[i].name = strtab_sec->data + delta;
+/* e.g. On ARM we should NEVER see $t* symbols. */


I'd prefer this comment in ARM's arch_livepatch_symbol_deny.

Either way,
Reviewed-by: Ross Lagerwall 

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

Re: [Xen-devel] [PATCH 02/17] x86emul: fetch all insn bytes during the decode phase

[Andrew Cooper]

On 14/09/16 10:55, Jan Beulich wrote:

On 13.09.16 at 20:44,  wrote:

On 08/09/16 14:07, Jan Beulich wrote:

@@ -1602,6 +1602,45 @@ struct x86_emulate_state {
  #define _regs (state->regs)
  
  static int

+x86_decode_base(

What do you mean by decode_base here?

The base instruction set (no 0f or alike prefixes). Suggestions for
a better name welcome.


x86_decode_onebyte() to match the table of opcodes it is further decoding.




@@ -2644,18 +2704,13 @@ x86_emulate(
  
  case 0x9a: /* call (far, absolute) */ {

  struct segment_register reg;
-uint16_t sel;
-uint32_t eip;
  
-generate_exception_if(mode_64bit(), EXC_UD, -1);

+ASSERT(!mode_64bit());

Are we going to strictly require that noone ever hand-crafts a
x86_emulate_state and hands it to x86_emulate()?

Absolutely - that's why its definition does not live in a header.


Ok.




I would suggest leaving the generate_exception_if(mode_64bit(), EXC_UD,
-1); after the ASSERT() so even if we do end up in a wonky state, we
don't try to jump the guest to 0.

That would look really strange to a reader, I think, and hence I'd
rather not do this if I can get the patch accepted without.


It is conceptually no different to

default:
ASSERT_UNREACHABLE();
return;

~Andrew

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

Re: [Xen-devel] [PATCH v5 03/21] acpi: Prevent GPL-only code from seeping into non-GPL binaries

[Boris Ostrovsky]

On 09/23/2016 10:38 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [PATCH v5 03/21] acpi: Prevent GPL-only code 
> from seeping into non-GPL binaries"):
>> On 09/23/2016 10:24 AM, Ian Jackson wrote:
>>> But really, why not make this (or most of it) a here document (ie with
>>> <<) ?  
>> Sorry, I don't follow this. What is a "here document"?
> It's a redirection from a literal, introduced with <<.

Ah. I've never heard "here document" term.

-boris

>
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_04
>
> You probably want the version that looks like this  <<'END'
> as it doesn't do interpolation on the literal text, rather than the
> version without the single quotes (which _does_ do interpolation
> of $ and `.)
>
> Ian.


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

Re: [Xen-devel] [PATCH v5 07/16] livepatch: ARM 32|64: Ignore mapping symbols: $[d, a, x]

[Ross Lagerwall]

On 09/21/2016 06:32 PM, Konrad Rzeszutek Wilk wrote:

Those symbols are used to help final linkers to replace insn.
The ARM ELF specification mandates that they are present
to denote the start of certain CPU features. There are two
variants of it - short and long format.

Either way - we can ignore these symbols.

Reviewed-by: Andrew Cooper  [x86 bits]
Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Konrad Rzeszutek Wilk 
Cc: Ross Lagerwall 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Andrew Cooper 

v1: First submission
v2: Update the order of symbols, fix title
Add {} in after the first if - per Jan's recommendation.
v3: Add Andrew's Review tag
Make the function return an bool_t.
Skip check for '$t'
Fix spelling of comments.
s/arch_is_payload_symbol/arch_livepatch_symbol_ok/
v4: s/bool_t/bool/
v5: Removed an extra space in the conditional.
---
 xen/arch/arm/livepatch.c| 33 +
 xen/arch/x86/livepatch.c|  7 +++
 xen/common/livepatch.c  |  2 +-
 xen/include/xen/livepatch.h |  2 ++
 4 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 9284766..9959315 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -84,6 +84,39 @@ void arch_livepatch_unmask(void)
 local_abort_enable();
 }

+bool arch_livepatch_symbol_ok(const struct livepatch_elf *elf,
+  const struct livepatch_elf_sym *sym)
+{
+/*
+ * - Mapping symbols - denote the "start of a sequence of bytes of the
+ *   appropriate type" to mark certain features - such as start of region
+ *   containing data ($d); ARM ($a), or A64 ($x) instructions.
+ *   We ignore Thumb instructions ($t) as we shouldn't have them.
+ *
+ * The format is either short: '$x' or long: '$x.'. We do not
+ * need this and more importantly - each payload will contain this
+ * resulting in symbol collisions.
+ */
+if ( *sym->name == '$' && sym->name[1] != '\0' )


This would be clear (IMO) as sym->name[0].

Either way,

Reviewed-by: Ross Lagerwall 

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

Re: [Xen-devel] [PATCH v5 03/21] acpi: Prevent GPL-only code from seeping into non-GPL binaries

[Jan Beulich]

>>> On 23.09.16 at 16:23,  wrote:
> On 09/23/2016 05:18 AM, Jan Beulich wrote:
>>
>>> @@ -36,18 +37,25 @@ ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl 
>>> iasl
>>>  mk_dsdt: mk_dsdt.c
>>> $(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
>>>  
>>> -dsdt_anycpu_qemu_xen.asl: dsdt.asl dsdt_acpi_info.asl mk_dsdt
>>> +ifeq ($(GPL),y)
>>> +dsdt_anycpu_qemu_xen.asl: dsdt.asl dsdt_acpi_info.asl gpl/mk_dsdt_gpl.sh 
>>> mk_dsdt
>>> awk 'NR > 1 {print s} {s=$$0}' $< > $@.$(TMP_SUFFIX)
>>> +   # Strip license comment
>>> +   sed -i '1,/\*\//{/\/\*/,/\*\//d}' $@.$(TMP_SUFFIX)
>>> +   ./gpl/mk_dsdt_gpl.sh >> $@.$(TMP_SUFFIX)
>> I don't think the leading ./ is necessary here, ...
>>
>>> cat dsdt_acpi_info.asl >> $@.$(TMP_SUFFIX)
>>> ./mk_dsdt --debug=$(debug) --dm-version qemu-xen >> $@.$(TMP_SUFFIX)
>> ... other than e.g. here.
> 
> What is the difference between the two?

The latter would then lack any directory components, and hence
would become subject to lookup through $PATH, which would fail
if . is not included in it (and which would possibly do the wrong
thing even if it was).

>>> --- /dev/null
>>> +++ b/tools/firmware/hvmloader/acpi/gpl/mk_dsdt_gpl.sh
>>> @@ -0,0 +1,110 @@
>>> +# 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 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 .
>>> +#
>>> +
>>> +printf "\n/* Beginning of GPL-only code */\n\n"
>>> +
>>> +printf "/* _S3 and _S4 are in separate SSDTs */\n"
>>> +printf "Name (\_S5, Package (0x04) {\n"
>>> +printf "0x00,  /* PM1a_CNT.SLP_TYP */\n"
>>> +printf "0x00,  /* PM1b_CNT.SLP_TYP */\n"
>>> +printf "0x00,  /* reserved */\n"
>>> +printf "0x00   /* reserved */\n"
>>> +printf "})\n"
>>> +
>>> +printf "Name(PICD, 0)\n"
>>> +printf "Method(_PIC, 1) {\n"
>>> +printf "Store(Arg0, PICD)\n"
>>> +printf "}\n"
>> Wouldn't this be better readable with "echo", avoiding all the \n
>> instances? Actually this seems to even apply to most if not
>> everything further down, as so far I didn't spot a case where
>> you actually pass anything other than just a format string.
> 
> Format string is the only reason. There are a couple of instances where
> output is formatted and I felt that having both echo and printf would
> feel inconsistent.

Hmm, I think avoiding the many \n would warrant this slight
inconsistency.

>>> +# PCI-ISA link definitions
>>> +
>>> +# BUFA: List of ISA IRQs available for linking to PCI INTx.
>>> +printf "Scope ( \_SB.PCI0 )  {\n"
>>> +printf "Name ( BUFA, ResourceTemplate() { IRQ(Level, ActiveLow, 
>>> Shared) { 5, 10, 11 } } )\n"
>>> +# BUFB: IRQ descriptor for returning from link-device _CRS methods.
>>> +printf "Name ( BUFB, Buffer() { 0x23, 0x00, 0x00, 0x18, 0x79, 0 } 
>>> )\n"
>>> +printf "CreateWordField ( BUFB, 0x01, IRQV )\n"
>>> +
>>> +links=(A B C D)
>> Is this portable?
> 
> I heard that associative arrays sometimes have portability issues but
> this is a regular one. FWIW this runs on a 2009 Fedora12.
> 
> Would 'declare -a links' help?

I don't know - honestly I'm not a shell script expert. All I can say is
that I wasn't able to find the construct above e.g. in SUS v6.

Jan


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

Re: [Xen-devel] [PATCH v5 03/21] acpi: Prevent GPL-only code from seeping into non-GPL binaries

[Ian Jackson]

Boris Ostrovsky writes ("Re: [PATCH v5 03/21] acpi: Prevent GPL-only code from 
seeping into non-GPL binaries"):
> On 09/23/2016 10:24 AM, Ian Jackson wrote:
> > But really, why not make this (or most of it) a here document (ie with
> > <<) ?  
> 
> Sorry, I don't follow this. What is a "here document"?

It's a redirection from a literal, introduced with <<.

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_04

You probably want the version that looks like this  <<'END'
as it doesn't do interpolation on the literal text, rather than the
version without the single quotes (which _does_ do interpolation
of $ and `.)

Ian.

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

Re: [Xen-devel] [PATCH v5 06/16] livepatch: ARM/x86: Check displacement of old_addr and new_addr

[Ross Lagerwall]

On 09/21/2016 06:32 PM, Konrad Rzeszutek Wilk wrote:

If the distance is too big we are in trouble - as our relocation
distance can surely be clipped, or still have a valid width - but
cause an overflow of distance.

On various architectures the maximum displacement for a unconditional
branch/jump varies. ARM32 is +/- 32MB, ARM64 is +/- 128MB while x86
for 32-bit relocations is +/- 2G.

Note: On x86 we could use the 64-bit jmpq instruction which
would provide much bigger displacement to do a jump, but we would
still have issues with the new function not being able to reach
any of the old functions (as all the relocations would assume 32-bit
displacement). And "furthermore would require an register or
memory location to load/store the address to." (From Jan).

On ARM the conditional branch supports even a smaller displacement
but fortunately we are not using that.


Wouldn't this be simpler as a BUILD_BUG_ON() in arch_livepatch_init()?

Something like BUILD_BUG_ON(((XEN_VIRT_END - NR_CPUS * PAGE_SIZE) - 
XEN_VIRT_START) > ARCH_LIVEPATCH_RANGE)?


And BUILD_BUG_ON(((XEN_VIRT_END - NR_CPUS * PAGE_SIZE) - XEN_VIRT_START) 
> ARCH_LIVEPATCH_RANGE)


And something similar for ARM...

--
Ross Lagerwall

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

Re: [Xen-devel] [PATCH v5 03/21] acpi: Prevent GPL-only code from seeping into non-GPL binaries

[Boris Ostrovsky]

On 09/23/2016 10:24 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [PATCH v5 03/21] acpi: Prevent GPL-only code 
> from seeping into non-GPL binaries"):
 +printf "\n/* Beginning of GPL-only code */\n\n"
 +
 +printf "/* _S3 and _S4 are in separate SSDTs */\n"
 +printf "Name (\_S5, Package (0x04) {\n"
 +printf "0x00,  /* PM1a_CNT.SLP_TYP */\n"
 +printf "0x00,  /* PM1b_CNT.SLP_TYP */\n"
 +printf "0x00,  /* reserved */\n"
 +printf "0x00   /* reserved */\n"
 +printf "})\n"
 +
 +printf "Name(PICD, 0)\n"
 +printf "Method(_PIC, 1) {\n"
 +printf "Store(Arg0, PICD)\n"
 +printf "}\n"
>>> Wouldn't this be better readable with "echo", avoiding all the \n
>>> instances? Actually this seems to even apply to most if not
>>> everything further down, as so far I didn't spot a case where
>>> you actually pass anything other than just a format string.
>> Format string is the only reason. There are a couple of instances where
>> output is formatted and I felt that having both echo and printf would
>> feel inconsistent.
> I don't think there is anything wrong with inconsistency.
>
> But really, why not make this (or most of it) a here document (ie with
> <<) ?  

Sorry, I don't follow this. What is a "here document"?

-boris

> That would remove a lot of the quoting clutter (and would also
> avoid any bugs where shell metacharacters or printf metacharacters are
> unintentionally written unquoted).
>
> Ian.


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

Re: [Xen-devel] [OSSTEST PATCH] TestSupport: use qemu-img to create vhd image

[Wei Liu]

On Fri, Sep 23, 2016 at 03:21:35PM +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: [OSSTEST PATCH] TestSupport: use qemu-img to create 
> vhd image"):
> > FAOD, I haven't dropped this.  This patch LGTM.
> > 
> > Acked-by: Ian Jackson 
> > 
> > I have queued it for a push at some point.  Right now there's a d-i
> > update in the pipeline ahead of it.
> 
> Well, it did this:
> 
>   ++ ./make-flight osstest xen-unstable real
>   No such class disk_mb_s at Osstest/TestSupport.pm line 1764, near "my 
> disk_mb_s"
>   syntax error at Osstest/TestSupport.pm line 1764, near "my disk_mb_s ="
>   Global symbol "$disk_mb_s" requires explicit package name at 
> Osstest/TestSupport.pm line 1765.
>   BEGIN not safe after errors--compilation aborted at Osstest/TestSupport.pm 
> line 1812.
>   Compilation failed in require at Osstest/JobDB/Executive.pm line 24.
>   BEGIN failed--compilation aborted at Osstest/JobDB/Executive.pm line 24.
>   Compilation failed in require at (eval 18) line 2.
>   + flight=
> 
> This is because of a missing dollar sign.  I will fix it up and retry.
> 

Oops... Sorry about that and thanks for fixing that up.

> Ian.

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

Re: [Xen-devel] PCI passthrough with stubdomain

[Marek Marczykowski-Górecki]

On Fri, Sep 23, 2016 at 03:27:07PM +0200, Samuel Thibault wrote:
> Marek Marczykowski-Górecki, on Fri 23 Sep 2016 10:48:14 +0200, wrote:
> > I'm still trying to get PCI passthrough working with stubdomain and
> > without qemu in dom0 (even for just vfb/vkbd backends). How is this
> > supposed to work?
> 
> Just as I recall from my memory:
> 
> > 1. Should xen-pcifront in the target domain be used (and consequently,
> > should xen-pciback be set for it)?
> 
> I guess that could work.

Could, or should? ;)

In the meantime, I've found this in xen-pcifront driver:

static int __init pcifront_init(void)
{
if (!xen_pv_domain() || xen_initial_domain())
return -ENODEV;

So, it looks like pcifront is not used in PV domain.

> > Currently xen-pciback is set for both
> > stubdomain and target domain, which presents a race condition and
> > xen-pciback refuses to setup one of them.
> 
> Yes, that's expected, for the reason you say.

In the meantime I've tried to modify libxl to not setup pciback for
target domain. This, along with other modifications (see below) improved
the situation.

> * to summarize
> **
>
> If running PV drivers in the guest, you set the pciback on the guest, be
> it run with stubdom or not. 
> If running plain drivers in the guest,
>   * when not using a stubdom you don't need to set a pciback.
>   * when using a stubdom you need to set a pciback on the stubdom.

Thanks for the explanation!

> So the unfortunate thing is that when using stubdom, you'd have to set
> the pciback either on the guest (to run a PV driver in it), or on the
> stubdom (to run a plain driver in the guest, and let mini-os use PV to
> let qemu pass the board through)

I've tried only on Linux HVM guest and as noted above xen-pcifront
doesn't look to be involved. Is it any different on other OSes?

As for getting PCI passthrough working with stubdomain, for now I hit
those problems:
1. getdomaininfo not allowed from stubdomain (already fixed in master),
2. double setup of pciback (explained above) - for now I've disabled one
of them,
3. race condition between pcifront in mini-os and qemu.

Regarding the last one:
Toolstack during (stub)domain startup setup two things, mostly
asynchronously:
1. pciback/pcifront (through standard xenstore entries)
2. instruct qemu to attach device (by writing "pci-ins" to
device-model/xxx/command)

The later fails if pcifront is not initialized yet. For now I've moved
the second step to be really after the first one, including
synchronization through libxl__wait_for_backend call. 
Is it ok? Or maybe it should be done on stubdomain side (handling
"pci-ins" should wait on pcifront)? I guess the same will apply to
qemu-xen case, or any other stubdomain, so probably better have it in
toolstack, right?

Work-in-progress patches attached. The result is that lspci inside the
guest finally list the device. No idea if it's really working yet.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
From b8a34904411cc6e7a7abdc6296657ff5f3eb92e9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
 
Date: Thu, 22 Sep 2016 16:07:14 +0200
Subject: [PATCH 1/2] libxl: attach xen-pciback only to stubdomain
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Organization: Invisible Things Lab
Cc: Marek Marczykowski-Górecki 

Signed-off-by: Marek Marczykowski-Górecki 
---
 tools/libxl/libxl_create.c | 2 +-
 tools/libxl/libxl_pci.c| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index c6862b8..5625ef2 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1429,7 +1429,7 @@ static void domcreate_attach_pci(libxl__egc *egc, 
libxl__multidev *multidev,
 }
 }
 
-if (d_config->num_pcidevs > 0) {
+if (d_config->num_pcidevs > 0 && d_config->c_info.type == 
LIBXL_DOMAIN_TYPE_PV) {
 ret = libxl__create_pci_backend(gc, domid, d_config->pcidevs,
 d_config->num_pcidevs);
 if (ret < 0) {
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 19c597e..2942772 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1001,7 +1001,7 @@ out:
 }
 }
 
-if (!starting)
+if (!starting && !hvm)
 rc = libxl__device_pci_add_xenstore(gc, domid, pcidev, starting);
 else
 rc = 0;
-- 
2.5.5

From 930398583d5a590c511e58057d000e1ed7defb82 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
 
Date: Fri, 23 Sep 2016 16:13:37 +0200
Subject: [PATCH 2/2] libxl: attach PCI device to qemu only after setting
 pciback/pcifront
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Organization: Invisible Things Lab
Cc: Marek Marcz

Re: [Xen-devel] [PATCH v5 03/21] acpi: Prevent GPL-only code from seeping into non-GPL binaries

[Ian Jackson]

Boris Ostrovsky writes ("Re: [PATCH v5 03/21] acpi: Prevent GPL-only code from 
seeping into non-GPL binaries"):
> >> +printf "\n/* Beginning of GPL-only code */\n\n"
> >> +
> >> +printf "/* _S3 and _S4 are in separate SSDTs */\n"
> >> +printf "Name (\_S5, Package (0x04) {\n"
> >> +printf "0x00,  /* PM1a_CNT.SLP_TYP */\n"
> >> +printf "0x00,  /* PM1b_CNT.SLP_TYP */\n"
> >> +printf "0x00,  /* reserved */\n"
> >> +printf "0x00   /* reserved */\n"
> >> +printf "})\n"
> >> +
> >> +printf "Name(PICD, 0)\n"
> >> +printf "Method(_PIC, 1) {\n"
> >> +printf "Store(Arg0, PICD)\n"
> >> +printf "}\n"
> > Wouldn't this be better readable with "echo", avoiding all the \n
> > instances? Actually this seems to even apply to most if not
> > everything further down, as so far I didn't spot a case where
> > you actually pass anything other than just a format string.
> 
> Format string is the only reason. There are a couple of instances where
> output is formatted and I felt that having both echo and printf would
> feel inconsistent.

I don't think there is anything wrong with inconsistency.

But really, why not make this (or most of it) a here document (ie with
<<) ?  That would remove a lot of the quoting clutter (and would also
avoid any bugs where shell metacharacters or printf metacharacters are
unintentionally written unquoted).

Ian.

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

Re: [Xen-devel] [OSSTEST PATCH] TestSupport: use qemu-img to create vhd image

[Ian Jackson]

Ian Jackson writes ("Re: [OSSTEST PATCH] TestSupport: use qemu-img to create 
vhd image"):
> FAOD, I haven't dropped this.  This patch LGTM.
> 
> Acked-by: Ian Jackson 
> 
> I have queued it for a push at some point.  Right now there's a d-i
> update in the pipeline ahead of it.

Well, it did this:

  ++ ./make-flight osstest xen-unstable real
  No such class disk_mb_s at Osstest/TestSupport.pm line 1764, near "my 
disk_mb_s"
  syntax error at Osstest/TestSupport.pm line 1764, near "my disk_mb_s ="
  Global symbol "$disk_mb_s" requires explicit package name at 
Osstest/TestSupport.pm line 1765.
  BEGIN not safe after errors--compilation aborted at Osstest/TestSupport.pm 
line 1812.
  Compilation failed in require at Osstest/JobDB/Executive.pm line 24.
  BEGIN failed--compilation aborted at Osstest/JobDB/Executive.pm line 24.
  Compilation failed in require at (eval 18) line 2.
  + flight=

This is because of a missing dollar sign.  I will fix it up and retry.

Ian.

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

Re: [Xen-devel] [PATCH v5 03/21] acpi: Prevent GPL-only code from seeping into non-GPL binaries

[Boris Ostrovsky]

On 09/23/2016 05:18 AM, Jan Beulich wrote:
>
>> @@ -36,18 +37,25 @@ ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
>>  mk_dsdt: mk_dsdt.c
>>  $(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
>>  
>> -dsdt_anycpu_qemu_xen.asl: dsdt.asl dsdt_acpi_info.asl mk_dsdt
>> +ifeq ($(GPL),y)
>> +dsdt_anycpu_qemu_xen.asl: dsdt.asl dsdt_acpi_info.asl gpl/mk_dsdt_gpl.sh 
>> mk_dsdt
>>  awk 'NR > 1 {print s} {s=$$0}' $< > $@.$(TMP_SUFFIX)
>> +# Strip license comment
>> +sed -i '1,/\*\//{/\/\*/,/\*\//d}' $@.$(TMP_SUFFIX)
>> +./gpl/mk_dsdt_gpl.sh >> $@.$(TMP_SUFFIX)
> I don't think the leading ./ is necessary here, ...
>
>>  cat dsdt_acpi_info.asl >> $@.$(TMP_SUFFIX)
>>  ./mk_dsdt --debug=$(debug) --dm-version qemu-xen >> $@.$(TMP_SUFFIX)
> ... other than e.g. here.

What is the difference between the two?

>
> Also I think shell scripts get better invoked via $(SHELL), to avoid
> running into problems when on some file system they end up without
> execute permission.
>
>> --- /dev/null
>> +++ b/tools/firmware/hvmloader/acpi/gpl/mk_dsdt_gpl.sh
>> @@ -0,0 +1,110 @@
>> +# 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 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 .
>> +#
>> +
>> +printf "\n/* Beginning of GPL-only code */\n\n"
>> +
>> +printf "/* _S3 and _S4 are in separate SSDTs */\n"
>> +printf "Name (\_S5, Package (0x04) {\n"
>> +printf "0x00,  /* PM1a_CNT.SLP_TYP */\n"
>> +printf "0x00,  /* PM1b_CNT.SLP_TYP */\n"
>> +printf "0x00,  /* reserved */\n"
>> +printf "0x00   /* reserved */\n"
>> +printf "})\n"
>> +
>> +printf "Name(PICD, 0)\n"
>> +printf "Method(_PIC, 1) {\n"
>> +printf "Store(Arg0, PICD)\n"
>> +printf "}\n"
> Wouldn't this be better readable with "echo", avoiding all the \n
> instances? Actually this seems to even apply to most if not
> everything further down, as so far I didn't spot a case where
> you actually pass anything other than just a format string.

Format string is the only reason. There are a couple of instances where
output is formatted and I felt that having both echo and printf would
feel inconsistent.

>
>> +# PCI-ISA link definitions
>> +
>> +# BUFA: List of ISA IRQs available for linking to PCI INTx.
>> +printf "Scope ( \_SB.PCI0 )  {\n"
>> +printf "Name ( BUFA, ResourceTemplate() { IRQ(Level, ActiveLow, 
>> Shared) { 5, 10, 11 } } )\n"
>> +# BUFB: IRQ descriptor for returning from link-device _CRS methods.
>> +printf "Name ( BUFB, Buffer() { 0x23, 0x00, 0x00, 0x18, 0x79, 0 } 
>> )\n"
>> +printf "CreateWordField ( BUFB, 0x01, IRQV )\n"
>> +
>> +links=(A B C D)
> Is this portable?

I heard that associative arrays sometimes have portability issues but
this is a regular one. FWIW this runs on a 2009 Fedora12.

Would 'declare -a links' help?

>
>> +for i in `seq 0 3`;
>> +do
> I think you want to use only one of ; and newline as separator here.
> And is there a reason to prefer backquotes over the imo better
> legible $()?

No reason, that's the style I usually use. I can change to $() if that's
the preferred one.

(I will resend this patch only to avoid spamming everyone with 20
already-acked patches)

-boris


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

Re: [Xen-devel] [PATCH v3 4/6] Pause/Unpause the domain before/after assigning PI hooks

[Jan Beulich]

>>> On 02.09.16 at 15:15,  wrote:
> And that is another reason I use pause/unpause here, it can address
> all the races. And this is an one-time action (Only occurs at the first
> device gets assigned), do you think it is that unacceptable?

Btw. please see George's very nice description - much better than
I would ever have been able to give - for why we will always want
alternatives to pausing considered first:
https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg02587.html

Jan


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

Re: [Xen-devel] [PATCH v6 08/15] x86/efi: create new early memory allocator

[Jan Beulich]

>>> On 23.09.16 at 13:35,  wrote:
> One early allocator for both platforms would be nice. And I have a feeling
> that this is the Jan's goal. However, I am not going to insist because you
> know ARM platforms better than I. So, I think that Jan should say what is
> his idea in this situation.

The question of what section to put the data in is pretty orthogonal
to my request to make the allocator platform independent. In fact,
if desired we could have a per-arch override to specify the section
this should go into.

Jan


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

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

[Julien Grall]

Hi Dario,

On 22/09/16 17:31, Dario Faggioli wrote:

On Thu, 2016-09-22 at 12:24 +0100, Julien Grall wrote:

On 22/09/16 09:43, Dario Faggioli wrote:

Local migration basically --from the vcpu perspective-- means
create a
new vcpu, stop the original vcpu, copy the state from original to
new,
destroy the original vcpu and start the new one. My point is that
this
is not something that can be done within nor initiated by the
scheduler, e.g., during a context switch or a vcpu wakeup!


By local migration, I meant from the perspective of the hypervisor.
In
the hypervisor you have to trap feature registers and other
implementation defined registers to show the same value across all
the
physical CPUs.


You mean we trap feature registers during the (normal) execution of a
vcpu, because we want Xen to vet what's returned to the guest itself.
And that migration support, and hence the possibility that the guest
have been migrated to a cpu different than the one where it was
created, is already one of the reasons why this is necessary... right?


That's correct.

Regards,

--
Julien Grall

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

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

[Dario Faggioli]

On Fri, 2016-09-23 at 18:05 +0800, Peng Fan wrote:
> We still can introduce cpupool-cluster-split or as Juergen suggested,
> use "cpupool-slit feature=xx"  to split the cluster or cpuclasses
> into different cpupools. This is just a feature that better to have,
> I think.
> 
> The reason to include cpupool-cluster-split or else is to split the
> big and little
> cores into different cpupools. And now big and little cores are in
> different cpu
> clusters from the hardware[1] I can see. 
>
Note that this `cpupool-split' thing is meant to be an aid to the user
to quickly put the system in a state that we think it could be a common
or relevant setup.

For instance, cpupools can be used to partition big NUMA system, and we
thought users may be interested in having one pool per NUMA node, so an
helper for doing that quickly (i.e., with just one command) has been
provided.

That does not mean that it's the only use of cpupools, nor that it's
the only --or the only sane-- way to use cpupools on NUMA systems...
it's just a speculation, in an attempt to make life easier for users.

In a similar way, if we think that, for instance, creating a 'big pool'
and a 'LITTLE pool' would be something common, and/or we (Peng?
Stefano?) already have an usecase for this, we can well implement a
`cpupool-split' variant that does that.

*BUT* that does not mean that people must use it, or that they can't do
anything else or different with cpupools on ARM! In fact, on a NUMA
system, one can completely ignore `cpupool-numa-split', and create
whatever pools and assign pcpus to them at will. Or she can actually
use `cpupool-numa-split' as a basis, i.e., issue the command, manually
alter the resulting status, by doing some more movement of pcpus among
the pools the command created.

All this to say that, especially when thinking about this
cpupool-split thing, we "only" need to come up with something that we
think makes sense, either to be used as is or as a basis, not to the
one and only way cpupools and big.LITTLE --or ARM in general-- should
interact.

In fact:
> I think assigning cores from
> different clusters into one cpupool is not a good idea.
> 
I'd be perfectly fine with this, and with cpupool-split on big.LITTLE
to cut pools around clusters boundaries. But I definitely would not
want to forbid the user to manually shuffle things around, including
ending up in a situation where there are pcpus from different
class/cluster/whatever in the same pool... If that is shooting in his
own foot, then so be it!

Thanks and Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 05/16] livepatch: Initial ARM64 support.

[Ross Lagerwall]

On 09/21/2016 06:32 PM, Konrad Rzeszutek Wilk wrote:
snip

+
+void arch_livepatch_revert(const struct livepatch_func *func)
+{
+uint32_t *new_ptr;
+unsigned int i, len;
+
+new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
+len = livepatch_insn_len(func) / sizeof(uint32_t);
+for ( i = 0; i < len; i++ )
+{
+uint32_t insn;
+
+memcpy(&insn, func->opaque + (i * sizeof(uint32_t)), 
ARCH_PATCH_INSN_SIZE);
+/* PATCH! */
+*(new_ptr + i) = insn;
+}


Why is this done in a loop? Can't we just memcpy 
livepatch_insn_len(func) bytes into *new_ptr?



+}
+
+int arch_livepatch_verify_elf(const struct livepatch_elf *elf)
+{
+const Elf_Ehdr *hdr = elf->hdr;
+
+if ( hdr->e_machine != EM_AARCH64 ||
+ hdr->e_ident[EI_CLASS] != ELFCLASS64 )
+{
+dprintk(XENLOG_ERR, LIVEPATCH "%s: Unsupported ELF Machine type!\n",
+elf->name);
+return -EOPNOTSUPP;
+}
+
+return 0;
+}
+

snip

 int arch_livepatch_verify_func(const struct livepatch_func *func)
 {
-return -ENOSYS;
-}
+/* If NOPing only do up to maximum amount we can put in the ->opaque. */
+if ( !func->new_addr && func->new_size > sizeof(func->opaque) &&
+ func->new_size % ARCH_PATCH_INSN_SIZE )
+return -EOPNOTSUPP;


Maybe I'm misunderstanding, but shouldn't this be ( !func->new_addr && 
(func->new_size > sizeof(func->opaque) || func->new_size % 
ARCH_PATCH_INSN_SIZE) ) ?


--
Ross Lagerwall

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

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

[Dario Faggioli]

On Fri, 2016-09-23 at 11:15 +0100, Julien Grall wrote:
> On 23/09/16 11:05, Peng Fan wrote:
> > If cluster is not prefered, cpuclass maybe a choice, but I
> > personally perfer
> > "cluster" split for ARM.
> > 
> > Thanks,
> > Peng.
> > 
> > [1] https://en.wikipedia.org/wiki/ARM_big.LITTLE
> 
> Please try to have a think on all the use case and not only yours.
> 
This last line is absolutely true and very important!

That being said, I am a bit lost.

So, AFAICT, in order to act properly when the user asks for:

 vcpuclass = ["1,2:foo", "0,3:bar"]

we need to decide what "foo" and "bar" are at the xl and libxl level,
and whether they are the same all the way down to Xen (and if not,
what's the mapping).

We also said it would be nice to support:

 xl cpupool-split --feature=foobar

and hence we also need to decide what's foobar, whether it is in the
same namespace of foo and bar (i.e., it can be foobar==foo, or
foobar==bar, etc), or it is something else, or both.

Can someone list what are the various alternative approaches on the
table?

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf fe882c01122e7e01e0e78ca8da64630faf9a7b5a
baseline version:
 ovmf 85b88deb18857af261c655dfa833de17b19d7163

Last test of basis   101113  2016-09-22 21:45:32 Z0 days
Testing same since   101122  2016-09-23 09:49:15 Z0 days1 attempts


People who touched revisions under test:
  Star Zeng 

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 :

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

Re: [Xen-devel] PCI passthrough with stubdomain

[Samuel Thibault]

Marek Marczykowski-Górecki, on Fri 23 Sep 2016 10:48:14 +0200, wrote:
> I'm still trying to get PCI passthrough working with stubdomain and
> without qemu in dom0 (even for just vfb/vkbd backends). How is this
> supposed to work?

Just as I recall from my memory:

> 1. Should xen-pcifront in the target domain be used (and consequently,
> should xen-pciback be set for it)?

I guess that could work.

> Currently xen-pciback is set for both
> stubdomain and target domain, which presents a race condition and
> xen-pciback refuses to setup one of them.

Yes, that's expected, for the reason you say.


For each question, I'll answer for two cases: either plain PCI drivers
in the guest, or xen-pvPCI drivers.


* Using plain PCI drivers.
**
I.e. no PV from the point of view of the guest, it directly pokes I/O
ports emulated by qemu.

> 1a. How does it look in case of qemu in dom0 (no stubdomain)?

qemu uses libpci (from pciutils) to access the board and pass through
requests coming from the guest. no pciback should thus be set since qemu
pokes directly from dom0.

> 2. What operations are done through stubdomain and what are handled
> directly by Xen (itself, or with help of IOMMU)? I'd guess config space
> accesses are done through device model. Anything else?

When using a qemu stubdomain, qemu still uses libpci to access the
board. The stubdom/ directory contains a patch to make the stubdom
libpci use the minios PV frontend. Thus, the pciback should be set for
the stubdom, since that's the one which will poke it through PV.  I
don't remember how the guest iomemory access are handled. At worse
they're trapped into qemu that does the access from the stubdom. At best
qemu maps the pages into the guest memory, and thus the guest directly
accesses it through Xen (potentially made safe by IOMMU). I guess I
implemented the latter, but that's far away, so my memory might be wrong
:)

> 3. What changes (if any) are required in qemu-xen to have it working in
> stubdomain in regards to PCI passthrough? Should it just work (assuming
> Linux-based stubdomain with xen-pcifront driver)?

IIRC it should just work, just need to set a PV pcifront on the stubdom
when using a stubdom. In the dom0 case qemu will access the PCI board
directly.


* Using PV drivers from the guest.
**
So the PV is running its own PV drivers.
The stubdom thus doesn't have to know about it.

> 1a. How does it look in case of qemu in dom0 (no stubdomain)?

qemu will not manage it, the guest will talk directly with the pciback,
to be set on the guest.

> 2. What operations are done through stubdomain and what are handled
> directly by Xen (itself, or with help of IOMMU)? I'd guess config space
> accesses are done through device model. Anything else?

Everything goes through Xen, potentially with the use of IOMMU. config
space goes through PV too, values are read from the xenstore. See
minios' pcifront_physical_to_virtual for an instance how it's
implemented. The iomemory accesses are done by the guest PV driver by
just mapping the right physical pages.

> 3. What changes (if any) are required in qemu-xen to have it working in
> stubdomain in regards to PCI passthrough? Should it just work (assuming
> Linux-based stubdomain with xen-pcifront driver)?

qemu is not involved, so it doesn't have to be changed :)


* to summarize
**

If running PV drivers in the guest, you set the pciback on the guest, be
it run with stubdom or not. 
If running plain drivers in the guest,
  * when not using a stubdom you don't need to set a pciback.
  * when using a stubdom you need to set a pciback on the stubdom.

So the unfortunate thing is that when using stubdom, you'd have to set
the pciback either on the guest (to run a PV driver in it), or on the
stubdom (to run a plain driver in the guest, and let mini-os use PV to
let qemu pass the board through)

Samuel

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

Re: [Xen-devel] [PATCH v5 03/16] livepatch: Reject payloads with .alternative or .ex_table if support is not built-in.

[Ross Lagerwall]

On 09/21/2016 06:32 PM, Konrad Rzeszutek Wilk wrote:

If the payload had the sections mentioned but the hypervisor
did not support some of them (say on ARM the .ex_table) - instead
of ignoring them - it should forbid loading of such payload.

Reviewed-by: Julien Grall 
Signed-off-by: Konrad Rzeszutek Wilk 
---


Reviewed-by: Ross Lagerwall 

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-qcow2  9 debian-di-install  fail REGR. vs. 101072

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

version targeted for testing:
 libvirt  e3d3c04a6cd7351fe8279234eb8c5aea27ad6bf9
baseline version:
 libvirt  e5568193f4d663f6a9edebcf9044d527f90a031f

Last test of basis   101072  2016-09-21 04:22:22 Z2 days
Failing since101094  2016-09-22 04:22:55 Z1 days2 attempts
Testing same since   101120  2016-09-23 04:21:27 Z0 days1 attempts


People who touched revisions under test:
  Chen Hanxiao 
  Jim Fehlig 
  Jiri Denemark 
  John Ferlan 
  Michal Privoznik 
  Nikolay Shirokovskiy 
  Nitesh Konkar 
  Nitesh Konkar 
  Pavel Hrdina 
  Peter Krempa 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   fail
 test-armhf-armhf-libvirt-raw fail
 test-amd64-amd64-libvirt-vhd 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.

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

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

Re: [Xen-devel] [PATCH v6 08/15] x86/efi: create new early memory allocator

[Daniel Kiper]

On Fri, Sep 23, 2016 at 12:42:10PM +0100, Julien Grall wrote:
>
>
> On 23/09/16 12:35, Daniel Kiper wrote:
> >On Fri, Sep 23, 2016 at 12:07:14PM +0100, Julien Grall wrote:
> >>On 23/09/16 11:50, Daniel Kiper wrote:
> >>>Hi Julien,
> >>
> >>Hi Daniel,
> >>
> >>>
> >>>On Thu, Sep 22, 2016 at 06:07:26PM +0100, Julien Grall wrote:
> >>>
> >>>[...]
> >>>
> >#ifndef CONFIG_ARM
> >/* Whole x86 ebmalloc stuff. */
> >...
> >#else
> >void __init free_ebmalloc_unused_mem(void)
> >{
> >}
> >#endif
> >
> >and then call free_ebmalloc_unused_mem() from e.g.
> >xen/arch/arm/setup.c:init_done(). Am I right?
> 
> Bear in mind that the EFI loader on ARM is standalone. It cannot
> interact with Xen.
> 
> The main goal of the EFI stub is to load the different images on the
> memory and then will jump at the same starting point as when Xen is
> loaded without EFI. So anything in bss will be zeroed.
> >>>
> >>>AIUI, on ARM EFI we have following call sequence:
> >>> - efi_start(),
> >>> - efi_xen_start(),
> >>> - real_start()
> >>> - ...
> >>> - el2() which zeroes BSS... ;-(((
> >>>
> >>>We had the same situation on x86. So, we moved BSS init just before
> >>>efi_start() call and disabled later zero BSS if we are booted via EFI.
> >>>Could we do the same on ARM? As I can see Jan wish to use ebmalloc on
> >>>ARM too. Does it make sense for you?
> >>
> >>The EFI on ARM has been designed to be standalone and disable page
> >>tables, flush the cache before hand and then jump in the startup
> >>beginning of the binary (as it would be done without EFI).
> >>
> >>The problem I can see here, is ebmalloc_mem is allocated in bss
> >>rather than in init. I understand this is an optimization, to shrink
> >>down the size of the binary.
> >>
> >>But, I am not in favor to start differing in startup code if we have
> >>EFI enabled just for that.
> >>
> >>IHMO, anything related to the stub should be in the init section and
> >>therefore will be freed when Xen has finished to boot.
> >
> >One early allocator for both platforms would be nice. And I have a feeling
> >that this is the Jan's goal. However, I am not going to insist because you
> >know ARM platforms better than I. So, I think that Jan should say what is
> >his idea in this situation.
>
> Out of interest, what is the reason behind putting the early
> allocator in bss rather than init?

First of all some data must live longer than just init phase.
Later we do not want to increase image size. You could find full
explanation in the commit message for this patch. However, if
you still have questions drop me a line.

Daniel

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

Re: [Xen-devel] [PATCH v5 04/21] acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1

[Ian Jackson]

Boris Ostrovsky writes ("[PATCH v5 04/21] acpi: Re-license ACPI builder files 
from GPLv2 to LGPLv2.1"):
> ACPI builder is currently distributed under GPLv2 license.

Acked-by: Ian Jackson 

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