Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core logic handling

[Wu, Feng]

> -Original Message-
> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: Tuesday, September 22, 2015 6:27 PM
> To: Wu, Feng; Dario Faggioli; George Dunlap
> Cc: Jan Beulich; Tian, Kevin; Keir Fraser; Andrew Cooper;
> xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core 
> logic
> handling
> 
> On 09/22/2015 08:19 AM, Wu, Feng wrote:
> >
> >
> >> -Original Message-
> >> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> >> Sent: Monday, September 21, 2015 10:25 PM
> >> To: Wu, Feng; George Dunlap; George Dunlap
> >> Cc: Jan Beulich; Tian, Kevin; Keir Fraser; Andrew Cooper;
> >> xen-devel@lists.xen.org
> >> Subject: Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core
> logic
> >> handling
> >>
> >> On Mon, 2015-09-21 at 12:22 +, Wu, Feng wrote:
> >>>
>  -Original Message-
>  From: George Dunlap [mailto:george.dun...@citrix.com]
> >>
>  You also need to check that local_events_need_delivery() will
>  return
>  "true" if you get an interrupt between that time and entering the
>  hypervisor.  Will that happen automatically from
>  hvm_local_events_need_delivery() -> hvm_vcpu_has_pending_irq() ->
>  vlapic_has_pending_irq()?  Or will you need to add a hook in
>  hvm_vcpu_has_pending_irq()?
> >>>
> >>> I think I don't need to add hook in hvm_vcpu_has_pending_irq(), what
> >>> I need
> >>> to do in vcpu_block() and do_poll() is as below:
> >>>
> >>> 1. set_bit(_VPF_blocked, &v->pause_flags);
> >>>
> >>> 2. ret = v->arch.arch_block(), in this hook, we can re-use the same
> >>> logic in
> >>> vmx_pre_ctx_switch_pi(), and check whether ON bit is set during
> >>> updating
> >>> posted-interrupt descriptor, can return 1 when ON is set
> >>>
> >> It think it would be ok for an hook to return a value (maybe, if doing
> >> that, let's pick variable names and use comments to explain what goes
> >> on as good as we can).
> >>
> >> I think I also see why you seem to prefer doing it that way, rather
> >> than hacking local_events_need_delivery(), but can you please elaborate
> >> on that? (My feeling is that you want to avoid having to update the
> >> data structures in between _VPF_blocked and the check
> >> local_events_need_delivery(), and then having to roll such update back
> >> if local_events_need_delivery() ends up being false, is that the
> >> case?).
> >
> > In the arch_block() hook, we actually need to
> > - Put vCPU to the blocking list
> > - Set the NV to wakeup vector
> > - Set NDST to the right pCPU
> > - Clear SN
> 
> Nit: We shouldn't need to actually clear SN here; SN should already be
> clear because the vcpu should be currently running.  (I don't think
> there's a way for a vcpu to go from runnable->blocked, is there?)  And
> if it's just been running, then NDST should also already be the correct
> pcpu.

Yes, we can go to blocked only from running state. let me clarify a
question first: Xen doesn't support kernel preemption, right?( i.e. we
can only perform context switch before returning to guest.) If that is
case, we can make sure the pcpu is not changed for the running
vCPU before we set the NDST filed in PI descriptor, so we don't need
to update NDST.

> 
> > During we are updating the posted-interrupt descriptor, the VT-d
> > hardware can issue notification event and hence ON is set. If that is the
> > case, it is straightforward to return directly, and it doesn't make sense
> > we continue to do the above operations since we don't need to actually.
> 
> But checking to see if any interrupts have come in in the middle of your
> code just adds unnecessary complication.  We need to have the code in
> place to un-do all the blocking steps in the case that
> local_events_need_delivery() returns true anyway.
> 
> Additionally, while local_events_need_delivery() is only called from
> do_block and do_poll, hvm_local_events_need_delivery() is called from a
> number of other places, as is hvm_vcpu_has_pending_irq().  All those
> places presumably also need to know whether there's a PI pending to work
> properly.

local_events_need_delivery() can be called in other places, since it is wrapped
in hypercall_preempt_check(), which can be called in bunch of places. But
that shouldn't be a question here. In fact, ON bit is checked in
local_events_need_delivery() call path: (this is added when the CPU side PI
patches is merged years ago)

local_events_need_delivery() --> hvm_local_events_need_delivery()
--> hvm_vcpu_has_pending_irq() --> vlapic_has_pending_irq()
--> vlapic_find_highest_irr() --> hvm_funcs.sync_pir_to_irr()
--> pi_test_and_clear_on()

What we need to do is to find a good way to recover the PI state in vcpu_block()
and do_poll() if local event delivery is needed. Need to think this more.

Thanks,
Feng

> 
> >> Code would look better, IMO, if we manage to fold that somehow inside
> >> local_events_need_delivery(), but that:
> >
> > As mentioned

[Xen-devel] [xen-unstable baseline-only test] 38011: trouble: broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair 4 host-install/dst_host(4) broken REGR. vs. 37938

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 37938

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-qcow2 9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-xl-raw   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 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-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass

version targeted for testing:
 xen  4600d7560425f89b32cd90ecf6084bae9293dfab
baseline version:
 xen  a7b39c8bd6cba3fe1c8012987b9e28bdbac7e92d

Last test of basis37938  2015-09-15 16:29:30 Z7 days
Testing same since38011  2015-09-22 10:48:55 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Boris Ostrovsky 
  Chris Brand 
  Christoph Egger 
  Chunyan Liu 
  Daniel De Graaf 
  Daniel Kiper 
  David Vrabel 
  George Dunlap 
  Hanjun Guo 
  Haozhong Zhang 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jonathan Creekmore 
  Julien Grall 
  Kevin Tian 
  Kouya Shimura 
  Len Brown 
  Rafael J. Wysocki 
  Razvan Cojocaru 
  Shannon Zhao 
  Stefano Stabellini 
  Tamas K Lengyel 
  Tiejun Chen 
  Tomasz Nowicki 
  Vitaly Kuznetsov 
  Wei Liu 

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

Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core logic handling

[Wu, Feng]

> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Tuesday, September 22, 2015 10:39 PM
> To: George Dunlap; Wu, Feng
> Cc: xen-devel@lists.xen.org; Tian, Kevin; Keir Fraser; George Dunlap; Andrew
> Cooper; Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core 
> logic
> handling
> 
> On Tue, 2015-09-22 at 15:15 +0100, George Dunlap wrote:
> > On 09/22/2015 02:52 PM, Wu, Feng wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> 
> > > > Yes, the idle to vCPUB switch is covered by __context_switch(),
> > > > but
> > > it cannot change the PI state of vCPUA at that point. Like
> > > mentioned
> > > above, in this case, spurious PI interrupts happens.
> >
> > On the contrary, when __context_switch() is called for the idle ->
> > vcpuB
> > transition in the above scenario, it is *actually* context switching
> > from vcpuA to vcpuB, since vcpuA is still actually on the cpu.
> >  Which
> > means that if you add PI code into arch->ctxt_switch_from(), the case
> > you describe above will be handled automatically.
> >
> Yep, that's exactly what I was also writing... luckily, I've seen
> George's email before getting too far with that! :-P
> 
> That's the point of lazy context switch. The context of vCPUA is still
> on pCPUA during the time idle executes. If, at the next transition
> point, we switch from idle to vCPUA again, then nothing is needed, and
> we just saved one context saving and one context restoring operation.
> If it is something else, like in your case, we need to save vCPUA's
> context, which is actually what we have on pCPUA, despite idle (and not
> vCPUA itself) was what was running.

George & Dario, thanks much for sharing so many scheduler knowledge
to me, it is very useful. I think I was making a mistake about how
__context_switch() work when I wrote the emails above. Now it is
clear, the scenario I mentioned above can be covered in __context_switch().

> 
> > So the only downside to doing everything in block(), wake(), and
> > __context_switch() is that if a VM is offline, or preempted by a
> > tasklet, and an interrupt comes in, we will get a spurious PI (i.e.,
> > one
> > which interrupts us but we can't do anything useful about).
> >
> Indeed. And that also seems bearable to me. Feng, are there reasons why
> you think it's not?

I cannot think the bad effect of the spurious PI as well. I was just a little
confused about we can do this and why we don't do this. Maybe
context_switch() is a critical path, if we can bear those spurious PI,
it is not worth adding those logic in it at the cost of some performance
lost during scheduling. Is this your concern?

Thanks,
Feng

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

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

Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core logic handling

[Wu, Feng]

> -Original Message-
> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: Tuesday, September 22, 2015 10:28 PM
> To: Wu, Feng; Dario Faggioli
> Cc: xen-devel@lists.xen.org; Tian, Kevin; Keir Fraser; George Dunlap; Andrew
> Cooper; Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core 
> logic
> handling
> 
> On 09/22/2015 02:25 PM, Wu, Feng wrote:
> >>> But if we want to avoid spurious PI interrupts when running idle, then
> >>> yes, we need *some* kind of a hook on the lazy context switch path.
> >>>
> >>> /me does some more thinking...
> >>
> >> To be honest, since we'll be get spurious PI interrupts in the
> >> hypervisor all the time anyway, I'm inclined at the moment not to worry
> >> to much about this case.
> >
> > Why do you say "we'll be get spurious PI interrupts in the  hypervisor all 
> > the
> time"?
> >
> > And could you please share what is your concern to handle this case to avoid
> > such spurious PI interrupts? Thanks!
> 
> So please correct me if I'm wrong in my understanding:
> 
> * When a vcpu is in runstate "running", with PI enabled, you have the PI
> vector set to "posted_interrupt_vector", SN=0.
> 
> * When in this state in non-root mode, PI interrupts result in an
> interrupt being delivered directly to the guest.
> 
> * When in this state in root mode, PI interrupts result in a
> posted_interrupt_vector interrupt being delivered to Xen.
> 
> Is that the case?

Exactly, it is how PI works today.

Thanks,
Feng

> 
> So basically, if the PI happens to come in when the guest is making a
> hypercall, or the guest is doing any other number of things that involve
> the hypervisor, then Xen will get a "spurious" PI interrupt -- spurious
> because there's nothing Xen actually needs to do about it; the guest
> interrupt will be delivered the next time we do a VMENTER.
> 
> So spurious PI interrupts are already going to happen from time to time
> -- they're not really that big of a deal.  Having them happen when a VM
> is running a tasklet or idle waiting for qemu isn't such a big deal either.



> 
>  -George

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

Re: [Xen-devel] [PATCH RFC] xen: if on Xen, "flatten" the scheduling domain hierarchy

[Juergen Gross]

On 09/22/2015 06:22 PM, George Dunlap wrote:

On 09/22/2015 05:42 AM, Juergen Gross wrote:

One other thing I just discovered: there are other consumers of the
topology sibling masks (e.g. topology_sibling_cpumask()) as well.

I think we would want to avoid any optimizations based on those in
drivers as well, not only in the scheduler.


I'm beginning to lose the thread of the discussion here a bit.

Juergen / Dario, could one of you summarize your two approaches, and the
(alleged) advantages and disadvantages of each one?


Okay, I'll have a try:

The problem we want to solve:
-

The Linux kernel is gathering cpu topology data during boot via the
CPUID instruction on each processor coming online. This data is
primarily used in the scheduler to decide to which cpu a thread should
be migrated when this seems to be necessary. There are other users of
the topology information in the kernel (e.g. some drivers try to do
optimizations like core-specific queues/lists).

When started in a virtualized environment the obtained data is next to
useless or even wrong, as it is reflecting only the status of the time
of booting the system. Scheduling of the (v)cpus done by the hypervisor
is changing the topology beneath the feet of the Linux kernel without
reflecting this in the gathered topology information. So any decisions
taken based on that data will be clueless and possibly just wrong.

The minimal solution is to change the topology data in the kernel in a
way that all cpus are regarded as equal regarding their relation to each
other (e.g. when migrating a thread to another cpu no cpu is preferred
as a target).

The topology information of the CPUID instruction is, however, even
accessible form user mode and might be used for licensing purposes of
any user program (e.g. by limiting the software to run on a specific
number of cores or sockets). So just mangling the data returned by
CPUID in the hypervisor seems not to be a general solution, while we
might want to do it at least optionally in the future.

In the future we might want to support either dynamic topology updates
or be able to tell the kernel to use some of the topology data, e.g.
when pinning vcpus.


Solution 1 (Dario):
---

Don't use the CPUID derived topology information in the Linux scheduler,
but let it use a simple "flat" topology by setting own scheduler domain
data under Xen.

Advantages:
+ very clean solution regarding the scheduler interface
+ scheduler decisions are based on a minimal data set
+ small patch

Disadvantages:
- covers the scheduler only, drivers still use the "wrong" data
- a little bit hacky regarding some NUMA architectures (needs either a
  hook in the code dealing with that architecture or multiple scheduler
  domain data overwrites)
- future enhancements will make the solution less clean (either need
  duplicating scheduler domain data or some new hooks in scheduler
  domain interface)


Solution 2 (Juergen):
-

When booted as a Xen guest modify the topology data built during boot
resulting in the same simple "flat" topology as in Dario's solution.

Advantages:
+ the simple topology is seen by all consumers of topology data as the
  data itself is modified accordingly
+ small patch
+ future enhancements rather easy by selecting which data to modify

Disadvantages:
- interface to scheduler not as clean as in Dario's approach
- scheduler decisions are based on multiple layers of topology data
  where one layer would be enough to describe the topology


Dario, are you okay with this summary?

Juergen

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck  6 xen-bootfail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail REGR. vs. 59254
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 19 guest-start/debianhvm.repeat 
fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-libvirt-qcow2  6 xen-boot  fail baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 59254
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 59254

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-raw   9 debian-di-installfail   never pass
 test-armhf-armhf-xl-qcow2 9 debian-di-installfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail 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-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   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-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass

version targeted for testing:
 linux99bc7215bc60f6cd414cf1b85cd9d52cc596cccb
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z   75 days
Failing since 59348  2015-07-10 04:24:05 Z   74 days   43 attempts
Testing same since62197  2015-09-20 10:42:19 Z2 days1 attempts


2307 people touched revisions under test,
not listing them all

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

Re: [Xen-devel] [PATCH] Remove a set operation for VCPU_KICK_SOFTIRQ when post interrupt to vm.

[Zhang, Yang Z]

Zhang, Yang Z wrote on 2015-09-08:
> Liuqiming (John) wrote on 2015-09-08:
>> Ok, I will try to explain, correct me if I got anything wrong:
>> 
>> The problem here is not interrupts lost but interrupts not delivered
>> in time.
>> 
>> there are basically two path to inject an interrupt into VM  (or
>> vCPU to another vCPU):
>> Path 1, the traditional way:
>>1) set bit  in vlapic IRR field which represent an interrupt,
>>then kick vcpu 2) a VCPU_KICK_SOFTIRQ softirq raised 3) if
>>VCPU_KICK_SOFTIRQ bit not set, then set it, otherwise return and
>>do nothing 4) send an EVENT_CHECK_VECTOR IPI  to target vcpu 5)
>>target vcpu will VMEXIT due to EXIT_REASON_EXTERNAL_INTERRUPT 6)
>>the interrupt handler basically do nothing 7) interrupt in IRR
>>will be evaluated 8) VCPU_KICK_SOFTIRQ will be cleared when
>>do_softirq 9) there will be an interrupt inject into vcpu when
>>VMENTRY Path 2, the Posted-interrupt way (current logic): 1) set
>>bit in posted-interrupt descriptor which represent an interrupt
>>2) if VCPU_KICK_SOFTIRQ bit not set, then set it, otherwise
>>return and do nothing 3) send an POSTED_INTR_NOTIFICATION_VECTOR
>>IPI to target vcpu 4) if target vcpu in non-ROOT mode it will
>>receive the interrupt
>> immediately otherwise interrupt will be injected when VMENTRY
>> 
>> As the first operation in both path is setting a interrupt represent
>> bit, so no interrupts will lost.
>> 
>> The issue is:
>> in path 2, the first interrupt will cause VCPU_KICK_SOFTIRQ set to
>> 1, and unless a VMEXIT occured or somewhere called do_softirq
>> directly, VCPU_KICK_SOFTIRQ will not cleared, that will make the
>> later interrupts injection  ignored at step 2), which will delay irq
>> handler process in VM.
>> 
>> And because path 2 set VCPU_KICK_SOFTIRQ to 1, the kick vcpu logic
>> in path 1 will also return in step 3), which make this vcpu only can
>> handle interrupt when some other reason cause VMEXIT.
> 
> Nice catch! But without set the softirq, the interrupt delivery also will be 
> delay.
> Look at the code in vmx_do_vmentry:
> 
> cli
> <---the virtual interrupt occurs here will be
> delay. Because there is no softirq pending and the following posted
> interrupt may consumed by another running VCPU, so the target VCPU
> will not aware there is pending virtual interrupt before next vmexit.
> cmp  %ecx,(%rdx,%rax,1)
> jnz  .Lvmx_process_softirqs
> 
> I need more time to think it.

Hi Qiming,

Can you help to take a look at this patch? Also, if possible, please help to do 
a testing since I don't have machine to test it. Thanks very much.

diff --git a/xen/arch/x86/hvm/vmx/entry.S b/xen/arch/x86/hvm/vmx/entry.S
index 664ed83..1ebb5d0 100644
--- a/xen/arch/x86/hvm/vmx/entry.S
+++ b/xen/arch/x86/hvm/vmx/entry.S
@@ -77,6 +77,9 @@ UNLIKELY_START(ne, realmode)
 call vmx_enter_realmode
 UNLIKELY_END(realmode)
 
+bt   $0,VCPU_vmx_pi_ctrl(%rbx)
+jc   .Lvmx_do_vmentry
+
 mov  %rsp,%rdi
 call vmx_vmenter_helper
 mov  VCPU_hvm_guest_cr2(%rbx),%rax
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index e0e9e75..315ce65 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1678,8 +1678,9 @@ static void __vmx_deliver_posted_interrupt(struct vcpu *v)
 {
 unsigned int cpu = v->processor;
 
-if ( !test_and_set_bit(VCPU_KICK_SOFTIRQ, &softirq_pending(cpu))
- && (cpu != smp_processor_id()) )
+if ( !test_bit(VCPU_KICK_SOFTIRQ, &softirq_pending(cpu))
+ && pi_test_on(&v->arch.hvm_vmx.pi_desc)
+ && (cpu != smp_processor_id()))
 send_IPI_mask(cpumask_of(cpu), posted_intr_vector);
 }
 }
diff --git a/xen/arch/x86/x86_64/asm-offsets.c 
b/xen/arch/x86/x86_64/asm-offsets.c
index 447c650..985725f 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -108,6 +108,7 @@ void __dummy__(void)
 OFFSET(VCPU_vmx_emulate, struct vcpu, arch.hvm_vmx.vmx_emulate);
 OFFSET(VCPU_vm86_seg_mask, struct vcpu, arch.hvm_vmx.vm86_segment_mask);
 OFFSET(VCPU_hvm_guest_cr2, struct vcpu, arch.hvm_vcpu.guest_cr[2]);
+OFFSET(VCPU_vmx_pi_ctrl, struct vcpu, arch.hvm_vmx.pi_desc.control);
 BLANK();
 
 OFFSET(VCPU_nhvm_guestmode, struct vcpu, arch.hvm_vcpu.nvcpu.nv_guestmode);
diff --git a/xen/include/asm-x86/hvm/vmx/vmx.h 
b/xen/include/asm-x86/hvm/vmx/vmx.h
index 35f804a..157a4fe 100644
--- a/xen/include/asm-x86/hvm/vmx/vmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h
@@ -116,6 +116,11 @@ static inline void pi_set_on(struct pi_desc *pi_desc)
 set_bit(POSTED_INTR_ON, &pi_desc->control);
 }
 
+static inline int pi_test_on(struct pi_desc *pi_desc)
+{
+return test_bit(POSTED_INTR_ON, &pi_desc->control);
+}
+
 static inline int pi_test_and_clear_on(struct pi_desc *pi_desc)
 {
 return test_and_clear_bit(POSTED_

[Xen-devel] [qemu-upstream-4.2-testing baseline-only test] 38010: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 38010 qemu-upstream-4.2-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38010/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-winxpsp3 16 guest-localmigrate/x10 fail baseline 
untested
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate  fail baseline untested
 test-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install  fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 21 leak-check/check   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 21 leak-check/checkfail never pass


jobs:
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 fail
 test-amd64-i386-xend-qemuu-winxpsp3  fail
 test-amd64-amd64-xl-qemuu-winxpsp3   fail
 test-i386-i386-xl-qemuu-winxpsp3 fail



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

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

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


Push not applicable.


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

Re: [Xen-devel] [PATCH v7 05/17] vmx: Extend struct pi_desc to support VT-d Posted-Interrupts

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, September 22, 2015 10:20 PM
> To: Wu, Feng
> Cc: Andrew Cooper; Tian, Kevin; xen-devel@lists.xen.org; Keir Fraser
> Subject: Re: [PATCH v7 05/17] vmx: Extend struct pi_desc to support VT-d
> Posted-Interrupts
> 
> >>> On 11.09.15 at 10:28,  wrote:
> > Extend struct pi_desc according to VT-d Posted-Interrupts Spec.
> >
> > Signed-off-by: Feng Wu 
> > Reviewed-by: Andrew Cooper 
> > Acked-by: Kevin Tian 
> > Reviewed-by: Konrad Rzeszutek Wilk 
> > ---
> > v7:
> > - Coding style.
> 
> Are you sure?
> 
> > --- a/xen/include/asm-x86/hvm/vmx/vmcs.h
> > +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
> > @@ -80,8 +80,18 @@ struct vmx_domain {
> >
> >  struct pi_desc {
> >  DECLARE_BITMAP(pir, NR_VECTORS);
> > -u32 control;
> > -u32 rsvd[7];
> > +union {
> > +struct {
> > +u16 on : 1,  /* bit 256 - Outstanding Notification */
> > +sn : 1,  /* bit 257 - Suppress Notification */
> > +rsvd_1 : 14; /* bit 271:258 - Reserved */
> > +u8  nv;  /* bit 279:272 - Notification Vector */
> > +u8  rsvd_2;  /* bit 287:280 - Reserved */
> > +u32 ndst;/* bit 319:288 - Notification Destination
> */
> > +};
> 
> Clearly the body of the structure is still mis-indented.

Seeing from the code, this structure is well indented. where do you
think it has problem?

Thanks,
Feng

> 
> Jan


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

Re: [Xen-devel] [PATCH] xen/mcfg: Call PHYSDEVOP_pci_mmcfg_reserved before PCI enumeration

[Konrad Rzeszutek Wilk]

On Tue, Sep 22, 2015 at 01:17:03PM -0700, Ed Swierk wrote:
> RFC. Tested with 3.14.51 and Xen 4.5.1. I'll make a proper patch against a
> more current kernel if we decide this is heading in the right direction.

CC-ing David as well
> 
> 
> xen/mcfg: Notify Xen of PCI MMCONFIG area before adding device
> 
> On systems where the ACPI DSDT advertises a PCI MMCONFIG area but the
> E820
> table does not reserve it, it's up to Dom0 to inform Xen of MMCONFIG
> areas
> via PHYSDEVOP_pci_mmcfg_reserved.  This needs to happen before Xen
> tries to
> access extended capabilities like SRIOV in pci_add_device(), which is
> triggered by PHYSDEVOP_pci_device_add et al.
> 
> Since both MMCONFIG discovery and PCI bus enumeration occur in
> acpi_init(),
> calling PHYSDEVOP_pci_mmcfg_reserved cannot be delegated to a separate
> initcall.  Instead, it can be done in xen_pci_notifier() immediately
> before
> calling PHYSDEVOP_pci_device_add.
> 
> Without this change, Xen 4.4 and 4.5 emit WARN messsages from
> msix_capability_init() when setting up Intel 82599 VFs, since vf_rlen
> has
> not been initialized by pci_add_device().  And on Xen 4.5, Xen nukes the
> DomU due to "Potentially insecure use of MSI-X" when the VF driver
> loads in
> the DomU.  Both problems are fixed by this change.
> 
> Signed-off-by: Ed Swierk 
> 
> diff --git a/drivers/xen/pci.c b/drivers/xen/pci.c
> index dd9c249..47f6b45 100644
> --- a/drivers/xen/pci.c
> +++ b/drivers/xen/pci.c
> @@ -26,8 +26,57 @@
>  #include 
>  #include 
>  #include "../pci/pci.h"
> +
>  #ifdef CONFIG_PCI_MMCONFIG
>  #include 
> +#include 
> +
> +/* pci_mmcfg_list entries that have already been reported to xen */
> +LIST_HEAD(xen_pci_mmcfg_list);
> +
> +static void xen_report_pci_mmcfg_region(u16 segment, u8 bus)
> +{
> + struct pci_mmcfg_region *cfg, *new;
> + struct physdev_pci_mmcfg_reserved r;
> + int rc;
> +
> + if ((pci_probe & PCI_PROBE_MMCONF) == 0)
> + return;
> +
> + cfg = pci_mmconfig_lookup(segment, bus);
> + if (!cfg)
> + return;
> +
> + list_for_each_entry_rcu(new, &xen_pci_mmcfg_list, list) {
> + if (new->segment == cfg->segment &&
> +new->start_bus == cfg->start_bus &&
> +new->end_bus == cfg->end_bus)
> + return;
> + }
> +
> + r.address = cfg->address;
> + r.segment = cfg->segment;
> + r.start_bus = cfg->start_bus;
> + r.end_bus = cfg->end_bus;
> + r.flags = XEN_PCI_MMCFG_RESERVED;
> + rc = HYPERVISOR_physdev_op(PHYSDEVOP_pci_mmcfg_reserved, &r);
> + if (rc != 0 && rc != -ENOSYS) {
> + pr_warn("Failed to report MMCONFIG reservation state for %s"
> + " to hypervisor (%d)\n", cfg->name, rc);
> + }
> +
> + new = kmemdup(cfg, sizeof(*new), GFP_KERNEL);
> + if (new) {
> + list_add_tail_rcu(&new->list, &xen_pci_mmcfg_list);
> + } else {
> + pr_warn("Failed to allocate xen_pci_mmcfg_list entry\n");
> + }
> +}
> +
> +#else
> +
> +static void xen_report_pci_mmcfg_region(u16 segment, u8 bus) { }
> +
>  #endif
> 
>  static bool __read_mostly pci_seg_supported = true;
> @@ -86,6 +135,7 @@ static int xen_add_device(struct device *dev)
>   }
>  #endif /* CONFIG_ACPI */
> 
> + xen_report_pci_mmcfg_region(add.seg, add.bus);
>   r = HYPERVISOR_physdev_op(PHYSDEVOP_pci_device_add, &add);
>   if (r != -ENOSYS)
>   return r;
> @@ -104,6 +154,7 @@ static int xen_add_device(struct device *dev)
>   .physfn.devfn = physfn->devfn,
>   };
> 
> + xen_report_pci_mmcfg_region(0, manage_pci_ext.bus);
>   r = HYPERVISOR_physdev_op(PHYSDEVOP_manage_pci_add_ext,
>   &manage_pci_ext);
>   }
> @@ -115,6 +166,7 @@ static int xen_add_device(struct device *dev)
>   .is_extfn = 1,
>   };
> 
> + xen_report_pci_mmcfg_region(0, manage_pci_ext.bus);
>   r = HYPERVISOR_physdev_op(PHYSDEVOP_manage_pci_add_ext,
>   &manage_pci_ext);
>   } else {
> @@ -123,6 +175,7 @@ static int xen_add_device(struct device *dev)
>   .devfn = pci_dev->devfn,
>   };
> 
> + xen_report_pci_mmcfg_region(0, manage_pci.bus);
>   r = HYPERVISOR_physdev_op(PHYSDEVOP_manage_pci_add,
>   &manage_pci);
>   }
> @@ -142,6 +195,7 @@ static int xen_remove_device(struct device *dev)
>   .devfn = pci_dev->devfn
>   };
> 
> + xen_report_pci_mmcfg_region(device.seg, device.bus);
>   r = HYPERVISOR_physdev_op(PHYSDEVOP_pci_device_remove,
>&device);
>   } else if (pci_domain_nr(pci_dev->bus))
> @@ -152,6 +206,7 @@ static int xen_remove_device(struct device *dev)
>   .devfn = pci_dev->devfn
>   };
> 
> + xen_report_pci_mmcfg_region(0, manage_pci.bus);
>   r = HYPERVISOR_physdev_op(PHYSDEVOP_manage_pci_remove,
>&manage_pci);
>   }
> @@ -195,49 +250,3 @@ static int __init register_xen_pci_notifier(void)
>  }
> 
>  arch_initcall(register_xen_pci_notifier);
> -
> -#ifdef CONFIG_PCI_MMCONFIG
> -static int __init xen_mcfg_late(void)
> -{
> - struct pci_mmcfg_region *cfg;
> - int rc;
> -
> - if (!xen_initial_domain())
> - return 0;
> -
> - if ((pci_probe & PCI_PROBE_MMCONF) == 0)
> - return 0;
> -
> - if (list_empty(&pci_mmcfg_list))
> - return 0;
> -
> - /* Check whether the

[Xen-devel] Xen, ACPI and Linux

[Stefano Stabellini]

Hi all,

Mark, Ard and I have just had a discussion on ACPI, EFI and booting
interfaces for Xen and kexec.

We all agree that the most important thing to do is to document
precisely what this interface looks like. Not just the device tree
nodes, but also who calls ExitBootServices, SetVirtualAddressMap, etc.
We need to make clear that it is an external interface and will be
maintained for backward compatibility going forward.  The proposed
renaming of the device tree nodes is OK, and can be part of it.



Regarding Runtime Services, the EFI spec doesn't allow a NULL pointer to
the Runtime Services table, so Mark would like to see a proper pointer
being passed there.  The function table could be populated with
hypercall wrappers in assembly, keeping the same interface to Xen that
we have today in drivers/xen/efi.c. It should be part of the initial
patch series.

If that turns out to be very hard to do (which is unlikely), or if that
approach has any unforeseen problems, we could specify in the external ABI
document that the Runtime Services table pointer can be NULL. Mark
would be less happy with this solution, let's try the other one first.


Cheers,

Stefano

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

[Xen-devel] [distros-debian-snapshot test] 38009: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops 3 host-install(3) broken REGR. vs. 37991
 build-armhf   5 xen-build fail REGR. vs. 37991
 test-amd64-amd64-amd64-weekly-netinst-pygrub 9 debian-di-install fail REGR. 
vs. 37991
 test-amd64-i386-amd64-daily-netboot-pygrub 9 debian-di-install fail REGR. vs. 
37991

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-amd64-weekly-netinst-pygrub 13 guest-saverestore fail like 
37991
 test-amd64-i386-amd64-current-netinst-pygrub 9 debian-di-install fail like 
37991
 test-amd64-amd64-i386-current-netinst-pygrub 9 debian-di-install fail like 
37991
 test-amd64-i386-i386-current-netinst-pygrub 9 debian-di-install fail like 37991
 test-amd64-amd64-amd64-current-netinst-pygrub 9 debian-di-install fail like 
37991

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-armhf-daily-netboot-pygrub  1 build-check(1)  blocked n/a
 test-amd64-amd64-amd64-daily-netboot-pvgrub 13 guest-saverestore fail never 
pass

baseline version:
 flight   37991

jobs:
 build-amd64  pass
 build-armhf  fail
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopsbroken  
 build-i386-pvops pass
 test-amd64-amd64-amd64-daily-netboot-pvgrub  fail
 test-amd64-i386-i386-daily-netboot-pvgrubpass
 test-amd64-i386-amd64-daily-netboot-pygrub   fail
 test-armhf-armhf-armhf-daily-netboot-pygrub  blocked 
 test-amd64-amd64-i386-daily-netboot-pygrub   pass
 test-amd64-amd64-amd64-current-netinst-pygrubfail
 test-amd64-i386-amd64-current-netinst-pygrub fail
 test-amd64-amd64-i386-current-netinst-pygrub fail
 test-amd64-i386-i386-current-netinst-pygrub  fail
 test-amd64-amd64-amd64-weekly-netinst-pygrub fail
 test-amd64-i386-amd64-weekly-netinst-pygrub  fail
 test-amd64-amd64-i386-weekly-netinst-pygrub  pass
 test-amd64-i386-i386-weekly-netinst-pygrub   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.


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

Re: [Xen-devel] vTPM ownership problem

[Zhenyang Feng]

I cleared TPM hardware, resetted it and upgraded xen to 4.5.0. But the same
problem still exists.
~# tpm_takeownership
Enter owner password:
Confirm password:
Enter SRK password:
Confirm password:
Tspi_TPM_TakeOwnership failed: 0x2004 - layer=tcs, code=0004 (4),
Internal software error


Here is my vtpmmgr / vtpm instance log.


*vtpmmgr:*
Xen Minimal OS!
  start_info: 0xea000(VA)
nr_pages: 0x8000
  shared_inf: 0xdb49c000(MA)
 pt_base: 0xed000(VA)
nr_pt_frames: 0x5
mfn_list: 0xaa000(VA)
   mod_start: 0x0(VA)
 mod_len: 0
   flags: 0x0
cmd_line:
   stack: 0x68d00-0x88d00
MM: Init
  _text: 0x0(VA)
 _etext: 0x44133(VA)
   _erodata: 0x5(VA)
 _edata: 0x53380(VA)
stack start: 0x68d00(VA)
   _end: 0xa9340(VA)
  start_pfn: f5
max_pfn: 8000
Mapping memory range 0x40 - 0x800
setting 0x0-0x5 readonly
skipped 0x1000
MM: Initialise page allocator for 133000(133000)-800(800)
MM: done
Demand map pfns at 8001000-2008001000.
Heap resides at 2008002000-4008002000.
Initialising timer interface
Initialising console ... done.
gnttab_table mapped at 0x8001000.
Initialising scheduler
Thread "Idle": pointer: 0x2008002050, stack: 0x18
Thread "xenstore": pointer: 0x2008002800, stack: 0x19
xenbus initialised on irq 1 mfn 0x122f20
Thread "shutdown": pointer: 0x2008002fb0, stack: 0x1a
main.c: dummy main: start_info=0x88e00
Thread "main": pointer: 0x2008003760, stack: 0x1b
"main"
INFO[VTPM]: Starting vTPM manager domain
INFO[VTPM]: Option: Using tpm_tis driver
*** BLKFRONT for device/vbd/768 **


backend at /local/domain/0/backend/qdisk/1/768
Failed to read /local/domain/0/backend/qdisk/1/768/feature-barrier.
524288 sectors of 512 bytes
**
blk_open(device/vbd/768) -> 3
= Init TPM BACK 
Thread "tpmback-listener": pointer: 0x20080044b0, stack: 0x1c
= Init TPM TIS Driver ==
IOMEM Machine Base Address: FED4
Enabled Localities: 0
1.2 TPM (device-id=0x0 vendor-id = 104A rev-id = 4E)
TPM interface capabilities (0x15):
Interrupt Level Low
Locality Change Int Support
Data Avail Int Support
Timeout b was adjusted to standard value.
tpm_tis_open() -> 4
INFO[TPM]: TPM_GetCapability
INFO[VTPM]: Hardware TPM:
INFO[VTPM]:  version: 1 2 8 8
INFO[VTPM]:  specLevel: 2
INFO[VTPM]:  errataRev: 2
INFO[VTPM]:  vendorID: STM
INFO[VTPM]:  vendorSpecificSize: 0
INFO[VTPM]:  vendorSpecific:
INFO[TPM]: TPM_GetCapability
INFO[TPM]: TPM_GetCapability
INFO[VTPM]: Flushing 1 handle(s) of type 2
INFO[TPM]: TPM_FlushSpecific
INFO[TPM]: TPM_GetCapability
INFO[TPM]: TPM_GetCapability
INFO[TPM]: TPM_GetCapability
INFO[TPM]: TPM_GetCapability
INFO[TPM]: TPM_GetRandom
INFO[TPM]: TPM_GetRandom
INFO[TPM]: TPM_OIAP
INFO[TPM]: Auth Session: 0x44c0f7 opened by TPM_OIAP.
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
TPM Manager - disk format 0
 root seal: 84; sector of 13: 3924
 root: 3200 v=528
 itree: 36; sector of 112: 4032
 group: 3560 v=3472 id=816 md=280
 group seal: 72; 5 in parent: 1860; sector of 13: 3904
 vtpm: 20+64; sector of 48: 4048
INFO[VTPM]: disk_read_sector 0
INFO[VTPM]: disk_read_sector 1
load_root_pre: n/n
INFO[VTPM]: Failed to read manager file. Assuming first time initialization.
INFO[TPM]: TPM_ReadPubek
INFO[TPM]: TPM_TakeOwnership
INFO[TPM]: TPM_DisablePubekRead
INFO[TPM]: TPM_OSAP
INFO[TPM]: Auth Session: 0xabc128 opened by TPM_OSAP.
INFO[TPM]: TPM_SaveState
INFO[VTPM]: Finished initialized new VTPM manager
INFO[TPM]: TPM_TerminateHandle
INFO[TPM]: Auth Session: 0xabc128 closed by TPM_TerminateHandle
INFO[VTPM]: Waiting for commands from vTPM's:
Tpmback:Info Frontend 2/0 connected
INFO[VTPM]: Passthrough: TPM_GetRandom
INFO[VTPM]: Waiting for commands from vTPM's:
INFO[VTPM]: Passthrough: TPM_GetRandom
INFO[VTPM]: Waiting for commands from vTPM's:
INFO[VTPM]: vtpmmgr_LoadHashKey
INFO[VTPM]: Waiting for commands from vTPM's:
INFO[VTPM]: vtpmmgr_SaveHashKey
SaveHashKey with unknown UUID=7740b63c-f6e3-4db2-a94c-9c5332609ad6 -
creating in auth0 (f=1)
INFO[VTPM]: Waiting for commands from vTPM's:
INFO[VTPM]: vtpmmgr_SaveHashKey
INFO[VTPM]: Waiting for commands from vTPM's:
INFO[VTPM]: vtpmmgr_SaveHashKey
INFO[VTPM]: Waiting for commands from vTPM's:
INFO[VTPM]: vtpmmgr_SaveHashKey
INFO[VTPM]: Waiting for commands from vTPM's:
INFO[VTPM]: vtpmmgr_SaveHashKey
INFO[VTPM]: Waiting for commands from vTPM's:
INFO[VTPM]: vtpmmgr_SaveHashKey
INFO[VTPM]

Re: [Xen-devel] [BUG] XEN domU crash when PV grub chainloads 32-bit domU grub

[Samuel Thibault]

Andreas Sundstrom, le Mon 21 Sep 2015 22:03:22 +0200, a écrit :
> Note that my original thought was that this bug probably is within GRUB.

It's probably in the GRUB implementation of loading the domU GRUB, since
you say that pvgrub1 loads it fine.

> (XEN) domain_crash_sync called from entry.S: fault at 82d08021feb0
> compat_create_bounce_frame+0xc6/0xde

So it's inside xen entry code...

> (XEN) Guest stack trace from esp=005a5ff0:

This looks like the end of the stack

> (XEN) 0010  0001e019 00010046 0016b38b 0016b38a 0016b389
> 0016b388
> (XEN) 0016b387 0016b386 0016b385 0016b384 0016b383 0016b382 0016b381
> 0016b380
[...]

and this looks like a lot of consecutive numbers.  Perhaps we simply
somehow overflow?  Did you try giving less memory to the domU?

> I see no output from the domU grub (except when it works as it should
> of course).

Yes, as explained in another mail domU has to get to connect to the
console before getting messages from there.  Another way is to make
console_io hypercalls, which should end up into xl dmesg.

You may also want to enable grub debugging prints, by setting the debug
variable to "all".

Samuel

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

Re: [Xen-devel] [PATCH v6 2/2] xen/arm: support gzip compressed kernels

[Stefano Stabellini]

On Tue, 22 Sep 2015, Julien Grall wrote:
> On 21/09/2015 23:51, Stefano Stabellini wrote:
> > +/*
> > + * Need to free pages after output_size here because they won't be
> > + * freed by discard_initial_modules
> > + */
> > +i = (output_size + PAGE_SIZE - 1) >> PAGE_SHIFT;
> > +for ( ; i < (1 << kernel_order_out); i++ )
> > +free_domheap_page(pages + i);
> > +
> > +vunmap(output);
> > +
> 
> I forgot to mention that vunmap should be called before free_domheap_pages to
> avoid mapping on unallocated pages.
 
You are right, thanks

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

Re: [Xen-devel] [PATCH OSSTEST] make_qcow2: Look for qemu-img under /usr as well as /usr/local

[Stefano Stabellini]

On Tue, 22 Sep 2015, Ian Jackson wrote:
> (CCing Stefano)
> 
> Ian Campbell writes ("Re: [PATCH OSSTEST] make_qcow2: Look for qemu-img under 
> /usr as well as /usr/local"):
> > On Tue, 2015-09-22 at 16:41 +0100, Ian Jackson wrote:
> > > Ian Campbell writes ("[PATCH OSSTEST] make_qcow2: Look for qemu-img under
> > > /usr as well as /usr/local"):
> > > > Older Xen's installed in /usr by default, so we need to check where
> > > > qemu-img if we want these tests to work on those versions.
> > > 
> > > Acked-by: Ian Jackson 
> > > 
> > > But, why are we executing a utility from /usr/lib/xen/bin ?  If this
> > > utility is useful to osstest it is presumably useful to users too, and
> > > in that case it should be on PATH (under some suitable name).
> > 
> > We install qemu-upstream under our own prefix, I think to avoid conficting
> > with the users own qemu installations?
> > 
> > qemu-img comes from there. We do install qemu-xen-img (from trad) into
> > $PATH, but when I wrote this test I thought it preferable to use qemu-img.
> 
> Maybe we should be installing qemu-img from our qemu upstream build
> instead ?
> 
> We evidently don't think that there is anything in the qcow block
> system in trad that we like, because we are only using upstream for
> qdisk vbd backends now.

Yes, this is a good idea. Qcow support is much better in upstream QEMU
compared to qemu-trad.

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

Re: [Xen-devel] Oldest supported Xen version in upstream QEMU (Was: Re: [Minios-devel] [PATCH v2 0/15+5+5] Begin to disentangle libxenctrl and provide some stable libraries)

[Stefano Stabellini]

On Tue, 22 Sep 2015, Ian Campbell wrote:
> (dropping minios-devel)
> 
> Stefano,
> 
> On Wed, 2015-07-15 at 16:46 +0100, Ian Campbell wrote:
> > 
> > There are 3 series, against xen.git (15 patches), mini-os.git (5
> > patches) and qemu-xen-trad.git (5 patches). The patches against xen.git
> > point to the patches in the other two trees via instructions to update
> > the relevant Config.mk field. The perils of changing unstable
> > interfaces!
> 
> I started looking into making the appropriate changes to QEMU upstream to
> use the new libraries directly.
> 
> QEMU (in include/hw/xen/xen_common.h) includes compat shims for libxenctrl
> versions back as far as 3.3.0.
> 
> The main distinction is between pre-4.1.0 and 4.1.0 and later, since
> various handles switching from int's to opaque pointers at that point,
> meaning there are some typedefs and wrappers for things.
> 
> My plan was to rework the QEMU code to use only the new library function
> names for everything such that this becomes the default case (which makes
> sense given these libraries are intended to be long term stable) and to
> update the code in xen_common.h to bridge the gap to 4.6 and earlier.
> 
> But I'm having to jump through some hoops in order to support the pre-4.1.0
> version of things. It's not impossible to support it, I'm sure, but things
> would be a lot easier if we could just drop that support code.
> 
> Can we consider dropping support for Xen 4.0 and earlier from upstream QEMU
> at this point?
> 
> Some data: Xen 4.0.0 was released in April 2010, the last point release was
> 4.0.4 in August 2012 and we no longer do security support for it (for a
> year or two now, I think).
 
The oldest Xen version I build-test for every pull request is Xen 4.0.0,
I think it is very reasonable to remove anything older than that.
I am OK with removing Xen 4.0.0 too, but I would like a warning to be
sent ahead of time to qemu-devel to see if anybody complains.

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

[Xen-devel] [linux-3.18 test] 62178: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail REGR. vs. 58581

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt  6 xen-boot  fail REGR. vs. 58581
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 
fail baseline untested
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 16 
guest-start/debianhvm.repeat fail baseline untested
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail baseline untested
 test-armhf-armhf-xl-rtds 15 guest-start.2   fail baseline untested
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail   like 58581
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail  like 58581
 test-armhf-armhf-xl   6 xen-boot fail   like 58581
 test-armhf-armhf-xl-xsm   6 xen-boot fail   like 58581
 test-armhf-armhf-xl-credit2   6 xen-boot fail   like 58581
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 58581
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 58581
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 58581

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-qcow2 9 debian-di-installfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-raw   9 debian-di-installfail   never pass
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail never 
pass
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail 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-amd64-amd64-libvirt 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-qcow2 11 migrate-support-checkfail never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-cubietruck  6 xen-boot fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass

version targeted for testing:
 linuxfcd9bfdb9d884f1aab89124dee894e7d821bb5dc
baseline version:
 linuxd048c068d00da7d4cfa5ea7651933b99026958cf

Last test of basis58581  2015-06-15 09:42:22 Z   99 days
Failing since 58976  2015-06-29 19:43:23 Z   85 days   61 attempts
Testing same since61524  2015-09-07 11:48:03 Z   15 days7 attempts


462 people touched revisions under test,
not listing them all

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

[Xen-devel] [PATCH for 4.6] xen/arm: vgic: Correctly emulate write when byte is used

[Julien Grall]

When a guest is writing a byte, the value will be located in bits[7:0]
of the register.

Although the current implementation is expecting the byte at the Nth
byte of the register where N = address & 4;

When the address is not 4-byte aligned, the corresponding byte in the
internal state will always be set to zero rather.

Note that byte access are only used for GICD_IPRIORITYR and
GICD_ITARGETSR. So the worst things that could happen is not setting the
priority correctly and ignore the target vCPU written.

Signed-off-by: Julien Grall 

---

This patch is a candidate for Xen 4.6 and backport to Xen 4.5 and Xen
4.4. Without it, write a byte to a register won't work as expected.

Spotted while doing some test on the vGICv2 driver. FWIW, Linux doesn't
use byte access in both GICv3 and GICv2 driver.

Note that Xen 4.4 will require a different patch because the function
was living in vgic.c at that time.
---
 xen/include/asm-arm/vgic.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 41cadb1..96839f0 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -174,10 +174,10 @@ static inline void vgic_byte_write(uint32_t *reg, 
uint32_t var, int offset)
 {
 int byte = offset & 0x3;
 
-var &= (0xff << (8*byte));
+var &= 0xff;
 
 *reg &= ~(0xff << (8*byte));
-*reg |= var;
+*reg |= (var << (8*byte));
 }
 
 enum gic_sgi_mode;
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] xen/mcfg: Call PHYSDEVOP_pci_mmcfg_reserved before PCI enumeration

[Ed Swierk]

RFC. Tested with 3.14.51 and Xen 4.5.1. I'll make a proper patch against a
more current kernel if we decide this is heading in the right direction.


xen/mcfg: Notify Xen of PCI MMCONFIG area before adding device

On systems where the ACPI DSDT advertises a PCI MMCONFIG area but the
E820
table does not reserve it, it's up to Dom0 to inform Xen of MMCONFIG
areas
via PHYSDEVOP_pci_mmcfg_reserved.  This needs to happen before Xen
tries to
access extended capabilities like SRIOV in pci_add_device(), which is
triggered by PHYSDEVOP_pci_device_add et al.

Since both MMCONFIG discovery and PCI bus enumeration occur in
acpi_init(),
calling PHYSDEVOP_pci_mmcfg_reserved cannot be delegated to a separate
initcall.  Instead, it can be done in xen_pci_notifier() immediately
before
calling PHYSDEVOP_pci_device_add.

Without this change, Xen 4.4 and 4.5 emit WARN messsages from
msix_capability_init() when setting up Intel 82599 VFs, since vf_rlen
has
not been initialized by pci_add_device().  And on Xen 4.5, Xen nukes the
DomU due to "Potentially insecure use of MSI-X" when the VF driver
loads in
the DomU.  Both problems are fixed by this change.

Signed-off-by: Ed Swierk 

diff --git a/drivers/xen/pci.c b/drivers/xen/pci.c
index dd9c249..47f6b45 100644
--- a/drivers/xen/pci.c
+++ b/drivers/xen/pci.c
@@ -26,8 +26,57 @@
 #include 
 #include 
 #include "../pci/pci.h"
+
 #ifdef CONFIG_PCI_MMCONFIG
 #include 
+#include 
+
+/* pci_mmcfg_list entries that have already been reported to xen */
+LIST_HEAD(xen_pci_mmcfg_list);
+
+static void xen_report_pci_mmcfg_region(u16 segment, u8 bus)
+{
+ struct pci_mmcfg_region *cfg, *new;
+ struct physdev_pci_mmcfg_reserved r;
+ int rc;
+
+ if ((pci_probe & PCI_PROBE_MMCONF) == 0)
+ return;
+
+ cfg = pci_mmconfig_lookup(segment, bus);
+ if (!cfg)
+ return;
+
+ list_for_each_entry_rcu(new, &xen_pci_mmcfg_list, list) {
+ if (new->segment == cfg->segment &&
+new->start_bus == cfg->start_bus &&
+new->end_bus == cfg->end_bus)
+ return;
+ }
+
+ r.address = cfg->address;
+ r.segment = cfg->segment;
+ r.start_bus = cfg->start_bus;
+ r.end_bus = cfg->end_bus;
+ r.flags = XEN_PCI_MMCFG_RESERVED;
+ rc = HYPERVISOR_physdev_op(PHYSDEVOP_pci_mmcfg_reserved, &r);
+ if (rc != 0 && rc != -ENOSYS) {
+ pr_warn("Failed to report MMCONFIG reservation state for %s"
+ " to hypervisor (%d)\n", cfg->name, rc);
+ }
+
+ new = kmemdup(cfg, sizeof(*new), GFP_KERNEL);
+ if (new) {
+ list_add_tail_rcu(&new->list, &xen_pci_mmcfg_list);
+ } else {
+ pr_warn("Failed to allocate xen_pci_mmcfg_list entry\n");
+ }
+}
+
+#else
+
+static void xen_report_pci_mmcfg_region(u16 segment, u8 bus) { }
+
 #endif

 static bool __read_mostly pci_seg_supported = true;
@@ -86,6 +135,7 @@ static int xen_add_device(struct device *dev)
  }
 #endif /* CONFIG_ACPI */

+ xen_report_pci_mmcfg_region(add.seg, add.bus);
  r = HYPERVISOR_physdev_op(PHYSDEVOP_pci_device_add, &add);
  if (r != -ENOSYS)
  return r;
@@ -104,6 +154,7 @@ static int xen_add_device(struct device *dev)
  .physfn.devfn = physfn->devfn,
  };

+ xen_report_pci_mmcfg_region(0, manage_pci_ext.bus);
  r = HYPERVISOR_physdev_op(PHYSDEVOP_manage_pci_add_ext,
  &manage_pci_ext);
  }
@@ -115,6 +166,7 @@ static int xen_add_device(struct device *dev)
  .is_extfn = 1,
  };

+ xen_report_pci_mmcfg_region(0, manage_pci_ext.bus);
  r = HYPERVISOR_physdev_op(PHYSDEVOP_manage_pci_add_ext,
  &manage_pci_ext);
  } else {
@@ -123,6 +175,7 @@ static int xen_add_device(struct device *dev)
  .devfn = pci_dev->devfn,
  };

+ xen_report_pci_mmcfg_region(0, manage_pci.bus);
  r = HYPERVISOR_physdev_op(PHYSDEVOP_manage_pci_add,
  &manage_pci);
  }
@@ -142,6 +195,7 @@ static int xen_remove_device(struct device *dev)
  .devfn = pci_dev->devfn
  };

+ xen_report_pci_mmcfg_region(device.seg, device.bus);
  r = HYPERVISOR_physdev_op(PHYSDEVOP_pci_device_remove,
   &device);
  } else if (pci_domain_nr(pci_dev->bus))
@@ -152,6 +206,7 @@ static int xen_remove_device(struct device *dev)
  .devfn = pci_dev->devfn
  };

+ xen_report_pci_mmcfg_region(0, manage_pci.bus);
  r = HYPERVISOR_physdev_op(PHYSDEVOP_manage_pci_remove,
   &manage_pci);
  }
@@ -195,49 +250,3 @@ static int __init register_xen_pci_notifier(void)
 }

 arch_initcall(register_xen_pci_notifier);
-
-#ifdef CONFIG_PCI_MMCONFIG
-static int __init xen_mcfg_late(void)
-{
- struct pci_mmcfg_region *cfg;
- int rc;
-
- if (!xen_initial_domain())
- return 0;
-
- if ((pci_probe & PCI_PROBE_MMCONF) == 0)
- return 0;
-
- if (list_empty(&pci_mmcfg_list))
- return 0;
-
- /* Check whether they are in the right area. */
- list_for_each_entry(cfg, &pci_mmcfg_list, list) {
- struct physdev_pci_mmcfg_reserved r;
-
- r.address = cfg->address;
- r.segment = cfg->segment;
- r.start_bus = cfg->start_bus;
- r.end_bus = cfg->end_bus;
- r.flags = XEN_PCI_MMCFG_RESERVED;
-
- rc = HYPERVISOR_physdev_op(PHYSDEVOP_pci_mmcfg_reserved, &r);
- switch (rc) {
- case 0:
- case -ENOSYS:
- continue;
-
- default:
-

[Xen-devel] Page Table Entry Modifications

[Gohar Irfan]

Hi All,

I want to know if, in the case of HVM (shadow page tables), we can change
the machine frame number pointed to by a page table entry?
An overly simplified example would be: let's say I have page number 10 that
is pointing to machine frame number 10, but I would like it to point to
machine frame number 1? Can this be achieved inside the "sh_page_fault"
function inside "xen/arch/x86/mm/shadow/multi.c" as this seems like a
relevant place for this modification to me.

Thanks!
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf 9a470dae60ed0c57afdf61342616dd1768ba5ec8
baseline version:
 ovmf 2f667c5488c81924861901d4d7c6f4bb170ffb69

Last test of basis37992  2015-09-19 08:51:15 Z3 days
Testing same since38001  2015-09-21 14:24:02 Z1 days1 attempts


People who touched revisions under test:
  Dandan Bi 
  Eric Dong 
  Jeff Fan 
  Laszlo Ersek 
  Qiu Shumin 
  Samer El-Haj-Mahmoud 
  Star Zeng 
  Yang Jadis 

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 9a470dae60ed0c57afdf61342616dd1768ba5ec8
Author: Laszlo Ersek 
Date:   Fri Sep 18 13:58:35 2015 +

ArmVirtPkg: PlatformIntelBdsLib: signal ReadyToBoot on direct kernel boot

According to the UEFI spec, EFI_EVENT_GROUP_READY_TO_BOOT "is notified by
the system when the Boot Manager is about to load and execute a boot
option". ArmVirtPkg doesn't do this currently when launching a kernel from
the QEMU command line. OvmfPkg does (see git commit 28a34033ee).

At least two edk2-wide callbacks are worth mentioning:

- OnReadyToBoot() in
  "MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c" performs
  variable reclaim and (optionally) installs variable usage statistics as
  a vendor config table;

- OnReadyToBoot() in
  "SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c"
  installs the image execution info table if it doesn't exist yet, in
  SecureBoot-enabled builds.

Cc: Ard Biesheuvel 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Ard Biesheuvel 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18513 
6f19259b-4bc3-4df7-8a09-765794883524

commit 7b577b246d34ace481041ad1599507121d5d7eed
Author: Qiu Shumin 
Date:   Fri Sep 18 05:51:14 2015 +

ShellBinPkg: Ia32/X64 Shell binary update.

The binaries of ShellBinPkg are generated with ShellPkg project 18507. The 
binaries are built with no debug information by building with "RELEASE" target.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18511 
6f19259b-4bc3-4df7-8a09-765794883524

commit 09d1c9e6939af68bfbe545dba1b1c053b96712b4
Author: Samer El-Haj-Mahmoud 
Date:   Fri Sep 18 02:58:31 2015 +

ShellPkg: Added SMBIOS 2.8 Type 17 changes to smbiosview

Updated smbiosview to decode SMBIOS Type 17 MinimumVoltage, MaximumVoltage, 
and ConfiguredVoltage

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud 
Reviewed-by: Jaben Carsey 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18507 
6f19259b-4bc3-4df7-8a09-765794883524

commit 08b822e56dc43666d586468a8b6fba69beda5eeb
Author: Samer El-Haj-Mahmoud 
Date:   Fri Sep 18 02:53:06 2015 +

ShellPkg: Added SMBIOS 3.0 support in dmem.

Added SMBIOS 3.0 support in dmdem Shell command since SMBIOS 3.0 uses a 
different GUID in the System Configuration Table.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud 
Reviewed-by: Jaben Carsey 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18506 
6f19259b-4bc3-4df7-8a09-765794883524

commit 3a05b13106d15ae161489d43d9d2f2311b2241db
Author: Star Zeng 
Date:   Fri Sep 18 02:02:11 2015 +

MdeModulePkg DxeCore: Take the range in resource HOB for PHIT as higher 
priority

Take the range in the resource descriptor HOB for the m

Re: [Xen-devel] rdmsr_safe in Linux PV (under Xen) gets an #GP:Re: [Fedora-xen] Running fedora xen on top of KVM?

[Andy Lutomirski]

On Tue, Sep 22, 2015 at 11:23 AM, Konrad Rzeszutek Wilk
 wrote:
> On Sun, Sep 20, 2015 at 09:49:04PM -0700, Andy Lutomirski wrote:
>> On Fri, Sep 18, 2015 at 12:04 PM, Borislav Petkov  wrote:
>> > On Fri, Sep 18, 2015 at 08:20:46AM -0700, Andy Lutomirski wrote:
>> >> In any event, Borislav, you must have typed rdmsr_safe for a reason :)
>> >
>> > Wasn't me:
>> >
>> > 6c62aa4a3c12 ("x86: make amd.c have 64bit support code")
>> >
>> > I think the error handling of rdmsrl_safe() was needed to do the pfn
>> > games which are done in the if-clause.
>>
>> I just tried it.  rdmsrl_safe and friends definitely work fine in that
>> code.  I think that Linux's Xen startup code is buggy and fails to set
>> up early exception handling.
>>
>> Try this (horribly whitespace damaged):
>>
>>  static void __init early_identify_cpu(struct cpuinfo_x86 *c)
>>  {
>> +   u64 tmp;
>>  #ifdef CONFIG_X86_64
>> c->x86_clflush_size = 64;
>> c->x86_phys_bits = 36;
>> @@ -752,6 +753,9 @@ static void __init early_identify_cpu(struct cpuinfo_x86 
>> *c)
>> c->cpu_index = 0;
>> filter_cpuid_features(c, false);
>>
>> +   pr_err("trying to crash\n");
>> +   rdmsrl_safe(0x12345678, &tmp);
>> +
>>
>> It works fine.  I bet it crashes on a Xen guest, though.  I assume
>> that Xen just works in most cases by luck.
>
> (d31) mapping kernel into physical memory
> (d31) about to get started...
> (XEN) traps.c:3151: GPF (): 82d0801a31ed -> 82d08023c77b
> (XEN) traps.c:459:d31v0 Unhandled general protection fault fault/trap [#13] 
> on VCPU 0 [ec=]
> (XEN) domain_crash_sync called from entry.S: fault at 82d080238213 
> create_bounce_frame+0x12b/0x13a
> (XEN) Domain 31 (vcpu#0) crashed on cpu#35:
> (XEN) [ Xen-4.5.0  x86_64  debug=n  Not tainted ]
> (XEN) CPU:35
> (XEN) RIP:e033:[]
> (XEN) RFLAGS: 0246   EM: 1   CONTEXT: pv guest
> (XEN) rax:    rbx: 81c03e64   rcx: 12345678
> (XEN) rdx: 81c03de8   rsi: 81c03dec   rdi: 12345278
> (XEN) rbp: 81c03e48   rsp: 81c03dd0   r8:  7420676e69797274
> (XEN) r9:  6873617263206f74   r10:    r11: 
> (XEN) r12: 12345678   r13: 81c03f00   r14: 
> (XEN) r15:    cr0: 8005003b   cr4: 001526f0
> (XEN) cr3: 0014e8c97000   cr2: 
> (XEN) ds:    es:    fs:    gs:    ss: e02b   cs: e033
> (XEN) Guest stack trace from rsp=81c03dd0:
> (XEN)12345678   81041b64
> (XEN)0001e030 00010046 81c03e18 e02b
> (XEN)81041b5d 81c03e48 00811809 
> (XEN)01a0 0100 82009000 81c03e68
> (XEN)81d211ea   81c03ed8
> (XEN)81d1be59 81c03ed8 811892ab 0010
> (XEN)81c03ee8 81c03ea8 697a696c61697469 81f15442
> (XEN) 81db3900  
> (XEN) 81c03f28 81d10f0a 
> (XEN)   
> (XEN)   81c03f38
> (XEN)81d10603 81c03ff8 81d15f5c 
> (XEN)   
> (XEN)   
> (XEN)   
> (XEN)   
> (XEN) ffd83a031f898b75 22400800 0001
> (XEN)  00010102464c457f 
> (XEN)0001003e0003 0940 0040 12a0
> (XEN)00380040 001100120044 00050001 
> [root@ovs107 ~]#
>
> (gdb) x/20i 0x81041b64
>0x81041b64:  rdmsr
>

Exactly.  I think that Xen is missing code to wire up early_fixup_exception.

--Andy

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

Re: [Xen-devel] rdmsr_safe in Linux PV (under Xen) gets an #GP:Re: [Fedora-xen] Running fedora xen on top of KVM?

[Konrad Rzeszutek Wilk]

On Sun, Sep 20, 2015 at 09:49:04PM -0700, Andy Lutomirski wrote:
> On Fri, Sep 18, 2015 at 12:04 PM, Borislav Petkov  wrote:
> > On Fri, Sep 18, 2015 at 08:20:46AM -0700, Andy Lutomirski wrote:
> >> In any event, Borislav, you must have typed rdmsr_safe for a reason :)
> >
> > Wasn't me:
> >
> > 6c62aa4a3c12 ("x86: make amd.c have 64bit support code")
> >
> > I think the error handling of rdmsrl_safe() was needed to do the pfn
> > games which are done in the if-clause.
> 
> I just tried it.  rdmsrl_safe and friends definitely work fine in that
> code.  I think that Linux's Xen startup code is buggy and fails to set
> up early exception handling.
> 
> Try this (horribly whitespace damaged):
> 
>  static void __init early_identify_cpu(struct cpuinfo_x86 *c)
>  {
> +   u64 tmp;
>  #ifdef CONFIG_X86_64
> c->x86_clflush_size = 64;
> c->x86_phys_bits = 36;
> @@ -752,6 +753,9 @@ static void __init early_identify_cpu(struct cpuinfo_x86 
> *c)
> c->cpu_index = 0;
> filter_cpuid_features(c, false);
> 
> +   pr_err("trying to crash\n");
> +   rdmsrl_safe(0x12345678, &tmp);
> +
> 
> It works fine.  I bet it crashes on a Xen guest, though.  I assume
> that Xen just works in most cases by luck.

(d31) mapping kernel into physical memory
(d31) about to get started...
(XEN) traps.c:3151: GPF (): 82d0801a31ed -> 82d08023c77b
(XEN) traps.c:459:d31v0 Unhandled general protection fault fault/trap [#13] on 
VCPU 0 [ec=]
(XEN) domain_crash_sync called from entry.S: fault at 82d080238213 
create_bounce_frame+0x12b/0x13a
(XEN) Domain 31 (vcpu#0) crashed on cpu#35:
(XEN) [ Xen-4.5.0  x86_64  debug=n  Not tainted ]
(XEN) CPU:35
(XEN) RIP:e033:[]
(XEN) RFLAGS: 0246   EM: 1   CONTEXT: pv guest
(XEN) rax:    rbx: 81c03e64   rcx: 12345678
(XEN) rdx: 81c03de8   rsi: 81c03dec   rdi: 12345278
(XEN) rbp: 81c03e48   rsp: 81c03dd0   r8:  7420676e69797274
(XEN) r9:  6873617263206f74   r10:    r11: 
(XEN) r12: 12345678   r13: 81c03f00   r14: 
(XEN) r15:    cr0: 8005003b   cr4: 001526f0
(XEN) cr3: 0014e8c97000   cr2: 
(XEN) ds:    es:    fs:    gs:    ss: e02b   cs: e033
(XEN) Guest stack trace from rsp=81c03dd0:
(XEN)12345678   81041b64
(XEN)0001e030 00010046 81c03e18 e02b
(XEN)81041b5d 81c03e48 00811809 
(XEN)01a0 0100 82009000 81c03e68
(XEN)81d211ea   81c03ed8
(XEN)81d1be59 81c03ed8 811892ab 0010
(XEN)81c03ee8 81c03ea8 697a696c61697469 81f15442
(XEN) 81db3900  
(XEN) 81c03f28 81d10f0a 
(XEN)   
(XEN)   81c03f38
(XEN)81d10603 81c03ff8 81d15f5c 
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN) ffd83a031f898b75 22400800 0001
(XEN)  00010102464c457f 
(XEN)0001003e0003 0940 0040 12a0
(XEN)00380040 001100120044 00050001 
[root@ovs107 ~]# 

(gdb) x/20i 0x81041b64
   0x81041b64:  rdmsr  

> 
> --Andy

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

[Xen-devel] [xen-4.5-testing test] 62168: tolerable FAIL - PUSHED

[osstest service owner]

flight 62168 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62168/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-qcow2 14 guest-saverestore.2  fail REGR. vs. 61513
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 61513
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-localmigrate fail REGR. vs. 61513
 test-amd64-i386-rumpuserxen-i386 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 61513
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail blocked in 61513
 test-amd64-i386-xl-qemuu-debianhvm-amd64 19 guest-start/debianhvm.repeat fail 
like 61309
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 61513
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 61513

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-xl-raw   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-amd64-i386-libvirt-raw  13 guest-saverestorefail   never pass
 test-amd64-i386-libvirt-raw  11 migrate-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-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-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-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-qcow2 9 debian-di-installfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-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

version targeted for testing:
 xen  bbbd29a25d090f1180d14210358c6d7ccdebef85
baseline version:
 xen  ef89dc8c00087c8c1819e60bdad5527db70425e1

Last test of basis61513  2015-09-07 11:42:18 Z   15 days
Failing since 61751  2015-09-10 14:07:54 Z   12 days5 attempts
Testing same since62168  2015-09-19 17:21:29 Z3 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anshul Makkar 
  Anthony PERARD 
  Aravind Gopalakrishnan 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jim Fehlig 
  Julien Grall 
  Roger Pau Monné 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 buil

[Xen-devel] [PATCH 3.19.y-ckt 002/102] x86/ldt: Make modify_ldt synchronous

[Kamal Mostafa]

3.19.8-ckt7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Andy Lutomirski 

commit 37868fe113ff2ba814b3b4eb12df214df555f8dc upstream.

modify_ldt() has questionable locking and does not synchronize
threads.  Improve it: redesign the locking and synchronize all
threads' LDTs using an IPI on all modifications.

This will dramatically slow down modify_ldt in multithreaded
programs, but there shouldn't be any multithreaded programs that
care about modify_ldt's performance in the first place.

This fixes some fallout from the CVE-2015-5157 fixes.

Signed-off-by: Andy Lutomirski 
Reviewed-by: Borislav Petkov 
Cc: Andrew Cooper 
Cc: Andy Lutomirski 
Cc: Boris Ostrovsky 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Sasha Levin 
Cc: Steven Rostedt 
Cc: Thomas Gleixner 
Cc: secur...@kernel.org 
Cc: xen-devel 
Link: 
http://lkml.kernel.org/r/4c6978476782160600471bd865b318db34c7b628.1438291540.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
[ kamal: backport to 3.13-stable: dropped comment changes in switch_mm();
  included asm/mmu_context.h in perf_event.c; context ]
Signed-off-by: Kamal Mostafa 
---
 arch/x86/include/asm/desc.h|  15 ---
 arch/x86/include/asm/mmu.h |   3 +-
 arch/x86/include/asm/mmu_context.h |  48 ++-
 arch/x86/kernel/cpu/common.c   |   4 +-
 arch/x86/kernel/cpu/perf_event.c   |  13 +-
 arch/x86/kernel/ldt.c  | 262 -
 arch/x86/kernel/process_64.c   |   4 +-
 arch/x86/kernel/step.c |   6 +-
 arch/x86/power/cpu.c   |   3 +-
 9 files changed, 208 insertions(+), 150 deletions(-)

diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
index a94b82e..6912618 100644
--- a/arch/x86/include/asm/desc.h
+++ b/arch/x86/include/asm/desc.h
@@ -280,21 +280,6 @@ static inline void clear_LDT(void)
set_ldt(NULL, 0);
 }
 
-/*
- * load one particular LDT into the current CPU
- */
-static inline void load_LDT_nolock(mm_context_t *pc)
-{
-   set_ldt(pc->ldt, pc->size);
-}
-
-static inline void load_LDT(mm_context_t *pc)
-{
-   preempt_disable();
-   load_LDT_nolock(pc);
-   preempt_enable();
-}
-
 static inline unsigned long get_desc_base(const struct desc_struct *desc)
 {
return (unsigned)(desc->base0 | ((desc->base1) << 16) | ((desc->base2) 
<< 24));
diff --git a/arch/x86/include/asm/mmu.h b/arch/x86/include/asm/mmu.h
index 876e74e..b6b7bc3 100644
--- a/arch/x86/include/asm/mmu.h
+++ b/arch/x86/include/asm/mmu.h
@@ -9,8 +9,7 @@
  * we put the segment information here.
  */
 typedef struct {
-   void *ldt;
-   int size;
+   struct ldt_struct *ldt;
 
 #ifdef CONFIG_X86_64
/* True if mm supports a task running in 32 bit compatibility mode. */
diff --git a/arch/x86/include/asm/mmu_context.h 
b/arch/x86/include/asm/mmu_context.h
index 4b75d59..1ab38a4 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -19,6 +19,50 @@ static inline void paravirt_activate_mm(struct mm_struct 
*prev,
 #endif /* !CONFIG_PARAVIRT */
 
 /*
+ * ldt_structs can be allocated, used, and freed, but they are never
+ * modified while live.
+ */
+struct ldt_struct {
+   /*
+* Xen requires page-aligned LDTs with special permissions.  This is
+* needed to prevent us from installing evil descriptors such as
+* call gates.  On native, we could merge the ldt_struct and LDT
+* allocations, but it's not worth trying to optimize.
+*/
+   struct desc_struct *entries;
+   int size;
+};
+
+static inline void load_mm_ldt(struct mm_struct *mm)
+{
+   struct ldt_struct *ldt;
+
+   /* lockless_dereference synchronizes with smp_store_release */
+   ldt = lockless_dereference(mm->context.ldt);
+
+   /*
+* Any change to mm->context.ldt is followed by an IPI to all
+* CPUs with the mm active.  The LDT will not be freed until
+* after the IPI is handled by all such CPUs.  This means that,
+* if the ldt_struct changes before we return, the values we see
+* will be safe, and the new values will be loaded before we run
+* any user code.
+*
+* NB: don't try to convert this to use RCU without extreme care.
+* We would still need IRQs off, because we don't want to change
+* the local LDT after an IPI loaded a newer value than the one
+* that we can see.
+*/
+
+   if (unlikely(ldt))
+   set_ldt(ldt->entries, ldt->size);
+   else
+   clear_LDT();
+
+   DEBUG_LOCKS_WARN_ON(preemptible());
+}
+
+/*
  * Used for LDT copy/destruction.
  */
 int init_new_context(struct task_struct *tsk, struct mm_struct *mm);
@@ -63,7 +107,7 @@ static inline void switch_mm(struct mm_struct *prev, struct 
mm_struct *next,

[Xen-devel] [PATCH 3/8] xen/arm: Fix comment coding style in handle_node in domain_build.c

[Julien Grall]

Only coding style changes. No functional changes.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/domain_build.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index f7ea240..651d75e 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1226,8 +1226,10 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
 return 0;
 }
 
-/* Replace these nodes with our own. Note that the original may be
- * used_by DOMID_XEN so this check comes first. */
+/*
+ * Replace these nodes with our own. Note that the original may be
+ * used_by DOMID_XEN so this check comes first.
+ */
 if ( device_get_class(node) == DEVICE_GIC )
 return make_gic_node(d, kinfo->fdt, node);
 if ( dt_match_node(timer_matches, node) )
@@ -1240,7 +1242,8 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
 return 0;
 }
 
-/* Even if the IOMMU device is not used by Xen, it should not be
+/*
+ * Even if the IOMMU device is not used by Xen, it should not be
  * passthrough to DOM0
  */
 if ( device_get_class(node) == DEVICE_IOMMU )
-- 
2.1.4


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

[Xen-devel] [PATCH 6/8] xen/arm: gic: Check the size of the CPU and vCPU interface retrieved from DT

[Julien Grall]

The size of the CPU interface will used in a follow-up patch to map the
region in Xen memory.

Based on GICv2 spec, the CPU interface should at least be 8KB, although
most of the platform we are supporting use the GICv1 size (i.e 4KB) in
their DT. Only warn and update the size to avoid any breakage on these
platforms.

Furthermore, Xen is relying on the Virtual CPU interface been at least
8KB. As in reality the Virtual CPU interface match the CPU interface,
check that the 2 interfaces have the same size. Also only warn, to avoid
any breakage with buggy DT.

For GICv3, only allow GICv2 compatibility when the Virtual CPU interface
and CPU interface are 8KB.

Signed-off-by: Julien Grall 
---
Cc: Zoltan Kiss 

I haven't done any change in the gic-hip04 driver. I will let the
maintainers doing it if they feel it's necessary.
---
 xen/arch/arm/gic-v2.c | 34 ++
 xen/arch/arm/gic-v3.c | 22 +++---
 2 files changed, 49 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 5841e59..62583e7 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -617,14 +617,16 @@ static hw_irq_controller gicv2_guest_irq_type = {
 static int __init gicv2_init(void)
 {
 int res;
-paddr_t hbase, dbase, cbase, vbase;
+paddr_t hbase, dbase;
+paddr_t cbase, csize;
+paddr_t vbase, vsize;
 const struct dt_device_node *node = gicv2_info.node;
 
 res = dt_device_get_address(node, 0, &dbase, NULL);
 if ( res )
 panic("GICv2: Cannot find a valid address for the distributor");
 
-res = dt_device_get_address(node, 1, &cbase, NULL);
+res = dt_device_get_address(node, 1, &cbase, &csize);
 if ( res )
 panic("GICv2: Cannot find a valid address for the CPU");
 
@@ -632,7 +634,7 @@ static int __init gicv2_init(void)
 if ( res )
 panic("GICv2: Cannot find a valid address for the hypervisor");
 
-res = dt_device_get_address(node, 3, &vbase, NULL);
+res = dt_device_get_address(node, 3, &vbase, &vsize);
 if ( res )
 panic("GICv2: Cannot find a valid address for the virtual CPU");
 
@@ -641,7 +643,31 @@ static int __init gicv2_init(void)
 panic("GICv2: Cannot find the maintenance IRQ");
 gicv2_info.maintenance_irq = res;
 
-/* TODO: Add check on distributor, cpu size */
+/* TODO: Add check on distributor */
+
+/*
+ * The GICv2 CPU interface should at least be 8KB. Although, most of the DT
+ * doesn't correctly set it and use the GICv1 CPU interface size (i.e 4KB).
+ * Warn and then fixup.
+ */
+if ( csize < SZ_8K )
+{
+printk(XENLOG_WARNING "GICv2: WARNING: "
+   "The CPU interface size is wrong: %#"PRIx64
+   " expected %#x\n",
+   csize, SZ_8K);
+csize = SZ_8K;
+}
+
+/*
+ * Check if the CPU interface and virtual CPU interface have the
+ * same size.
+ */
+if ( csize != vbase )
+printk(XENLOG_WARNING "GICv2: WARNING: "
+   "The size of the CPU interface (%#"PRIpaddr") and the vCPU"
+   " interface (%#"PRIpaddr") doesn't match\n",
+   csize, vsize);
 
 printk("GICv2 initialization:\n"
   "gic_dist_addr=%"PRIpaddr"\n"
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 957e491..4c58baf 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1143,22 +1143,38 @@ static void __init gicv3_init_v2(const struct 
dt_device_node *node,
  paddr_t dbase)
 {
 int res;
-paddr_t cbase, vbase;
+paddr_t cbase, csize;
+paddr_t vbase, vsize;
 
 /*
  * For GICv3 supporting GICv2, GICC and GICV base address will be
  * provided.
  */
 res = dt_device_get_address(node, 1 + gicv3.rdist_count,
-&cbase, NULL);
+&cbase, &csize);
 if ( res )
 return;
 
 res = dt_device_get_address(node, 1 + gicv3.rdist_count + 2,
-&vbase, NULL);
+&vbase, &vsize);
 if ( res )
 return;
 
+/*
+ * Only allow support of GICv2 compatible when the CPU interface
+ * and virtual CPU interface are 8KB
+ * XXX: Handle other size?
+ */
+if ( csize != SZ_8K && vsize != SZ_8K )
+{
+printk(XENLOG_WARNING
+   "GICv3: WARNING: Don't enable support of GICv2.\n"
+   "The size of the CPU interface (%#"PRIpaddr") and the vCPU"
+   " interface (%#"PRIpaddr") should be 8KB.\n",
+   csize, vsize);
+return;
+}
+
 printk("GICv3 compatible with GICv2 cbase %#"PRIpaddr" vbase 
%#"PRIpaddr"\n",
cbase, vbase);
 
-- 
2.1.4


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

[Xen-devel] [PATCH 2/8] xen/arm: Retrieve the correct number of cells when building dom0 DT

[Julien Grall]

The function dt_n_*_cells will retrieve the number of cells for a given
node. Those numbers may not be correct to use for the child "reg"
property if the parent is passed.

This is fine today because the parent is always the root node which
means there is no upper parent.

Introduce new helpers dt_child_n_*_cells to retrieve the number of
cells for the address and size that can be used to create the "reg"
property of a child of a given parent.

Use the new helpers when creating the hypervisor and memory node where
we only have the parent in hand. This is because those nodes are
recreated from scratch by Xen and therefore we don't have a
dt_device_node for them. The only thing we have is a pointer to there
future parent.

We also have to modify dt_set_range to take a parent in parameter rather
than an HW DT node that we will replicated in the DOM0 DT.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/domain_build.c   |  6 +++---
 xen/arch/arm/gic-v3.c |  4 ++--
 xen/common/device_tree.c  | 38 +++---
 xen/include/xen/device_tree.h | 23 +--
 4 files changed, 57 insertions(+), 14 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index a059de6..f7ea240 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -569,7 +569,7 @@ static int make_memory_node(const struct domain *d,
 const struct kernel_info *kinfo)
 {
 int res, i;
-int reg_size = dt_n_addr_cells(parent) + dt_n_size_cells(parent);
+int reg_size = dt_child_n_addr_cells(parent) + 
dt_child_n_size_cells(parent);
 int nr_cells = reg_size*kinfo->mem.nr_banks;
 __be32 reg[nr_cells];
 __be32 *cells;
@@ -617,8 +617,8 @@ static int make_hypervisor_node(const struct kernel_info 
*kinfo,
 __be32 *cells;
 int res;
 /* Convenience alias */
-int addrcells = dt_n_addr_cells(parent);
-int sizecells = dt_n_size_cells(parent);
+int addrcells = dt_child_n_addr_cells(parent);
+int sizecells = dt_child_n_size_cells(parent);
 void *fdt = kinfo->fdt;
 
 DPRINT("Create hypervisor node\n");
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 0df4baf..957e491 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1096,10 +1096,10 @@ static int gicv3_make_hwdom_dt_node(const struct domain 
*d,
 
 tmp = new_cells;
 
-dt_set_range(&tmp, gic, d->arch.vgic.dbase, SZ_64K);
+dt_set_range(&tmp, gic->parent, d->arch.vgic.dbase, SZ_64K);
 
 for ( i = 0; i < d->arch.vgic.nr_regions; i++ )
-dt_set_range(&tmp, gic, d->arch.vgic.rdist_regions[i].base,
+dt_set_range(&tmp, gic->parent, d->arch.vgic.rdist_regions[i].base,
  d->arch.vgic.rdist_regions[i].size);
 
 res = fdt_property(fdt, "reg", new_cells, len);
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 18cdb6f..845cc77 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -110,11 +110,11 @@ void dt_set_cell(__be32 **cellp, int size, u64 val)
 (*cellp) += cells;
 }
 
-void dt_set_range(__be32 **cellp, const struct dt_device_node *np,
+void dt_set_range(__be32 **cellp, const struct dt_device_node *parent,
   u64 address, u64 size)
 {
-dt_set_cell(cellp, dt_n_addr_cells(np), address);
-dt_set_cell(cellp, dt_n_size_cells(np), size);
+dt_set_cell(cellp, dt_child_n_addr_cells(parent), address);
+dt_set_cell(cellp, dt_child_n_size_cells(parent), size);
 }
 
 static void __init *unflatten_dt_alloc(unsigned long *mem, unsigned long size,
@@ -386,13 +386,15 @@ dt_find_matching_node(struct dt_device_node *from,
 return NULL;
 }
 
-int dt_n_addr_cells(const struct dt_device_node *np)
+static int __dt_n_addr_cells(const struct dt_device_node *np, bool_t parent)
 {
 const __be32 *ip;
 
 do {
-if ( np->parent )
+if ( np->parent && !parent )
 np = np->parent;
+parent = false;
+
 ip = dt_get_property(np, "#address-cells", NULL);
 if ( ip )
 return be32_to_cpup(ip);
@@ -401,13 +403,15 @@ int dt_n_addr_cells(const struct dt_device_node *np)
 return DT_ROOT_NODE_ADDR_CELLS_DEFAULT;
 }
 
-int dt_n_size_cells(const struct dt_device_node *np)
+int __dt_n_size_cells(const struct dt_device_node *np, bool_t parent)
 {
 const __be32 *ip;
 
 do {
-if ( np->parent )
+if ( np->parent && !parent )
 np = np->parent;
+parent = false;
+
 ip = dt_get_property(np, "#size-cells", NULL);
 if ( ip )
 return be32_to_cpup(ip);
@@ -416,6 +420,26 @@ int dt_n_size_cells(const struct dt_device_node *np)
 return DT_ROOT_NODE_SIZE_CELLS_DEFAULT;
 }
 
+int dt_n_addr_cells(const struct dt_device_node *np)
+{
+return __dt_n_addr_cells(np, false);
+}
+
+int dt_n_size_cells(const struct dt_device_node *np)
+{
+return __dt_n_size_cells(np, false);
+}
+
+int dt_child_n_addr

[Xen-devel] [PATCH 1/8] xen/arm: gic: Make clear the GIC node is passed to make_hwdom_dt_node

[Julien Grall]

The callback make_hwdom_dt_node already have the gic node in parameter.

Rather than using a weird mix between "dt_interrupt_controller" (aliased
to "gic") and "node", rename the callback parameter "node" to "gic".

Signed-off-by: Julien Grall 
---
 xen/arch/arm/gic-hip04.c  | 5 ++---
 xen/arch/arm/gic-v2.c | 5 ++---
 xen/arch/arm/gic-v3.c | 9 -
 xen/arch/arm/gic.c| 6 --
 xen/include/asm-arm/gic.h | 5 +++--
 5 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/xen/arch/arm/gic-hip04.c b/xen/arch/arm/gic-hip04.c
index c5ed545..e8cdcd4 100644
--- a/xen/arch/arm/gic-hip04.c
+++ b/xen/arch/arm/gic-hip04.c
@@ -562,10 +562,9 @@ static void hip04gic_irq_set_affinity(struct irq_desc 
*desc, const cpumask_t *cp
 }
 
 static int hip04gic_make_hwdom_dt_node(const struct domain *d,
-   const struct dt_device_node *node,
+   const struct dt_device_node *gic,
void *fdt)
 {
-const struct dt_device_node *gic = dt_interrupt_controller;
 const void *compatible;
 u32 len;
 const __be32 *regs;
@@ -598,7 +597,7 @@ static int hip04gic_make_hwdom_dt_node(const struct domain 
*d,
 return -FDT_ERR_XEN(ENOENT);
 }
 
-len = dt_cells_to_size(dt_n_addr_cells(node) + dt_n_size_cells(node));
+len = dt_cells_to_size(dt_n_addr_cells(gic) + dt_n_size_cells(gic));
 len *= 2;
 
 res = fdt_property(fdt, "reg", regs, len);
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 596126d..5841e59 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -552,10 +552,9 @@ static void gicv2_irq_set_affinity(struct irq_desc *desc, 
const cpumask_t *cpu_m
 }
 
 static int gicv2_make_hwdom_dt_node(const struct domain *d,
-const struct dt_device_node *node,
+const struct dt_device_node *gic,
 void *fdt)
 {
-const struct dt_device_node *gic = dt_interrupt_controller;
 const void *compatible = NULL;
 u32 len;
 const __be32 *regs;
@@ -584,7 +583,7 @@ static int gicv2_make_hwdom_dt_node(const struct domain *d,
 return -FDT_ERR_XEN(ENOENT);
 }
 
-len = dt_cells_to_size(dt_n_addr_cells(node) + dt_n_size_cells(node));
+len = dt_cells_to_size(dt_n_addr_cells(gic) + dt_n_size_cells(gic));
 len *= 2;
 
 res = fdt_property(fdt, "reg", regs, len);
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index d1db1ce..0df4baf 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1054,10 +1054,9 @@ static void gicv3_irq_set_affinity(struct irq_desc 
*desc, const cpumask_t *mask)
 }
 
 static int gicv3_make_hwdom_dt_node(const struct domain *d,
-const struct dt_device_node *node,
+const struct dt_device_node *gic,
 void *fdt)
 {
-const struct dt_device_node *gic = dt_interrupt_controller;
 const void *compatible = NULL;
 uint32_t len;
 __be32 *new_cells, *tmp;
@@ -1084,7 +1083,7 @@ static int gicv3_make_hwdom_dt_node(const struct domain 
*d,
 if ( res )
 return res;
 
-len = dt_cells_to_size(dt_n_addr_cells(node) + dt_n_size_cells(node));
+len = dt_cells_to_size(dt_n_addr_cells(gic) + dt_n_size_cells(gic));
 /*
  * GIC has two memory regions: Distributor + rdist regions
  * CPU interface and virtual cpu interfaces accessesed as System registers
@@ -1097,10 +1096,10 @@ static int gicv3_make_hwdom_dt_node(const struct domain 
*d,
 
 tmp = new_cells;
 
-dt_set_range(&tmp, node, d->arch.vgic.dbase, SZ_64K);
+dt_set_range(&tmp, gic, d->arch.vgic.dbase, SZ_64K);
 
 for ( i = 0; i < d->arch.vgic.nr_regions; i++ )
-dt_set_range(&tmp, node, d->arch.vgic.rdist_regions[i].base,
+dt_set_range(&tmp, gic, d->arch.vgic.rdist_regions[i].base,
  d->arch.vgic.rdist_regions[i].size);
 
 res = fdt_property(fdt, "reg", new_cells, len);
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 1757193..1e1e5ba 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -702,10 +702,12 @@ void __cpuinit init_maintenance_interrupt(void)
 }
 
 int gic_make_hwdom_dt_node(const struct domain *d,
-   const struct dt_device_node *node,
+   const struct dt_device_node *gic,
void *fdt)
 {
-return gic_hw_ops->make_hwdom_dt_node(d, node, fdt);
+ASSERT(gic == dt_interrupt_controller);
+
+return gic_hw_ops->make_hwdom_dt_node(d, gic, fdt);
 }
 
 /*
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index d343abf..6d53f97 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -350,13 +350,14 @@ struct gic_hw_operations {
 unsigned int (*read_apr)(int apr_reg);
 /* Secondary CPU init */

[Xen-devel] [PATCH 8/8] xen/arm: platform: Drop the quirks callback

[Julien Grall]

All the quirks has been replaced by proper detection. Lets drop the
callback and hope that no one will need new quirks.

At the same time, remove the definition platform_dom0_evtchn_ppi with is
not used any more.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/platform.c| 10 --
 xen/include/asm-arm/platform.h |  8 
 2 files changed, 18 deletions(-)

diff --git a/xen/arch/arm/platform.c b/xen/arch/arm/platform.c
index 0af6d57..b0bfaa9 100644
--- a/xen/arch/arm/platform.c
+++ b/xen/arch/arm/platform.c
@@ -127,16 +127,6 @@ void platform_poweroff(void)
 platform->poweroff();
 }
 
-bool_t platform_has_quirk(uint32_t quirk)
-{
-uint32_t quirks = 0;
-
-if ( platform && platform->quirks )
-quirks = platform->quirks();
-
-return !!(quirks & quirk);
-}
-
 bool_t platform_device_is_blacklisted(const struct dt_device_node *node)
 {
 const struct dt_device_match *blacklist = NULL;
diff --git a/xen/include/asm-arm/platform.h b/xen/include/asm-arm/platform.h
index 5e462ac..f97315d 100644
--- a/xen/include/asm-arm/platform.h
+++ b/xen/include/asm-arm/platform.h
@@ -27,12 +27,6 @@ struct platform_desc {
 /* Platform power-off */
 void (*poweroff)(void);
 /*
- * Platform quirks
- * Defined has a function because a platform can support multiple
- * board with different quirk on each
- */
-uint32_t (*quirks)(void);
-/*
  * Platform blacklist devices
  * List of devices which must not pass-through to a guest
  */
@@ -48,9 +42,7 @@ int platform_cpu_up(int cpu);
 #endif
 void platform_reset(void);
 void platform_poweroff(void);
-bool_t platform_has_quirk(uint32_t quirk);
 bool_t platform_device_is_blacklisted(const struct dt_device_node *node);
-unsigned int platform_dom0_evtchn_ppi(void);
 
 #define PLATFORM_START(_name, _namestr) \
 static const struct platform_desc  __plat_desc_##_name __used   \
-- 
2.1.4


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

[Xen-devel] [PATCH 5/8] xen/arm: vgic-v2: Drop cbase from arch_domain

[Julien Grall]

The field value is only used within a single function in the vgic-v2
emulation. So it's not necessary to store the value in the domain
structure.

This is also saving 8 bytes on a structure which begin to be constrained
(the maximum size of struct domain is 4KB).

Signed-off-by: Julien Grall 
---
 xen/arch/arm/vgic-v2.c   | 11 ++-
 xen/include/asm-arm/domain.h |  1 -
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index fa71598..ecd6bf3 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -546,6 +546,7 @@ static int vgic_v2_vcpu_init(struct vcpu *v)
 static int vgic_v2_domain_init(struct domain *d)
 {
 int i, ret;
+paddr_t cbase;
 
 /*
  * The hardware domain gets the hardware address.
@@ -554,12 +555,12 @@ static int vgic_v2_domain_init(struct domain *d)
 if ( is_hardware_domain(d) )
 {
 d->arch.vgic.dbase = vgic_v2_hw.dbase;
-d->arch.vgic.cbase = vgic_v2_hw.cbase;
+cbase = vgic_v2_hw.cbase;
 }
 else
 {
 d->arch.vgic.dbase = GUEST_GICD_BASE;
-d->arch.vgic.cbase = GUEST_GICC_BASE;
+cbase = GUEST_GICC_BASE;
 }
 
 /*
@@ -569,16 +570,16 @@ static int vgic_v2_domain_init(struct domain *d)
  * The second page is always mapped at +4K irrespective of the
  * GIC_64K_STRIDE quirk. The DTB passed to the guest reflects this.
  */
-ret = map_mmio_regions(d, paddr_to_pfn(d->arch.vgic.cbase), 1,
+ret = map_mmio_regions(d, paddr_to_pfn(cbase), 1,
paddr_to_pfn(vgic_v2_hw.vbase));
 if ( ret )
 return ret;
 
 if ( !platform_has_quirk(PLATFORM_QUIRK_GIC_64K_STRIDE) )
-ret = map_mmio_regions(d, paddr_to_pfn(d->arch.vgic.cbase + PAGE_SIZE),
+ret = map_mmio_regions(d, paddr_to_pfn(cbase + PAGE_SIZE),
1, paddr_to_pfn(vgic_v2_hw.vbase + PAGE_SIZE));
 else
-ret = map_mmio_regions(d, paddr_to_pfn(d->arch.vgic.cbase + PAGE_SIZE),
+ret = map_mmio_regions(d, paddr_to_pfn(cbase + PAGE_SIZE),
1, paddr_to_pfn(vgic_v2_hw.vbase + SZ_64K));
 
 if ( ret )
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index c3f5a95..ba430a7 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -101,7 +101,6 @@ struct arch_domain
 struct pending_irq *pending_irqs;
 /* Base address for guest GIC */
 paddr_t dbase; /* Distributor base address */
-paddr_t cbase; /* CPU base address */
 #ifdef HAS_GICV3
 /* GIC V3 addressing */
 /* List of contiguous occupied by the redistributors */
-- 
2.1.4


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

[Xen-devel] [PATCH 7/8] xen/arm: gic-v2: Detect automatically aliased GIC400

[Julien Grall]

We are currently using a per-platform quirk to know if the 2 4KB region of
the GIC CPU interface are each aligned to 64KB. Although, it may be
possible to have different layout on a same platform (depending on the
firmware version).

Rather than having a quirk it's possible to detect by reading the GIC
memory. This patch is based from the Linux commit "irqchip/GIC: Add workaround
for aliased GIC400" [1].

Take the opportunity to clean up the GICv2 of code which was only
required because of the quirk.

Note that none of the platform using the gic-hip04 where actually using
the quirk, so the code has been dropped. I will let the maintainers
decide whether it's relevant or not to add proper detection for aliased
GIC for this hardware.

[1] commit 12e14066f4835f5ee1ca795f0309415b54c067a9
Author: Marc Zyngier 
Date:   Sun Sep 13 12:14:31 2015 +0100

irqchip/GIC: Add workaround for aliased GIC400

The GICv2 architecture mandates that the two 4kB GIC regions are
contiguous, and on two separate physical pages (so that access to
the second page can be trapped by a hypervisor). This doesn't work
very well when PAGE_SIZE is 64kB.

A relatively common hack^Wway to work around this is to alias each
4kB region over its own 64kB page. Of course in this case, the base
address you want to use is not really the begining of the region,
but base + 60kB (so that you get a contiguous 8kB region over two
distinct pages).

Normally, this would be described in DT with a new property, but
some HW is already out there, and the firmware makes sure that
it will override whatever you put in the GIC node. Duh. And of course,
said firmware source code is not available, despite being based
on u-boot.

The workaround is to detect the case where the CPU interface size
is set to 128kB, and verify the aliasing by checking that the ID
register for GIC400 (which is the only GIC wired this way so far)
is the same at base and base + 0xF000. In this case, we update
the GIC base address and let it roll.

And if you feel slightly sick by looking at this, rest assured that
I do too...

Reported-by: Julien Grall 
Signed-off-by: Marc Zyngier 
Cc: linux-arm-ker...@lists.infradead.org
Cc: Stuart Yoder 
Cc: Pavel Fedin 
Cc: Jason Cooper 
Link: 
http://lkml.kernel.org/r/1442142873-20213-2-git-send-email-marc.zyng...@arm.com
Signed-off-by: Thomas Gleixner 

Signed-off-by: Julien Grall 
---
Cc: Zoltan Kiss 
---
 xen/arch/arm/gic-hip04.c | 13 +++-
 xen/arch/arm/gic-v2.c| 59 ++--
 xen/arch/arm/gic-v3.c|  3 +-
 xen/arch/arm/platforms/xgene-storm.c |  6 
 xen/arch/arm/vgic-v2.c   | 48 ++---
 xen/include/asm-arm/gic.h|  1 +
 xen/include/asm-arm/platform.h   |  6 
 xen/include/asm-arm/vgic.h   |  3 +-
 8 files changed, 83 insertions(+), 56 deletions(-)

diff --git a/xen/arch/arm/gic-hip04.c b/xen/arch/arm/gic-hip04.c
index e8cdcd4..ac2912a 100644
--- a/xen/arch/arm/gic-hip04.c
+++ b/xen/arch/arm/gic-hip04.c
@@ -631,14 +631,14 @@ static hw_irq_controller hip04gic_guest_irq_type = {
 static int __init hip04gic_init(void)
 {
 int res;
-paddr_t hbase, dbase, cbase, vbase;
+paddr_t hbase, dbase, cbase, csize, vbase;
 const struct dt_device_node *node = gicv2_info.node;
 
 res = dt_device_get_address(node, 0, &dbase, NULL);
 if ( res )
 panic("GIC-HIP04: Cannot find a valid address for the distributor");
 
-res = dt_device_get_address(node, 1, &cbase, NULL);
+res = dt_device_get_address(node, 1, &cbase, &csize);
 if ( res )
 panic("GIC-HIP04: Cannot find a valid address for the CPU");
 
@@ -675,11 +675,7 @@ static int __init hip04gic_init(void)
 panic("GIC-HIP04: Failed to ioremap for GIC distributor\n");
 
 gicv2.map_cbase[0] = ioremap_nocache(cbase, PAGE_SIZE);
-
-if ( platform_has_quirk(PLATFORM_QUIRK_GIC_64K_STRIDE) )
-gicv2.map_cbase[1] = ioremap_nocache(cbase + SZ_64K, PAGE_SIZE);
-else
-gicv2.map_cbase[1] = ioremap_nocache(cbase + PAGE_SIZE, PAGE_SIZE);
+gicv2.map_cbase[1] = ioremap_nocache(cbase + PAGE_SIZE, PAGE_SIZE);
 
 if ( !gicv2.map_cbase[0] || !gicv2.map_cbase[1] )
 panic("GIC-HIP04: Failed to ioremap for GIC CPU interface\n");
@@ -688,7 +684,8 @@ static int __init hip04gic_init(void)
 if ( !gicv2.map_hbase )
 panic("GIC-HIP04: Failed to ioremap for GIC Virtual interface\n");
 
-vgic_v2_setup_hw(dbase, cbase, vbase);
+/* XXX: Support aliased HIP04 GIC? */
+vgic_v2_setup_hw(dbase, cbase, csize, vbase, 0);
 
 /* Global settings: interrupt distributor */
 spin_lock_init(&gicv2.lock);
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 62583e7..b60bd9b 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -65,7 +65,7 @@
 /* Global

[Xen-devel] [PATCH 0/8] xen/arm: gic-v2: Detect automatically aliased GIC400

[Julien Grall]

Hi all,

Only patch #7 is related to subject. The others are clean up of code I looked
while I was working on this series.

Regards,

Julien Grall (8):
  xen/arm: gic: Make clear the GIC node is passed to make_hwdom_dt_node
  xen/arm: Retrieve the correct number of cells when building dom0 DT
  xen/arm: Fix comment coding style in handle_node in domain_build.c
  xen/arm: Warn when a device tree path will be re-used by Xen
  xen/arm: vgic-v2: Drop cbase from arch_domain
  xen/arm: gic: Check the size of the CPU and vCPU interface retrieved
from DT
  xen/arm: gic-v2: Detect automatically aliased GIC400
  xen/arm: platform: Drop the quirks callback

 xen/arch/arm/domain_build.c  | 30 ---
 xen/arch/arm/gic-hip04.c | 18 +++
 xen/arch/arm/gic-v2.c| 98 +++-
 xen/arch/arm/gic-v3.c| 34 +
 xen/arch/arm/gic.c   |  6 ++-
 xen/arch/arm/platform.c  | 10 
 xen/arch/arm/platforms/xgene-storm.c |  6 ---
 xen/arch/arm/vgic-v2.c   | 51 ---
 xen/common/device_tree.c | 38 +++---
 xen/include/asm-arm/domain.h |  1 -
 xen/include/asm-arm/gic.h|  6 ++-
 xen/include/asm-arm/platform.h   | 14 --
 xen/include/asm-arm/vgic.h   |  3 +-
 xen/include/xen/device_tree.h| 23 -
 14 files changed, 225 insertions(+), 113 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH 4/8] xen/arm: Warn when a device tree path will be re-used by Xen

[Julien Grall]

Xen is using unconditionnally some device tree path to create DOM0
specific node (for instance /psci, /memory and /hypervisor).

Rather than blindly add new nodes with the same, print a warning message
on the console to let know the user that something may go wrong.

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

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 651d75e..2670431 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1205,6 +1205,13 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
 DT_MATCH_TIMER,
 { /* sentinel */ },
 };
+static const struct dt_device_match reserved_matches[] __initconst =
+{
+DT_MATCH_PATH("/psci"),
+DT_MATCH_PATH("/memory"),
+DT_MATCH_PATH("/hypervisor"),
+{ /* sentinel */ },
+};
 struct dt_device_node *child;
 int res;
 const char *name;
@@ -1252,6 +1259,14 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
 return 0;
 }
 
+/*
+ * Xen is using some path for its own purpose. Warn if a node
+ * already exists with the same path.
+ */
+if ( dt_match_node(reserved_matches, node) )
+printk(XENLOG_WARNING "WARNING: Path %s is reserved, skip the node\n",
+   path);
+
 res = handle_device(d, node);
 if ( res)
 return res;
-- 
2.1.4


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

[Xen-devel] [PATCH 0/2] x86/hvm: Improvements to HAP superpage feature detection

[Andrew Cooper]

Two small patches which reduce the runtime overhead of detecting HAP
superpages by moving more initialisation into __init.

Noticed while reviewing "x86/p2m: use large pages for MMIO mappings".

Andrew Cooper (2):
  x86/hvm: Refine hap_has_{2mb,1gb} checks
  x86/hvm: Fold opt_hap_{2mb,1gb} into hap_capabilities

 xen/arch/x86/hvm/hvm.c|8 
 xen/arch/x86/mm/p2m-ept.c |4 ++--
 xen/arch/x86/mm/p2m.c |   10 --
 xen/include/asm-x86/hvm/hvm.h |6 ++
 4 files changed, 16 insertions(+), 12 deletions(-)

-- 
1.7.10.4


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

[Xen-devel] [PATCH 2/2] x86/hvm: Fold opt_hap_{2mb, 1gb} into hap_capabilities

[Andrew Cooper]

This allows all runtime users to simply check hap_has_{2mb,1gb} rather than
having to check opt_hap_{2mb,1gb} as well.

As a result, opt_hap_{2mb,1gb} can move into __initdata.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: George Dunlap 
---
 xen/arch/x86/hvm/hvm.c |8 
 xen/arch/x86/mm/p2m.c  |   10 --
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index f082b86..6afc344 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -158,9 +158,17 @@ static int __init hvm_enable(void)
 printk("HVM: Hardware Assisted Paging (HAP) detected\n");
 printk("HVM: HAP page sizes: 4kB");
 if ( fns->hap_capabilities & HVM_HAP_SUPERPAGE_2MB )
+{
 printk(", 2MB%s", opt_hap_2mb ? "" : " [disabled]");
+if ( !opt_hap_2mb )
+hvm_funcs.hap_capabilities &= ~HVM_HAP_SUPERPAGE_2MB;
+}
 if ( fns->hap_capabilities & HVM_HAP_SUPERPAGE_1GB )
+{
 printk(", 1GB%s", opt_hap_1gb ? "" : " [disabled]");
+if ( !opt_hap_1gb )
+hvm_funcs.hap_capabilities &= ~HVM_HAP_SUPERPAGE_1GB;
+}
 printk("\n");
 }
 
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 9cf7a71..5d2a532 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -41,11 +41,9 @@
 
 #include "mm-locks.h"
 
-/* turn on/off 1GB host page table support for hap, default on */
-bool_t __read_mostly opt_hap_1gb = 1;
+/* turn on/off host superpage page table support for hap, default on */
+bool_t __initdata opt_hap_1gb = 1, __initdata opt_hap_2mb = 1;
 boolean_param("hap_1gb", opt_hap_1gb);
-
-bool_t __read_mostly opt_hap_2mb = 1;
 boolean_param("hap_2mb", opt_hap_2mb);
 
 
@@ -452,9 +450,9 @@ int p2m_set_entry(struct p2m_domain *p2m, unsigned long 
gfn, mfn_t mfn,
 {
 if ( hap_enabled(d) )
 order = ( (((gfn | mfn_x(mfn) | todo) & ((1ul << PAGE_ORDER_1G) - 
1)) == 0) &&
-  hap_has_1gb && opt_hap_1gb) ? PAGE_ORDER_1G :
+  hap_has_1gb) ? PAGE_ORDER_1G :
   gfn | mfn_x(mfn) | todo) & ((1ul << PAGE_ORDER_2M) - 
1)) == 0) &&
-  hap_has_2mb && opt_hap_2mb) ? PAGE_ORDER_2M : 
PAGE_ORDER_4K;
+  hap_has_2mb) ? PAGE_ORDER_2M : PAGE_ORDER_4K;
 else
 order = 0;
 
-- 
1.7.10.4


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

[Xen-devel] [PATCH 1/2] x86/hvm: Refine hap_has_{2mb,1gb} checks

[Andrew Cooper]

HAP superpages are a host property and not dependent on domain configuration.
Drop the domain paramter (which was only used in one of the two callsites),
and drop the redundant hvm_ prefix to mirror the cpu_has_* style of feature
detection.

Finally, convert the checks to being proper booleans rather than just non-zero
integers.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: George Dunlap 
---
 xen/arch/x86/mm/p2m-ept.c |4 ++--
 xen/arch/x86/mm/p2m.c |4 ++--
 xen/include/asm-x86/hvm/hvm.h |6 ++
 3 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 58db34e..dde242e 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -696,8 +696,8 @@ bool_t ept_handle_misconfig(uint64_t gpa)
 if ( ret > 0 )
 needs_sync = sync_on;
 
-ASSERT((target == 2 && hvm_hap_has_1gb()) ||
-   (target == 1 && hvm_hap_has_2mb()) ||
+ASSERT((target == 2 && hap_has_1gb) ||
+   (target == 1 && hap_has_2mb) ||
(target == 0));
 ASSERT(!p2m_is_foreign(p2mt) || target == 0);
 
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index e1d930a..9cf7a71 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -452,9 +452,9 @@ int p2m_set_entry(struct p2m_domain *p2m, unsigned long 
gfn, mfn_t mfn,
 {
 if ( hap_enabled(d) )
 order = ( (((gfn | mfn_x(mfn) | todo) & ((1ul << PAGE_ORDER_1G) - 
1)) == 0) &&
-  hvm_hap_has_1gb(d) && opt_hap_1gb ) ? PAGE_ORDER_1G :
+  hap_has_1gb && opt_hap_1gb) ? PAGE_ORDER_1G :
   gfn | mfn_x(mfn) | todo) & ((1ul << PAGE_ORDER_2M) - 
1)) == 0) &&
-  hvm_hap_has_2mb(d) && opt_hap_2mb) ? PAGE_ORDER_2M : 
PAGE_ORDER_4K;
+  hap_has_2mb && opt_hap_2mb) ? PAGE_ORDER_2M : 
PAGE_ORDER_4K;
 else
 order = 0;
 
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index 9f49e6d..2c3192c 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -278,10 +278,8 @@ int vmsi_deliver(
 (!!((v)->arch.hvm_vcpu.guest_efer & EFER_NX))
 
 /* Can we use superpages in the HAP p2m table? */
-#define hvm_hap_has_1gb(d) \
-(hvm_funcs.hap_capabilities & HVM_HAP_SUPERPAGE_1GB)
-#define hvm_hap_has_2mb(d) \
-(hvm_funcs.hap_capabilities & HVM_HAP_SUPERPAGE_2MB)
+#define hap_has_1gb !!(hvm_funcs.hap_capabilities & HVM_HAP_SUPERPAGE_1GB)
+#define hap_has_2mb !!(hvm_funcs.hap_capabilities & HVM_HAP_SUPERPAGE_2MB)
 
 /* Can the guest use 1GB superpages in its own pagetables? */
 #define hvm_pse1gb_supported(d) \
-- 
1.7.10.4


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

[Xen-devel] [PATCH v2] xen/x86: Record xsave features in c->x86_capabilities

[Andrew Cooper]

Convert existing cpu_has_x??? to being functions of boot_cpu_data (matching
the prevailing style), and mask out unsupported features.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Shuai Ruan 

v2:
 * Reuse word 2 rather than introducing word 8
 * Remove bsp check when validating homogeneity

This is another patch from my feature levelling series which is being posted
early because of interactions with other code.

Shuai: This patch will interact with your xsaves series, although I hope it
will make your series easier.
---
 xen/arch/x86/cpu/common.c|2 +-
 xen/arch/x86/traps.c |5 +
 xen/arch/x86/xstate.c|   30 ++
 xen/include/asm-x86/cpufeature.h |   11 ++-
 xen/include/asm-x86/xstate.h |8 ++--
 5 files changed, 24 insertions(+), 32 deletions(-)

diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 35ef21b..0be0656 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -311,7 +311,7 @@ void __cpuinit identify_cpu(struct cpuinfo_x86 *c)
clear_bit(X86_FEATURE_XSAVE, boot_cpu_data.x86_capability);
 
if ( cpu_has_xsave )
-   xstate_init(c == &boot_cpu_data);
+   xstate_init(c);
 
/*
 * The vendor-specific functions might have changed features.  Now
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 9f5a6c6..07feb6d 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -935,10 +935,7 @@ void pv_cpuid(struct cpu_user_regs *regs)
 goto unsupported;
 if ( regs->_ecx == 1 )
 {
-a &= XSTATE_FEATURE_XSAVEOPT |
- XSTATE_FEATURE_XSAVEC |
- (cpu_has_xgetbv1 ? XSTATE_FEATURE_XGETBV1 : 0) |
- (cpu_has_xsaves ? XSTATE_FEATURE_XSAVES : 0);
+a &= boot_cpu_data.x86_capability[X86_FEATURE_XSAVEOPT / 32];
 if ( !cpu_has_xsaves )
 b = c = d = 0;
 }
diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
index d5f5e3b..9ddff90 100644
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -14,11 +14,6 @@
 #include 
 #include 
 
-static bool_t __read_mostly cpu_has_xsaveopt;
-static bool_t __read_mostly cpu_has_xsavec;
-bool_t __read_mostly cpu_has_xgetbv1;
-bool_t __read_mostly cpu_has_xsaves;
-
 /*
  * Maximum size (in byte) of the XSAVE/XRSTOR save area required by all
  * the supported and enabled features on the processor, including the
@@ -281,8 +276,9 @@ unsigned int xstate_ctxt_size(u64 xcr0)
 }
 
 /* Collect the information of processor's extended state */
-void xstate_init(bool_t bsp)
+void xstate_init(struct cpuinfo_x86 *c)
 {
+bool_t bsp = c == &boot_cpu_data;
 u32 eax, ebx, ecx, edx;
 u64 feature_mask;
 
@@ -325,20 +321,14 @@ void xstate_init(bool_t bsp)
 
 /* Check extended XSAVE features. */
 cpuid_count(XSTATE_CPUID, 1, &eax, &ebx, &ecx, &edx);
-if ( bsp )
-{
-cpu_has_xsaveopt = !!(eax & XSTATE_FEATURE_XSAVEOPT);
-cpu_has_xsavec = !!(eax & XSTATE_FEATURE_XSAVEC);
-/* XXX cpu_has_xgetbv1 = !!(eax & XSTATE_FEATURE_XGETBV1); */
-/* XXX cpu_has_xsaves = !!(eax & XSTATE_FEATURE_XSAVES); */
-}
-else
-{
-BUG_ON(!cpu_has_xsaveopt != !(eax & XSTATE_FEATURE_XSAVEOPT));
-BUG_ON(!cpu_has_xsavec != !(eax & XSTATE_FEATURE_XSAVEC));
-/* XXX BUG_ON(!cpu_has_xgetbv1 != !(eax & XSTATE_FEATURE_XGETBV1)); */
-/* XXX BUG_ON(!cpu_has_xsaves != !(eax & XSTATE_FEATURE_XSAVES)); */
-}
+
+/* Mask out features not currently understood by Xen. */
+eax &= (cpufeat_mask(X86_FEATURE_XSAVEOPT) |
+cpufeat_mask(X86_FEATURE_XSAVEC));
+
+c->x86_capability[X86_FEATURE_XSAVEOPT / 32] = eax;
+
+BUG_ON(eax != boot_cpu_data.x86_capability[X86_FEATURE_XSAVEOPT / 32]);
 }
 
 static bool_t valid_xcr0(u64 xcr0)
diff --git a/xen/include/asm-x86/cpufeature.h b/xen/include/asm-x86/cpufeature.h
index 9a01563..6a94724 100644
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -57,7 +57,11 @@
 #define X86_FEATURE_3DNOWEXT   (1*32+30) /* AMD 3DNow! extensions */
 #define X86_FEATURE_3DNOW  (1*32+31) /* 3DNow! */
 
-/* *** Available for re-use ***, word 2 */
+/* Intel-defined CPU features, CPUID level 0x000D:1 (eax), word 2 */
+#define X86_FEATURE_XSAVEOPT   (2*32+ 0) /* XSAVEOPT instruction. */
+#define X86_FEATURE_XSAVEC (2*32+ 1) /* XSAVEC/XRSTORC instructions. */
+#define X86_FEATURE_XGETBV1(2*32+ 2) /* XGETBV with %ecx=1. */
+#define X86_FEATURE_XSAVES (2*32+ 3) /* XSAVES/XRSTORS instructions. */
 
 /* Other features, Linux-defined mapping, word 3 */
 /* This range is used for feature bits which conflict or are synthesized */
@@ -219,6 +223,11 @@
 
 #define cpu_has_cx16boot_cpu_has(X86_FEATURE_CX16)
 
+#define cpu_has_xsaveopt   boot_cpu_has(X86_FEATURE_XSAVEOPT)
+#define cpu_has_xsavec boot_cpu_h

Re: [Xen-devel] [PATCH v2 21/23] x86/boot: implement early command line parser in C

[Daniel Kiper]

On Thu, Aug 27, 2015 at 06:43:39AM -0600, Jan Beulich wrote:
> >>> On 20.07.15 at 16:29,  wrote:
> > 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 and much easier
> > to maintain.
>
> All appreciated and nice, but the goal of making the code
> relocatable by playing with segment registers sounds fragile:
> This breaks assumptions the compiler may validly make.

Well, it looks that this sentence is not precise. I should fix this.
Anyway, I am not playing with segment registers in C code because
it is not needed and as you pointed out it is dangerous.

> >  xen/arch/x86/boot/cmdline.S|  367 -
> >  xen/arch/x86/boot/cmdline.c|  396 
> > 
>
> A fundamental expectation I would have had is for the C file to be
> noticeably smaller than the assembly file.
>
> > --- /dev/null
> > +++ b/xen/arch/x86/boot/cmdline.c
> >[...]
> > +#define VESA_WIDTH 0
> > +#define VESA_HEIGHT1
> > +#define VESA_DEPTH 2
> > +
> > +#define VESA_SIZE  3
>
> These should go away in favor of using individual (sub)structure fields.
>
> > +#define __cdecl__attribute__((__cdecl__))
>
> ???

Please look below.

> > +#define __packed   __attribute__((__packed__))
> > +#define __text __attribute__((__section__(".text")))
> > +#define __used __attribute__((__used__))
>
> Likely better to include compiler.h instead.

As I know you do not like to include such headers in early C files
because it makes code fragile and it looks strange. I agree with you
to some extent. So, I decided to define needed constants ourselves.
Whatever we do we should be consistent. Hence, if we include compiler.h
here we should do the same in reloc.c too if it is required.

> > +#define max(x,y) ({ \
> > +const typeof(x) _x = (x);   \
> > +const typeof(y) _y = (y);   \
> > +(void) (&_x == &_y);\
> > +_x > _y ? _x : _y; })
>
> I also wonder whether -imacros .../xen/kernel.h wouldn't be a better
> approach here. Please really think hard on how to avoid duplications
> like these.

Ditto. So, what is your decision? Include or define? If include then
we should think how to generate relevant dependencies automatically.

> > +#define strlen_static(s) (sizeof(s) - 1)
>
> What is this good for? A decent compiler should be able to deal with
> strlen("..."). Plus your macro is longer that what it tries to "abbreviate".

I thought that it is true but it is not. Sadly, without this binary is 
bigger... :-(((
However, you are right that the name could be better.

> > +static const char empty_chars[] __text = " \n\r\t";
>
> What is empty about them? DYM blank or (white) space or separator
> or delimiter? I also wonder whether \n and \r are actually usefully here,

Yep, delimiter or something like that looks better.

> as they should (if at all) only end the line.

Yes, I included them just in case and they should not appear in command line.

> > +static const char *find_opt(const char *cmdline, const char *opt, int arg)
> > +{
> > +size_t lc, lo;
> > +static const char mm[] __text = "--";
>
> I'd be surprised if there weren't compiler/assembler versions
> complaining about a section type conflict here. I can see why you
> want everything in one section, but I'd rather suggest achieving
> this at the linking step (which I would suppose to already be taking
> care of this).

Nope, it does not work in that way. However, I discovered that newer GCC
versions generate .rodata for switch/case. So, anyway we must cope with
at least two different sections and link them properly.

> > +static u8 skip_realmode(const char *cmdline)
> > +{
> > +static const char nrm[] __text = "no-real-mode";
> > +static const char tboot[] __text = "tboot=";
> > +
> > +if ( find_opt(cmdline, nrm, 0) || find_opt(cmdline, tboot, 1) )
> > +return 1;
> > +
> > +return 0;
>
> return find_opt(cmdline, nrm, 0) || find_opt(cmdline, tboot, 1);
>
> > +static u8 edd_parse(const char *cmdline)
> > +{
> > +const char *c;
> > +size_t la;
> > +static const char edd[] __text = "edd=";
> > +static const char edd_off[] __text = "off";
> > +static const char edd_skipmbr[] __text = "skipmbr";
> > +
> > +c = find_opt(cmdline, edd, 1);
> > +
> > +if ( !c )
> > +return 0;
> > +
> > +c += strlen_static(edd);
> > +la = strcspn(c, empty_chars);
> > +
> > +if ( !strncmp(c, edd_off, max(la, strlen_static(edd_off))) )
> > +return 2;
> > +else if ( !strncmp(c, edd_skipmbr, max(la, 
> > strlen_static(edd_skipmbr))) )
>
> Pointless else.
>
> > +return 1;
> > +
> > +return 0;
>
> And the last two returns can be folde

Re: [Xen-devel] Is: Make XENVER_* use XSM, seperate the different ops in smaller security domains. Was:Re: [PATCH v1 5/5] xsplice: Use ld-embedded build-ids

[Daniel De Graaf]

On 22/09/15 09:45, Konrad Rzeszutek Wilk wrote:

On Tue, Sep 22, 2015 at 02:33:23PM +0100, Andrew Cooper wrote:

On 22/09/15 14:22, Konrad Rzeszutek Wilk wrote:

On Fri, Sep 18, 2015 at 12:40:46PM +0100, Andrew Cooper wrote:

On 17/09/15 19:45, Konrad Rzeszutek Wilk wrote:

. snip..

The build id of the current running hypervisor should belong in the
xeninfo hypercall.  It is not specific to xsplice.

However in the previous reviews it was pointed out that it should only be 
accessible to dom0.

Or to any domains as long as the XSM allows (and is turned on) - so not the 
default dummy one.

That is a bit of 'if' extra complexity which I am not sure is worth it?

DomU can already read the build information such as changeset, compile
time, etc.  Build-id is no more special or revealing.

I would take this as an argument *against* giving DomU access to those
pieces of information in details and not as an argument for
*additionally* giving it access to build-id.

With build-id we have the chance to shape a not-yet-established API and
I would like to follow the Principle of least privilege wherever it
makes sense.

To reach a similar security level with the existing API, it might make
sense to limit DomU access to compile date, compile time, compiled by,
compiled domain, compiler version and command line details, xen extra
version, and xen changeset.  Basically anything that might help DomUs to
uniquely identify a Xen build.

The approach can not directly drop access to those fields, as that would
break an existing API, but it could restrict the detail level handed out
to DomU.

These are all valid arguments to be made, but please lets fix the issue
properly rather than hacking build-id on the side of an unrelated component.

 From my point of view, the correct course of action is this:

* Split the current XSM model to contain separate attributes for general
and privileged information.
** For current compatibility, all existing XENVER_* subops fall into general
* Apply an XSM check at the very start of the hypercall.

That would introduce a performance regression I fear. Linux pvops does this:

/*
  * Force a proper event-channel callback from Xen after clearing the
  * callback mask. We do this in a very simple manner, by making a call
  * down into Xen. The pending flag will be checked by Xen on return.
  */
void xen_force_evtchn_callback(void)
{
 (void)HYPERVISOR_xen_version(0, NULL);
}

quite often, which now will have to do the XSM check which is extra code.


I would say that the XENVER_compile_info (/sys/hypervisor/compilation),
XENVER_changeset (/sys/hypervisor/compilation) should go over
the XSM check.

While:XENVER_version, XENVER_extraversion,XENVER_capabilities,
XENVER_platform_parameters, XENVER_get_features,XENVER_pagesize

should have no XSM check.


The XSM check will fall into the noise, performance wise, compared to the
context switch to make the hypercall in the first place.  It is just another
switch statement.  Also, selectively applying XSM checks will incur even
more overhead than doing a blanket XSM check.


I would be surprised if placing the XSM check inside the individual case
statement is more expensive than a single XSM check outside the switch:
in either case, it's either a single call or a single if statement, and
since there's only 10 cases (6 of which were identified as not needing a
check) it's not much code added either.

You could also define a bitmask of operations that require an XSM check
and do "if ((1 << cmd) & NEEDS_XSM_CHECK_BITMASK) { do_xsm_check() }".


I am worried about some spinlock in the depths of XSM code.

But then I haven't looked in detail so perhaps this is not an issue after all.


The XSM code tries to use read locks where possible to avoid this type of
performance hit, and if the call is being made as often as it sounds like,
the check will almost always hit the AVC cache (avoiding the more expensive
parts of the FLASK security server).  However, it's always faster to return
success right away (and no less secure if you were going to do so anyway).


Also, I really don't care if you can measure a performance hit (not that I
reckon you could).  How Linux chooses to behave itself has absolutely no
bearing on how we go about securing the hypercall.


But making something slower is surely not something we strive for.



~Andrew





--
Daniel De Graaf
National Security Agency

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

[Xen-devel] [PATCH for-4.6 1/2] libxl: fix devd removal path

[Roger Pau Monne]

The current flow of the devd helper (in charge of launching hotplug scripts
inside of driver domains) is to wait for the device backend to switch to
state 6 (XenbusStateClosed) and then remove it. This is not correct, since
a domain can reconnect it's PV devices as many times as it wants.

In order to fix this, introduce the following logic: the control domain will
set the "online" backend node to 0 when it wants the driver domain to
disconnect the device, so now the condition applied in devd is that "state"
must be 6 and "online" 0 in order to proceed with the disconnection.

Signed-off-by: Roger Pau Monné 
Reported-by: Alex Velazquez 
Cc: Alex Velazquez 
Cc: Ian Jackson 
Cc: Ian Campbell 
Cc: Wei Liu 
---
 tools/libxl/libxl.c| 38 --
 tools/libxl/libxl_device.c | 11 ++-
 2 files changed, 30 insertions(+), 19 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 10d1909..1d1917e 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4410,32 +4410,42 @@ static void backend_watch_callback(libxl__egc *egc, 
libxl__ev_xswatch *watch,
 libxl__ao *nested_ao = libxl__nested_ao_create(ddomain->ao);
 STATE_AO_GC(nested_ao);
 char *p, *path;
-const char *sstate;
-int state, rc, num_devs;
+const char *sstate, *sonline;
+int state, online, rc, num_devs;
 libxl__device *dev = NULL;
 libxl__ddomain_device *ddev = NULL;
 libxl__ddomain_guest *dguest = NULL;
 bool free_ao = false;
 
-/* Check if event_path ends with "state" and truncate it */
-if (strlen(event_path) < strlen("state"))
+/* Check if event_path ends with "state" or "online" and truncate it. */
+if (strlen(event_path) < strlen("state") ||
+strlen(event_path) < strlen("online"))
 goto skip;
 
 path = libxl__strdup(gc, event_path);
-p = path + strlen(path) - strlen("state") - 1;
-if (*p != '/')
-goto skip;
-*p = '\0';
-p++;
-if (strcmp(p, "state") != 0)
-goto skip;
+p = strstr(path, "/state");
+if (p != NULL) {
+*p = '\0';
+} else {
+p = strstr(path, "/online");
+if (p == NULL)
+goto skip;
+*p = '\0';
+}
 
-/* Check if the state is 1 (XenbusStateInitialising) or greater */
-rc = libxl__xs_read_checked(gc, XBT_NULL, event_path, &sstate);
+/* Fetch the value of the state and online nodes. */
+rc = libxl__xs_read_checked(gc, XBT_NULL, GCSPRINTF("%s/state", path),
+&sstate);
 if (rc || !sstate)
 goto skip;
 state = atoi(sstate);
 
+rc = libxl__xs_read_checked(gc, XBT_NULL, GCSPRINTF("%s/online", path),
+&sonline);
+if (rc || !sonline)
+goto skip;
+online = atoi(sonline);
+
 dev = libxl__zalloc(NOGC, sizeof(*dev));
 rc = libxl__parse_backend_path(gc, path, dev);
 if (rc)
@@ -4477,7 +4487,7 @@ static void backend_watch_callback(libxl__egc *egc, 
libxl__ev_xswatch *watch,
 rc = add_device(egc, nested_ao, dguest, ddev);
 if (rc > 0)
 free_ao = true;
-} else if (state == XenbusStateClosed) {
+} else if (state == XenbusStateClosed && online == 0) {
 /*
  * Removal of an active device, remove it from the list and
  * free it's data structures if they are no longer needed.
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index bee5ed5..51da10e 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -837,16 +837,17 @@ void libxl__initiate_device_remove(libxl__egc *egc,
 goto out;
 }
 
+rc = libxl__xs_write_checked(gc, t, online_path, "0");
+if (rc) {
+LOG(ERROR, "unable to write to xenstore path %s", online_path);
+goto out;
+}
+
 /*
  * Check if device is already in "closed" state, in which case
  * it should not be changed.
  */
  if (state && atoi(state) != XenbusStateClosed) {
-rc = libxl__xs_write_checked(gc, t, online_path, "0");
-if (rc) {
-LOG(ERROR, "unable to write to xenstore path %s", online_path);
-goto out;
-}
 rc = libxl__xs_write_checked(gc, t, state_path, GCSPRINTF("%d", 
XenbusStateClosing));
 if (rc) {
 LOG(ERROR, "unable to write to xenstore path %s", state_path);
-- 
1.9.5 (Apple Git-50.3)


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

Re: [Xen-devel] Is: Make XENVER_* use XSM, seperate the different ops in smaller security domains. Was:Re: [PATCH v1 5/5] xsplice: Use ld-embedded build-ids

[Daniel De Graaf]

On 17/09/15 14:45, Konrad Rzeszutek Wilk wrote:

. snip..

The build id of the current running hypervisor should belong in the
xeninfo hypercall.  It is not specific to xsplice.

However in the previous reviews it was pointed out that it should only be 
accessible to dom0.

Or to any domains as long as the XSM allows (and is turned on) - so not the 
default dummy one.

That is a bit of 'if' extra complexity which I am not sure is worth it?

DomU can already read the build information such as changeset, compile
time, etc.  Build-id is no more special or revealing.

I would take this as an argument *against* giving DomU access to those
pieces of information in details and not as an argument for
*additionally* giving it access to build-id.

With build-id we have the chance to shape a not-yet-established API and
I would like to follow the Principle of least privilege wherever it
makes sense.

To reach a similar security level with the existing API, it might make
sense to limit DomU access to compile date, compile time, compiled by,
compiled domain, compiler version and command line details, xen extra
version, and xen changeset.  Basically anything that might help DomUs to
uniquely identify a Xen build.

The approach can not directly drop access to those fields, as that would
break an existing API, but it could restrict the detail level handed out
to DomU.


These are all valid arguments to be made, but please lets fix the issue
properly rather than hacking build-id on the side of an unrelated component.

 From my point of view, the correct course of action is this:

* Split the current XSM model to contain separate attributes for general
and privileged information.
** For current compatibility, all existing XENVER_* subops fall into general
* Apply an XSM check at the very start of the hypercall.
* Extend do_xen_version() to take 3 parameters.  (It is curious that it
didn't take a length parameter before)
** This is still ABI compatible, as existing subops simply ignore the
parameter.


Or we can just use 1024 bytes space the XENVER_* use.


* Introduce new XENVER_build_id subop which is documented to require the
3-parameter version of the hypercall.
** This subop falls into straight into privileged information.

This will introduce build-id in its correct location, with appropriate
restrictions.

Moving forwards, we really should have an audit of the existing XENVER_*
subops.  Some are clearly safe/required for domU to read, but some such
as XENVER_commandline have no business being accessible.  A separate
argument, from the repeatable build point of view, says that compilation
information isn't useful at all.

Depending on how we wish to fix the issue, we could either do a blanket
move of the subops into the privileged XSM catagory, or introduce a 3rd
"legacy privileged" category to allow the admin to control access on a
per-vm basis.


CC-ing Daniel. Changing title.


With XSM enabled, I think the correct thing to do is to have a distinct
permission so that an admin can do per-VM controls.  Without XSM enabled,
how common is the case where some VMs need to get this information and
some need it hidden?  A global (command line controlled?) enable of the
feature for domUs seems like a reasonable solution if this is uncommon.

As far as the xsm_default_t value, this is really what XSM_OTHER is for,
but if there are going to be many instances of this type of data, a new
value like XSM_PRIV_INFOLEAK could be introduced.

--
Daniel De Graaf
National Security Agency

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

[Xen-devel] [PATCH for-4.6 0/2] libxl: devd fixes

[Roger Pau Monne]

The following patches fix an error when reconnecting a device that's handled 
by a driver domain and a possible race when doing the cleanup of the backend 
path.

I think both should be included in 4.6, since this a regression as compared 
to using udev inside of the driver domain.

Roger.

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

Re: [Xen-devel] [PATCH for-4.6 2/2] libxl: fix the cleanup of the backend path when using driver domains

[Ian Jackson]

Roger Pau Monne writes ("[PATCH for-4.6 2/2] libxl: fix the cleanup of the 
backend path when using driver domains"):
> With the current libxl implementation the control domain will remove both
> the frontend and the backend xenstore paths of a device that's handled by a
> driver domain. This is incorrect, since the driver domain possibly needs to
> access the backend path in order to perform the disconnection and cleanup of
> the device.
> 
> Fix this by making sure the control domain only cleans the frontend path,
> leaving the backend path to be cleaned by the driver domain. Note that if
> the device is not handled by a driver domain the control domain will perform
> the removal of both the frontend and the backend paths.
> 
> Signed-off-by: Roger Pau Monné 
> Reported-by: Alex Velazquez 

Acked-by: Ian Jackson 

I would like to have a second review before committing, and also we
should wait for a release ack from Wei.

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH RFC] xen: if on Xen, "flatten" the scheduling domain hierarchy

[George Dunlap]

On 09/22/2015 05:42 AM, Juergen Gross wrote:
> One other thing I just discovered: there are other consumers of the
> topology sibling masks (e.g. topology_sibling_cpumask()) as well.
> 
> I think we would want to avoid any optimizations based on those in
> drivers as well, not only in the scheduler.

I'm beginning to lose the thread of the discussion here a bit.

Juergen / Dario, could one of you summarize your two approaches, and the
(alleged) advantages and disadvantages of each one?

Thanks,
 -George

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

Re: [Xen-devel] [PATCH OSSTEST] make_qcow2: Look for qemu-img under /usr as well as /usr/local

[Ian Jackson]

(CCing Stefano)

Ian Campbell writes ("Re: [PATCH OSSTEST] make_qcow2: Look for qemu-img under 
/usr as well as /usr/local"):
> On Tue, 2015-09-22 at 16:41 +0100, Ian Jackson wrote:
> > Ian Campbell writes ("[PATCH OSSTEST] make_qcow2: Look for qemu-img under
> > /usr as well as /usr/local"):
> > > Older Xen's installed in /usr by default, so we need to check where
> > > qemu-img if we want these tests to work on those versions.
> > 
> > Acked-by: Ian Jackson 
> > 
> > But, why are we executing a utility from /usr/lib/xen/bin ?  If this
> > utility is useful to osstest it is presumably useful to users too, and
> > in that case it should be on PATH (under some suitable name).
> 
> We install qemu-upstream under our own prefix, I think to avoid conficting
> with the users own qemu installations?
> 
> qemu-img comes from there. We do install qemu-xen-img (from trad) into
> $PATH, but when I wrote this test I thought it preferable to use qemu-img.

Maybe we should be installing qemu-img from our qemu upstream build
instead ?

We evidently don't think that there is anything in the qcow block
system in trad that we like, because we are only using upstream for
qdisk vbd backends now.

Ian.

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

Re: [Xen-devel] falha para instalar VM

[Julio Cesar Begalli]

Mai algumas informações:

soemrjoc:/backup/SOEM # rpm -qa | grep xen
xen-libs-4.2.2_06-0.7.1
xen-tools-4.2.2_06-0.7.1
kernel-xen-base-3.0.101-0.47.52.1
kernel-xen-3.0.101-0.47.52.1
xen-4.2.5_06-0.7.1
soemrjoc:/backup/SOEM #
soemrjoc:/backup/SOEM #
soemrjoc:/backup/SOEM # uname -r
3.0.101-0.47.52-xen
soemrjoc:/backup/SOEM #

From: Julio Cesar Begalli
Sent: terça-feira, 22 de setembro de 2015 11:53
To: 'xen-devel@lists.xen.org'
Subject: falha para instalar VM

Olá,

Estou tentando instalar um windons 7 dendro de uma VM no Linux,só que já tentei 
e não consigo,aparece a falha abaixo,voces podem me ajudar por favor ?

Grato,Júlio


[cid:image001.png@01D0F52D.92514F00]
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.6 1/2] libxl: fix devd removal path

[Ian Jackson]

Roger Pau Monne writes ("[PATCH for-4.6 1/2] libxl: fix devd removal path"):
> The current flow of the devd helper (in charge of launching hotplug scripts
> inside of driver domains) is to wait for the device backend to switch to
> state 6 (XenbusStateClosed) and then remove it. This is not correct, since
> a domain can reconnect it's PV devices as many times as it wants.

Oops.  Thanks for investigating.

> +p = strstr(path, "/state");
> +if (p != NULL) {
> +*p = '\0';
> +} else {
> +p = strstr(path, "/online");
> +if (p == NULL)
> +goto skip;
> +*p = '\0';
> +}

I don't think this is correct.  You could use strrstr, I guess.  But
it would probably be better to strrchr '/' and then strcmp the result
with /online and/or /state ?

> +rc = libxl__xs_write_checked(gc, t, online_path, "0");
> +if (rc) {
> +LOG(ERROR, "unable to write to xenstore path %s", online_path);
> +goto out;

libxl__xs_write_checked logs on error so this is redundant (I
appreciate that it was there before...)

Ian.

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

Re: [Xen-devel] [PATCH] x86/p2m: add PoD accounting to set_typed_p2m_entry()

[George Dunlap]

On 09/22/2015 02:01 PM, Jan Beulich wrote:
> While neither PoD together with pass-through nor PVH are currently
> supported we still shouldn't leave in place such latent issues.
> 
> Signed-off-by: Jan Beulich 
> Reviewed-by: Tim Deegan 

Acked-by: George Dunlap 


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

[Xen-devel] [PATCH for-4.6 2/2] libxl: fix the cleanup of the backend path when using driver domains

[Roger Pau Monne]

With the current libxl implementation the control domain will remove both
the frontend and the backend xenstore paths of a device that's handled by a
driver domain. This is incorrect, since the driver domain possibly needs to
access the backend path in order to perform the disconnection and cleanup of
the device.

Fix this by making sure the control domain only cleans the frontend path,
leaving the backend path to be cleaned by the driver domain. Note that if
the device is not handled by a driver domain the control domain will perform
the removal of both the frontend and the backend paths.

Signed-off-by: Roger Pau Monné 
Reported-by: Alex Velazquez 
Cc: Alex Velazquez 
Cc: Ian Jackson 
Cc: Ian Campbell 
Cc: Wei Liu 
---
 tools/libxl/libxl_device.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 51da10e..6035c6e 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -595,8 +595,8 @@ int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
  * frontend and the backend path
  */
 libxl__xs_path_cleanup(gc, t, fe_path);
-libxl__xs_path_cleanup(gc, t, be_path);
-} else if (dev->backend_domid == domid) {
+}
+if (dev->backend_domid == domid) {
 /*
  * The driver domain is in charge for removing what it can
  * from the backend path
-- 
1.9.5 (Apple Git-50.3)


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

[Xen-devel] OutreachY round 11 - Please add new sensible projects

[Lars Kurth]

Hi everyone,

most of http://wiki.xenproject.org/wiki/Outreach_Program_Projects has been 
scrubbed and out-of-date projects removed. 

I also restructured http://wiki.xenproject.org/wiki/Outreachy/Round11 to make 
it easier to
a) Navigate the right mailing list, IRC channel
b) Make it easier to identify "SMALL CODE CONTRIBUTIONS" projects prior to 
application 

However, now we do have very few Hypervisor projects and NO XAPI projects. 

I think we are fine on Mirage OS projects and I added links to 
https://github.com/mirage/mirage-www/wiki/Pioneer-Projects (although I don't 
know how up-to-date these are).

Best Regards
Lars

> On 17 Sep 2015, at 14:00, Lars Kurth  wrote:
> 
> Hi all,
> 
> the AB is sponsoring 2 interns again for the winter round
> 
> This means we need to update the following pages by September 28
> * All: http://wiki.xenproject.org/wiki/Outreach_Program_Projects - aka add 
> new projects/remove old ones
> * MirageOS: http://wiki.xenproject.org/wiki/Outreach_Program_Projects has 
> projects in it - are these still valid, or are they replaced by 
> https://github.com/mirage/mirage-www/wiki/Pioneer-Projects ?
> 
> Everyone who has a project on that list is on the TO list. Please update the 
> "Verified" line and add the current date to each project with your name 
> against it. Feel free to add new projects.
> 
> {{project
> ...
> |Verified=02/13/2015
> ...
> }}
> 
> I will purge *all* projects which have not been verified.
> 
> = Timeline =
> September 28 organizations' landing pages need to be ready with project ideas
> September 29 application process opens
> November 2 application deadline
> November 17 accepted applicants announced
> December 7 - March 7 internship dates
> 
> = Xen Resources =
> http://wiki.xenproject.org/wiki/Outreachy/Round11
> 
> Regards
> Lars
> 


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

Re: [Xen-devel] [OSSTest Nested v12 20/21] Don't lvextend if actually no more space to extend

[Ian Jackson]

Ian Campbell writes ("Re: [OSSTest Nested v12 20/21] Don't lvextend if actually 
no more space to extend"):
> On Wed, 2015-09-16 at 15:27 +0100, Ian Jackson wrote:
> > I think this should be done by moving the start of the if block to
> > after overall_limit_pe.  That would avoid a tested if (and various
> > other slight anomalies).
> 
> IOW move the overall_limit_pe outside the if? 
> 
> Like so:
> 
> diff --git a/ts-xen-build-prep b/ts-xen-build-prep
> index 03ad35c..b35e91b 100755
> --- a/ts-xen-build-prep
> +++ b/ts-xen-build-prep
> @@ -151,9 +151,9 @@ sub lvextend1 ($$$) {
>  
>  $do_limit_pe->(\$vg_more_free_pe, 'unstriped');
>  
> +overall_limit_pe(\$vg_more_free_pe);
>  if ($vg_more_free_pe) {
>  logm("$what: unstriped $vg_more_free_pe PEs");
> -overall_limit_pe(\$vg_more_free_pe);
>  $more_pe += $vg_more_free_pe;
>  target_cmd_root($ho, "lvextend -i1 -l +$vg_more_free_pe $lv");
>  }
> 
> (untested, but I've just tripped over this in a standalone run myself).

Yes.  With a suitable commit message:

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH V2 1/2] xen, libxc: Fine grained control of REP emulation optimizations

[Razvan Cojocaru]

On 09/22/2015 06:39 PM, Jan Beulich wrote:
 On 22.09.15 at 17:28,  wrote:
>> On 09/22/2015 06:17 PM, Jan Beulich wrote:
>> On 21.09.15 at 15:31,  wrote:
 --- a/xen/arch/x86/hvm/emulate.c
 +++ b/xen/arch/x86/hvm/emulate.c
 @@ -514,7 +514,8 @@ static int hvmemul_virtual_to_linear(
   * being triggered for repeated writes to a whole page.
   */
  *reps = min_t(unsigned long, *reps,
 -  
 unlikely(current->domain->arch.mem_access_emulate_enabled)
 +  
 unlikely(current->domain->arch.mem_access_emulate_enabled &&
 +   
 current->domain->arch.mem_access_emulate_each_rep)
 ? 1 : 4096);
>>>
>>> unlikely() should not wrap compound conditions, or else its effect of
>>> eliminating mis-predicted branches from the fast path won't be
>>> achieved. In the case here I wonder though whether you couldn't
>>> simply test only ->arch.mem_access_emulate_each_rep.
>>
>> I'll unfold the unlikely().
>>
>> Testing only ->arch.mem_access_emulate_each_rep is what I had done in
>> the original patch, however on Andrew Cooper's suggestion I've now gated
>> this on ->domain->arch.mem_access_emulate_enabled as well.
>>
>> Otherwise, somebody might set mem_access_emulate_each_rep via its
>> xc_monitor_*() call, but then after calling xc_monitor_disable() it
>> would still be in effect, even if the guest is no longer being monitored.
>>
>> If this is not a problem, I'm happy to check just
>> ->arch.mem_access_emulate_each_rep.
> 
> Or perhaps "disabled" should just clear that flag, also to not surprise
> the next one to "enable"?

Fair point, I'll do that.


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH v3] xen/xsm: Make p->policyvers be a local variable (ver) to shut up GCC 5.1.1 warnings.

[Daniel De Graaf]

On 16/09/15 15:57, Konrad Rzeszutek Wilk wrote:

policydb.c: In function ‘user_read’:
policydb.c:1443:26: error: ‘buf[2]’ may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
  usrdatum->bounds = le32_to_cpu(buf[2]);
   ^
cc1: all warnings being treated as errors

Which (as Andrew mentioned) is because GCC cannot assume
that 'p->policyvers' has the same value between checks.

We make it local, optimize the name to 'ver' and the warnings go away.
We also update another call site with this modification to
make it more inline with the rest of the functions.

Signed-off-by: Konrad Rzeszutek Wilk 


Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [PATCH OSSTEST] make_qcow2: Look for qemu-img under /usr as well as /usr/local

[Ian Jackson]

Ian Campbell writes ("[PATCH OSSTEST] make_qcow2: Look for qemu-img under /usr 
as well as /usr/local"):
> Older Xen's installed in /usr by default, so we need to check where
> qemu-img if we want these tests to work on those versions.

Acked-by: Ian Jackson 

But, why are we executing a utility from /usr/lib/xen/bin ?  If this
utility is useful to osstest it is presumably useful to users too, and
in that case it should be on PATH (under some suitable name).

Ian.

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

Re: [Xen-devel] [PATCH v2 20/23] x86: add multiboot2 protocol support for EFI platforms

[Jan Beulich]

>>> On 22.09.15 at 17:21,  wrote:
> On Thu, Aug 27, 2015 at 06:01:26AM -0600, Jan Beulich wrote:
>> >>> On 20.07.15 at 16:29,  wrote:
>> > @@ -130,6 +146,119 @@ print_err:
>> >  .Lhalt: hlt
>> >  jmp .Lhalt
>> >
>> > +.code64
>> > +
>> > +__efi64_start:
>> > +cld
>> > +
>> > +/* Check for Multiboot2 bootloader. */
>> > +cmp $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
>> > +je  efi_multiboot2_proto
>> > +
>> > +/* Jump to not_multiboot after switching CPU to x86_32 mode. */
>> > +lea not_multiboot(%rip),%rdi
>> > +jmp x86_32_switch
>> > +
>> > +efi_multiboot2_proto:
>>
>> .L
> 
> Why do you want to hide labels which could be useful during debugging?

With a few exceptions, assembly code should follow C and other
high level languages: Symbol table entries only at function
boundaries (or whatever their suitable counterparts in assembly
are).

>> > +x86_32_switch:
>> > +cli
>> > +
>> > +/* Initialise GDT. */
>> > +lgdtgdt_boot_descr(%rip)
>> > +
>> > +/* Reload code selector. */
>> > +ljmpl   *cs32_switch_addr(%rip)
>> > +
>> > +.code32
>> > +
>> > +cs32_switch:
>> > +/* Initialise basic data segments. */
>> > +mov $BOOT_DS,%edx
>> > +mov %edx,%ds
>> > +mov %edx,%es
>> > +mov %edx,%fs
>> > +mov %edx,%gs
>> > +mov %edx,%ss
>>
>> I see no point in loading %fs and %gs with other than nul selectors.
>> I also think %ss should be loaded first. Which reminds me - what
>> about %rsp? Is it guaranteed to have its upper 32 bits clear, so you
>> can re-use the stack in 32-bit mode? (If it is, saying so in a comment
>> would be very desirable.)
> 
> I am not reusing %rsp value. %esp is initialized later in 32-bit code.
> Stack is not used until %esp is not initialized.

If you load %ss without loading the stack pointer, you should imo
at least add a comment saying when/where the other half will be
done.

>> > --- a/xen/common/efi/boot.c
>> > +++ b/xen/common/efi/boot.c
>> > @@ -79,6 +79,17 @@ static size_t wstrlen(const CHAR16 * s);
>> >  static int set_color(u32 mask, int bpp, u8 *pos, u8 *sz);
>> >  static bool_t match_guid(const EFI_GUID *guid1, const EFI_GUID *guid2);
>> >
>> > +static void efi_init(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
>> > *SystemTable);
>> > +static void efi_console_set_mode(void);
>> > +static EFI_GRAPHICS_OUTPUT_PROTOCOL *efi_get_gop(void);
>> > +static UINTN efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
>> > +   UINTN cols, UINTN rows, UINTN depth);
>> > +static void efi_tables(void);
>> > +static void setup_efi_pci(void);
>> > +static void efi_variables(void);
>> > +static void efi_set_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop, UINTN 
>> > gop_mode);
>> > +static void efi_exit_boot(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
>> > *SystemTable);
>>
>> This is ugly; I'm sure there is a way to avoid these declarations.
> 
> This probably requires play with '#include "efi-boot.h"' and move
> somewhere before efi_start(). Maybe something else. If it is not
> a problem for you I can do that.

Indeed moving an #include would seem far better than adding almost
a dozen declarations (any of which will need to get touched if the
respective definition changes, i.e. arranging for future churn).

Jan


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

Re: [Xen-devel] [PATCH OSSTEST] make_qcow2: Look for qemu-img under /usr as well as /usr/local

[Ian Campbell]

On Tue, 2015-09-22 at 16:41 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST] make_qcow2: Look for qemu-img under
> /usr as well as /usr/local"):
> > Older Xen's installed in /usr by default, so we need to check where
> > qemu-img if we want these tests to work on those versions.
> 
> Acked-by: Ian Jackson 
> 
> But, why are we executing a utility from /usr/lib/xen/bin ?  If this
> utility is useful to osstest it is presumably useful to users too, and
> in that case it should be on PATH (under some suitable name).

We install qemu-upstream under our own prefix, I think to avoid conficting
with the users own qemu installations?

qemu-img comes from there. We do install qemu-xen-img (from trad) into
$PATH, but when I wrote this test I thought it preferable to use qemu-img.

Ian.

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

Re: [Xen-devel] [OSSTest Nested v12 20/21] Don't lvextend if actually no more space to extend

[Ian Campbell]

On Wed, 2015-09-16 at 15:27 +0100, Ian Jackson wrote:
> Robert Ho writes ("[OSSTest Nested v12 20/21] Don't lvextend if actually
> no more space to extend"):
> > Though passes if judgement, the
> > overall_limit_pe(\$vg_more_free_pe);
> > may final judge no more free_pe to extend.
> > So, check if $vg_more_free_pe is 0, if so, we don't lvextend,
> > otherwise lvextend will report error on nonsense operation.
> 
> I think this should be done by moving the start of the if block to
> after overall_limit_pe.  That would avoid a tested if (and various
> other slight anomalies).

IOW move the overall_limit_pe outside the if? 

Like so:

diff --git a/ts-xen-build-prep b/ts-xen-build-prep
index 03ad35c..b35e91b 100755
--- a/ts-xen-build-prep
+++ b/ts-xen-build-prep
@@ -151,9 +151,9 @@ sub lvextend1 ($$$) {
 
 $do_limit_pe->(\$vg_more_free_pe, 'unstriped');
 
+overall_limit_pe(\$vg_more_free_pe);
 if ($vg_more_free_pe) {
 logm("$what: unstriped $vg_more_free_pe PEs");
-overall_limit_pe(\$vg_more_free_pe);
 $more_pe += $vg_more_free_pe;
 target_cmd_root($ho, "lvextend -i1 -l +$vg_more_free_pe $lv");
 }

(untested, but I've just tripped over this in a standalone run myself).

Ian.

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

Re: [Xen-devel] [OSSTEST PATCH 15/28] cr-daily-branch: Use mg-adjust-flight to have smoke tests reuse builds

[Ian Jackson]

Ian Campbell writes ("Re: [OSSTEST PATCH 15/28] cr-daily-branch: Use 
mg-adjust-flight to have smoke tests reuse builds"):
> On Tue, 2015-09-22 at 16:12 +0100, Ian Jackson wrote:
> 
> Title is missing -makexrefs?

Yes, fixed.

> > Signed-off-by: Ian Jackson 
> > Acked-by: Ian Campbell 
> 
> Reaffirmed.

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH V2 2/2] xen: Introduce VM_EVENT_FLAG_SET_REGISTERS

[Tamas K Lengyel]

On Tue, Sep 22, 2015 at 9:35 AM, Razvan Cojocaru 
wrote:

> On 09/22/2015 06:19 PM, Jan Beulich wrote:
>  On 21.09.15 at 15:31,  wrote:
> >> A previous version of this patch dealing with support for skipping
> >> the current instruction when a vm_event response requested it
> >> computed the instruction length in the hypervisor, adding non-trivial
> >> code dependencies. This patch allows a userspace vm_event client to
> >> simply request that the guest's EIP is set to an arbitary value,
> >> computed by the introspection application. In the future, other
> >> registers can also be set via a vm_event reply by using this flag.
> >> The VCPU needs to be paused for this flag to take effect.
> >>
> >> Signed-off-by: Razvan Cojocaru 
> >>
> >> ---
> >> Changes since V1:
> >>  - Renamed the patch (VM_EVENT_FLAG_SET_EIP ->
> >>VM_EVENT_FLAG_SET_REGISTERS).
> >>  - As suggested by Tamas Lengyel, EIP is now being set via a dedicated
> >>generic vm_event_set_registers() function that can be extended to
> >>set other registers in the future.
> >
> > Isn't it a bad move to call the thing "set registers" but have it set
> > just EIP? If going forward you were to add more registers, you'd
> > need new flags anyway I suppose, and hence the public interface
> > part of this should be reverted (while the other internal
> > abstraction seems fine to me).
>
> Well, the way I've read Tamas' request is that he'd like other registers
> to be set as well in vm_event_set_registers() (such as EAX, and so on) -
> but since I'm not sure what he'd like added and how to test his
> scenarios, I thought I could just set EIP for now, and either add what
> he's requesting in future versions of the series, or allow him to extend
> the code as needed with future patches.
>
> I think that the end goal for Tamas would be to just, if this flag is
> set, to set at least some of the registers that come back from the
> vm_event reply to the VCPU that caused the vm_event request.
>

Yeap, my idea would be to just set all registers to the values included in
the snapshot sent back by the user. If the user doesn't change a register
value in the snapshot he received, that register would effectively be reset
to the same value it already had. Not perfect but IMHO harmless and reduces
the code required to keep track of things.

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

Re: [Xen-devel] [PATCH V2 1/2] xen, libxc: Fine grained control of REP emulation optimizations

[Jan Beulich]

>>> On 22.09.15 at 17:28,  wrote:
> On 09/22/2015 06:17 PM, Jan Beulich wrote:
> On 21.09.15 at 15:31,  wrote:
>>> --- a/xen/arch/x86/hvm/emulate.c
>>> +++ b/xen/arch/x86/hvm/emulate.c
>>> @@ -514,7 +514,8 @@ static int hvmemul_virtual_to_linear(
>>>   * being triggered for repeated writes to a whole page.
>>>   */
>>>  *reps = min_t(unsigned long, *reps,
>>> -  
>>> unlikely(current->domain->arch.mem_access_emulate_enabled)
>>> +  
>>> unlikely(current->domain->arch.mem_access_emulate_enabled &&
>>> +   
>>> current->domain->arch.mem_access_emulate_each_rep)
>>> ? 1 : 4096);
>> 
>> unlikely() should not wrap compound conditions, or else its effect of
>> eliminating mis-predicted branches from the fast path won't be
>> achieved. In the case here I wonder though whether you couldn't
>> simply test only ->arch.mem_access_emulate_each_rep.
> 
> I'll unfold the unlikely().
> 
> Testing only ->arch.mem_access_emulate_each_rep is what I had done in
> the original patch, however on Andrew Cooper's suggestion I've now gated
> this on ->domain->arch.mem_access_emulate_enabled as well.
> 
> Otherwise, somebody might set mem_access_emulate_each_rep via its
> xc_monitor_*() call, but then after calling xc_monitor_disable() it
> would still be in effect, even if the guest is no longer being monitored.
> 
> If this is not a problem, I'm happy to check just
> ->arch.mem_access_emulate_each_rep.

Or perhaps "disabled" should just clear that flag, also to not surprise
the next one to "enable"?

Jan


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

Re: [Xen-devel] [PATCH V2 2/2] xen: Introduce VM_EVENT_FLAG_SET_REGISTERS

[Razvan Cojocaru]

On 09/22/2015 06:34 PM, Tamas K Lengyel wrote:
> 
> 
> On Tue, Sep 22, 2015 at 9:19 AM, Jan Beulich  > wrote:
> 
> >>> On 21.09.15 at 15:31,  > wrote:
> > A previous version of this patch dealing with support for skipping
> > the current instruction when a vm_event response requested it
> > computed the instruction length in the hypervisor, adding non-trivial
> > code dependencies. This patch allows a userspace vm_event client to
> > simply request that the guest's EIP is set to an arbitary value,
> > computed by the introspection application. In the future, other
> > registers can also be set via a vm_event reply by using this flag.
> > The VCPU needs to be paused for this flag to take effect.
> >
> > Signed-off-by: Razvan Cojocaru  >
> >
> > ---
> > Changes since V1:
> >  - Renamed the patch (VM_EVENT_FLAG_SET_EIP ->
> >VM_EVENT_FLAG_SET_REGISTERS).
> >  - As suggested by Tamas Lengyel, EIP is now being set via a dedicated
> >generic vm_event_set_registers() function that can be extended to
> >set other registers in the future.
> 
> Isn't it a bad move to call the thing "set registers" but have it set
> just EIP? If going forward you were to add more registers, you'd
> need new flags anyway I suppose, and hence the public interface
> part of this should be reverted (while the other internal
> abstraction seems fine to me).
> 
> Jan
> 
> 
> IMHO you should just add setting all registers included in the snapshot
> here rather then postpone it to a later patch.

Right, but setting some of the registers in the reply has side-effects
(such as the control registers), so I thought it better to not just try
to copy them if it's not needed (though I suppose we could check if the
new value differs from the old and only set it if it is at least).


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH v2 20/23] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

On Thu, Aug 27, 2015 at 06:01:26AM -0600, Jan Beulich wrote:
> >>> On 20.07.15 at 16:29,  wrote:
> > Signed-off-by: Daniel Kiper 
>
> For a patch of this size, no description at all seems rather
> problematic.
>
> > --- a/xen/arch/x86/boot/head.S
> > +++ b/xen/arch/x86/boot/head.S
> > @@ -89,6 +89,13 @@ multiboot1_header_end:
> > 0, /* Number of the lines - no preference. */ \
> > 0  /* Number of bits per pixel - no preference. */
> >
> > +/* Do not disable EFI boot services. */
> > +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)
>
> Iirc at least one of those two is what upstream doesn't have yet,
> or not all earlier grub2 versions might have. If so - what happens
> if the resulting Xen gets booted on an incapable grub? Silent death
> (with black screen)? Or at least some note to the user that the
> grub2 version is not suitable?

There is the code below which sends relevant message to COM1 and...
...well, VGA which of course does not make sense and should be fixed.

> > @@ -130,6 +146,119 @@ print_err:
> >  .Lhalt: hlt
> >  jmp .Lhalt
> >
> > +.code64
> > +
> > +__efi64_start:
> > +cld
> > +
> > +/* Check for Multiboot2 bootloader. */
> > +cmp $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
> > +je  efi_multiboot2_proto
> > +
> > +/* Jump to not_multiboot after switching CPU to x86_32 mode. */
> > +lea not_multiboot(%rip),%rdi
> > +jmp x86_32_switch
> > +
> > +efi_multiboot2_proto:
>
> .L

Why do you want to hide labels which could be useful during debugging?

> > +run_bs:
>
> Again.

Ditto.

> > +x86_32_switch:
> > +cli
> > +
> > +/* Initialise GDT. */
> > +lgdtgdt_boot_descr(%rip)
> > +
> > +/* Reload code selector. */
> > +ljmpl   *cs32_switch_addr(%rip)
> > +
> > +.code32
> > +
> > +cs32_switch:
> > +/* Initialise basic data segments. */
> > +mov $BOOT_DS,%edx
> > +mov %edx,%ds
> > +mov %edx,%es
> > +mov %edx,%fs
> > +mov %edx,%gs
> > +mov %edx,%ss
>
> I see no point in loading %fs and %gs with other than nul selectors.
> I also think %ss should be loaded first. Which reminds me - what
> about %rsp? Is it guaranteed to have its upper 32 bits clear, so you
> can re-use the stack in 32-bit mode? (If it is, saying so in a comment
> would be very desirable.)

I am not reusing %rsp value. %esp is initialized later in 32-bit code.
Stack is not used until %esp is not initialized.

[...]

> > --- a/xen/common/efi/boot.c
> > +++ b/xen/common/efi/boot.c
> > @@ -79,6 +79,17 @@ static size_t wstrlen(const CHAR16 * s);
> >  static int set_color(u32 mask, int bpp, u8 *pos, u8 *sz);
> >  static bool_t match_guid(const EFI_GUID *guid1, const EFI_GUID *guid2);
> >
> > +static void efi_init(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
> > *SystemTable);
> > +static void efi_console_set_mode(void);
> > +static EFI_GRAPHICS_OUTPUT_PROTOCOL *efi_get_gop(void);
> > +static UINTN efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
> > +   UINTN cols, UINTN rows, UINTN depth);
> > +static void efi_tables(void);
> > +static void setup_efi_pci(void);
> > +static void efi_variables(void);
> > +static void efi_set_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop, UINTN 
> > gop_mode);
> > +static void efi_exit_boot(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
> > *SystemTable);
>
> This is ugly; I'm sure there is a way to avoid these declarations.

This probably requires play with '#include "efi-boot.h"' and move
somewhere before efi_start(). Maybe something else. If it is not
a problem for you I can do that.

Daniel

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-qcow2 9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-raw   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail never 
pass
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-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-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-raw 11 migrate-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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-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-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-vhd   9 debian-di-installfail   never pass
 test-amd64-i386-libvirt-vhd   9 debian-di-installfail   never pass
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail   never pass
 test-amd64-i386-xl-vhd9 debian-di-installfail   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-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass

version targeted for testing:
 qemuu18640989a9f5e4d2e84b566c52ff1fccfa0dbf4a
baseline version:
 qemuufc04a730b7e60f4a62d6260d4eb9c537d1d3643f

Last test of basis61666  2015-09-09 03:07:40 Z   13 days
Failing since 61767  2015-09-10 17:49:38 Z   11 days5 attempts
Testing same since62173  2015-09-19 20:57:30 Z2 days1 attempts


People who touched revisions under test:
  Alberto Garcia 
  Alex Smith 
  Alexandre Derumier 
  Alistair Francis 
  Andreas Färber 
  Andrey Korolyov 
  Andrey Smetanin 
  Aníbal Limón 
  Aurelien Jarno 
  Benjamin Herrenschmidt 
  Carlos L. Torres 
  Chen Gang 
  Chen Gang 
  Cornelia Huck 
  Daniel P. Berrange 
  Denis V. Lunev 
  Don Slutz 
  Dr. David Alan Gilbert 
  Edgar E. Iglesias 
  Eduardo Habkost 
  Emilio G. Cota 
  Eric Blake 
  Fam Zheng 
  Frank Schreuder 
  Gerd Hoffmann 
  Gonglei 
  Guenter Roeck 
  Igor Mammedov 
  Jan Beulich 
  Jason Wang 
  Jean-Christophe Dubois 
  John Snow 
  Juan Quintela 
  Kevin Wolf 
  KONRAD Frederic 
  Konrad Rzeszutek Wilk 
  Kővágó, Zoltán 
  Laszlo Ersek 
  Laurent Desnogues 
  Laurent Vivier 
  Leon Alrae 
  Marc-André Lureau 
  Markus Armbruster 
  Max Reitz 
  Mic

Re: [Xen-devel] AMD Radeon 7970 passthrough on XEN 4.4.3 with an AMD FX-8350/Gigabyte GA-970A-UD3 *HORROR*

[George Dunlap]

On Tue, Sep 22, 2015 at 4:21 PM, NiX  wrote:
> This issue occur also on Win10 though the upgrade fixed all the other
> issues I encountered.
>
>>
>> Do you happen to have a serial console available, so you could capture the
>> crash/error messages from Xen and/or dom0 Linux kernel?
>>
>> SOL (Serial-Over-LAN) works too, if you have Intel AMT, IPMI, or other
>> BMC..
>>
>
> Not regular MB's such the one mentioned in the topic has such a feature.
>
> PS. Is not XEN-DEVEL team able to code in XEN kernel such feature it
> captures kernel log somewhere before panic occurs or whatever the reason
> is? It is loading before actual kernel so I think it is possible.

Xen, by design, has no disk or network drivers.  Where do you propose
it should log this information?

You can buy a cheap PCI serial card.

There are two reasons VGA pass-through is often frustrating. One is
that graphics cards companies do all kinds of clever tricks that make
virtualizing them a nightmare.

But the second is that VGA pass-through, in the general case, is not a
feature which is commercially important to most of the large companies
working on Xen.  It is, therefore, very much a community project --
people like you who "scratch their own itch", as it were.  The best
way you can help the situation is to contribute to make things better.

 -George

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

Re: [Xen-devel] [OSSTEST PATCH 05/28] sg-report-flight: Better searching for used revisions

[Ian Campbell]

On Tue, 2015-09-22 at 16:12 +0100, Ian Jackson wrote:
> The old algorithm used for determining which flight might be a
> suitable test of a particular revision was rather crude, in two ways:
> 
>  * It would look at _all_ jobs in a flight referred to from the flight
>of interest, not just at the relevant jobs;
> 
>  * It would only look at the direct referents of the flight in
>question.  So for example, if a flight of interest contained
>test-amd64-i386-libvirt, it would find a referenced
>build-i386-libvirt in another flight, but that build refers to
>build-i386, and it would not look at that (unless it happened to be
>in the same flight).
> 
> Fix this by redoing the revision archaeology, with some $why tracking
> to explain how we found a particular revision.
> 
> cs-bisection-step and sg-check-tested arguably ought to do do it this
> way too.  But I am leaving centralising this new logic, and using it
> in those other programs, for another day.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 

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

Re: [Xen-devel] [PATCH V2 2/2] xen: Introduce VM_EVENT_FLAG_SET_REGISTERS

[Razvan Cojocaru]

On 09/22/2015 06:19 PM, Jan Beulich wrote:
 On 21.09.15 at 15:31,  wrote:
>> A previous version of this patch dealing with support for skipping
>> the current instruction when a vm_event response requested it
>> computed the instruction length in the hypervisor, adding non-trivial
>> code dependencies. This patch allows a userspace vm_event client to
>> simply request that the guest's EIP is set to an arbitary value,
>> computed by the introspection application. In the future, other
>> registers can also be set via a vm_event reply by using this flag.
>> The VCPU needs to be paused for this flag to take effect.
>>
>> Signed-off-by: Razvan Cojocaru 
>>
>> ---
>> Changes since V1:
>>  - Renamed the patch (VM_EVENT_FLAG_SET_EIP ->
>>VM_EVENT_FLAG_SET_REGISTERS).
>>  - As suggested by Tamas Lengyel, EIP is now being set via a dedicated
>>generic vm_event_set_registers() function that can be extended to
>>set other registers in the future.
> 
> Isn't it a bad move to call the thing "set registers" but have it set
> just EIP? If going forward you were to add more registers, you'd
> need new flags anyway I suppose, and hence the public interface
> part of this should be reverted (while the other internal
> abstraction seems fine to me).

Well, the way I've read Tamas' request is that he'd like other registers
to be set as well in vm_event_set_registers() (such as EAX, and so on) -
but since I'm not sure what he'd like added and how to test his
scenarios, I thought I could just set EIP for now, and either add what
he's requesting in future versions of the series, or allow him to extend
the code as needed with future patches.

I think that the end goal for Tamas would be to just, if this flag is
set, to set at least some of the registers that come back from the
vm_event reply to the VCPU that caused the vm_event request.


Thanks,
Razvan

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-vhd  7 host-ping-check-xen   fail REGR. vs. 62098
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 16 
guest-start/debianhvm.repeat fail REGR. vs. 62098

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   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-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-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-libvirt-pair 21 guest-migrate/src_host/dst_host fail 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-vhd  11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass

version targeted for testing:
 libvirt  79ccfec803ed939a32e569baa9a2b11022ec48b7
baseline version:
 libvirt  636a99058758a0447482f3baad94de8de3ab1151

Last test of basis62098  2015-09-17 15:17:14 Z5 days
Testing same since62175  2015-09-19 22:23:48 Z2 days1 attempts


People who touched revisions under test:
  Chunyan Liu 
  Jiri Denemark 

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-xsmfail
 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-pairfail
 test-amd64-i386-libvirt-pair fail
 test-amd64-amd64-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-qcow2   fail
 test-amd64-i386-libvirt-qcow2pass
 test-amd64-amd64-libvirt-raw pass
 test-armhf-armhf-libvirt-raw fail
 test-amd64-i386-libvirt-raw  pass
 test-amd64-amd64-libvirt-vhd pass
 test-armhf-armhf-libvirt-vhd fail
 test-amd64-i386-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 re

Re: [Xen-devel] [PATCH V2 2/2] xen: Introduce VM_EVENT_FLAG_SET_REGISTERS

[Tamas K Lengyel]

On Tue, Sep 22, 2015 at 9:19 AM, Jan Beulich  wrote:

> >>> On 21.09.15 at 15:31,  wrote:
> > A previous version of this patch dealing with support for skipping
> > the current instruction when a vm_event response requested it
> > computed the instruction length in the hypervisor, adding non-trivial
> > code dependencies. This patch allows a userspace vm_event client to
> > simply request that the guest's EIP is set to an arbitary value,
> > computed by the introspection application. In the future, other
> > registers can also be set via a vm_event reply by using this flag.
> > The VCPU needs to be paused for this flag to take effect.
> >
> > Signed-off-by: Razvan Cojocaru 
> >
> > ---
> > Changes since V1:
> >  - Renamed the patch (VM_EVENT_FLAG_SET_EIP ->
> >VM_EVENT_FLAG_SET_REGISTERS).
> >  - As suggested by Tamas Lengyel, EIP is now being set via a dedicated
> >generic vm_event_set_registers() function that can be extended to
> >set other registers in the future.
>
> Isn't it a bad move to call the thing "set registers" but have it set
> just EIP? If going forward you were to add more registers, you'd
> need new flags anyway I suppose, and hence the public interface
> part of this should be reverted (while the other internal
> abstraction seems fine to me).
>
> Jan
>

IMHO you should just add setting all registers included in the snapshot
here rather then postpone it to a later patch.

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

Re: [Xen-devel] [OSSTEST PATCH 28/28] Executive: Delay releasing build host shares by 90s

[Ian Campbell]

On Tue, 2015-09-22 at 16:12 +0100, Ian Jackson wrote:
> When a build job finishes, the same flight may well want to do a
> subsequent build that depended on the first.  When this happens, we
> have a race:
> 
> One the one hand, we have the flight: after sg-run-job exits,
> sg-execute-flight needs to double-check the job status, and search the
> flight for more jobs to run; it will spawn ts-allocate-hosts-Executive
> for the new job, which needs to get its head together, parse its
> arguments, become a client of the queue daemon, and ask to be put in
> the queue.
> 
> On the other hand, we have the planning system: currently, as soon as
> sg-run-job exits, the connection to the ownerdaemon closes.  The
> ownerdaemon tells the queue daemon, and the planning queue is
> restarted.  It might even happen that coincidentally the planning
> queue is about to start.
> 
> If the planning system wins the race, another job will pick up the
> newly-freed resource.  Often this will mean unsharing the build host,
> which is very wasteful if the releasing flight hasn't finished its
> builds for that architecture: it means that the next build job needs
> to regroove a host for builds.
> 
> Add a bodge to try to make the race go the other way: after a build
> job completes successfuly, do not give up the share for a further 90
> seconds.  (We have to use setsid because sg-execute-flight kills the
> process group to clean up stray processes, which this sleep definitely
> is.)
> 
> A better solution would be to move the wait-for-referenced-job logic
> from sg-execute-flight to ts-hosts-allocate-*.  But that would be much
> more complicated.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 

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

Re: [Xen-devel] [OSSTEST PATCH 22/28] ts-debian-hvm-install: Do not create EFI partition if EFI not in use

[Ian Campbell]

On Tue, 2015-09-22 at 16:12 +0100, Ian Jackson wrote:
> If we are booting our install ISO using a non-EFI executable, don't
> try to provide an EFI for the installed system either.
> 
> Signed-off-by: Ian Jackson 


Acked-by: Ian Campbell 


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

Re: [Xen-devel] [OSSTEST PATCH 20/28] ts-debian-hvm-install: Cope with images containing only isolinux

[Ian Campbell]

On Tue, 2015-09-22 at 16:12 +0100, Ian Jackson wrote:
> debian-7.2.0-i386-CD-1.iso contains no grub, only isolinux.
> 
> If the specified EFI grub file does not exist, fall back to isolinux.
> This requires a -c option as well, according to
>   https://wiki.debian.org/DebianInstaller/Modify/CD
> 
> Only try to set up a grub config if we are booting grub.  (The i386
> image in question does not contain a [debian]/boot/grub directory.)
> 
> If boot/grub/efi.img _does_ exist (ie, for other existing tests), the
> only difference in behaviour is to reorder slightly the options to
> genisoimage: `-b boot/grub/efi.img' now occurs after `-no-emul-boot
> -r' rather than before.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 

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

Re: [Xen-devel] [OSSTEST PATCH 14/28] Provide xen-unstable-smoke branch

[Ian Jackson]

Ian Campbell writes ("Re: [OSSTEST PATCH 14/28] Provide xen-unstable-smoke 
branch"):
> On Tue, 2015-09-22 at 16:12 +0100, Ian Jackson wrote:
> > (Deployment note: This needs images/debian-7.2.0-i386-CD-1.iso which I
> > have already placed in the Cambridge and Xen Project instances.)
> 
> Which made me thing, what will be the effect of this series on the
> Cambridge instance, and in particular on the "OSSTEST_BASELINES_ONLY=y ./cr
> -for-branches" ?
> 
> I suppose it will just do a single test of every new #smoke branch which
> appears in xen.git? I think that is probably fine or even desirable.

Yes, I think it will do a single smoke test of every new #smoke.

> > Signed-off-by: Ian Jackson 
> 
> Acked-by: Ian Campbell 

Thanks,
Ian.

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

Re: [Xen-devel] [OSSTEST PATCH 19/28] ts-debian-hvm-install: Defer preseed generation

[Ian Campbell]

On Tue, 2015-09-22 at 16:12 +0100, Ian Jackson wrote:
> Defer preseed file generation until after we have fetched and looked
> inside the install image, because we are going to want to make changes
> to the preseed file based on the image contents.
> 
> No overall functional change, although some things happen in a
> different order now, and the ISO manipulation takes place in two calls
> to target_cmd_root rather than one.
> 
> Signed-off-by: Ian Jackson 
Acked-by: Ian Campbell 


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

Re: [Xen-devel] [OSSTEST PATCH 15/28] cr-daily-branch: Use mg-adjust-flight to have smoke tests reuse builds

[Ian Campbell]

On Tue, 2015-09-22 at 16:12 +0100, Ian Jackson wrote:

Title is missing -makexrefs?

> The smoke tests are for testing xen-unstable.  We want to avoid
> building anything else.  So arrange to reuse previous builds by
> calling mg-adjust-flight-makexrefs.
> 
> We rebuild libvirt too.  This is necessary because libvirt is built
> against xen.git, and uses ABI-unstable APIs, so we need a libvirt
> built against the right xen.git.  This means, for the smoke tests, we
> need to build libvirt ourselves.  Currently this build seems to take
> 416 sends (from host allocation, which we - perhaps naively - hope
> will be able to reuse the host from the just-finished build job).
> 
> Signed-off-by: Ian Jackson 
> Acked-by: Ian Campbell 

Reaffirmed.


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

Re: [Xen-devel] [OSSTEST PATCH 14/28] Provide xen-unstable-smoke branch

[Ian Campbell]

On Tue, 2015-09-22 at 16:12 +0100, Ian Jackson wrote:

> (Deployment note: This needs images/debian-7.2.0-i386-CD-1.iso which I
> have already placed in the Cambridge and Xen Project instances.)

Which made me thing, what will be the effect of this series on the
Cambridge instance, and in particular on the "OSSTEST_BASELINES_ONLY=y ./cr
-for-branches" ?

I suppose it will just do a single test of every new #smoke branch which
appears in xen.git? I think that is probably fine or even desirable.

[...]
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 


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

[Xen-devel] falha para instalar VM

[Julio Cesar Begalli]

Olá,

Estou tentando instalar um windons 7 dendro de uma VM no Linux,só que já tentei 
e não consigo,aparece a falha abaixo,voces podem me ajudar por favor ?

Grato,Júlio


[cid:image001.png@01D0F52D.3F970660]
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V2 1/2] xen, libxc: Fine grained control of REP emulation optimizations

[Razvan Cojocaru]

On 09/22/2015 06:17 PM, Jan Beulich wrote:
 On 21.09.15 at 15:31,  wrote:
>> --- a/xen/arch/x86/hvm/emulate.c
>> +++ b/xen/arch/x86/hvm/emulate.c
>> @@ -514,7 +514,8 @@ static int hvmemul_virtual_to_linear(
>>   * being triggered for repeated writes to a whole page.
>>   */
>>  *reps = min_t(unsigned long, *reps,
>> -  unlikely(current->domain->arch.mem_access_emulate_enabled)
>> +  unlikely(current->domain->arch.mem_access_emulate_enabled 
>> &&
>> +   
>> current->domain->arch.mem_access_emulate_each_rep)
>> ? 1 : 4096);
> 
> unlikely() should not wrap compound conditions, or else its effect of
> eliminating mis-predicted branches from the fast path won't be
> achieved. In the case here I wonder though whether you couldn't
> simply test only ->arch.mem_access_emulate_each_rep.

I'll unfold the unlikely().

Testing only ->arch.mem_access_emulate_each_rep is what I had done in
the original patch, however on Andrew Cooper's suggestion I've now gated
this on ->domain->arch.mem_access_emulate_enabled as well.

Otherwise, somebody might set mem_access_emulate_each_rep via its
xc_monitor_*() call, but then after calling xc_monitor_disable() it
would still be in effect, even if the guest is no longer being monitored.

If this is not a problem, I'm happy to check just
->arch.mem_access_emulate_each_rep.

>> --- a/xen/arch/x86/monitor.c
>> +++ b/xen/arch/x86/monitor.c
>> @@ -79,6 +79,12 @@ int monitor_domctl(struct domain *d, struct 
>> xen_domctl_monitor_op *mop)
>>  return 0;
>>  }
>>  
>> +if ( mop->op == XEN_DOMCTL_MONITOR_OP_EMULATE_EACH_REP )
>> +{
>> +d->arch.mem_access_emulate_each_rep = !!mop->event;
>> +return 0;
>> +}
> 
> Considering that there's another "if(mop->op == ...)" right above
> this, these two together should become another switch().

Understood.


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH V2 2/2] xen: Introduce VM_EVENT_FLAG_SET_REGISTERS

[Jan Beulich]

>>> On 21.09.15 at 15:31,  wrote:
> A previous version of this patch dealing with support for skipping
> the current instruction when a vm_event response requested it
> computed the instruction length in the hypervisor, adding non-trivial
> code dependencies. This patch allows a userspace vm_event client to
> simply request that the guest's EIP is set to an arbitary value,
> computed by the introspection application. In the future, other
> registers can also be set via a vm_event reply by using this flag.
> The VCPU needs to be paused for this flag to take effect.
> 
> Signed-off-by: Razvan Cojocaru 
> 
> ---
> Changes since V1:
>  - Renamed the patch (VM_EVENT_FLAG_SET_EIP ->
>VM_EVENT_FLAG_SET_REGISTERS).
>  - As suggested by Tamas Lengyel, EIP is now being set via a dedicated
>generic vm_event_set_registers() function that can be extended to
>set other registers in the future.

Isn't it a bad move to call the thing "set registers" but have it set
just EIP? If going forward you were to add more registers, you'd
need new flags anyway I suppose, and hence the public interface
part of this should be reverted (while the other internal
abstraction seems fine to me).

Jan


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

[Xen-devel] [OSSTEST PATCH 14/28] Provide xen-unstable-smoke branch

[Ian Jackson]

Introduce support for branch=qemu-xen-unstable-smoke which has
xenbranch=xen-unstable-smoke.

In make-flight, this contains a very limited set of jobs
test-amd64-amd64-libvirt
test-amd64-amd64-xl-qemuu-debianhvm-i386
test-armhf-armhf-xl
and the builds they depend on.

The debianhvm job exists only in this flight, and is generated by
having branch_debianhvm_arch return i386 instead of amd64.  This is so
that this branch contains a 32-bit x86 guest as well as a 64-bit one.

We override host allocator parameters to make this flight not care
about host stickiness: it just takes whatever comes to hand.  These
runvars are marked `synth' so that cs-bisection-step and
cs-adjust-flight do not copy them, as discussed in previous patches.

Later we will arrange to reuse previous builds for the build artefacts
which aren't intended subjects of the smoke test.

(Deployment note: This needs images/debian-7.2.0-i386-CD-1.iso which I
have already placed in the Cambridge and Xen Project instances.)

In ap-common we need to arrange to use the same qemu trees as for
xen-unstable, rather than looking for special smoke ones.

In select_xenbranch xen-unstable-smoke is mostly like xen-unstable.

There are only two places in osstest where xenbranch `xen-unstable' is
treated specially and only one of them needs adjusting to match
xen-unstable-smoke too.

The new branch `xen-unstable-smoke' has a `prev' branch of
`xen-unstable' according to cri-getprevxenbranch, which is technically
wrong, but this is not important because xen-unstable-smoke has no
prev tests.

We are going to sort out the push gate ref plumbing in xen.git in the
next osstest patch.

Also, use a branch-settings file to set the new branch's resource
priority to -20 to make it run ahead of anything else automatic.

Signed-off-by: Ian Jackson 
---
v4: Introduce xenbranch_forqemu into ap-common.
Combine patches for make-flight and cr-*.  make-flight includes
cri-common and ap-common (which is arguably a layering violation,
but there we are).
Dropped ack from Ian Campbell.
Set `qemuubranch' correctly in select_xenbranch.
v2: Generate all the jobs that this flight's tests use, and add
note about this to the commit message.
Mention `synth'-ness of hostalloc runvars in commit message.
Image is in Xen Project test colo too.
---
 README.planner |1 +
 ap-common  |8 +---
 branch-settings.xen-unstable-smoke |1 +
 cr-daily-branch|2 +-
 cri-common |1 +
 make-flight|   31 ++-
 6 files changed, 39 insertions(+), 5 deletions(-)
 create mode 100644 branch-settings.xen-unstable-smoke

diff --git a/README.planner b/README.planner
index dfa623e..3a491a4 100644
--- a/README.planner
+++ b/README.planner
@@ -87,6 +87,7 @@ in the more distant future.
 Values for OSSTEST_RESOURCE_PRIORITY:
   mg-allocate-100
   mg-blockage-200
+  xen-unstable-smoke cr-daily-branch  -20
   default Executive.pm with controlling terminal  -10
   mg-execute-flight-8
   default   0
diff --git a/ap-common b/ap-common
index dfeab9e..91425a9 100644
--- a/ap-common
+++ b/ap-common
@@ -19,6 +19,8 @@
 
 # $xenbranch must already be set
 
+xenbranch_forqemu=${xenbranch/xen-unstable-smoke/xen-unstable}
+
 : ${XENBITS:=osst...@xenbits.xen.org}
 
 : ${TREEBRANCH_OSSTEST_UPSTREAM=`getconfig OsstestUpstream`}
@@ -26,8 +28,8 @@
 : ${TREE_XEN:=git://xenbits.xen.org/xen.git}
 : ${PUSH_TREE_XEN:=$XENBITS:/home/xen/git/xen.git}
 
-#: ${TREE_QEMU:=git://mariner.uk.xensource.com/qemu-$xenbranch.git}
-: ${TREE_QEMU:=git://xenbits.xen.org/staging/qemu-$xenbranch.git}
+#: ${TREE_QEMU:=git://mariner.uk.xensource.com/qemu-$xenbranch_forqemu.git}
+: ${TREE_QEMU:=git://xenbits.xen.org/staging/qemu-$xenbranch_forqemu.git}
 
 
 : ${GIT_KERNEL_ORG:=git://git.kernel.org}
@@ -87,7 +89,7 @@ fi
 
 : ${TREEBASE_LINUX_XCP:=http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27}
 
-: 
${TREE_QEMU_UPSTREAM:=git://xenbits.xen.org/staging/qemu-upstream-${xenbranch#xen-}.git}
+: 
${TREE_QEMU_UPSTREAM:=git://xenbits.xen.org/staging/qemu-upstream-${xenbranch_forqemu#xen-}.git}
 : ${LOCALREV_QEMU_UPSTREAM:=daily-cron.$branch}
 
 : ${TREE_QEMU_MAINLINE:=git://git.qemu.org/qemu.git}
diff --git a/branch-settings.xen-unstable-smoke 
b/branch-settings.xen-unstable-smoke
new file mode 100644
index 000..b73bc6a
--- /dev/null
+++ b/branch-settings.xen-unstable-smoke
@@ -0,0 +1 @@
+export OSSTEST_RESOURCE_PRIORITY=-20
diff --git a/cr-daily-branch b/cr-daily-branch
index 9500bdc..141bce5 100755
--- a/cr-daily-branch
+++ b/cr-daily-branch
@@ -328,7 +328,7 @@ case "$NEW_REVISION/$OLD_REVISION" in
 "$treeurl#$OLD_REVISION-$NEW_REVISION" \
 
 case

Re: [Xen-devel] [PATCH V2 1/2] xen, libxc: Fine grained control of REP emulation optimizations

[Jan Beulich]

>>> On 21.09.15 at 15:31,  wrote:
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -514,7 +514,8 @@ static int hvmemul_virtual_to_linear(
>   * being triggered for repeated writes to a whole page.
>   */
>  *reps = min_t(unsigned long, *reps,
> -  unlikely(current->domain->arch.mem_access_emulate_enabled)
> +  unlikely(current->domain->arch.mem_access_emulate_enabled 
> &&
> +   current->domain->arch.mem_access_emulate_each_rep)
> ? 1 : 4096);

unlikely() should not wrap compound conditions, or else its effect of
eliminating mis-predicted branches from the fast path won't be
achieved. In the case here I wonder though whether you couldn't
simply test only ->arch.mem_access_emulate_each_rep.

> --- a/xen/arch/x86/monitor.c
> +++ b/xen/arch/x86/monitor.c
> @@ -79,6 +79,12 @@ int monitor_domctl(struct domain *d, struct 
> xen_domctl_monitor_op *mop)
>  return 0;
>  }
>  
> +if ( mop->op == XEN_DOMCTL_MONITOR_OP_EMULATE_EACH_REP )
> +{
> +d->arch.mem_access_emulate_each_rep = !!mop->event;
> +return 0;
> +}

Considering that there's another "if(mop->op == ...)" right above
this, these two together should become another switch().

Jan


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

[Xen-devel] Xen Security Advisory 142 (CVE-2015-7311) - libxl fails to honour readonly flag on disks with qemu-xen

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Xen Security Advisory CVE-2015-7311 / XSA-142
  version 2

libxl fails to honour readonly flag on disks with qemu-xen

UPDATES IN VERSION 2


CVE assigned.

ISSUE DESCRIPTION
=

Callers of libxl can specify that a disk should be read-only to the
guest.  However, there is no code in libxl to pass this information to
qemu-xen (the upstream-based qemu); and indeed there is no way in qemu
to make a disk read-only.

The vulnerability is exploitable only via devices emulated by the
device model, not the parallel PV devices for supporting PVHVM.
Normally the PVHVM device unplug protocol renders the emulated devices
inaccessible early in boot.

IMPACT
==

Malicious guest administrators or (in some situations) users may be
able to write to supposedly read-only disk images.

CDROM devices (that is, devices specified to be presented to the guest
as CDROMs, regardless of the nature of the backing storage on the
host) are not affected.

VULNERABLE SYSTEMS
==

Only systems using qemu-xen (rather than qemu-xen-traditional) as the
device model version are vulnerable.

Only systems using libxl or libxl-based toolstacks are vulnerable.
(This includes xl, and libvirt with the libxl driver.)

All versions of libxl which support qemu-xen are vulnerable.  The
affected code was introduced in Xen 4.1.

If the host and guest together usually support PVHVM, the issue is
exploitable only if the malicious guest administrator has control of
the guest kernel or guest kernel command line.

MITIGATION
==

Switching to qemu-xen-traditional will avoid this vulnerability.
This can be done with
   device_model_version="qemu-xen-traditional"
in the xl configuration file.

Using stub domain device models (which necessarily involves switching
to qemu-xen-traditional) will also avoid this vulnerability.
This can be done with
   device_model_stubdomain_override=true
in the xl configuration file.

Either of these mitigations is liable to have other guest-visible
effects or even regressions.

It may be possible, depending on the configuration, to make the
underlying storage object readonly, or to make it reject writes.

RESOLUTION
==

There is no reasonable resolution because Qemu does not (at the time
of writing) support presenting a read-only block device to a guest as
a disk.

The attached patch corrects the weakness in the libxl code, by
rejecting the unsupported configurations, rather than allowing them to
run but with the device perhaps writeable by the guest.  Applying it
should increase confidence and avoid future configuration errors, but
will break affected configurations specifying read-only disk devices.

xsa142-4.6.patch Xen 4.6.x and later
xsa142-4.5.patch Xen 4.3.x to 4.5.x inclusive

$ sha256sum xsa142*.patch
9ec0649f39720bc692be03c87ebea0506d6ec574f339fc745e41b31643240124  
xsa142-4.5.patch
65f01167bfc141048261f56b99ed9b48ec7ff6e98155454ced938a17ec20e7d1  
xsa142-4.6.patch
$

NOTE REGARDING LACK OF EMBARGO
==

This issue was discussed in public in the Red Hat bugzilla:
  https://bugzilla.redhat.com/show_bug.cgi?id=1257893

CREDITS
===

Thanks to Michael Young of Durham University for bring this problem to
our attention.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJWAXCcAAoJEIP+FMlX6CvZ1asH/0yJQ9+33gZtE69Bxicms3C2
uSepfkZVBUym+eEBqGKd2hiapngIAInotOTk+iI7DDo41wvfnJxq1eaEaQ9XurKK
kylHOb8eHmYw+HwTW2kJV2g6ffeGBMIcI5mpK35yBa5NnNHHJz0b9ZeRzddR9rSR
0eQpuP4DlN1/2/z6obXmYms84Q1oiIzMDz+MzJA/zPtfL7Q/tBjUmMfPj67zNKwe
vIfIstI5IbCRgnXSEL9EjTckqNFszyr3pH4z/Y97UXWlbTg233ewAS11Wz/CwJKT
yzS4uJGpckqTRC3YKyS1unKCP39yAVIBTx4QoPu9hrWyzUJpZUD/FvmrIHhr8co=
=kHPH
-END PGP SIGNATURE-


xsa142-4.5.patch
Description: Binary data


xsa142-4.6.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [OSSTEST PATCH 28/28] Executive: Delay releasing build host shares by 90s

[Ian Jackson]

When a build job finishes, the same flight may well want to do a
subsequent build that depended on the first.  When this happens, we
have a race:

One the one hand, we have the flight: after sg-run-job exits,
sg-execute-flight needs to double-check the job status, and search the
flight for more jobs to run; it will spawn ts-allocate-hosts-Executive
for the new job, which needs to get its head together, parse its
arguments, become a client of the queue daemon, and ask to be put in
the queue.

On the other hand, we have the planning system: currently, as soon as
sg-run-job exits, the connection to the ownerdaemon closes.  The
ownerdaemon tells the queue daemon, and the planning queue is
restarted.  It might even happen that coincidentally the planning
queue is about to start.

If the planning system wins the race, another job will pick up the
newly-freed resource.  Often this will mean unsharing the build host,
which is very wasteful if the releasing flight hasn't finished its
builds for that architecture: it means that the next build job needs
to regroove a host for builds.

Add a bodge to try to make the race go the other way: after a build
job completes successfuly, do not give up the share for a further 90
seconds.  (We have to use setsid because sg-execute-flight kills the
process group to clean up stray processes, which this sleep definitely
is.)

A better solution would be to move the wait-for-referenced-job logic
from sg-execute-flight to ts-hosts-allocate-*.  But that would be much
more complicated.

Signed-off-by: Ian Jackson 
---
v4: New patch
---
 sg-run-job   |2 ++
 tcl/JobDB-Executive.tcl  |6 ++
 tcl/JobDB-Standalone.tcl |1 +
 3 files changed, 9 insertions(+)

diff --git a/sg-run-job b/sg-run-job
index c51a508..66145b8 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -71,6 +71,8 @@ proc run-job {job} {
 
 if {$ok} { setstatus pass }
 
+if {$need_build_host && $ok} { jobdb::preserve-task 90 }
+
 if {$anyfailed} {
 jobdb::logputs stdout "at least one test failed"
 }
diff --git a/tcl/JobDB-Executive.tcl b/tcl/JobDB-Executive.tcl
index d61d2a2..f37bbaf 100644
--- a/tcl/JobDB-Executive.tcl
+++ b/tcl/JobDB-Executive.tcl
@@ -280,6 +280,12 @@ proc become-task {comment} {
 }
 }
 
+proc preserve-task {seconds} {
+# This keeps the owner daemon connection open: our `sleep'
+# will continue to own our resources for $seconds longer
+exec setsid sleep $seconds > /dev/null < /dev/null 2> /dev/null &
+}
+
 proc step-log-filename {flight job stepno ts} {
 global c
 set logdir $c(Logs)/$flight/$job
diff --git a/tcl/JobDB-Standalone.tcl b/tcl/JobDB-Standalone.tcl
index a2b8dd9..d7d8422 100644
--- a/tcl/JobDB-Standalone.tcl
+++ b/tcl/JobDB-Standalone.tcl
@@ -74,6 +74,7 @@ proc step-set-status {flight job stepno st} {
 }
 
 proc become-task {argv} { }
+proc preserve-task {argv} { }
 
 proc step-log-filename {flight job stepno ts} {
 return {}
-- 
1.7.10.4


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

[Xen-devel] [OSSTEST PATCH 15/28] cr-daily-branch: Use mg-adjust-flight to have smoke tests reuse builds

[Ian Jackson]

The smoke tests are for testing xen-unstable.  We want to avoid
building anything else.  So arrange to reuse previous builds by
calling mg-adjust-flight-makexrefs.

We rebuild libvirt too.  This is necessary because libvirt is built
against xen.git, and uses ABI-unstable APIs, so we need a libvirt
built against the right xen.git.  This means, for the smoke tests, we
need to build libvirt ourselves.  Currently this build seems to take
416 sends (from host allocation, which we - perhaps naively - hope
will be able to reuse the host from the just-finished build job).

Signed-off-by: Ian Jackson 
Acked-by: Ian Campbell 
---
v4: Keep build-amd64-libvirt too.
v3: Add a comment about the --blessings=real
v2: New patch
---
 cr-daily-branch |   12 
 1 file changed, 12 insertions(+)

diff --git a/cr-daily-branch b/cr-daily-branch
index 141bce5..dd9c30a 100755
--- a/cr-daily-branch
+++ b/cr-daily-branch
@@ -276,7 +276,19 @@ if [ "x$NEW_REVISION" = "x$OLD_REVISION" ]; then
 fi
 
 $DAILY_BRANCH_PREMAKE_HOOK
+
 flight=`$makeflight $branch $xenbranch $OSSTEST_BLESSING "$@"`
+
+case $branch in
+xen-unstable-smoke)
+   ./mg-adjust-flight-makexrefs -v $flight \
+   '!build-amd64 !build-amd64-libvirt !build-armhf build-*' \
+   --debug --branch=xen-unstable --blessings=real
+   # Even adhoc or play flights ought to reuse only real
+   # previous builds.
+   ;;
+esac
+
 $DAILY_BRANCH_POSTMAKE_HOOK
 
 heading=tmp/$flight.heading-info
-- 
1.7.10.4


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

[Xen-devel] [OSSTEST PATCH 22/28] ts-debian-hvm-install: Do not create EFI partition if EFI not in use

[Ian Jackson]

If we are booting our install ISO using a non-EFI executable, don't
try to provide an EFI for the installed system either.

Signed-off-by: Ian Jackson 
---
v4: Fix regexp to match efi.img (!)
Rebased, fixed code motion conflict.
---
 ts-debian-hvm-install |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
index b9f9025..6646a5a 100755
--- a/ts-debian-hvm-install
+++ b/ts-debian-hvm-install
@@ -49,6 +49,7 @@ our $guesthost= "$gn.guest.osstest";
 our $gho;
 
 our ($kernel, $ramdisk);
+our $bootfile;
 
 our $gsuite;
 
@@ -56,7 +57,7 @@ sub preseed () {
 
 my $preseed_file = preseed_base($gho,$gsuite,'','',());
 
-$preseed_file .= (

[Xen-devel] [OSSTEST PATCH 05/28] sg-report-flight: Better searching for used revisions

[Ian Jackson]

The old algorithm used for determining which flight might be a
suitable test of a particular revision was rather crude, in two ways:

 * It would look at _all_ jobs in a flight referred to from the flight
   of interest, not just at the relevant jobs;

 * It would only look at the direct referents of the flight in
   question.  So for example, if a flight of interest contained
   test-amd64-i386-libvirt, it would find a referenced
   build-i386-libvirt in another flight, but that build refers to
   build-i386, and it would not look at that (unless it happened to be
   in the same flight).

Fix this by redoing the revision archaeology, with some $why tracking
to explain how we found a particular revision.

cs-bisection-step and sg-check-tested arguably ought to do do it this
way too.  But I am leaving centralising this new logic, and using it
in those other programs, for another day.

Signed-off-by: Ian Jackson 
---
v4: New patch
---
 sg-report-flight |   79 ++
 1 file changed, 62 insertions(+), 17 deletions(-)

diff --git a/sg-report-flight b/sg-report-flight
index ef3fd6b..3d0bf64 100755
--- a/sg-report-flight
+++ b/sg-report-flight
@@ -201,15 +201,26 @@ END
 $flightsq= db_prepare($flightsq);
 $flightsq->execute(@flightsq_params);
 
-my $buildflightsq= db_prepare(execute($tflight);
-   while (my $bflightrow = $buildflightsq->fetchrow_hashref()) {
-   my $val = $bflightrow->{val};
-   next unless $val =~ m/\./; # same flight, already added
-   push @bflights, $`;
+   # Recurse from the starting flight looking for relevant build
+   # jobs.  We start with all jobs in $tflight, and for each job
+   # we also process any other jobs it refers to in *buildjob runvars.
+   #
+   # We don't actually use a recursive algorithm because that
+   # would involve recursive use of the same sql query object;
+   # hence the @binfos_todo queue.
+   my @binfos_todo;
+   my $binfos_queue = sub {
+   my ($inflight,$q,$why) = @_;
+   while (my ($morewhy,$jobref) = $q->fetchrow_array()) {
+   my @info = "$why $morewhy$jobref";
+   push @info, flight_otherjob($inflight,$jobref);
+   push @binfos_todo, \@info;
+   }
+   $q->finish();
+   };
+   $jobsq->execute($tflight);
+   $binfos_queue->($tflight,$jobsq,"$tflight");
+
+   my %binfos;
+   while (@binfos_todo) {
+   my ($why,$bflight,$bjob) = @{ shift @binfos_todo };
+   next if $binfos{$bflight}{$bjob};
+   $binfos{$bflight}{$bjob} = $why;
+   $buildjobsq->execute($bflight,$bjob);
+   $binfos_queue->($bflight,$buildjobsq,$why);
}
+
+   my @binfos;
+   foreach my $bflight (sort { $a <=> $b } keys %binfos) {
+   my $bjobs = $binfos{$bflight};
+   foreach my $bjob (sort keys %$bjobs) {
+   my $why = $bjobs->{$bjob};
+   #print DEBUG " relevant $bflight.$bjob because $why\n";
+   push @binfos, [ $why, $bflight, $bjob ];
+   }
+   }
+
my $whynot;
foreach my $tree (keys %{ $specver{$thisthat} }) {
my @revisions;
my $v= $specver{$thisthat}{$tree};
-   foreach my $bflight (@bflights) {
+   foreach my $binfo (@binfos) {
+   my ($bwhy,@bfj) = @$binfo;
my $revisions;
if ($tree ne 'osstest') {
-   $revisionsq->execute($bflight, "built_revision_$tree");
+   $revisionsq->execute(@bfj, "built_revision_$tree");
$revisions= $revisionsq->fetchall_arrayref({});
} else {
-   $revisionsosstestq->execute($bflight);
+   $revisionsosstestq->execute($bfj[0]);
$revisions= $revisionsosstestq->fetchall_arrayref({});
}
-   push @revisions, @$revisions;
+   push @revisions, map { [ $bwhy, $_ ] } @$revisions;
}
 if (!@revisions) {
 $whynot= "no built/used $tree";
 last;
 }
-my ($wrong) = grep {
-$_->{val} !~ m/^(?: .*: )? $v /x;
+my ($wronginfo) = grep {
+$_->[1]{val} !~ m/^(?: .*: )? $v /x;
 } @revisions;
 
-if (defined $wrong) {
+if (defined $wronginfo) {
+   my ($why,$wrong) = @$wronginfo;
 $whynot= "mismatch $tree ".
 (defined $wrong->{job} ?
 "$wrong->{flight}.$wrong->{job}" : "(osstest)").
-" $wrong->{val} != $v";
+" $wrong->{val} != $v".
+   " ($why)";
 last;
 }
}
-- 
1.7.10.4


__

[Xen-devel] [OSSTEST PATCH 20/28] ts-debian-hvm-install: Cope with images containing only isolinux

[Ian Jackson]

debian-7.2.0-i386-CD-1.iso contains no grub, only isolinux.

If the specified EFI grub file does not exist, fall back to isolinux.
This requires a -c option as well, according to
  https://wiki.debian.org/DebianInstaller/Modify/CD

Only try to set up a grub config if we are booting grub.  (The i386
image in question does not contain a [debian]/boot/grub directory.)

If boot/grub/efi.img _does_ exist (ie, for other existing tests), the
only difference in behaviour is to reorder slightly the options to
genisoimage: `-b boot/grub/efi.img' now occurs after `-no-emul-boot
-r' rather than before.

Signed-off-by: Ian Jackson 
---
v4: Log $bootfile value.
Preseed generation now happens later due to previous patch;
  so $bootfile setting now also deferred.  Context change only.
---
 ts-debian-hvm-install |   12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
index bb79d59..5197f9b 100755
--- a/ts-debian-hvm-install
+++ b/ts-debian-hvm-install
@@ -197,7 +197,6 @@ sub prep () {
 my $preseed_file_path = $base . "preseed";
 
 my @isogen_extra = qw(-eltorito-alt-boot
-  -b boot/grub/efi.img
   -no-emul-boot
   -r);
 
@@ -222,6 +221,14 @@ sub prep () {
 my $cmds = iso_copy_content_from_image($gho, $newiso);
 target_cmd_root($ho, $cmds, $isotimeout);
 
+my $bootfile = 'boot/grub/efi.img';
+if (!target_file_exists($ho, "$newiso/$bootfile")) {
+$bootfile = "isolinux/isolinux.bin";
+push @isogen_extra, qw(-c isolinux/boot.cat);
+}
+logm("using boot image $bootfile");
+push @isogen_extra, '-b', $bootfile;
+
 my @isogen_opts = (iso_gen_flags_basic(), @isogen_extra);
 
 target_putfilecontents_root_stash($ho, 10, preseed(),
@@ -231,7 +238,8 @@ sub prep () {
 target_cmd_root($ho, $cmds, $isotimeout);
 
 target_putfilecontents_root_stash($ho, 10, grub_cfg(),
-  "$newiso/debian/boot/grub/grub.cfg");
+  "$newiso/debian/boot/grub/grub.cfg")
+   if $bootfile =~ m/grub/;
 
 target_putfilecontents_root_stash($ho, 10, isolinux_cfg(),
   "$newiso/isolinux/isolinux.cfg");
-- 
1.7.10.4


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

[Xen-devel] [OSSTEST PATCH 19/28] ts-debian-hvm-install: Defer preseed generation

[Ian Jackson]

Defer preseed file generation until after we have fetched and looked
inside the install image, because we are going to want to make changes
to the preseed file based on the image contents.

No overall functional change, although some things happen in a
different order now, and the ISO manipulation takes place in two calls
to target_cmd_root rather than one.

Signed-off-by: Ian Jackson 
---
v4: New patch.  Needed because otherwise the test for the grub install
image (to be introduced in the next patch) happens before the ISO
is unpacked, and we would then always fall back to isolinux.
---
 ts-debian-hvm-install |   14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
index 3b93ebd..bb79d59 100755
--- a/ts-debian-hvm-install
+++ b/ts-debian-hvm-install
@@ -200,13 +200,9 @@ sub prep () {
   -b boot/grub/efi.img
   -no-emul-boot
   -r);
-my @isogen_opts = (iso_gen_flags_basic(), @isogen_extra);
 
 iso_create_empty($ho, $emptyiso, $emptydir);
 
-target_putfilecontents_root_stash($ho, 10, preseed(),
-  $preseed_file_path);
-
 # If host has >8G free memory, create a guest with 4G memory to catch
 # any error that triggers cross 4G boundary
 my $host_freemem_mb = host_get_free_memory($ho);
@@ -224,8 +220,16 @@ sub prep () {
   Bios => $r{bios},
   PostImageHook => sub {
 my $cmds = iso_copy_content_from_image($gho, $newiso);
-$cmds .= prepare_initrd($initrddir,$newiso,$preseed_file_path);
 target_cmd_root($ho, $cmds, $isotimeout);
+
+my @isogen_opts = (iso_gen_flags_basic(), @isogen_extra);
+
+target_putfilecontents_root_stash($ho, 10, preseed(),
+  $preseed_file_path);
+
+$cmds = prepare_initrd($initrddir,$newiso,$preseed_file_path);
+target_cmd_root($ho, $cmds, $isotimeout);
+
 target_putfilecontents_root_stash($ho, 10, grub_cfg(),
   "$newiso/debian/boot/grub/grub.cfg");
 
-- 
1.7.10.4


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

[Xen-devel] [OSSTEST PATCH v4 00/28] xen.git#staging smoke tests

[Ian Jackson]

This time, for sure.  Specifically, I have:

 * Run this as a nearly-live cr-daily-branch in my account on
   in the production colo, and checked that the versions used
   and result emails look sane.

 * Double-checked the standalone-generate-dump-flight-runvars
   again.

 * Ad-hoc tested 28/28 in the Cambridge instance with intrusive
   monitoring and checked that it does what I expect.

I am sending out only those patchbomb mails which (a) lack an ack or
(b) have changed in v4.  They are these:

 +  05/28  sg-report-flight: Better searching for used revisions
 !- 14/28  Provide xen-unstable-smoke branch
 *a 15/28  cr-daily-branch: Use mg-adjust-flight to have smoke tests...
 +  19/28  ts-debian-hvm-install: Defer preseed generation
 *- 20/28  ts-debian-hvm-install: Cope with images containing only isolinux
 *- 22/28  ts-debian-hvm-install: Do not create EFI partition if EFI...
 +  28/28  Executive: Delay releasing build host shares

Where:

 +  New patch
 *  Modified
 !  Modified and combined several previous patches
 a  Acked
 -  Ack dropped due to changes


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

Re: [Xen-devel] [PATCH v7 28/28] xen/arm: ITS: Add pci devices in ThunderX

[Julien Grall]

Hi Vijay,

On 18/09/15 14:09, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K 
> 
> ITS initialization required for all PCI devices in
> ThunderX platform are done by calling from specific
> mapping function.
> 
> This patch can be reverted once XEN PCI passthrough
> framework for arm64 is in available.

When a new feature is added in Xen (such as ITS and basic PCI support
with Thunder-X), we are trying to avoid any breakage no matter the
version of Linux.

With this series, any Linux with Thunder-X support is able to boot on
Xen and use basic PCI without Manish's series. If we decide to revert
this patch, a such Linux won't be able to boot any more on Xen.

IIUC, what matters is having Xen booting on Thunder-X with PCI supported
when 4.7 released. If we can get PCI passthrough fully working by then,
this patch will become unnecessary.

Xen 4.6 hasn't yet been released, so it's entirely feasible to get the
PCI passthrough for the next release if we start to review it very soon.

If the feature doesn't land in staging before the freeze, then we can
talk about having this patch in 4.7 and come up with a plan to revert it
when PCI passthrough will be fully supported.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH] xen/mcfg: Call PHYSDEVOP_pci_mmcfg_reserved before PCI enumeration

[Jan Beulich]

>>> On 22.09.15 at 16:37,  wrote:
> On Tue, Sep 22, 2015 at 08:11:41AM -0600, Jan Beulich wrote:
>> >>> On 22.09.15 at 16:03,  wrote:
>> > On Tue, Sep 22, 2015 at 07:52:19AM -0600, Jan Beulich wrote:
>> >> >>> On 22.09.15 at 15:39,  wrote:
>> >> > On Tue, Sep 22, 2015 at 06:26:11AM -0700, Ed Swierk wrote:
>> >> >> Any other ideas?
>> >> > 
>> >> > I like it - as it will update it right away. However we would need some
>> >> > extra smarts in Xen to reconfigure its view of the PCI device now that 
>> >> > the
>> >> > extended configuration space has become available.
>> >> 
>> >> What parts are you thinking of that would need updating (and
>> >> aren't getting updated already)?
>> > 
>> > The VF data. As before this call Xen might have not been able to
>> > get to the extended configuration.
>> 
>> I still don't understand: Afaics pci_add_device() updates everything
>> that may need updating already. And things appear to be working
>> fine with our kernel (where the MMCFG notification comes right out
>> of the x86 code earlier referred to), despite this meaning updates
>> to the data collected during early boot. I guess you'll need to be
>> more specific on what you see missing...
> 
> This is all ancient recollection of what I had seen a year or so ago
> so take it a with a cup of salt.

Urgh - a whole cup...

> I have one of those Intel machines where the MMCFG is not marked
> in the E820 but is in the ACPI and I remember getting frequent
> WARN_ON from Xen in the msi.c code when doing passthrough on the VF.
> I don't have the logs but my vague recollection was that Xen could
> not validate the VF's MSI-X because at the time it gathered the
> VF PCI device information the extended configurations were not
> available. This was prior to the XSA120 discovery so ancient
> code.

Well, VFs should not even show up prior to MMCFG getting
announced.

Jan


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

Re: [Xen-devel] AMD Radeon 7970 passthrough on XEN 4.4.3 with an AMD FX-8350/Gigabyte GA-970A-UD3 *HORROR*

[NiX]

> Hello,
>
> On Sat, Sep 19, 2015 at 08:21:15PM +0300, NiX wrote:
>> After a lot of trial and error I got it working as a secondary
>> pass-through. Thanks mainly to bullshit examples around the net. None
>> seem
>> to know nothing.
>>
>> I though of I am the idiot but I was wrong.
>>
>
> GPU passthru isn't very simple or straight-forward unfortunately..

I did not expected it to be simple. I upgraded that VM to Win10 and there
is less horror. It works and runs the game with as good FPS as on Win7
bare metal.

>
>
>> Whole system crashes upon shutting down the VM that had the adapter
>> passed
>> through. This actually screw up whole pass-through feature. Do that
>> crash
>> happen because 7970 does not have device reset feature or whatever it
>> was
>> called?
>>

This issue occur also on Win10 though the upgrade fixed all the other
issues I encountered.

>
> Do you happen to have a serial console available, so you could capture the
> crash/error messages from Xen and/or dom0 Linux kernel?
>
> SOL (Serial-Over-LAN) works too, if you have Intel AMT, IPMI, or other
> BMC..
>

Not regular MB's such the one mentioned in the topic has such a feature.

PS. Is not XEN-DEVEL team able to code in XEN kernel such feature it
captures kernel log somewhere before panic occurs or whatever the reason
is? It is loading before actual kernel so I think it is possible.


>
>> I got it working only few times and Battlefield 4 started and ran
>> actually
>> surprisingly good at 50+ FPS with maxed details at 1600:900 on AMD 7970.
>>
>> However the next day immediately after when I attempt to login to VM
>> screen goes blank and whole system crashes (power off is required to
>> restore). It is also significantly lagged. ie. typing the password has
>> around 1 second delay per letter.
>>
>> This is unacceptable issue. Anyone else experienced the same horror?
>>
>> Thanks anyway for providing XEN but there are a lot to be fixed ...
>>
>> I've no issues on that VM when I don't use pass-through expect a
>> significantly high CPU usage in HVM mode when I start using the computer
>> say IE 11 browser. All cores have a 30-50% CPU usage when I do a small
>> tasks such as windows udpate etc.
>>
>
> How do you use the VM? I hope using RDP over the network..
>
>
>> PS. That VM image is on Samsung 840 PRO SSD and it was loading the game
>> really fast when it worked.
>>
>> There was no difference to the issue wheter or not CCC was installed.
>
>
> -- Pasi
>
>



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

Re: [Xen-devel] [PATCH] xen/mcfg: Call PHYSDEVOP_pci_mmcfg_reserved before PCI enumeration

[Jan Beulich]

>>> On 22.09.15 at 16:33,  wrote:
> On Tue, Sep 22, 2015 at 08:12:56AM -0600, Jan Beulich wrote:
>> >>> On 22.09.15 at 16:09,  wrote:
>> > On Tue, Sep 22, 2015 at 07:57:29AM -0600, Jan Beulich wrote:
>> >> >>> On 22.09.15 at 15:36,  wrote:
>> >> > The best I could come up with is to do two loops:
>> >> >  1) for 0:0:0 -> ff:ff:ff call PHYSDEVOP_pci_device_remove
>> >> > (so blow away what Xen has for its PCI devices.. except for the AMD 
>> >> > IOMMU)
>> >> >  2) list_for_each_pci_device PHYSDEVOP_pci_device_add (or other variants
>> >> > if VF).
>> >> > 
>> >> > But that is just a hack working around the Linux code.
>> >> 
>> >> The price of being non-intrusive on the Linux side. The above would
>> >> seem okay to me for the (rare?) reassign case. (Not sure why you
>> >> mean to exclude the AMD IOMMU there.)
>> > 
>> > I think we hide it altogether from the dom0 - so when it does the
>> > bus reassignment it does not see the AMD IOMMU.
>> > 
>> > My concern was that the bus number of the AMD IOMMU device may
>> > overlap with other bus numbers - which got moved as a result
>> > of the bridge expanding its subordinate bus numbers.
>> > 
>> > In other words, the AMD IOMMU may have been at bus 0xb, the
>> > bridge in question at 0x01, with an PCI device at 0x02;
>> > some devices between 0x03 down to 0x0a.
>> > 
>> > The bridge would now cover 0x01->0x04 (with the PCI device
>> > still at 0x02). But the devices at the old 0x03->0x0a have now
>> > been shifted to 0x04->0x0b. And the AMD IOMMU is at 0x0c.
>> > 
>> > But Xen has no clue about this and "loses" the AMD IOMMU and
>> > starts writting configuration data to whatever poor device used to
>> > be at bus 0x0b.
>> 
>> And how would that issue be solved by leaving that device alone?
> 
> If it was exposed to dom0, it could make an PHYSDEVOP_pci_device_add
> to add it back to Xen (as a new device at bus 0x0c).
> 
> But Xen wouldn't know what to do with it - it would still think that
> the AMD IOMMU is at bus 0x0b.

Ah, now I see what you're getting at: It's the AMD IOMMU code itself
which would need to get notified. That's even more of an orthogonal
issue than the general mixing in of bus reassignment you allude to ...

> I believe I am going on a tangent here - that is the MMCFG
> conversation is about the extended configuration registers and how
> to make Xen aware of them such that when the VF is added Xen will
> be able to validate them. Ed's idea of making the MMCFG hypercall
> when the PCI notification (with your suggestions) should take care
> of it (I hope).
> 
> The issue I am waxing on about is just Linux reassigning the
> PCI devices and what are some of the repercussions that stem from that.

... here. (As a side note - I don't think we do or even reasonably
could hide that device from being found during a bus scan. All we
do is disallow it being played with by Dom0 or getting assigned to
a DomU.)

> I should start a new thread about it and propose some prototype
> patch, once my TODO queue is a bit sane.

Much appreciated, thanks.

Jan


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

[Xen-devel] Oldest supported Xen version in upstream QEMU (Was: Re: [Minios-devel] [PATCH v2 0/15+5+5] Begin to disentangle libxenctrl and provide some stable libraries)

[Ian Campbell]

(dropping minios-devel)

Stefano,

On Wed, 2015-07-15 at 16:46 +0100, Ian Campbell wrote:
> 
> There are 3 series, against xen.git (15 patches), mini-os.git (5
> patches) and qemu-xen-trad.git (5 patches). The patches against xen.git
> point to the patches in the other two trees via instructions to update
> the relevant Config.mk field. The perils of changing unstable
> interfaces!

I started looking into making the appropriate changes to QEMU upstream to
use the new libraries directly.

QEMU (in include/hw/xen/xen_common.h) includes compat shims for libxenctrl
versions back as far as 3.3.0.

The main distinction is between pre-4.1.0 and 4.1.0 and later, since
various handles switching from int's to opaque pointers at that point,
meaning there are some typedefs and wrappers for things.

My plan was to rework the QEMU code to use only the new library function
names for everything such that this becomes the default case (which makes
sense given these libraries are intended to be long term stable) and to
update the code in xen_common.h to bridge the gap to 4.6 and earlier.

But I'm having to jump through some hoops in order to support the pre-4.1.0
version of things. It's not impossible to support it, I'm sure, but things
would be a lot easier if we could just drop that support code.

Can we consider dropping support for Xen 4.0 and earlier from upstream QEMU
at this point?

Some data: Xen 4.0.0 was released in April 2010, the last point release was
4.0.4 in August 2012 and we no longer do security support for it (for a
year or two now, I think).

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH v7 16/17] VT-d: Dump the posted format IRTE

[Jan Beulich]

>>> On 11.09.15 at 10:29,  wrote:
> Add the utility to dump the posted format IRTE.
> 
> CC: Yang Zhang 
> CC: Kevin Tian 
> Signed-off-by: Feng Wu 
> ---
> v7:
> - Remove the two stage loop

This looks quite a bit better now, thanks.

> --- a/xen/drivers/passthrough/vtd/utils.c
> +++ b/xen/drivers/passthrough/vtd/utils.c
> @@ -203,6 +203,9 @@ static void dump_iommu_info(unsigned char key)
>  ecap_intr_remap(iommu->ecap) ? "" : "not ",
>  (status & DMA_GSTS_IRES) ? " and enabled" : "" );
>  
> +printk("  Interrupt Posting: %ssupported.\n",
> +cap_intr_post(iommu->cap) ? "" : "not ");

Wrong indentation.

> @@ -213,8 +216,11 @@ static void dump_iommu_info(unsigned char key)
>  
>  printk("  Interrupt remapping table (nr_entry=%#x. "
>  "Only dump P=1 entries here):\n", nr_entry);
> -printk("   SVT  SQ   SID  DST  V  AVL DLM TM RH DM "
> -   "FPD P\n");
> +printk("R means remapped format, P means posted format.\n");
> +printk("R:   SVT  SQ   SID  V  AVL FPD  DST DLM TM RH DM 
> "
> +   "P\n");
> +printk("P:   SVT  SQ   SID  V  AVL FPD  PDA  URG 
> "
> +   "P\n");

Correct indentation, but this should really be a single line.

> @@ -232,11 +238,21 @@ static void dump_iommu_info(unsigned char key)
>  
>  if ( !p->remap.p )
>  continue;
> -printk("  %04x:  %x   %x  %04x %08x %02x%x   %x  %x  %x  
> %x"
> -"   %x %x\n", i,
> -p->remap.svt, p->remap.sq, p->remap.sid, p->remap.dst,
> -p->remap.vector, p->remap.avail, p->remap.dlm, 
> p->remap.tm,
> -p->remap.rh, p->remap.dm, p->remap.fpd, p->remap.p);
> +if ( !p->remap.im )
> +printk("R:  %04x:  %x   %x  %04x %02x%x   %x %08x   "
> +"%x  %x  %x  %x %x\n", i,
> +p->remap.svt, p->remap.sq, p->remap.sid,
> +p->remap.vector, p->remap.avail, p->remap.fpd,
> +p->remap.dst, p->remap.dlm, p->remap.tm, p->remap.rh,
> +p->remap.dm, p->remap.p);
> +else
> +printk("P:  %04x:  %x   %x  %04x %02x%x   %x %16lx   
>  "
> +"%x %x\n", i,
> +p->post.svt, p->post.sq, p->post.sid, p->post.vector,
> +p->post.avail, p->post.fpd,
> +((u64)p->post.pda_h << 32) | (p->post.pda_l << 6),
> +p->post.urg, p->post.p);

Wrong indentation again, and the format strings also again should all
be on the same line.

Jan


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

Re: [Xen-devel] [PATCH v7 13/17] Update IRTE according to guest interrupt config changes

[Jan Beulich]

>>> On 11.09.15 at 10:29,  wrote:
> @@ -198,6 +199,103 @@ void free_hvm_irq_dpci(struct hvm_irq_dpci *dpci)
>  xfree(dpci);
>  }
>  
> +/*
> + * This routine handles lowest-priority interrupts using vector-hashing
> + * mechanism. As an example, modern Intel CPUs use this method to handle
> + * lowest-priority interrupts.
> + *
> + * Here is the details about the vector-hashing mechanism:
> + * 1. For lowest-priority interrupts, store all the possible destination
> + *vCPUs in an array.
> + * 2. Use "gvec % max number of destination vCPUs" to find the right
> + *destination vCPU in the array for the lowest-priority interrupt.
> + */
> +static struct vcpu *vector_hashing_dest(const struct domain *d,
> +uint32_t dest_id,
> +bool_t dest_mode,
> +uint8_t gvec)
> +
> +{
> +unsigned long *dest_vcpu_bitmap;
> +unsigned int dest_vcpus = 0;
> +unsigned int bitmap_array_size = BITS_TO_LONGS(d->max_vcpus);

You use the variable just once. Ditch it, or at least make it const.

> +struct vcpu *v, *dest = NULL;
> +unsigned int i;
> +
> +dest_vcpu_bitmap = xzalloc_array(unsigned long, bitmap_array_size);
> +if ( !dest_vcpu_bitmap )
> +return NULL;
> +
> +for_each_vcpu ( d, v )
> +{
> +if ( !vlapic_match_dest(vcpu_vlapic(v), NULL, APIC_DEST_NOSHORT,
> +dest_id, dest_mode) )
> +continue;
> +
> +__set_bit(v->vcpu_id, dest_vcpu_bitmap);
> +dest_vcpus++;
> +}
> +
> +if ( dest_vcpus != 0 )
> +{
> +unsigned int mod = gvec % dest_vcpus;
> +unsigned int idx = 0;
> +
> +for ( i = 0; i <= mod; i++ )
> +{
> +idx = find_next_bit(dest_vcpu_bitmap, d->max_vcpus, idx) + 1;
> +BUG_ON(idx >= d->max_vcpus);
> +}
> +
> +dest = d->vcpu[idx-1];

Blanks around the - please.

> +static struct vcpu *pi_find_dest_vcpu(const struct domain *d, uint32_t 
> dest_id,
> +  bool_t dest_mode, uint8_t 
> delivery_mode,
> +  uint8_t gvec)
> +{
> +unsigned int dest_vcpus = 0;
> +struct vcpu *v, *dest = NULL;
> +
> +if ( delivery_mode == dest_LowestPrio )
> +return vector_hashing_dest(d, dest_id, dest_mode, gvec);
> +else if ( delivery_mode == dest_Fixed )

Pointless else. And perhaps this should be switch(delivery_mode)
anyway.

With those cosmetic issues addressed
Acked-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v7 12/17] x86: move some APIC related macros to apicdef.h

[Jan Beulich]

>>> On 11.09.15 at 10:29,  wrote:
> Move some APIC related macros to apicdef.h, so they can be used
> outside of vlapic.c.
> 
> CC: Keir Fraser 
> CC: Jan Beulich 
> CC: Andrew Cooper 
> Signed-off-by: Feng Wu 
> ---
> v7:
> - Put the Macros to the right place inside the file.

Almost:

> --- a/xen/include/asm-x86/apicdef.h
> +++ b/xen/include/asm-x86/apicdef.h
> @@ -57,6 +57,8 @@
>  #define  APIC_DEST_SELF  0x4
>  #define  APIC_DEST_ALLINC0x8
>  #define  APIC_DEST_ALLBUT0xC
> +#define  APIC_SHORT_MASK 0xC
> +#define  APIC_DEST_NOSHORT   0x0

This last one would more naturally go ahead of APIC_DEST_SELF. And
both it and ...

> @@ -64,6 +66,7 @@
>  #define  APIC_INT_LEVELTRIG  0x08000
>  #define  APIC_INT_ASSERT 0x04000
>  #define  APIC_ICR_BUSY   0x01000
> +#define  APIC_DEST_MASK  0x800

... this one should be zero-padded to match the respective neighbors.

With that done
Acked-by: Jan Beulich 


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

[Xen-devel] [xen-4.2-testing baseline-only test] 37998: trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 37998 xen-4.2-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/37998/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl-vhd 3 host-install(3) broken REGR. vs. 37942
 test-amd64-i386-xl-qcow2  3 host-install(3) broken REGR. vs. 37942
 test-amd64-amd64-xl-qemuu-ovmf-amd64  3 host-install(3) broken REGR. vs. 37942
 test-amd64-amd64-pv   3 host-install(3) broken REGR. vs. 37942
 test-i386-i386-xl-credit2 3 host-install(3) broken REGR. vs. 37942
 test-i386-i386-xl-raw 3 host-install(3) broken REGR. vs. 37942
 test-amd64-i386-xl-raw3 host-install(3) broken REGR. vs. 37942
 test-i386-i386-xl-multivcpu   3 host-install(3) broken REGR. vs. 37942
 test-amd64-i386-xl3 host-install(3) broken REGR. vs. 37942
 test-amd64-amd64-xl-winxpsp3  3 host-install(3) broken REGR. vs. 37942
 test-amd64-amd64-xl-qemut-win7-amd64  3 host-install(3) broken REGR. vs. 37942
 test-amd64-i386-rhel6hvm-amd  3 host-install(3) broken REGR. vs. 37942
 test-amd64-i386-qemut-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 37942
 test-amd64-amd64-xl-multivcpu  3 host-install(3)broken REGR. vs. 37942
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 37942
 test-i386-i386-pv 3 host-install(3) broken REGR. vs. 37942
 test-i386-i386-xl 3 host-install(3) broken REGR. vs. 37942
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken REGR. vs. 
37942
 test-amd64-i386-xl-vhd3 host-install(3) broken REGR. vs. 37942
 test-amd64-i386-xl-qemut-debianhvm-amd64 3 host-install(3) broken REGR. vs. 
37942
 test-amd64-i386-xl-qemuu-ovmf-amd64  3 host-install(3)  broken REGR. vs. 37942
 test-amd64-i386-xl-win7-amd64  3 host-install(3)broken REGR. vs. 37942
 test-amd64-i386-xl-qemut-win7-amd64  3 host-install(3)  broken REGR. vs. 37942
 test-amd64-i386-qemuu-freebsd10-amd64 3 host-install(3) broken REGR. vs. 37942
 test-amd64-i386-pv3 host-install(3) broken REGR. vs. 37942
 test-amd64-i386-xl-qemuu-debianhvm-amd64 3 host-install(3) broken REGR. vs. 
37942
 test-amd64-i386-qemuu-freebsd10-i386  3 host-install(3) broken REGR. vs. 37942
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 37942
 test-amd64-i386-xl-qemuu-win7-amd64  3 host-install(3)  broken REGR. vs. 37942
 test-amd64-amd64-xl-qemut-debianhvm-amd64 3 host-install(3) broken REGR. vs. 
37942
 test-amd64-amd64-xl-credit2   3 host-install(3) broken REGR. vs. 37942
 test-amd64-amd64-xl   3 host-install(3) broken REGR. vs. 37942
 test-amd64-amd64-xl-raw   3 host-install(3) broken REGR. vs. 37942
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 37942
 test-amd64-amd64-xl-qcow2 3 host-install(3) broken REGR. vs. 37942
 test-amd64-i386-xend-winxpsp3  3 host-install(3)broken REGR. vs. 37942
 test-amd64-amd64-pygrub   3 host-install(3) broken REGR. vs. 37942
 test-amd64-amd64-xl-vhd   3 host-install(3) broken REGR. vs. 37942
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)   broken REGR. vs. 37942
 test-amd64-i386-qemut-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 37942
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken REGR. vs. 
37942
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)   broken REGR. vs. 37942
 test-amd64-i386-xend-qemut-winxpsp3  3 host-install(3)  broken REGR. vs. 37942
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 3 host-install(3) broken REGR. vs. 
37942
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 37942
 test-i386-i386-pair  4 host-install/dst_host(4) broken REGR. vs. 37942
 test-i386-i386-pair  3 host-install/src_host(3) broken REGR. vs. 37942
 test-amd64-amd64-pair3 host-install/src_host(3) broken REGR. vs. 37942
 test-amd64-amd64-pair4 host-install/dst_host(4) broken REGR. vs. 37942
 test-amd64-i386-pair 3 host-install/src_host(3) broken REGR. vs. 37942
 test-amd64-i386-pair 4 host-install/dst_host(4) broken REGR. vs. 37942
 test-amd64-amd64-xl-qemuu-winxpsp3  3 host-install(3)   broken REGR. vs. 37942
 test-amd64-amd64-xl-qemut-winxpsp3  3 host-install(3)   broken REGR. vs. 37942

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt   3 host-install(3) broken REGR. vs. 37942
 test-amd64-i386-libvirt-raw   3 host-install(3) broken REGR. vs. 37942
 test-amd64-amd64-libvirt-vhd  3 host-install(3) broken REGR. vs. 37942
 test-amd64-i386-libvirt-vhd   3 host-install(3) broken REGR. vs. 37942
 test-amd64-amd64-libvirt-raw  3 host-install(3) broken REGR. vs. 379

Re: [Xen-devel] [PATCH v7 11/17] vt-d: Add API to update IRTE when VT-d PI is used

[Jan Beulich]

>>> On 11.09.15 at 10:29,  wrote:
> --- a/xen/drivers/passthrough/vtd/intremap.c
> +++ b/xen/drivers/passthrough/vtd/intremap.c
> @@ -899,3 +899,124 @@ void iommu_disable_x2apic_IR(void)
>  for_each_drhd_unit ( drhd )
>  disable_qinval(drhd->iommu);
>  }
> +
> +static void setup_posted_irte(
> +struct iremap_entry *new_ire, const struct iremap_entry *old_ire,
> +const struct pi_desc *pi_desc, const uint8_t gvec)
> +{
> +memset(new_ire, sizeof(*new_ire), 0);
> +
> +if (!old_ire->remap.im)

Coding style.

> +{
> +new_ire->post.p = old_ire->remap.p;
> +new_ire->post.fpd = old_ire->remap.fpd;
> +new_ire->post.sid = old_ire->remap.sid;
> +new_ire->post.sq = old_ire->remap.sq;
> +new_ire->post.svt = old_ire->remap.svt;
> +new_ire->post.urg = 0;

No longer needed.

> +}
> +else
> +{
> +new_ire->post.p = old_ire->post.p;
> +new_ire->post.fpd = old_ire->post.fpd;
> +new_ire->post.sid = old_ire->post.sid;
> +new_ire->post.sq = old_ire->post.sq;
> +new_ire->post.svt = old_ire->post.svt;
> +new_ire->post.urg = old_ire->post.urg;
> +}
> +
> +new_ire->post.im = 1;
> +new_ire->post.vector = gvec;
> +new_ire->post.pda_l = virt_to_maddr(pi_desc) >> (32 - PDA_LOW_BIT);
> +new_ire->post.pda_h = virt_to_maddr(pi_desc) >> 32;
> +}

Quite a bit more explicit about what gets inherited and what gets
written anew. Thanks!

With the minor adjustment above done
Reviewed-by: Jan Beulich 


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