Re: [Xen-devel] [Xen-users] Xen bridging issue.

[Wei Liu]

On Tue, Sep 08, 2015 at 09:58:59AM +0100, Ian Campbell wrote:
> On Mon, 2015-09-07 at 15:50 +0300, johnny Strom wrote:
> > 
> > Hello
> > 
> > I sent an email before about bridging not working in domU using Debian 
> > 8.1 and XEN 4.4.1.
> > 
> > It was not the network card "igb" as I first taught.
> > 
> > I managed to get bridging working in DOMU if is set the limit of cpu's 
> > in dom0 to 14, this is from /etc/default/grub
> > when it works ok:
> > 
> > GRUB_CMDLINE_XEN="dom0_max_vcpus=14 dom0_vcpus_pin"
> > 
> > 
> > Is there any known issue/limitations running xen with more with more 
> > than 14 CPU cores in dom0?
> > 
> > 
> > The cpu in question is:
> > 
> > processor   : 16
> > vendor_id   : GenuineIntel
> > cpu family  : 6
> > model   : 63
> > model name  : Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz
> > stepping: 2
> > microcode   : 0x2d
> > cpu MHz : 2298.718
> > cache size  : 25600 KB
> > physical id : 0
> > siblings: 17
> > core id : 11
> > cpu cores   : 9
> > apicid  : 22
> > initial apicid  : 22
> > fpu : yes
> > fpu_exception   : yes
> > cpuid level : 15
> > wp  : yes
> > flags   : fpu de tsc msr pae mce cx8 apic sep mca cmov pat 
> > clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good 
> > nopl nonstop_tsc eagerfpu pni pclmulqdq monitor est ssse3 fma cx16 
> > sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand 
> > hypervisor lahf_lm abm ida arat epb xsaveopt pln pts dtherm fsgsbase 
> > bmi1 avx2 bmi2 erms
> > bogomips: 4597.43
> > clflush size: 64
> > cache_alignment : 64
> > address sizes   : 46 bits physical, 48 bits virtual
> > power management:
> > 
> > 
> > 
> > 
> > If I set it to 17 in dom0:
> > 
> > GRUB_CMDLINE_XEN="dom0_max_vcpus=17 dom0_vcpus_pin"
> > 
> > Then I get this oops whan I try to boot domU with 40 vcpu's.
> > 
> > [1.588313] systemd-udevd[255]: starting version 215
> > [1.606097] xen_netfront: Initialising Xen virtual ethernet driver
> > [1.648172] blkfront: xvda2: flush diskcache: enabled; persistent 
> > grants: enabled; indirect descriptors: disabled;
> > [1.649190] blkfront: xvda1: flush diskcache: enabled; persistent 
> > grants: enabled; indirect descriptors: disabled;
> > [1.649705] Setting capacity to 2097152
> > [1.649716] xvda2: detected capacity change from 0 to 1073741824
> > [1.653540] xen_netfront: can't alloc rx grant refs
> 
> The frontend has run out of grant refs, perhaps due to multiqueue support
> in the front/backend where I think the number of queues scales with number
> of processors.
> 

The default number of queues would be number of _backend_ processors.
Xen command line indicates 17 Dom0 vcpus, which isn't too large I think.

Can you check in xenstore what the value of multi-queue-max-queues is?
Use xenstore-ls /local/domain/$DOMID/ when the guest is still around.

> I've added some relevant maintainers for net{front,back} and grant tables,
> plus people who were involved with MQ and the devel list.
> 
> 
> > [1.653547] net eth1: only created 17 queues

This indicates it only created 16 queues.  And there seems to be a bug
in code.

Wei.

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

Re: [Xen-devel] [PATCH v6 15/18] vmx: Properly handle notification event when vCPU is running

[Jan Beulich]

>>> On 08.09.15 at 07:18,  wrote:

> 
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Monday, September 07, 2015 8:10 PM
>> To: Wu, Feng; Zhang, Yang Z
>> Cc: Andrew Cooper; Tian, Kevin; xen-devel@lists.xen.org; Keir Fraser
>> Subject: Re: [PATCH v6 15/18] vmx: Properly handle notification event when
>> vCPU is running
>> 
>> >>> On 25.08.15 at 03:57,  wrote:
>> > --- a/xen/arch/x86/hvm/vmx/vmx.c
>> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> >  const struct hvm_function_table * __init start_vmx(void)
>> >  {
>> >  set_in_cr4(X86_CR4_VMXE);
>> > @@ -2073,7 +2119,7 @@ const struct hvm_function_table * __init
>> start_vmx(void)
>> >
>> >  if ( cpu_has_vmx_posted_intr_processing )
>> >  {
>> > -alloc_direct_apic_vector(_intr_vector,
>> event_check_interrupt);
>> > +alloc_direct_apic_vector(_intr_vector,
>> pi_notification_interrupt);
>> >
>> >  if ( iommu_intpost )
>> >  alloc_direct_apic_vector(_wakeup_vector,
>> pi_wakeup_interrupt);
>> 
>> Considering that you do this setup independent of iommu_intpost,
>> won't this (namely, but not only) for the !iommu_inpost case result
>> in a whole lot of useless softirqs to be raised? 
> 
> I don't think lots of useless softirqs will be raised in !iommu_intpost
> case, since we can get pi_notification_interrupt() only when someone
> called __vmx_deliver_posted_interrupt() in which, the VCPU_KICK_SOFTIRQ
> bit was set.

Now that you say it, this looks even more odd: Why would you need
to raise that softirq if the only way to come here is via the triggering
in __vmx_deliver_posted_interrupt() (which already raised that
softirq)? I suppose I must be missing something...

>> IOW - shouldn't this setup be conditional, 
> 
> We cannot setup pi_notification_interrupt() conditional, since it is
> for all cases, non-vtd-pi and vt-d pi.

But you could continue to use event_check_interrupt in the
!iommu_intpost case.

>> and shouldn't the handler also only conditionally raise the softirq
>> (to as much as possible limit their amount)?
> 
> As mentioned above, there are not extra softirq raised. If you think
> It is necessary, I can add a condition here as below, which I really think
> is useless, but I am fine to add it if you really think it is a must.
> 
>   if ( iommu_intpost )
>   raise_softirq(VCPU_KICK_SOFTIRQ);

See above - if this doesn't raise any extra softirqs, then why do
you call raise_softirq() in the first place?

Jan


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

Re: [Xen-devel] [PATCH v6 15/18] vmx: Properly handle notification event when vCPU is running

[Jan Beulich]

>>> On 08.09.15 at 11:23,  wrote:

> 
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Tuesday, September 08, 2015 5:14 PM
>> To: Wu, Feng
>> Cc: Andrew Cooper; Tian, Kevin; Zhang, Yang Z; xen-devel@lists.xen.org; Keir
>> Fraser
>> Subject: RE: [PATCH v6 15/18] vmx: Properly handle notification event when
>> vCPU is running
>> 
>> >>> On 08.09.15 at 07:18,  wrote:
>> 
>> >
>> >> -Original Message-
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: Monday, September 07, 2015 8:10 PM
>> >> To: Wu, Feng; Zhang, Yang Z
>> >> Cc: Andrew Cooper; Tian, Kevin; xen-devel@lists.xen.org; Keir Fraser
>> >> Subject: Re: [PATCH v6 15/18] vmx: Properly handle notification event when
>> >> vCPU is running
>> >>
>> >> >>> On 25.08.15 at 03:57,  wrote:
>> >> > --- a/xen/arch/x86/hvm/vmx/vmx.c
>> >> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> >> >  const struct hvm_function_table * __init start_vmx(void)
>> >> >  {
>> >> >  set_in_cr4(X86_CR4_VMXE);
>> >> > @@ -2073,7 +2119,7 @@ const struct hvm_function_table * __init
>> >> start_vmx(void)
>> >> >
>> >> >  if ( cpu_has_vmx_posted_intr_processing )
>> >> >  {
>> >> > -alloc_direct_apic_vector(_intr_vector,
>> >> event_check_interrupt);
>> >> > +alloc_direct_apic_vector(_intr_vector,
>> >> pi_notification_interrupt);
>> >> >
>> >> >  if ( iommu_intpost )
>> >> >  alloc_direct_apic_vector(_wakeup_vector,
>> >> pi_wakeup_interrupt);
>> >>
>> >> Considering that you do this setup independent of iommu_intpost,
>> >> won't this (namely, but not only) for the !iommu_inpost case result
>> >> in a whole lot of useless softirqs to be raised?
>> >
>> > I don't think lots of useless softirqs will be raised in !iommu_intpost
>> > case, since we can get pi_notification_interrupt() only when someone
>> > called __vmx_deliver_posted_interrupt() in which, the VCPU_KICK_SOFTIRQ
>> > bit was set.
>> 
>> Now that you say it, this looks even more odd: Why would you need
>> to raise that softirq if the only way to come here is via the triggering
>> in __vmx_deliver_posted_interrupt() (which already raised that
>> softirq)? I suppose I must be missing something...
> 
> Before VT-d PI, __vmx_deliver_posted_interrupt() is the only way
> to trigger interrupt with vector ' posted_intr_vector ', but after
> introducing VT-d PI, VT-d hardware can issue the interrupt with
> that vector as well. In __vmx_deliver_posted_interrupt(), it set
> the softirqs, the reason of which is described in the comments
> of pi_notification_interrupt(), however, I need do the same thing
> when VT-d hardware issue the interrupt, so pi_notification_interrupt()
> is the proper place to do it.

But again - my main concern is about the !iommu_intpost case: What
good does the raising of the softirq there? (As a general remark -
please, when you add code to support a new feature, don't just
think about the case where the new feature is available in hardware,
but also about the case where it's not. While over time the set of
systems lacking the feature will likely decrease, initially it may be the
vast majority of systems Xen gets run on which would get penalized.)

Jan


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

Re: [Xen-devel] [PATCH v6 02/18] Add cmpxchg16b support for x86-64

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, September 08, 2015 5:19 PM
> To: Wu, Feng
> Cc: Andrew Cooper; xen-devel@lists.xen.org; Keir Fraser
> Subject: RE: [PATCH v6 02/18] Add cmpxchg16b support for x86-64
> 
> >>> On 08.09.15 at 10:57,  wrote:
> 
> >
> >> -Original Message-
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Tuesday, September 08, 2015 4:52 PM
> >> To: Wu, Feng
> >> Cc: Andrew Cooper; xen-devel@lists.xen.org; Keir Fraser
> >> Subject: RE: [PATCH v6 02/18] Add cmpxchg16b support for x86-64
> >>
> >> >>> On 08.09.15 at 09:37,  wrote:
> >> > Thanks for your suggestion. How about this?
> >> >
> >> > #define cmpxchg16b(ptr,o,n)
> >> \
> >> > ( ({ ASSERT(((unsigned long)ptr & 0xF) == 0); }),
> \
> >> >   BUILD_BUG_ON(sizeof(*o) != sizeof(__uint128_t)),
> >> \
> >> >   BUILD_BUG_ON(sizeof(*n) != sizeof(__uint128_t)),
> >> \
> >> >   __cmpxchg16b((ptr), (__uint128_t *)(o), (__uint128_t *)(n)) )
> >>
> >> Yes (properly parenthesized and the ({ }) either removed or extended
> >
> > We need the ({ }) for the ASSERT statement, or we will meet build error.
> 
> And note that I didn't unconditionally say drop it, I provided the
> alternative of making it cover the entire expression (at once allowing
> you to convert the comma expressions to more conventional individual
> statements).
> 

This is not a big issue, If you don't like the above solution, please be 
explicit,
just type it, in code, save efforts for both of us. Thanks!

Thanks,
Feng

> Jan


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

Re: [Xen-devel] [OSSTEST PATCH 07/29] Planner: client side: Do not force OSSTEST_RESOURCE_PRIORITY

[Ian Campbell]

On Mon, 2015-09-07 at 17:08 +0100, Ian Jackson wrote:
> This makes it possible to run mg-allocate with a different priority
> simply by setting OSSTEST_RESOURCE_PRIORITY in its environment.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 

> ---
> v2: New patch
> ---
>  mg-allocate |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mg-allocate b/mg-allocate
> index 6dc7ddd..14c9088 100755
> --- a/mg-allocate
> +++ b/mg-allocate
> @@ -365,7 +365,7 @@ while (@ARGV && $ARGV[0] =~ m/^[-0-9]/) {
>   $2 eq 'm' ?60 :
>   1);
>  } elsif (s/^\-U/-/) {
> -$ENV{OSSTEST_RESOURCE_PRIORITY}= -100;
> +$ENV{OSSTEST_RESOURCE_PRIORITY} //= -100;
>  } else {
>  die "bad option \`$_'";
>  }

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

[Xen-devel] Fwd: Question about the status of vNUMA in Xen

[甘清甜]

-- Forwarded message -
From: Wei Liu 
Date: 2015年9月7日周一 下午6:23
Subject: Re: [Xen-devel] Question about the status of vNUMA in Xen
To: 甘清甜 
Cc: , 


On Sun, Sep 06, 2015 at 03:03:13PM +0800, 甘清甜 wrote:
> I'm a master student from Huazhong University of Science & technology,
> China. I'm now researching on Xen optimization under NUMA. I'm puzzled
> that if  vNUMA on HVM is enbaded in Xen or not. If yes, which version of
> xen support it?
>

Upcoming Xen 4.6 supports vNUMA for HVM guest, with certain limitations.

> So far, I have read the Xen NUMA Roadmap page and watched the
> video about vNUMA in Xen on Youtube. I have known that some work
> has been done for vNUMA in Xen. Since my benchmark result show a
> great improvement in Xen-4.5.1 when compared with Xen-4.0.1. I'm
> puzzled if vNUMA has contributed to that improvement.

No. That's mostly due to other improvements.

Wei.

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

I’m sorry that I didn’t express clearly in the last mail. What I want to
know is

that how much the NUMA optimizations (including NUMA-aware VM placement,

NUMA-aware scheduling and vNUMA)  contribute to the improvement

between xen-4.5.1 and xen-4.0.1.  Surely it may also due to other changes.
Thanks!
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] XEN_NETIF_NR_SLOTS_MIN

[Jan Beulich]

>>> On 07.09.15 at 17:58,  wrote:
> On Mon, Sep 07, 2015 at 09:15:40AM -0600, Jan Beulich wrote:
>> >>> On 07.09.15 at 16:56,  wrote:
>> > Linux netfront is able to consolidate several slots into reasonable
>> > number of frags and make sure the number of frags won't exceed limit.
>> > See xennet_fill_frags.
>> 
>> That's too late - xennet_get_responses() would have rejected such
>> a packet already afaict (error message "Too many slots").
>> 
> 
> Right, that's a bit unfortunate.  We might need to have that on the
> protocol level, say, backend should not push more than X slots to
> frontend.
> 
> OOI are you seeing this in real world?

Yes, with our netback (which I'm only now getting an equivalent of
David's coalescing patch added) I could easily see these "Too many
frags" (in our netfront, still using the old naming) messages. Clearly
the patch to netback will hide the errors, but it still shows that
netfront doesn't cope with old netback (and that's even when the
netfront used sees the same smaller MAX_SKB_FRAGS that netback
also uses, i.e. the situation would be worse with a netback on an
older kernel with the one larger MAX_SKB_FRAGS).

Jan


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

Re: [Xen-devel] [linux-3.10 bisection] complete test-amd64-amd64-xl-vhd

[Ian Campbell]

On Tue, 2015-09-08 at 05:24 +, osstest service owner wrote:
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-amd64-xl-vhd
> test debian-di-install
> 
> Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux
> -stable.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> Tree: xen git://xenbits.xen.org/xen.git
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  linux 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
>   Bug introduced:  292f53675e097ca807df744fb6fd39211a134bf7
>   Bug not present: 3f2c206ae6f9e1005ac7f092e8d65c17307a0d59
> 
> 
>   commit 292f53675e097ca807df744fb6fd39211a134bf7
>   Author: Marek Marczykowski-Górecki 
>   Date:   Fri Jun 26 03:28:24 2015 +0200
>   
>   xen/gntdevt: Fix race condition in gntdev_release()


Known issue:
 http://lists.xen.org/archives/html/xen-devel/2015-09/msg00161.html


>   
>   commit 30b03d05e07467b8c6ec683ea96b5bffcbcd3931 upstream.
>   
>   While gntdev_release() is called the MMU notifier is still 
> registered
>   and can traverse priv->maps list even if no pages are mapped (which 
> is
>   the case -- gntdev_release() is called after all). But
>   gntdev_release() will clear that list, so make sure that only one 
> of
>   those things happens at the same time.
>   
>   Signed-off-by: Marek Marczykowski-Górecki <
> marma...@invisiblethingslab.com>
>   Signed-off-by: David Vrabel 
>   Signed-off-by: Greg Kroah-Hartman 
> 
> 
> For bisection revision-tuple graph see:
>http://logs.test-lab.xenproject.org/osstest/results/bisect/linux
> -3.10/test-amd64-amd64-xl-vhd.debian-di-install.html
> Revision IDs in each graph node refer, respectively, to the Trees above.
> 
> 
> Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux
> -3.10/test-amd64-amd64-xl-vhd.debian-di-install --summary
> -out=tmp/61590.bisection-summary --basis-template=60670 -
> -blessings=real,real-bisect linux-3.10 test-amd64-amd64-xl-vhd debian-di
> -install
> Searching for failure / basis pass:
>  61268 fail [host=chardonnay1] / 60670 [host=godello1] 60656 
> [host=chardonnay0] 60548 [host=fiano1] template as basis? using template 
> as basis.
> Failure / basis pass flights: 61268 / 60670
> (tree with no url: ovmf)
> (tree with no url: seabios)
> Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux
> -stable.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> Tree: xen git://xenbits.xen.org/xen.git
> Latest 5a427ce18a14d6b85972c62196a8f10c3624d74a 
> c530a75c1e6a472b0eb9558310b518f0dfcd8860 
> 5cdde31eacdd288359746019ad05cac8ed5d9f70 
> b05befcbea71a979509ce04f02929969a790c923 
> 801ab48e5556cb54f67e3cb57f077f47e8663ced
> Basis pass 78fb9f4236d9077fb343fb5a4e55fe27075e9a1d 
> c530a75c1e6a472b0eb9558310b518f0dfcd8860 
> 7f057440b31da38196e3398fd1b618fc36ad97d6 
> bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa 
> 201eac83831d94ba2e9a63a7eed4c128633fafb1
> Generating revisions with ./adhoc-revtuple-generator 
>  git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux
> -stable.git#78fb9f4236d9077fb343fb5a4e55fe27075e9a1d
> -5a427ce18a14d6b85972c62196a8f10c3624d74a 
> git://xenbits.xen.org/osstest/linux
> -firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860
> -c530a75c1e6a472b0eb9558310b518f0dfcd8860 
> git://xenbits.xen.org/staging/qemu-xen
> -unstable.git#7f057440b31da38196e3398fd1b618fc36ad97d6
> -5cdde31eacdd288359746019ad05cac8ed5d9f70 
> git://xenbits.xen.org/staging/qemu-upstream
> -unstable.git#bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa
> -b05befcbea71a979509ce04f02929969a790c923 
> git://xenbits.xen.org/xen.git#201eac83831d94ba2e9a63a7eed4c128633fafb1
> -801ab48e5556cb54f67e3cb57f077f47e8663ced
> Loaded 18027 nodes in revision graph
> Searching for test results:
>  60670 [host=godello1]
>  60656 [host=chardonnay0]
>  60827 fail irrelevant
>  60790 fail irrelevant
>  60748 fail irrelevant
>  60950 fail 5a427ce18a14d6b85972c62196a8f10c3624d74a 
> c530a75c1e6a472b0eb9558310b518f0dfcd8860 
> 7f057440b31da38196e3398fd1b618fc36ad97d6 
> b05befcbea71a979509ce04f02929969a790c923 
> 7b99717f62caeac08eea224a177cd28f047ac4b5
>  60865 fail irrelevant
>  60992 fail 5a427ce18a14d6b85972c62196a8f10c3624d74a 
> c530a75c1e6a472b0eb9558310b518f0dfcd8860 
> 7f057440b31da38196e3398fd1b618fc36ad97d6 
> b05befcbea71a979509ce04f02929969a790c923 
> 7b99717f62caeac08eea224a177cd28f047ac4b5
>  61103 fail 5a427ce18a14d6b85972c62196a8f10c3624d74a 
> c530a75c1e6a472b0eb9558310b518f0dfcd8860 
> 

Re: [Xen-devel] [PATCH] xen/vtd/iommu: permit group devices to passthrough in relaxed mode

[Wei Liu]

On Tue, Sep 08, 2015 at 08:57:14AM +0800, Tiejun Chen wrote:
> Currently we don't allow passing through any group devices which are
> sharing same RMRR entry since it would break security among VMs. And
> indeed, we expect we can figure out a better way to handle this kind
> of case completely.
> 
> But before the group assignment gets implemented, we might make this
> permission dependent on our RMRR policy. So, now it would be allowed
> in the relaxed mode.
> 

Is this targeting 4.6? I think so.

> CC: Yang Zhang 
> CC: Kevin Tian 
> CC: Jan Beulich 
> Signed-off-by: Tiejun Chen 
> ---
>  xen/drivers/passthrough/vtd/iommu.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/drivers/passthrough/vtd/iommu.c 
> b/xen/drivers/passthrough/vtd/iommu.c
> index 836aed5..4249cfa 100644
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -2310,12 +2310,16 @@ static int intel_iommu_assign_device(


FWIW the comment before this hunk also needs to be updated.

>   PCI_DEVFN2(bdf) == devfn &&
>   rmrr->scope.devices_cnt > 1 )
>  {
> +u32 relaxed = flag & XEN_DOMCTL_DEV_RDM_RELAXED;
> +
>  printk(XENLOG_G_ERR VTDPREFIX
> -   " cannot assign %04x:%02x:%02x.%u"
> +   " Currently its %s to assign %04x:%02x:%02x.%u"

"it's" or "it is"

> " with shared RMRR at %"PRIx64" for Dom%d.\n",
> +   relaxed ? "risky" : "disallowed",
> seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
> rmrr->base_address, d->domain_id);
> -return -EPERM;
> +if ( !relaxed )
> +return -EPERM;
>  }
>  }
>  
> -- 
> 1.9.1
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

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

[Jan Beulich]

>>> On 08.09.15 at 06:47,  wrote:

> 
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Monday, September 07, 2015 7:03 PM
>> To: Wu, Feng
>> Cc: xen-devel@lists.xen.org 
>> Subject: RE: [PATCH v6 13/18] Update IRTE according to guest interrupt 
> config
>> changes
>> 
>> >>> On 06.09.15 at 06:54,  wrote:
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: Friday, September 04, 2015 11:59 PM
>> >> >>> On 25.08.15 at 03:57,  wrote:
>> >>> 
>> >> > +if ( vcpu )
>> >> > +{
>> >> > +rc = pi_update_irte( vcpu, info,
>> pirq_dpci->gmsi.gvec );
>> >> > +if ( unlikely(rc) )
>> >> > +dprintk(XENLOG_G_INFO,
>> >> > +"%pv: failed to update PI IRTE,
>> >> gvec:%02x\n",
>> >> > +vcpu, pirq_dpci->gmsi.gvec);
>> >>
>> >> Even if only a debug build printk() - aren't you afraid that if this
>> >> ever triggers, it will trigger a lot? And hence be pretty useless?
>> >
>> > I think it reaches this debug printk rarely, but a least, when it is really
>> > failed, it
>> > can give people some hints about why we are using interrupt remapping
>> > instead
>> > of interrupt posing for the external interrupts.
>> 
>> I understand your motivation, but you don't really answer my
>> question. (And btw., if you really mean "rarely", then there's a bug
>> somewhere that you need to fix. It should _never_ trigger if
>> everything is working correctly.)
> 
> I mean pi_update_irte() can return failure theoretically, because there
> are some pointer check in it. You said, it would trigger a lot if this ever
> triggers.

I didn't say it would, I asked whether it might. That's on the basis
that often once an error like this happened, more similar errors are
likely to occur subsequently. Whether that's the case here I can't
easily tell, hence I'm asking you (supposedly having a better
understanding of what can go wrong when and how often).

> Do you mean for a specific pirq, it will always fail after the first
> failure? So what is your suggestion here? Adding an ASSERT()?

An ASSERT() would make things worse (bringing down a debug
hypervisor). Limiting the amount of printing is what I asked to
consider.

Jan


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

Re: [Xen-devel] [PATCH v6 14/18] vmx: posted-interrupt handling when vCPU is blocked

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, September 08, 2015 5:08 PM
> To: Wu, Feng
> Cc: Andrew Cooper; Tian, Kevin; xen-devel@lists.xen.org; Keir Fraser
> Subject: RE: [PATCH v6 14/18] vmx: posted-interrupt handling when vCPU is
> blocked
> 
> >> And without that (plus without anything ever
> >> adding to pi_blocked_vcpu), this moving between two lists seems
> >> rather odd; I think the splitting of the series into patches needs
> >> to be re-thought unless (preferably) you can find a (reasonably
> >> clean) way without using two lists in the first place.
> >
> > Do you mean if using two lists here, I need re-split this patch-set?
> > I wonder why the two lists affect the patchset splitting?
> 
> Because (see above) at this point in the series it makes no sense to
> use two lists, as there's no locking issue to take care of.

Oh, you are right! I need to consider how to split it. Thanks for the
finding.

Thanks,
Feng

> 
> Jan


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

Re: [Xen-devel] [PATCH v6 15/18] vmx: Properly handle notification event when vCPU is running

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, September 08, 2015 5:14 PM
> To: Wu, Feng
> Cc: Andrew Cooper; Tian, Kevin; Zhang, Yang Z; xen-devel@lists.xen.org; Keir
> Fraser
> Subject: RE: [PATCH v6 15/18] vmx: Properly handle notification event when
> vCPU is running
> 
> >>> On 08.09.15 at 07:18,  wrote:
> 
> >
> >> -Original Message-
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Monday, September 07, 2015 8:10 PM
> >> To: Wu, Feng; Zhang, Yang Z
> >> Cc: Andrew Cooper; Tian, Kevin; xen-devel@lists.xen.org; Keir Fraser
> >> Subject: Re: [PATCH v6 15/18] vmx: Properly handle notification event when
> >> vCPU is running
> >>
> >> >>> On 25.08.15 at 03:57,  wrote:
> >> > --- a/xen/arch/x86/hvm/vmx/vmx.c
> >> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> >> >  const struct hvm_function_table * __init start_vmx(void)
> >> >  {
> >> >  set_in_cr4(X86_CR4_VMXE);
> >> > @@ -2073,7 +2119,7 @@ const struct hvm_function_table * __init
> >> start_vmx(void)
> >> >
> >> >  if ( cpu_has_vmx_posted_intr_processing )
> >> >  {
> >> > -alloc_direct_apic_vector(_intr_vector,
> >> event_check_interrupt);
> >> > +alloc_direct_apic_vector(_intr_vector,
> >> pi_notification_interrupt);
> >> >
> >> >  if ( iommu_intpost )
> >> >  alloc_direct_apic_vector(_wakeup_vector,
> >> pi_wakeup_interrupt);
> >>
> >> Considering that you do this setup independent of iommu_intpost,
> >> won't this (namely, but not only) for the !iommu_inpost case result
> >> in a whole lot of useless softirqs to be raised?
> >
> > I don't think lots of useless softirqs will be raised in !iommu_intpost
> > case, since we can get pi_notification_interrupt() only when someone
> > called __vmx_deliver_posted_interrupt() in which, the VCPU_KICK_SOFTIRQ
> > bit was set.
> 
> Now that you say it, this looks even more odd: Why would you need
> to raise that softirq if the only way to come here is via the triggering
> in __vmx_deliver_posted_interrupt() (which already raised that
> softirq)? I suppose I must be missing something...

Before VT-d PI, __vmx_deliver_posted_interrupt() is the only way
to trigger interrupt with vector ' posted_intr_vector ', but after
introducing VT-d PI, VT-d hardware can issue the interrupt with
that vector as well. In __vmx_deliver_posted_interrupt(), it set
the softirqs, the reason of which is described in the comments
of pi_notification_interrupt(), however, I need do the same thing
when VT-d hardware issue the interrupt, so pi_notification_interrupt()
is the proper place to do it.

Thanks,
Feng

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

[Xen-devel] Notes from Xen BoF at Debconf15

[Ian Campbell]

Xen upstream BoF


We had a discussion around Xen and packaging at Debian's annual developer
conference (Debconf) a few weeks back:
https://summit.debconf.org/debconf15/meeting/279/xen-upstream-bof/

These are my notes, I think there is probably stuff of interest to most
distro people, not just Debian folks.

The session was scheduled in a small, out of the way, room. Around 2
dozen people attended including:

  Ian Jackson
  Bastian Blank ("waldi", current Xen package maintainer in Debian)
  Guido Trotter (previous Xen package maintainer, who still takes care
 of stable security updates)
  Axel Beckert  (maintainer of the xen-tools helpers)
  Various users
  Myself

The majority of the conversation was between Ian & I and Bastian and
Guido, some users raised some issues towards the end.

Embedding in xen.git


We are much better about providing ways to use system-supplied
components these days (since 4.4) and Debian uses them.

Waldi noted that iPXE did not have such an option. Since that iPXE is
only used by qemu-trad (for qemu-upstream the iPXE comes from the PCI
ROM BAR) and Debian disabled qemu-trad it should be pretty quick to
patch the build system to disable iPXE.

Secondly it was noted that SeaBIOS is still built into hvmloader,
which makes package updates harder (needs a binNMU of the Xen package
to pickup a new SeaBIOS). Since this is in guest context it is not an
issue for the security team (which would make it higher priority) and
there are medium term plans to perhaps make it possible to load the
BIOS via the toolstack instead.

Note that OVMF would also be built in but is non-free and hence
disabled.

Lowlevel library API stability
==

The majority of the current Debian patch queue is moving unstable
libraries (mainly libxc) from $libdir to $libexecdir/xen-X.Y, adding
-rpath where needed and removing the SONAME from such libraries. Also
move related binary files.

Waldi expressed hope that the hypervisor interfaces could become
stable, but we think this is unlikely. Having the hypervisor provide a
compat layer for older interfaces was ruled out as the wrong place
from a security PoV. Second choice would be to have the tools provide
a compat layer for older hypervisors, which would be possible but
perhaps tricky to achieve.

This is also a problem for some third packages, e.g. qemu-upstream and
kexec-tools. This requires a binNMU of those packages to build against
a new Xen package. This is painful for maintainers.

We explained our plan was to move some sections of the unstable
library out into small stable libraries for specific purposes, with
stuff needed for qemu-upstream, kexec-tools and other external
packages being a priority in the short term. After this we plan to
reexamine what is left and consider next steps.

In the meantime it should be much easier these days to provide
upstream configure options to provide the changes currently patched in
by Debian.

Midlevel library stability
==

libxenlight is only API not ABI stable. This is a pain in particular
for libvirt which needs binNMU for new Xen package.

We would like to eventually offer ABI stability or this library, but
we are not there yet.

Stubdomains
===

Hard to do in a packaging environment (is really its own partial
architecture). Rump kernels are no different in this regard.

No clever ideas were put forward.

initscripts
===

Debian has its own initscripts, does not use the upstream ones.

Waldi stated this was because the upstream ones were not properly LSB
and were too "cross-distro".

We would like to try and have these in xen.git. Perhaps a Yakk, but
closer to upstream the better. Not a very high priority though.

grub-xen


Needs much better docs.

ACTION: I agreed to move the text of my blog post somewhere more
obvious.

Release cycle
=

Waldi commented that the stable release cycle was too long. Would like
to see a release after any large security update.

We asked if the RCs for stable releases were valuable, the answer was
"not so much".

Waldi would prefer to avoid cherry-picking security fixes if possible.

We asked if we thought Xen stable releases could be added to Debian
point releases. Waldi thought they likely could be, citing the
inclusion of Linux stable releases in point releases.

Our stable releases follow a similar set of rules to Linux, we think
we implement them more faithfully (less feature or feature-like
backports)

ACTION: Talk to Jan about making changes to stable release process.

Security updates


Guido asked if security updates could go back further.

Currently we go to 4.2, but Debian Wheezy has Xen 4.1.

The security team don't currently have the effort to go further, but
have recently introduced a private discussion list where predisclosure
members are encouraged to exchange their own backports.

Guido is not on global 

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

[Zhang, Yang Z]

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.

Best regards,
Yang


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

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

[Jan Beulich]

>>> On 08.09.15 at 10:10,  wrote:
> 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.

Right. The patch as it stands, while improving performance, breaks
correctness (by - theoretically - deferring delivery of the interrupt
indefinitely). Yet there certainly is room for improvement, by finding
a correct condition for suppressing the softirq.

Jan


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

Re: [Xen-devel] [PATCH v6 02/18] Add cmpxchg16b support for x86-64

[Jan Beulich]

>>> On 08.09.15 at 10:57,  wrote:

> 
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Tuesday, September 08, 2015 4:52 PM
>> To: Wu, Feng
>> Cc: Andrew Cooper; xen-devel@lists.xen.org; Keir Fraser
>> Subject: RE: [PATCH v6 02/18] Add cmpxchg16b support for x86-64
>> 
>> >>> On 08.09.15 at 09:37,  wrote:
>> > Thanks for your suggestion. How about this?
>> >
>> > #define cmpxchg16b(ptr,o,n)
>> \
>> > ( ({ ASSERT(((unsigned long)ptr & 0xF) == 0); }),  \
>> >   BUILD_BUG_ON(sizeof(*o) != sizeof(__uint128_t)),
>> \
>> >   BUILD_BUG_ON(sizeof(*n) != sizeof(__uint128_t)),
>> \
>> >   __cmpxchg16b((ptr), (__uint128_t *)(o), (__uint128_t *)(n)) )
>> 
>> Yes (properly parenthesized and the ({ }) either removed or extended
> 
> We need the ({ }) for the ASSERT statement, or we will meet build error.

And note that I didn't unconditionally say drop it, I provided the
alternative of making it cover the entire expression (at once allowing
you to convert the comma expressions to more conventional individual
statements).

Jan


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

Re: [Xen-devel] [PATCH v6 02/18] Add cmpxchg16b support for x86-64

[Jan Beulich]

>>> On 08.09.15 at 09:37,  wrote:
> Thanks for your suggestion. How about this?
> 
> #define cmpxchg16b(ptr,o,n)\
> ( ({ ASSERT(((unsigned long)ptr & 0xF) == 0); }),  \
>   BUILD_BUG_ON(sizeof(*o) != sizeof(__uint128_t)), \
>   BUILD_BUG_ON(sizeof(*n) != sizeof(__uint128_t)), \
>   __cmpxchg16b((ptr), (__uint128_t *)(o), (__uint128_t *)(n)) )

Yes (properly parenthesized and the ({ }) either removed or extended
to the whole expression).

Jan


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

[Xen-devel] Question to Xen log level in the case of PT

[Chen, Tiejun]

All guys,

Sorry to raise a question to you since I'm not very sure how to deal 
with this.


When I passthrough a device like IGD, I can see so many messages:

"memory_map:add:" and "memory_map:remove:"

since we have to add/remove all pages map residing PCI bar. Especially 
as a graphic device, oftentimes this range would occupy dozens of MB, 
even hundreds of MB. These print messages consume a lot of time to boot 
a VM. For instance, it takes about 5 minutes to boot a Windows guest on 
my BDW. But if I remove these output simply like this,


diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 7f959f3..82da9d1 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -1049,10 +1049,6 @@ long 
do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)


 if ( add )
 {
-printk(XENLOG_G_INFO
-   "memory_map:add: dom%d gfn=%lx mfn=%lx nr=%lx\n",
-   d->domain_id, gfn, mfn, nr_mfns);
-
 ret = map_mmio_regions(d, gfn, nr_mfns, mfn);
 if ( ret )
 printk(XENLOG_G_WARNING
@@ -1061,10 +1057,6 @@ long 
do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)

 }
 else
 {
-printk(XENLOG_G_INFO
-   "memory_map:remove: dom%d gfn=%lx mfn=%lx nr=%lx\n",
-   d->domain_id, gfn, mfn, nr_mfns);
-
 ret = unmap_mmio_regions(d, gfn, nr_mfns, mfn);
 if ( ret && is_hardware_domain(current->domain) )
 printk(XENLOG_ERR

its down to a half, about 2.5 minutes.

I know I can't delete this directly. But currently there are four log 
level on Xen side,


 *   XENLOG_ERR: Fatal errors, either Xen, Guest or Dom0
 *   is about to crash.
 *
 *   XENLOG_WARNING: Something bad happened, but we can recover.
 *
 *   XENLOG_INFO: Interesting stuff, but not too noisy.
 *
 *   XENLOG_DEBUG: Use where ever you like. Lots of noise.

looks I have to change XENLOG_G_INFO to XENLOG_G_WARNING but its not 
appropriate here.


So can Xen change log level dynamically like Linux? If yes, we might 
change this level temporarily while passing through IGD. If not, any 
suggestion?


Thanks
Tiejun

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

Re: [Xen-devel] [PATCH v6 02/18] Add cmpxchg16b support for x86-64

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, September 07, 2015 6:37 PM
> To: Wu, Feng
> Cc: Andrew Cooper; xen-devel@lists.xen.org; Keir Fraser
> Subject: RE: [PATCH v6 02/18] Add cmpxchg16b support for x86-64
> 
> >>> On 06.09.15 at 08:32,  wrote:
> >> From: Wu, Feng
> >> Sent: Sunday, September 06, 2015 2:07 PM
> >> If that is the case, what about the changes below?
> >>
> >> #define cmpxchg16b(ptr,o,n)
> >> \
> >> ASSERT((unsigned long)ptr & 0xF == 0);
> >> \
> >> ASSERT(sizeof(*o) == sizeof(__uint128_t))
> >> \
> >> ASSERT(sizeof(*n) == sizeof(__uint128_t))
> >> \
> >> __cmpxchg16b((ptr), (void *)(o), (void *)(n))
> >
> > Seems there is a build error with this change, we cannot
> > add stuff before __cmpxchg() since it needs return some
> > value to the caller. Any suggestion here?
> 
> You of course first need to make this proper C (missing semicolons)
> and convert it to a construct that is just a single statement (if
> necessary using gcc's compound expression extension).

Thanks for your suggestion. How about this?

#define cmpxchg16b(ptr,o,n)\
( ({ ASSERT(((unsigned long)ptr & 0xF) == 0); }),  \
  BUILD_BUG_ON(sizeof(*o) != sizeof(__uint128_t)), \
  BUILD_BUG_ON(sizeof(*n) != sizeof(__uint128_t)), \
  __cmpxchg16b((ptr), (__uint128_t *)(o), (__uint128_t *)(n)) )

Thanks,
Feng

> 
> Jan


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

Re: [Xen-devel] [xen-4.4-testing test] 61512: regressions - FAIL

[Ian Campbell]

On Tue, 2015-09-08 at 05:21 +, osstest service owner wrote:
> flight 61512 xen-4.4-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/61512/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-xl-qcow2  9 debian-di-install fail REGR. vs. 
> 60727
>  test-amd64-i386-xl-raw9 debian-di-install fail REGR. vs. 
> 60727

These are both:

libxl: error: libxl_dm.c:1390:device_model_spawn_outcome: domain 1 device 
model: spawn failed (rc=-3)
libxl: error: libxl_create.c:1189:domcreate_devmodel_started: device model 
did not start: -3

on merlot[01]. I think we should backport this to 4.5 and 4.4 at least:

commit 9acfbe14d7261b03e3b3f4dc3c850ba2a7093e1f
Author: Anthony PERARD 
Date:   Tue Jul 7 16:09:13 2015 +0100

libxl: Increase device model startup timeout to 1min.

On a busy host, QEMU may take more than 10s to load and start.

This is likely due to a bug in Linux where the I/O subsystem sometime
produce high latency under load and result in QEMU taking a long time to
load every single dynamic libraries.

Signed-off-by: Anthony PERARD 
Acked-by: Ian Jackson 

> 
> Regressions which are regarded as allowable (not blocking):
>  test-amd64-i386-libvirt-vhd   9 debian-di-install fail REGR. vs. 
> 60727
>  test-amd64-amd64-libvirt-raw  9 debian-di-install fail REGR. vs. 
> 60727
>  test-amd64-amd64-libvirt-vhd  9 debian-di-install fail REGR. vs. 
> 60727
>  test-armhf-armhf-xl-multivcpu 16 guest-start/debian.repeatfail  like 
> 60696
>  test-amd64-i386-libvirt-qcow2  9 debian-di-installfail  like 
> 60727
>  test-amd64-i386-xl-vhd9 debian-di-installfail   like 
> 60727
>  test-amd64-amd64-xl-vhd   9 debian-di-installfail   like 
> 60727
>  test-amd64-i386-libvirt  11 guest-start  fail   like 
> 60727
>  test-amd64-amd64-libvirt 11 guest-start  fail   like 
> 60727
>  test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 
> 60727
> 
> Tests which did not succeed, but are not blocking:
>  test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)  
>  blocked n/a
>  test-amd64-amd64-migrupgrade  1 build-check(1)   blocked 
>  n/a
>  test-amd64-i386-migrupgrade   1 build-check(1)   blocked 
>  n/a
>  test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked
>   n/a
>  build-amd64-prev  5 xen-buildfail  
>  never pass
>  build-amd64-rumpuserxen   6 xen-buildfail  
>  never pass
>  test-armhf-armhf-xl-raw   9 debian-di-installfail  
>  never pass
>  build-i386-rumpuserxen6 xen-buildfail  
>  never pass
>  test-armhf-armhf-libvirt-qcow2  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
>  build-i386-prev   5 xen-buildfail  
>  never pass
>  test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail 
> never pass
>  test-amd64-amd64-xl-qcow2 9 debian-di-installfail  
>  never pass
>  test-armhf-armhf-libvirt 11 guest-start  fail  
>  never pass
>  test-amd64-amd64-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-qcow2 11 migrate-support-checkfail 
> never pass
>  test-amd64-i386-libvirt-raw  11 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-cubietruck 12 migrate-support-checkfail 
> never pass
>  test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail 
> 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
>  test-armhf-armhf-libvirt-raw  9 debian-di-installfail  
>  never pass
>  test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail 
> never pass
>  test-amd64-i386-xend-qemut-winxpsp3 21 leak-check/checkfail 
> never pass
>  test-armhf-armhf-xl-multivcpu 13 saverestore-support-check

Re: [Xen-devel] [PATCH v6 14/18] vmx: posted-interrupt handling when vCPU is blocked

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, September 07, 2015 7:48 PM
> To: Wu, Feng
> Cc: Andrew Cooper; Tian, Kevin; xen-devel@lists.xen.org; Keir Fraser
> Subject: Re: [PATCH v6 14/18] vmx: posted-interrupt handling when vCPU is
> blocked
> 
> >>> On 25.08.15 at 03:57,  wrote:
> > --- a/xen/arch/x86/hvm/vmx/vmcs.c
> > +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> > @@ -661,6 +661,9 @@ int vmx_cpu_up(void)
> >  if ( cpu_has_vmx_vpid )
> >  vpid_sync_all();
> >
> > +INIT_LIST_HEAD(_cpu(pi_blocked_vcpu, cpu));
> > +spin_lock_init(_cpu(pi_blocked_vcpu_lock, cpu));
> 
> This initialization appears to be the sole reason why the respective
> variables can't be static (in vmx.c). I'd really like to ask for this to
> be adjusted, even if this means adding another call out of
> vmx_cpu_up() into vmx.c.
> 
> > @@ -106,6 +114,9 @@ static int vmx_vcpu_initialise(struct vcpu *v)
> >
> >  spin_lock_init(>arch.hvm_vmx.vmcs_lock);
> >
> > +INIT_LIST_HEAD(>arch.hvm_vmx.pi_blocked_vcpu_list);
> > +INIT_LIST_HEAD(>arch.hvm_vmx.pi_vcpu_on_set_list);
> 
> Are these really needed (these aren't list heads afaict)?

I can remove the initialization operations.

> 
> > @@ -1976,6 +1987,54 @@ static struct hvm_function_table __initdata
> vmx_function_table = {
> >  .altp2m_vcpu_emulate_vmfunc = vmx_vcpu_emulate_vmfunc,
> >  };
> >
> > +/*
> > + * Handle VT-d posted-interrupt when VCPU is blocked.
> > + */
> 
> This is (and hence should be formatted as) a single line comment.
> 
> > +static void pi_wakeup_interrupt(struct cpu_user_regs *regs)
> > +{
> > +struct arch_vmx_struct *vmx, *tmp;
> > +struct vcpu *v;
> > +spinlock_t *lock = _cpu(pi_blocked_vcpu_lock);
> > +struct list_head *blocked_vcpus = _cpu(pi_blocked_vcpu);
> 
> At least on possibly performance relevant paths please avoid
> multiple back-to-back uses of this_cpu() (use per_cpu() instead).

Thanks for the suggestion, would you mind share more information
about why per_cpu() is preferable in this case? Thanks!

> 
> > +LIST_HEAD(list);
> > +
> > +spin_lock(lock);
> > +
> > +/*
> > + * XXX: The length of the list depends on how many vCPU is current
> > + * blocked on this specific pCPU. This may hurt the interrupt latency
> > + * if the list grows to too many entries.
> > + */
> > +list_for_each_entry_safe(vmx, tmp, blocked_vcpus,
> pi_blocked_vcpu_list)
> > +{
> > +if ( pi_test_on(>pi_desc) )
> > +{
> > +list_del_init(>pi_blocked_vcpu_list);
> 
> Why not just list_del() (also further down in the second loop)?

What is the bad effect for list_del_init() here?

> 
> > +
> > +/*
> > + * We cannot call vcpu_unblock here, since it also needs
> > + * 'pi_blocked_vcpu_lock', we store the vCPUs with ON
> > + * set in another list and unblock them after we release
> > + * 'pi_blocked_vcpu_lock'.
> > + */
> 
> At least at this point in time this doesn't appear to be correct: I
> cannot see how, after this patch, vcpu_unblock() would end up
> acquiring the lock.

vcpu_unblock()
--> vcpu_wake()
--> arch_vcpu_wake_prepare()
--> spin_lock_irqsave(_cpu(pi_blocked_vcpu_lock,
   v->arch.hvm_vmx.pi_block_cpu), flags);

> And without that (plus without anything ever
> adding to pi_blocked_vcpu), this moving between two lists seems
> rather odd; I think the splitting of the series into patches needs
> to be re-thought unless (preferably) you can find a (reasonably
> clean) way without using two lists in the first place.

Do you mean if using two lists here, I need re-split this patch-set?
I wonder why the two lists affect the patchset splitting?

Thanks,
Feng

> 
> > +list_add_tail(>pi_vcpu_on_set_list, );
> > +}
> > +}
> > +
> > +spin_unlock(lock);
> > +
> > +ack_APIC_irq();
> 
> So why here and not further up or further down? If this is "as
> early as possible", a comment should say why it can't be moved
> further up.
> 
> > +list_for_each_entry_safe(vmx, tmp, , pi_vcpu_on_set_list)
> > +{
> > +v = container_of(vmx, struct vcpu, arch.hvm_vmx);
> > +list_del_init(>pi_vcpu_on_set_list);
> > +vcpu_unblock(v);
> > +}
> > +
> > +this_cpu(irq_count)++;
> 
> This would probably better pair with ack_APIC_irq().
> 
> Jan


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-vhd  3 host-install(3)  broken in 61309 pass in 61513
 test-amd64-i386-libvirt  14 guest-saverestore  fail in 61309 pass in 61513
 test-amd64-i386-xl-qemuu-debianhvm-amd64 19 guest-start/debianhvm.repeat fail 
in 61309 pass in 61513
 test-amd64-amd64-libvirt-vhd 13 guest-saverestore  fail in 61309 pass in 61513
 test-amd64-i386-libvirt-vhd  13 guest-saverestore   fail pass in 61309

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 60672
 test-armhf-armhf-xl-rtds 11 guest-start  fail   like 60695
 test-amd64-amd64-libvirt-raw  9 debian-di-installfail   like 60723
 test-amd64-i386-libvirt-raw   9 debian-di-installfail   like 60723
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 60723
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 60723

Tests which did not succeed, but are not blocking:
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 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-xl-vhd   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
 build-amd64-prev  5 xen-buildfail   never pass
 build-i386-prev   5 xen-buildfail   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  12 migrate-support-checkfail   never pass
 test-amd64-amd64-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-amd64-xl-qcow2 9 debian-di-installfail   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-pair 21 guest-migrate/src_host/dst_host 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  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-libvirt-pair 21 guest-migrate/src_host/dst_host fail never 
pass
 test-amd64-i386-libvirt-qcow2 11 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-vhd 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-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   never pass

version targeted for testing:
 xen  ef89dc8c00087c8c1819e60bdad5527db70425e1
baseline version:
 xen  7f7642f778b78e8e204fc082ce03072bb26887c7

Last test of basis60723  2015-08-16 12:18:15 Z   22 days
Testing same since61309  2015-09-02 13:18:00 Z5 days2 attempts


People who touched revisions under test:
  Ian Campbell 
  Julien Grall 

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 fail
 build-i386-prev  fail
 

Re: [Xen-devel] [PATCH v6 15/18] vmx: Properly handle notification event when vCPU is running

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, September 08, 2015 5:31 PM
> To: Wu, Feng
> Cc: Andrew Cooper; Tian, Kevin; Zhang, Yang Z; xen-devel@lists.xen.org; Keir
> Fraser
> Subject: RE: [PATCH v6 15/18] vmx: Properly handle notification event when
> vCPU is running
> 
> >>> On 08.09.15 at 11:23,  wrote:
> 
> >>
> >> Now that you say it, this looks even more odd: Why would you need
> >> to raise that softirq if the only way to come here is via the triggering
> >> in __vmx_deliver_posted_interrupt() (which already raised that
> >> softirq)? I suppose I must be missing something...
> >
> > Before VT-d PI, __vmx_deliver_posted_interrupt() is the only way
> > to trigger interrupt with vector ' posted_intr_vector ', but after
> > introducing VT-d PI, VT-d hardware can issue the interrupt with
> > that vector as well. In __vmx_deliver_posted_interrupt(), it set
> > the softirqs, the reason of which is described in the comments
> > of pi_notification_interrupt(), however, I need do the same thing
> > when VT-d hardware issue the interrupt, so pi_notification_interrupt()
> > is the proper place to do it.
> 
> But again - my main concern is about the !iommu_intpost case: What
> good does the raising of the softirq there? (As a general remark -
> please, when you add code to support a new feature, don't just
> think about the case where the new feature is available in hardware,
> but also about the case where it's not. While over time the set of
> systems lacking the feature will likely decrease, initially it may be the
> vast majority of systems Xen gets run on which would get penalized.)

No problem. Two solutions:
#1, Register pi_notification_interrupt when iommu_intpost and still
use event_check_interrupt in the !iommu_intpost case.
#1, Use pi_notification_interrupt() for both iommu_intpost and
!iommu_intpost, add the following check it:
if ( iommu_intpost )
raise_softirq(VCPU_KICK_SOFTIRQ);

Which one do you prefer?

Thanks,
Feng


> 
> Jan


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

Re: [Xen-devel] [PATCH v6 02/18] Add cmpxchg16b support for x86-64

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, September 08, 2015 4:52 PM
> To: Wu, Feng
> Cc: Andrew Cooper; xen-devel@lists.xen.org; Keir Fraser
> Subject: RE: [PATCH v6 02/18] Add cmpxchg16b support for x86-64
> 
> >>> On 08.09.15 at 09:37,  wrote:
> > Thanks for your suggestion. How about this?
> >
> > #define cmpxchg16b(ptr,o,n)
> \
> > ( ({ ASSERT(((unsigned long)ptr & 0xF) == 0); }),  \
> >   BUILD_BUG_ON(sizeof(*o) != sizeof(__uint128_t)),
> \
> >   BUILD_BUG_ON(sizeof(*n) != sizeof(__uint128_t)),
> \
> >   __cmpxchg16b((ptr), (__uint128_t *)(o), (__uint128_t *)(n)) )
> 
> Yes (properly parenthesized and the ({ }) either removed or extended

We need the ({ }) for the ASSERT statement, or we will meet build error.

Thanks,
Feng

> to the whole expression).
> 
> Jan


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

Re: [Xen-devel] [PATCH v6 15/18] vmx: Properly handle notification event when vCPU is running

[Jan Beulich]

>>> On 08.09.15 at 03:38,  wrote:
> Jan Beulich wrote on 2015-09-07:
> On 07.09.15 at 15:00,  wrote:
>>> Jan Beulich wrote on 2015-09-07:
 Yang, in this context: Why does __vmx_deliver_posted_interrupt()
 not use cpu_raise_softirq(), instead kind of open coding it (see your
 d7dafa375b ["VMX: Add posted interrupt supporting"])?
>>> 
>>> Sorry, I am not in the context. What do you mean of using
>>> cpu_raise_softirq() in __vmx_deliver_posted_interrupt()?
>> 
>> Why is the function not using that ready to use helper? Looking at
>> it ...
>> 
>>> static void __vmx_deliver_posted_interrupt(struct vcpu *v)
>>> {
>>>bool_t running = v->is_running;
>>>
>>>vcpu_unblock(v);
>>>if ( running && (in_irq() || (v != current)) )
>>>{
>>>unsigned int cpu = v->processor;
>>>
>>>if ( !test_and_set_bit(VCPU_KICK_SOFTIRQ, _pending(cpu))
>> 
>> ... this line as well as ...
>> 
>>> && (cpu != smp_processor_id()) )
>>>send_IPI_mask(cpumask_of(cpu), posted_intr_vector);
>> 
>> ... this one ...
>> 
>>>}
>>> }
>> 
>> ... pretty certainly don't belong into vmx.c, or the apparent open
>> coding of cpu_raise_softirq() would require a justifying comment.
> 
> I still don't see how to use cpu_raise_softirq() since the 
> posted_intr_vector doesn't belong to softirq.

I realize that because of the special in-processor treatment of that
vector it ma not be possible to eliminate this open coding. That's why
I said above "would require a justifying comment". After all, namely
with the handler for the vector being the same as for normal event
check interrupts, it is far from obvious why the open coding can't be
avoided.

Jan


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

Re: [Xen-devel] [ovmf bisection] complete test-amd64-amd64-xl-qemuu-ovmf-amd64

[Ian Campbell]

Anthony/Wei,

Please could one of you investigate this new upstream OVMF failure.

Ian.

On Tue, 2015-09-08 at 02:48 +, osstest service owner wrote:
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-amd64-xl-qemuu-ovmf-amd64
> test debian-hvm-install
> 
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> Tree: ovmf https://github.com/tianocore/edk2.git
> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> Tree: xen git://xenbits.xen.org/xen.git
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  ovmf https://github.com/tianocore/edk2.git
>   Bug introduced:  ead7cb12d5b0e23b55e47f38a8a0675958783668
>   Bug not present: 1a85139d9eac7f260a21a6ecb06a578a5255edf7
> 
> 
>   commit ead7cb12d5b0e23b55e47f38a8a0675958783668
>   Author: Laszlo Ersek 
>   Date:   Fri Aug 28 08:12:51 2015 +
>   
>   OvmfPkg: prevent code execution from DXE stack
>   
>   SVN rev 18166 ("MdeModulePkg DxeIpl: Add stack NX support") enables
>   platforms to request non-executable stack for the DXE phase, by 
> setting
>   PcdSetNxForStack to TRUE.
>   
>   The PCD defaults to FALSE, because:
>   
>   (a) A non-executable DXE stack is a new feature and causes changes 
> in
>   behavior. Some platform could rely on executing code from the 
> stack.
>   
>   (b) The code enabling NX in the DXE IPL PEIM enforces the
>   
> PcdSetNxForStack ==> PcdDxeIplBuildPageTables
>   
>   implication for "64-bit PEI + 64-bit DXE" platforms, with a new
>   ASSERT(). Some platform might not comply with this requirement
>   immediately.
>   
>   Regarding (a), in none of the OVMF builds do we try to execute code 
> from
>   the stack.
>   
>   Regarding (b):
>   
>   - In the OvmfPkgX64.dsc build (which is where (b) applies) we 
> simply
> inherit the PcdDxeIplBuildPageTables|TRUE default from
> "MdeModulePkg/MdeModulePkg.dec". Therefore we can set 
> PcdSetNxForStack
> to TRUE.
>   
>   - In OvmfPkgIa32X64.dsc, page tables are built by default for DXE. 
> Hence
> we can set PcdSetNxForStack to TRUE.
>   
>   - In OvmfPkgIa32.dsc, page tables used not to be necessary until 
> now.
> After we set PcdSetNxForStack to TRUE in this patch, the DXE IPL 
> will
> construct page tables even when it is built as part of 
> OvmfPkgIa32.dsc,
> provided the (virtual) hardware supports both PAE mode and the XD 
> bit.
>   
>   Should this setting cause problems in a GPU (or other device) 
> passthru
>   scenario, with a UEFI_DRIVER in the PCI option rom attempting to 
> execute
>   code from the stack, the feature can be dynamically disabled on the 
> QEMU
>   command line, with "-cpu ,-nx".
>   
>   Cc: Paolo Bonzini 
>   Cc: Jordan Justen 
>   Cc: "Zeng, Star" 
>   Suggested-by: Paolo Bonzini 
>   Contributed-under: TianoCore Contribution Agreement 1.0
>   Signed-off-by: Laszlo Ersek 
>   Reviewed-by: Star Zeng 
>   
>   git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18360 6f
> 19259b-4bc3-4df7-8a09-765794883524
> 
> 
> For bisection revision-tuple graph see:
>http://logs.test-lab.xenproject.org/osstest/results/bisect/ovmf/test
> -amd64-amd64-xl-qemuu-ovmf-amd64.debian-hvm-install.html
> Revision IDs in each graph node refer, respectively, to the Trees above.
> 
> 
> Running cs-bisection-step --graph-out=/home/logs/results/bisect/ovmf/test
> -amd64-amd64-xl-qemuu-ovmf-amd64.debian-hvm-install --summary
> -out=tmp/61576.bisection-summary --basis-template=60869 -
> -blessings=real,real-bisect ovmf test-amd64-amd64-xl-qemuu-ovmf-amd64 
> debian-hvm-install
> Searching for failure / basis pass:
>  61299 fail [host=italia1] / 60904 ok.
> Failure / basis pass flights: 61299 / 60904
> (tree with no url: seabios)
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> Tree: ovmf https://github.com/tianocore/edk2.git
> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> Tree: xen git://xenbits.xen.org/xen.git
> Latest 9b8b905951bde404f20a7bd4b37a5134f3484569 
> c530a75c1e6a472b0eb9558310b518f0dfcd8860 
> 776566530b15a4241db00ac317659e5904ad453c 
> 5cdde31eacdd288359746019ad05cac8ed5d9f70 
> b05befcbea71a979509ce04f02929969a790c923 
> 801ab48e5556cb54f67e3cb57f077f47e8663ced
> Basis pass 9b8b905951bde404f20a7bd4b37a5134f3484569 
> c530a75c1e6a472b0eb9558310b518f0dfcd8860 
> 

[Xen-devel] [distros-debian-squeeze test] 37917: all pass

[Platform Team regression test user]

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

Perfect :-)
All tests in this flight passed
baseline version:
 flight   37842

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-squeeze-netboot-pygrubpass
 test-amd64-i386-amd64-squeeze-netboot-pygrub pass
 test-amd64-amd64-i386-squeeze-netboot-pygrub pass
 test-amd64-i386-i386-squeeze-netboot-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] [Xen-users] Xen bridging issue.

[Ian Campbell]

On Mon, 2015-09-07 at 15:50 +0300, johnny Strom wrote:
> 
> Hello
> 
> I sent an email before about bridging not working in domU using Debian 
> 8.1 and XEN 4.4.1.
> 
> It was not the network card "igb" as I first taught.
> 
> I managed to get bridging working in DOMU if is set the limit of cpu's 
> in dom0 to 14, this is from /etc/default/grub
> when it works ok:
> 
> GRUB_CMDLINE_XEN="dom0_max_vcpus=14 dom0_vcpus_pin"
> 
> 
> Is there any known issue/limitations running xen with more with more 
> than 14 CPU cores in dom0?
> 
> 
> The cpu in question is:
> 
> processor   : 16
> vendor_id   : GenuineIntel
> cpu family  : 6
> model   : 63
> model name  : Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz
> stepping: 2
> microcode   : 0x2d
> cpu MHz : 2298.718
> cache size  : 25600 KB
> physical id : 0
> siblings: 17
> core id : 11
> cpu cores   : 9
> apicid  : 22
> initial apicid  : 22
> fpu : yes
> fpu_exception   : yes
> cpuid level : 15
> wp  : yes
> flags   : fpu de tsc msr pae mce cx8 apic sep mca cmov pat 
> clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good 
> nopl nonstop_tsc eagerfpu pni pclmulqdq monitor est ssse3 fma cx16 
> sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand 
> hypervisor lahf_lm abm ida arat epb xsaveopt pln pts dtherm fsgsbase 
> bmi1 avx2 bmi2 erms
> bogomips: 4597.43
> clflush size: 64
> cache_alignment : 64
> address sizes   : 46 bits physical, 48 bits virtual
> power management:
> 
> 
> 
> 
> If I set it to 17 in dom0:
> 
> GRUB_CMDLINE_XEN="dom0_max_vcpus=17 dom0_vcpus_pin"
> 
> Then I get this oops whan I try to boot domU with 40 vcpu's.
> 
> [1.588313] systemd-udevd[255]: starting version 215
> [1.606097] xen_netfront: Initialising Xen virtual ethernet driver
> [1.648172] blkfront: xvda2: flush diskcache: enabled; persistent 
> grants: enabled; indirect descriptors: disabled;
> [1.649190] blkfront: xvda1: flush diskcache: enabled; persistent 
> grants: enabled; indirect descriptors: disabled;
> [1.649705] Setting capacity to 2097152
> [1.649716] xvda2: detected capacity change from 0 to 1073741824
> [1.653540] xen_netfront: can't alloc rx grant refs

The frontend has run out of grant refs, perhaps due to multiqueue support
in the front/backend where I think the number of queues scales with number
of processors.

I've added some relevant maintainers for net{front,back} and grant tables,
plus people who were involved with MQ and the devel list.


> [1.653547] net eth1: only created 17 queues
> [1.654027] BUG: unable to handle kernel NULL pointer dereference at 
> 0018
> [1.654033] IP: [] netback_changed+0x964/0xee0 
> [xen_netfront]
> [1.654041] PGD 0
> [1.654044] Oops:  [#1] SMP
> [1.654048] Modules linked in: xen_netfront(+) xen_blkfront(+) 
> crct10dif_pclmul crct10dif_common crc32c_intel
> [1.654057] CPU: 3 PID: 209 Comm: xenwatch Not tainted 3.16.0-4-amd64 
> #1 Debian 3.16.7-ckt11-1+deb8u3
> [1.654061] task: 880faf477370 ti: 880faf478000 task.ti: 
> 880faf478000
> [1.654064] RIP: e030:[] [] 
> netback_changed+0x964/0xee0 [xen_netfront]
> [1.654071] RSP: e02b:880faf47be20  EFLAGS: 00010202
> [1.654074] RAX:  RBX: 880002a729c0 RCX: 
> 0001
> [1.654077] RDX: 0066785c RSI: 880002a72a58 RDI: 
> 3f1f
> [1.654080] RBP: 880faa44e000 R08: c9000624 R09: 
> ea0036d3f180
> [1.654083] R10: 251e R11:  R12: 
> 880faa44f000
> [1.654086] R13: 880002a72a58 R14: 000729c0 R15: 
> 880fab6f4000
> [1.654093] FS:  () GS:880fb706() 
> knlGS:
> [1.654096] CS:  e033 DS:  ES:  CR0: 80050033
> [1.654099] CR2: 0018 CR3: 01813000 CR4: 
> 00042660
> [1.654102] Stack:
> [1.654104]  880faf5aec00 880f000f 00110001 
> 880faf5aec00
> [1.654109]  880002a6b041 880002a6af84 0001af561000 
> 00110001
> [1.656945]  8800028e9df1 8800028e8880 880faf47beb8 
> 8135b9e0
> [1.656945] Call Trace:
> [1.656945]  [] ? unregister_xenbus_watch+0x220/0x220
> [1.656945]  [] ? xenwatch_thread+0x98/0x140
> [1.656945]  [] ? prepare_to_wait_event+0xf0/0xf0
> [1.656945]  [] ? kthread+0xbd/0xe0
> [1.656945]  [] ? kthread_create_on_node+0x180/0x180
> [1.656945]  [] ? ret_from_fork+0x58/0x90
> [1.656945]  [] ? kthread_create_on_node+0x180/0x180
> [1.656945] Code: 48 89 c6 e9 bd fd ff ff 48 8b 3c 24 48 c7 c2 b3 52 
> 06 a0 be f4 ff ff ff 31 c0 e8 38 61 2f e1 e9 54 ff ff ff 48 8b 43 20 4c 
> 89 ee <48> 8b 78 18 e8 13 63 2f e1 85 c0 0f 88 b0 fd ff ff 48 8b 43 20
> [1.656945] RIP  [] netback_changed+0x964/0xee0 
> 

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

[Jan Beulich]

>>> On 08.09.15 at 07:38,  wrote:
> And consider this is just a debug function, is it that bad to add a
> two stage search here? The output is clear and nice in this way.

The primary questions to ask are: How much longer will the function
take on a huge system with many guests when using two loops
compared with just one? And how much longer will it take someone
looking at the output to find the entry (s)he's after, possibly not
immediately realizing that it missing among dozens or hundreds of
lines of one kind of output means it could be in the other half, far
away in the log?

Jan


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

Re: [Xen-devel] Questions related to the analysis of the Xen mailing lists

[Ian Campbell]

On Mon, 2015-09-07 at 17:11 +0100, Lars Kurth wrote:
> Daniel,
> 
> I am assuming it is OK to post this one to the devel-list, to get extra
> answers.
> 
> > On 7 Sep 2015, at 16:19, Daniel Izquierdo 
> > wrote:
> > 
> > Hi Lars,
> > 
> > I promise this is the last email ;).
> > 
> > We've found that there are several flags launched by different
> > developers depending on the status of the patchset.
> > 
> > By 'flag' I mean comments like 'Signed-off-by: xxx@xxx'.
> > 
> > However, I think we do not fully understand all of them. I'm listing
> > all
> > of them below adding some comments. Please, would you mind double
> > checking this and adding others that we may have missed? Thanks in
> > advance!.
> > 
> > * Signed-off-by: Jan Beulich : This is the author of
> > the patch
> 
> Correct

This isn't 100% accurate (for Linux or Xen).

The author of a patch is the person listed in the From header or pseudo-header. 
The pseudo-header is a fake From: header at the top of the message body, which 
is used when somebody forwards a patch written by someone else. and overrides 
the emails From header. This is what becomes the "Author" field in the git 
metadata.

For example see
http://mid.gmane.org/<1434375399-19107-3-git-send-email-wei.l...@citrix.com>
which is a patch where I am the author but Wei was resending it as part of his 
larger series. Here the mail is "From: Wei" but has a "From: Ian" pseudo-header.

The first S-o-b would usually also be the author but there are two caveats here:

Firstly a mail may have multiple S-o-b lines, reflecting the path which a patch 
has taken through different people, i.e. under 3(b) or 3(c) in the DCO. 
Arguably in the mail above Wei should have added his S-o-b when he forwarded it.

Secondly in (very) rare cases the S-o-b may be by other than the author. This 
could happen e.g. if two people work for the same company which owns the 
copyright on both their work and one person writes a patch and a second submits 
it and asserts they have the right to do so (i.e. that the have the right to 
submit works owned by the company under the appropriate license). This is 
pretty unusual (I'm not sure I've ever actually seen it) and normally there 
would be a S-o-b from the original author, but that isn't always possible 
(maybe they are gone).

> See https://www.kernel.org/doc/Documentation/SubmittingPatches section 11

AKA The Developers Certificate of Origin or DCO.

It also lives at http://developercertificate.org/ where it is unencumbered
by the rest of the Linux SubmittingPatches and is therefore a better
reference when talking about projects other than Linux.

> - we have exactly the same requirement in Xen

> 
> > * Reviewed-by: Andrew Cooper  : This is the
> > reviewer of the patch

NB: it is _a_ reviewer, there may be several.

> Correct
> Although the definition is more loose compared to 
> https://www.kernel.org/doc/Documentation/SubmittingPatches
> 
> > * Acked-by: Roger Pau Monnà : Is this another
> > reviewer of the patch, but with more privileges?
> 
> Correct
> Although the definition is more loose compared to 
> https://www.kernel.org/doc/Documentation/SubmittingPatches
> 
> One of the things I would like to find out, is whether we do have a lot
> of cases where there are
> a) comments
> b) changes
> for a patch after it was marked Acked-by and whether there are any
> frequent patterns.  
> 
> > * Release-acked-by: Wei Liu : Is this the
> > developer
> > in charge of merging the code into master?
> 
> That means the release manager signals that this particular patch can be
> committed. It is normally only relevant during times of a feature freeze.
> In other words, a patch can be acked (because it's technical sound), but
> it might not be appropriate to be committed (too much risk vs too little
> gain). 
> 
> I think you should just ignore that tag when counting contributions. But
> it may be worthwhile including it in the model.

FWIW when I commit I often don't bother adding this tag if it was given,
since I think it is only of ephemeral usefulness. I don't remove it if it
is already in the patch though and I know other committers do add it.

I agree that it should be ignored.

Ian.


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

Re: [Xen-devel] Notes from Xen BoF at Debconf15

[Ian Campbell]

On Tue, 2015-09-08 at 03:47 -0600, Jan Beulich wrote:
> > > > On 08.09.15 at 11:24,  wrote:
> > Release cycle
> > =
> > 
> > Waldi commented that the stable release cycle was too long. Would like
> > to see a release after any large security update.
> > 
> > We asked if the RCs for stable releases were valuable, the answer was
> > "not so much".
> > 
> > Waldi would prefer to avoid cherry-picking security fixes if possible.
> > 
> > We asked if we thought Xen stable releases could be added to Debian
> > point releases. Waldi thought they likely could be, citing the
> > inclusion of Linux stable releases in point releases.
> > 
> > Our stable releases follow a similar set of rules to Linux, we think
> > we implement them more faithfully (less feature or feature-like
> > backports)
> > 
> > ACTION: Talk to Jan about making changes to stable release process.
> 
> That's kind of the opposite of what we quite recently changed to
> (a [hopefully] more predictable four month cycle). Apart from the
> question what "large" is, doing a release after any large security
> update seems unreasonable to me (not only because of giving up
> the predictability, but also because of the overhead involved,
> which is there even if we ditched the RCs). I have to admit that I
> fail to see why Debian would be different than other distros, all
> cherry picking security fixes until a new stable release becomes
> available. If otoh other major distros voiced similar desires, I
> think we'd have to once again re-think our stable release cadence.

IIRC (hopefully Ian or someone else will correct me if not) the main
proposal to discuss with you was WRT the usefulness of the RCs for stable
releases, since it was felt they didn't provide much benefit to
downstreams.

IOW perhaps it would be just as useful to downstreams and less work for us
(mainly you I suppose) to do 0 or only 1 rc for a point release, based on
whatever is in the branch at the appropriate time. It might also avoid
various delays which the stable release process can currently suffer from
waiting for a push for each rc instead of just once (or maybe twice), which
in turn might help the release timing to be even more predictable.

Ian.

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

Re: [Xen-devel] [PATCH v4 18/20] net/xen-netback: Make it running on 64KB page granularity

[Julien Grall]

Hi Wei,

On 07/09/15 17:57, Wei Liu wrote:
> You might need to rebase you patch. A patch to netback went it recently.

Do you mean 210c34dcd8d912dcc740f1f17625a7293af5cb56 "xen-netback: add
support for multicast control"?

If so I didn't see any specific issue while rebasing on the latest
linus' master.

> On Mon, Sep 07, 2015 at 04:33:56PM +0100, Julien Grall wrote:
>> The PV network protocol is using 4KB page granularity. The goal of this
>> patch is to allow a Linux using 64KB page granularity working as a
>> network backend on a non-modified Xen.
>>
>> It's only necessary to adapt the ring size and break skb data in small
>> chunk of 4KB. The rest of the code is relying on the grant table code.
>>
>> Signed-off-by: Julien Grall 
>>
> 
> Reviewed-by: Wei Liu 

Thank you!

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH v4 18/20] net/xen-netback: Make it running on 64KB page granularity

[Wei Liu]

On Tue, Sep 08, 2015 at 12:07:31PM +0100, Julien Grall wrote:
> Hi Wei,
> 
> On 07/09/15 17:57, Wei Liu wrote:
> > You might need to rebase you patch. A patch to netback went it recently.
> 
> Do you mean 210c34dcd8d912dcc740f1f17625a7293af5cb56 "xen-netback: add
> support for multicast control"?
> 

Yes, that one.

> If so I didn't see any specific issue while rebasing on the latest
> linus' master.
> 

Good.

> > On Mon, Sep 07, 2015 at 04:33:56PM +0100, Julien Grall wrote:
> >> The PV network protocol is using 4KB page granularity. The goal of this
> >> patch is to allow a Linux using 64KB page granularity working as a
> >> network backend on a non-modified Xen.
> >>
> >> It's only necessary to adapt the ring size and break skb data in small
> >> chunk of 4KB. The rest of the code is relying on the grant table code.
> >>
> >> Signed-off-by: Julien Grall 
> >>
> > 
> > Reviewed-by: Wei Liu 
> 
> Thank you!
> 
> Regards,
> 
> -- 
> Julien Grall

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

Re: [Xen-devel] [Xen-users] Xen bridging issue.

[Wei Liu]

On Tue, Sep 08, 2015 at 02:33:53PM +0300, johnny Strom wrote:
> On 09/08/2015 02:12 PM, Wei Liu wrote:
> >On Tue, Sep 08, 2015 at 02:07:21PM +0300, johnny Strom wrote:
> >>On 09/08/2015 01:06 PM, Wei Liu wrote:
> >>>On Tue, Sep 08, 2015 at 12:59:39PM +0300, johnny Strom wrote:
> On 09/08/2015 12:13 PM, Wei Liu wrote:
> >  xenstore-ls/local/domain/$DOMID/
> Here is the output of xenstore-ls only one network card is working.
> 
> xenstore-ls  /local/domain/1
> 
> >>>[...]
>   vif = ""
>    0 = ""
> backend = "/local/domain/0/backend/vif/1/0"
> backend-id = "0"
> state = "4"
> handle = "0"
> mac = "00:16:3e:ee:aa:aa"
> multi-queue-num-queues = "17"
> >>>OK so the number of queues is 17. You probably don't need that many
> >>>queues.
> >>>
> >>>Set module parameter "xenvif_max_queues" of netback to something like 4
> >>>should work around the problem for you.
> >>Hello
> >>
> >>I tried to set it to 4 in  /etc/modprobe.d/xen_netback.conf
> >>
> >>rmmod xen_netback
> >>
> >>modprobe -v xen_netback
> >>insmod
> >>/lib/modules/3.16.0-4-amd64/kernel/drivers/net/xen-netback/xen-netback.ko
> >>xenvif_max_queues=4
> >>
> >>
> >>
> >>But it is still the same issue..
> >>
> >>Is xenvif_max_queues supported in Linux kernel 3.16?
> >>
> >>modinfo -p xen_netback
> >>
> >>separate_tx_rx_irq: (bool)
> >>rx_drain_timeout_msecs: (uint)
> >>rx_stall_timeout_msecs: (uint)
> >>max_queues:Maximum number of queues per virtual interface (uint)
> >Oh, right, the parameter name should be "max_queues".
> >
> >Sorry about that!
> >
> >Wei.
> 
> 
> It's still the same issue:
> 
> modprobe -v xen_netback
> insmod
> /lib/modules/3.16.0-4-amd64/kernel/drivers/net/xen-netback/xen-netback.ko
> max_queues=4
> 

If there are the precise steps you took, isn't modprobe -v already
inserted the module without parameter set? I.e. the later insmod had no
effect.

> 
> But what could be reason for this?
> 

Make sure that parameter is correctly set. You can look at
/sys/module/xen_netback/parameter/max_queues for the actual number.

You can even just echo a number to that file to set the value on the
fly.

> Could it be problems with one of the CPUS? since if I boot dom0 with just 14
> cpu cores then it works
> 

No, it can't be related to CPUs.  That's because DomU doesn't exhaust
resources anymore.

Wei.

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

Re: [Xen-devel] [PATCH v6 15/18] vmx: Properly handle notification event when vCPU is running

[Jan Beulich]

>>> On 08.09.15 at 11:36,  wrote:

> 
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Tuesday, September 08, 2015 5:31 PM
>> To: Wu, Feng
>> Cc: Andrew Cooper; Tian, Kevin; Zhang, Yang Z; xen-devel@lists.xen.org; Keir
>> Fraser
>> Subject: RE: [PATCH v6 15/18] vmx: Properly handle notification event when
>> vCPU is running
>> 
>> >>> On 08.09.15 at 11:23,  wrote:
>> 
>> >>
>> >> Now that you say it, this looks even more odd: Why would you need
>> >> to raise that softirq if the only way to come here is via the triggering
>> >> in __vmx_deliver_posted_interrupt() (which already raised that
>> >> softirq)? I suppose I must be missing something...
>> >
>> > Before VT-d PI, __vmx_deliver_posted_interrupt() is the only way
>> > to trigger interrupt with vector ' posted_intr_vector ', but after
>> > introducing VT-d PI, VT-d hardware can issue the interrupt with
>> > that vector as well. In __vmx_deliver_posted_interrupt(), it set
>> > the softirqs, the reason of which is described in the comments
>> > of pi_notification_interrupt(), however, I need do the same thing
>> > when VT-d hardware issue the interrupt, so pi_notification_interrupt()
>> > is the proper place to do it.
>> 
>> But again - my main concern is about the !iommu_intpost case: What
>> good does the raising of the softirq there? (As a general remark -
>> please, when you add code to support a new feature, don't just
>> think about the case where the new feature is available in hardware,
>> but also about the case where it's not. While over time the set of
>> systems lacking the feature will likely decrease, initially it may be the
>> vast majority of systems Xen gets run on which would get penalized.)
> 
> No problem. Two solutions:
> #1, Register pi_notification_interrupt when iommu_intpost and still
> use event_check_interrupt in the !iommu_intpost case.
> #1, Use pi_notification_interrupt() for both iommu_intpost and
> !iommu_intpost, add the following check it:
>   if ( iommu_intpost )
>   raise_softirq(VCPU_KICK_SOFTIRQ);
> 
> Which one do you prefer?

#1 ;-) (the earlier one, to avoid you guessing)

Jan


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

Re: [Xen-devel] [PATCH OSSTEST v2 3/6] ts-xen-install: Add dom0_mem runvar to control dom0 memory

[Ian Campbell]

On Thu, 2015-08-06 at 18:03 +0100, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD 
> ---
>  ts-xen-install | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/ts-xen-install b/ts-xen-install
> index 0f53382..17edfb7 100755
> --- a/ts-xen-install
> +++ b/ts-xen-install
> @@ -153,7 +153,8 @@ sub setupboot () {
>   logm("No Xen console device defined for host");
>  }
>  if (toolstack($ho)->{Dom0MemFixed}) {
> -$xenhopt .= " dom0_mem=512M,max:512M";
> +my $mem = $r{'dom0_mem'} // 512;

I think the highest preference should be for $r{"$ho->{Ident}_dom0_mem"}
(which makes it host specific in multi host jobs). I think it is probably
still worth having a global dom0_mem runvar you have here too. So:

my $mem = $r{"$ho->{Ident}_dom0_mem"} // $r{'dom0_mem'} // 512;

(maybe needs wrapping)

> +$xenhopt .= " dom0_mem=${mem}M,max:${mem}M";
>  }
>  
>  # If /boot/microcode.cpio is present then ts-host-install has

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

Re: [Xen-devel] [Xen-users] Xen bridging issue.

[johnny Strom]

On 09/08/2015 02:12 PM, Wei Liu wrote:

On Tue, Sep 08, 2015 at 02:07:21PM +0300, johnny Strom wrote:

On 09/08/2015 01:06 PM, Wei Liu wrote:

On Tue, Sep 08, 2015 at 12:59:39PM +0300, johnny Strom wrote:

On 09/08/2015 12:13 PM, Wei Liu wrote:

  xenstore-ls/local/domain/$DOMID/

Here is the output of xenstore-ls only one network card is working.

xenstore-ls  /local/domain/1


[...]

  vif = ""
   0 = ""
backend = "/local/domain/0/backend/vif/1/0"
backend-id = "0"
state = "4"
handle = "0"
mac = "00:16:3e:ee:aa:aa"
multi-queue-num-queues = "17"

OK so the number of queues is 17. You probably don't need that many
queues.

Set module parameter "xenvif_max_queues" of netback to something like 4
should work around the problem for you.

Hello

I tried to set it to 4 in  /etc/modprobe.d/xen_netback.conf

rmmod xen_netback

modprobe -v xen_netback
insmod
/lib/modules/3.16.0-4-amd64/kernel/drivers/net/xen-netback/xen-netback.ko
xenvif_max_queues=4



But it is still the same issue..

Is xenvif_max_queues supported in Linux kernel 3.16?

modinfo -p xen_netback

separate_tx_rx_irq: (bool)
rx_drain_timeout_msecs: (uint)
rx_stall_timeout_msecs: (uint)
max_queues:Maximum number of queues per virtual interface (uint)

Oh, right, the parameter name should be "max_queues".

Sorry about that!

Wei.



It's still the same issue:

modprobe -v xen_netback
insmod 
/lib/modules/3.16.0-4-amd64/kernel/drivers/net/xen-netback/xen-netback.ko max_queues=4 



But what could be reason for this?

Could it be problems with one of the CPUS? since if I boot dom0 with 
just 14 cpu cores then it works



xenstore-ls  /local/domain/7
vm = "/vm/8602b443-6828-44ca-9e2c-8023b2fe8583"
name = "test.debian-jessie"
cpu = ""
 0 = ""
  availability = "online"
 1 = ""
  availability = "online"
 2 = ""
  availability = "online"
 3 = ""
  availability = "online"
 4 = ""
  availability = "online"
 5 = ""
  availability = "online"
 6 = ""
  availability = "online"
 7 = ""
  availability = "online"
 8 = ""
  availability = "online"
 9 = ""
  availability = "online"
 10 = ""
  availability = "online"
 11 = ""
  availability = "online"
 12 = ""
  availability = "online"
 13 = ""
  availability = "online"
 14 = ""
  availability = "online"
 15 = ""
  availability = "online"
 16 = ""
  availability = "online"
 17 = ""
  availability = "online"
 18 = ""
  availability = "online"
 19 = ""
  availability = "online"
 20 = ""
  availability = "online"
 21 = ""
  availability = "online"
 22 = ""
  availability = "online"
 23 = ""
  availability = "online"
 24 = ""
  availability = "online"
 25 = ""
  availability = "online"
 26 = ""
  availability = "online"
 27 = ""
  availability = "online"
 28 = ""
  availability = "online"
 29 = ""
  availability = "online"
 30 = ""
  availability = "online"
 31 = ""
  availability = "online"
 32 = ""
  availability = "online"
 33 = ""
  availability = "online"
 34 = ""
  availability = "online"
 35 = ""
  availability = "online"
 36 = ""
  availability = "online"
 37 = ""
  availability = "online"
 38 = ""
  availability = "online"
 39 = ""
  availability = "online"
memory = ""
 static-max = "4194304"
 target = "4194305"
 videoram = "-1"
device = ""
 suspend = ""
  event-channel = ""
 vbd = ""
  51713 = ""
   backend = "/local/domain/0/backend/qdisk/7/51713"
   backend-id = "0"
   state = "4"
   virtual-device = "51713"
   device-type = "disk"
   protocol = "x86_64-abi"
   ring-ref = "8"
   event-channel = "243"
   feature-persistent = "1"
  51714 = ""
   backend = "/local/domain/0/backend/qdisk/7/51714"
   backend-id = "0"
   state = "4"
   virtual-device = "51714"
   device-type = "disk"
   protocol = "x86_64-abi"
   ring-ref = "9"
   event-channel = "244"
   feature-persistent = "1"
 vif = ""
  0 = ""
   backend = "/local/domain/0/backend/vif/7/0"
   backend-id = "0"
   state = "4"
   handle = "0"
   mac = "00:16:3e:ee:aa:aa"
   multi-queue-num-queues = "17"
   queue-0 = ""
tx-ring-ref = "8960"
rx-ring-ref = "8961"
event-channel-tx = "245"
event-channel-rx = "246"
   queue-1 = ""
tx-ring-ref = "8962"
rx-ring-ref = "8963"
event-channel-tx = "247"
event-channel-rx = "248"
   queue-2 = ""
tx-ring-ref = "8964"
rx-ring-ref = "8965"
event-channel-tx = "249"
event-channel-rx = "250"
   queue-3 = ""
tx-ring-ref = "8966"
rx-ring-ref = "8967"
event-channel-tx = "251"
event-channel-rx = "252"
   queue-4 = ""
tx-ring-ref = "8968"
rx-ring-ref = "8969"
event-channel-tx = "253"
event-channel-rx = "254"
   queue-5 = ""
tx-ring-ref = "8970"
rx-ring-ref = "8971"
event-channel-tx = "255"
event-channel-rx = "256"
   queue-6 = ""
tx-ring-ref = "8972"
rx-ring-ref = "8973"
event-channel-tx = "257"
event-channel-rx = "258"
   queue-7 = ""
tx-ring-ref = "8974"
rx-ring-ref = "8975"
event-channel-tx = "259"
event-channel-rx = "260"
   queue-8 = ""
tx-ring-ref = "8976"
rx-ring-ref = 

Re: [Xen-devel] [Xen-users] Xen bridging issue.

[johnny Strom]

On 09/08/2015 02:45 PM, Wei Liu wrote:

On Tue, Sep 08, 2015 at 02:33:53PM +0300, johnny Strom wrote:

On 09/08/2015 02:12 PM, Wei Liu wrote:

On Tue, Sep 08, 2015 at 02:07:21PM +0300, johnny Strom wrote:

On 09/08/2015 01:06 PM, Wei Liu wrote:

On Tue, Sep 08, 2015 at 12:59:39PM +0300, johnny Strom wrote:

On 09/08/2015 12:13 PM, Wei Liu wrote:

  xenstore-ls/local/domain/$DOMID/

Here is the output of xenstore-ls only one network card is working.

xenstore-ls  /local/domain/1


[...]

  vif = ""
   0 = ""
backend = "/local/domain/0/backend/vif/1/0"
backend-id = "0"
state = "4"
handle = "0"
mac = "00:16:3e:ee:aa:aa"
multi-queue-num-queues = "17"

OK so the number of queues is 17. You probably don't need that many
queues.

Set module parameter "xenvif_max_queues" of netback to something like 4
should work around the problem for you.

Hello

I tried to set it to 4 in  /etc/modprobe.d/xen_netback.conf

rmmod xen_netback

modprobe -v xen_netback
insmod
/lib/modules/3.16.0-4-amd64/kernel/drivers/net/xen-netback/xen-netback.ko
xenvif_max_queues=4



But it is still the same issue..

Is xenvif_max_queues supported in Linux kernel 3.16?

modinfo -p xen_netback

separate_tx_rx_irq: (bool)
rx_drain_timeout_msecs: (uint)
rx_stall_timeout_msecs: (uint)
max_queues:Maximum number of queues per virtual interface (uint)

Oh, right, the parameter name should be "max_queues".

Sorry about that!

Wei.


It's still the same issue:

modprobe -v xen_netback
insmod
/lib/modules/3.16.0-4-amd64/kernel/drivers/net/xen-netback/xen-netback.ko
max_queues=4


If there are the precise steps you took, isn't modprobe -v already
inserted the module without parameter set? I.e. the later insmod had no
effect.


But what could be reason for this?


Make sure that parameter is correctly set. You can look at
/sys/module/xen_netback/parameter/max_queues for the actual number.

You can even just echo a number to that file to set the value on the
fly.


Yes thanks that works, I will figure out how to load the module.






Could it be problems with one of the CPUS? since if I boot dom0 with just 14
cpu cores then it works


No, it can't be related to CPUs.  That's because DomU doesn't exhaust
resources anymore.


Ok

And DomU also works if I use the kernel  3.2.68-1+deb7u2 that is in 
debian Wheezy.


Best Regards Johnny




Wei.

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



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

Re: [Xen-devel] Fwd: Question about the status of vNUMA in Xen

[Wei Liu]

Please configure your email client properly.

On Tue, Sep 08, 2015 at 01:21:04AM +, 甘清甜 wrote:
> -- Forwarded message -
> From: Wei Liu 
> Date: 2015年9月7日周一 下午6:23
> Subject: Re: [Xen-devel] Question about the status of vNUMA in Xen
> To: 甘清甜 
> Cc: , 
> 
> 
> On Sun, Sep 06, 2015 at 03:03:13PM +0800, 甘清甜 wrote:
> > I'm a master student from Huazhong University of Science & technology,
> > China. I'm now researching on Xen optimization under NUMA. I'm puzzled
> > that if  vNUMA on HVM is enbaded in Xen or not. If yes, which version of
> > xen support it?
> >
> 
> Upcoming Xen 4.6 supports vNUMA for HVM guest, with certain limitations.
> 
> > So far, I have read the Xen NUMA Roadmap page and watched the
> > video about vNUMA in Xen on Youtube. I have known that some work
> > has been done for vNUMA in Xen. Since my benchmark result show a
> > great improvement in Xen-4.5.1 when compared with Xen-4.0.1. I'm
> > puzzled if vNUMA has contributed to that improvement.
> 
> No. That's mostly due to other improvements.
> 
> Wei.
> 
> > ___
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 
> I’m sorry that I didn’t express clearly in the last mail. What I want to
> know is
> 
> that how much the NUMA optimizations (including NUMA-aware VM placement,
> 
> NUMA-aware scheduling and vNUMA)  contribute to the improvement
> 

There is wiki page on wiki.xen.org for NUMA-aware scheduling.

http://wiki.xenproject.org/wiki/Xen_4.3_NUMA_Aware_Scheduling

No tests for vNUMA have been done so far. At least not the upstream
version.

Wei.

> between xen-4.5.1 and xen-4.0.1.  Surely it may also due to other changes.
> Thanks!

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


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

Re: [Xen-devel] Notes from Xen BoF at Debconf15

[Jan Beulich]

>>> On 08.09.15 at 12:49,  wrote:
> Jan Beulich writes ("Re: [Xen-devel] Notes from Xen BoF at Debconf15"):
>> Right - 4.4.3 already was released with just one RC, and indeed I
>> meant to stay with that model considering the little (if any) feedback
>> we get on these RCs. I personally could live without doing any RCs,
>> but [...]
> 
> Having had the chance to reflect I am convinced that we should stop
> doing RCs for point releases.
> 
>> [I] thought so far that doing at least one kind of publicly indicates
>> the intention of doing a release soon.
> 
> You might hope that it would have that effect, but I don't think it is
> working.  Also, if it does work, all it does is generate more patches,
> making the `rc' more of a `prod to get your stuff shoveled in'.

Well, okay - no RCs anymore then unless someone offers a
convincing reason to have them.

Jan


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

Re: [Xen-devel] [PATCH] MAINTAINERS: stable backports should be requested on xen-devel

[Ian Campbell]

On Sat, 2015-07-25 at 09:25 +0100, Ian Campbell wrote:
> As well as CC-ing the correct people. I just saw such a request on
> xen-users and thought this was worth clarifying here too.
> 
> Signed-off-by: Ian Campbell 

Just found this in my folder, do we want to take it for 4.6?

> ---
>  MAINTAINERS | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a4e64ea..156a95f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -49,9 +49,10 @@ for inclusion in xen-unstable.
>  Please see http://wiki.xen.org/wiki/Xen_Maintenance_Releases for more
>  information.
>  
> -Remember to copy the appropriate stable branch maintainer who will be
> -listed in this section of the MAINTAINERS file in the appropriate
> -branch.
> +Backport requests should be made on the xen-de...@lists.xenproject.org
> +list. Remember to copy the appropriate stable branch maintainer who
> +will be listed in this section of the MAINTAINERS file in the
> +appropriate branch.
>  
>   Unstable Subsystem Maintainers
>   ==

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

Re: [Xen-devel] [PATCH] xen/vtd/iommu: permit group devices to passthrough in relaxed mode

[Jan Beulich]

>>> On 08.09.15 at 02:57,  wrote:
> Currently we don't allow passing through any group devices which are
> sharing same RMRR entry since it would break security among VMs. And
> indeed, we expect we can figure out a better way to handle this kind
> of case completely.
> 
> But before the group assignment gets implemented, we might make this
> permission dependent on our RMRR policy. So, now it would be allowed
> in the relaxed mode.
> 
> CC: Yang Zhang 
> CC: Kevin Tian 
> CC: Jan Beulich 
> Signed-off-by: Tiejun Chen 
> ---
>  xen/drivers/passthrough/vtd/iommu.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/drivers/passthrough/vtd/iommu.c 
> b/xen/drivers/passthrough/vtd/iommu.c
> index 836aed5..4249cfa 100644
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -2310,12 +2310,16 @@ static int intel_iommu_assign_device(
>   PCI_DEVFN2(bdf) == devfn &&
>   rmrr->scope.devices_cnt > 1 )
>  {
> +u32 relaxed = flag & XEN_DOMCTL_DEV_RDM_RELAXED;

Conventionally this ought to be a bool_t.

>  printk(XENLOG_G_ERR VTDPREFIX
> -   " cannot assign %04x:%02x:%02x.%u"
> +   " Currently its %s to assign %04x:%02x:%02x.%u"

In addition to what Wei said - what meaning is "currently" supposed
to have here? To a reader of the resulting log it might look as if
(s)he'd need to reconfigure the hypervisor (via some command line
option perhaps), while acceptance / refusal solely depends on the
arguments the caller provides.

Apart from that in the relaxed case the message level should be
XENLOG_G_WARNING, not XENLOG_G_ERR.

Jan


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

[Xen-devel] Questions about the FreeBSD network subsystem

[Roger Pau Monné]

Hello,

I'm not very familiar with FreeBSD network subsystem and I'm trying to
import a new version of xen-netfront from Linux to FreeBSD. So far so
good, most stuff is pretty similar and I think I've _mostly_ figured it
out by myself. I have however a couple of questions regarding the
network subsystem.

I'm planning to use if_transmit/if_qflush instead of if_start. AFAICT I
have to create my own queue inside of the driver in order to queue
packets if the shared ring is full. What's the prefer way to do this? I
see there are functions to create a mbuf queue (mbufq) or a ifnet based
queue (drbr_* family of functions). I expect using drbr is TRTTD, but I
would like to get some confirmation before proceeding.

Also, the Xen PV network protocol allows signalling packets that contain
valid data or blank checksums. It allows specifying the following flags:

 - NET{RX/TR}F_data_validated: packet data has been validated against
protocol checksum.
 - NET{RX/TX}F_csum_blank: protocol checksum field is blank in the
packet (hardware offload)?.
 - No flag: checksum present and valid.

How do this options translate to the csum_flags present in mbufs on FreeBSD?

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v2] efi: introduce efi_arch_flush_dcache_area

[Julien Grall]

Hi Stefano,

On 08/09/15 11:38, Stefano Stabellini wrote:
> Objects loaded by FileHandle->Read need to be flushed from dcache,
> otherwise copy_from_paddr will read stale data when copying the kernel,
> causing a failure to boot.

It would have been nice to have some explanation why we can read stale
data in the commit message (see [1]).

It would avoid to look at the ML in the future to understand why this
patch is here.

> Introduce efi_arch_flush_dcache_area and call it from read_file.
> 
> This commit introduces no functional changes on x86.

[1] http://www.gossamer-threads.com/lists/xen/devel/396892#396892

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH v6 15/18] vmx: Properly handle notification event when vCPU is running

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, September 08, 2015 6:13 PM
> To: Wu, Feng
> Cc: Andrew Cooper; Tian, Kevin; Zhang, Yang Z; xen-devel@lists.xen.org; Keir
> Fraser
> Subject: RE: [PATCH v6 15/18] vmx: Properly handle notification event when
> vCPU is running
> 
> >>> On 08.09.15 at 11:36,  wrote:
> 
> >
> >> -Original Message-
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Tuesday, September 08, 2015 5:31 PM
> >> To: Wu, Feng
> >> Cc: Andrew Cooper; Tian, Kevin; Zhang, Yang Z; xen-devel@lists.xen.org;
> Keir
> >> Fraser
> >> Subject: RE: [PATCH v6 15/18] vmx: Properly handle notification event when
> >> vCPU is running
> > No problem. Two solutions:
> > #1, Register pi_notification_interrupt when iommu_intpost and still
> > use event_check_interrupt in the !iommu_intpost case.
> > #1, Use pi_notification_interrupt() for both iommu_intpost and
> > !iommu_intpost, add the following check it:
> > if ( iommu_intpost )
> > raise_softirq(VCPU_KICK_SOFTIRQ);
> >
> > Which one do you prefer?
> 
> #1 ;-) (the earlier one, to avoid you guessing)

Hmm, sorry for the typo. :)

Thanks,
Feng

> 
> Jan


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

Re: [Xen-devel] Notes from Xen BoF at Debconf15

[Jan Beulich]

>>> On 08.09.15 at 12:15,  wrote:
> On Tue, 2015-09-08 at 03:47 -0600, Jan Beulich wrote:
>> > > > On 08.09.15 at 11:24,  wrote:
>> > Release cycle
>> > =
>> > 
>> > Waldi commented that the stable release cycle was too long. Would like
>> > to see a release after any large security update.
>> > 
>> > We asked if the RCs for stable releases were valuable, the answer was
>> > "not so much".
>> > 
>> > Waldi would prefer to avoid cherry-picking security fixes if possible.
>> > 
>> > We asked if we thought Xen stable releases could be added to Debian
>> > point releases. Waldi thought they likely could be, citing the
>> > inclusion of Linux stable releases in point releases.
>> > 
>> > Our stable releases follow a similar set of rules to Linux, we think
>> > we implement them more faithfully (less feature or feature-like
>> > backports)
>> > 
>> > ACTION: Talk to Jan about making changes to stable release process.
>> 
>> That's kind of the opposite of what we quite recently changed to
>> (a [hopefully] more predictable four month cycle). Apart from the
>> question what "large" is, doing a release after any large security
>> update seems unreasonable to me (not only because of giving up
>> the predictability, but also because of the overhead involved,
>> which is there even if we ditched the RCs). I have to admit that I
>> fail to see why Debian would be different than other distros, all
>> cherry picking security fixes until a new stable release becomes
>> available. If otoh other major distros voiced similar desires, I
>> think we'd have to once again re-think our stable release cadence.
> 
> IIRC (hopefully Ian or someone else will correct me if not) the main
> proposal to discuss with you was WRT the usefulness of the RCs for stable
> releases, since it was felt they didn't provide much benefit to
> downstreams.
> 
> IOW perhaps it would be just as useful to downstreams and less work for us
> (mainly you I suppose) to do 0 or only 1 rc for a point release, based on
> whatever is in the branch at the appropriate time. It might also avoid
> various delays which the stable release process can currently suffer from
> waiting for a push for each rc instead of just once (or maybe twice), which
> in turn might help the release timing to be even more predictable.

Right - 4.4.3 already was released with just one RC, and indeed I
meant to stay with that model considering the little (if any) feedback
we get on these RCs. I personally could live without doing any RCs,
but thought so far that doing at least one kind of publicly indicates
the intention of doing a release soon.

Jan


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

[Xen-devel] [PATCH v2] efi: introduce efi_arch_flush_dcache_area

[Stefano Stabellini]

Objects loaded by FileHandle->Read need to be flushed from dcache,
otherwise copy_from_paddr will read stale data when copying the kernel,
causing a failure to boot.

Introduce efi_arch_flush_dcache_area and call it from read_file.

This commit introduces no functional changes on x86.

Reported-by: Mark Rutland 
Signed-off-by: Stefano Stabellini 
Release-acked-by: Wei Liu 
CC: Mark Rutland 
CC: ian.campb...@citrix.com
CC: jbeul...@suse.com

---

Changed in v2:
- code style
- remove misplaced "else"
---
 xen/arch/arm/efi/efi-boot.h |7 +++
 xen/arch/x86/efi/efi-boot.h |2 ++
 xen/common/efi/boot.c   |1 +
 3 files changed, 10 insertions(+)

diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
index 6a12d91..e427e5f 100644
--- a/xen/arch/arm/efi/efi-boot.h
+++ b/xen/arch/arm/efi/efi-boot.h
@@ -9,6 +9,7 @@
 #include 
 
 void noreturn efi_xen_start(void *fdt_ptr, uint32_t fdt_size);
+void __flush_dcache_area(const void *vaddr, unsigned long size);
 
 #define DEVICE_TREE_GUID \
 {0xb1b621d5, 0xf19c, 0x41a5, {0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 0xe0}}
@@ -571,6 +572,12 @@ static void __init 
efi_arch_video_init(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
EFI_GRAPHICS_OUTPUT_MODE_INFORMATION 
*mode_info)
 {
 }
+
+static void efi_arch_flush_dcache_area(const void *vaddr, UINTN size)
+{
+__flush_dcache_area(vaddr, size);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
index 2dd69f6..4c7f383 100644
--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -640,6 +640,8 @@ static bool_t __init 
efi_arch_use_config_file(EFI_SYSTEM_TABLE *SystemTable)
 return 1; /* x86 always uses a config file */
 }
 
+static void efi_arch_flush_dcache_area(const void *vaddr, UINTN size) { }
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 75a939f..be5ed8e 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -527,6 +527,7 @@ static bool_t __init read_file(EFI_FILE_HANDLE dir_handle, 
CHAR16 *name,
 PrintErr(L" failed for ");
 PrintErrMesg(name, ret);
 }
+efi_arch_flush_dcache_area(file->ptr, file->size);
 
 return 1;
 }
-- 
1.7.10.4


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

Re: [Xen-devel] Notes from Xen BoF at Debconf15

[Ian Jackson]

Jan Beulich writes ("Re: [Xen-devel] Notes from Xen BoF at Debconf15"):
> Right - 4.4.3 already was released with just one RC, and indeed I
> meant to stay with that model considering the little (if any) feedback
> we get on these RCs. I personally could live without doing any RCs,
> but [...]

Having had the chance to reflect I am convinced that we should stop
doing RCs for point releases.

> [I] thought so far that doing at least one kind of publicly indicates
> the intention of doing a release soon.

You might hope that it would have that effect, but I don't think it is
working.  Also, if it does work, all it does is generate more patches,
making the `rc' more of a `prod to get your stuff shoveled in'.

Ian.

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

Re: [Xen-devel] [PATCH RFC v2 0/4] HVM x86 deprivileged mode operations

[Ben Catterall]

Hi Fabio,

On 04/09/15 11:46, Fabio Fantoni wrote:
[snip]


Sorry for my stupid questions:
Is there a test with benchmark using qemu instead for know how is
different? Qemu seems that emulate also some istructions cases that xen
hypervisor doesn't for now, or I'm wrong?

So, QEMU emulates devices for HVM guests. Now, letting the portio 
operation through to QEMU to emulate takes about 20e-6 seconds. But, 
that includes the time QEMU takes to actually emulate the port operation 
so is not the 'pure' overhead. I need to do more detailed analysis to 
get that figure.



Is there any possible hardware technology or set of instructions for
improve the operations also deprivileged or transition from Xen is
obliged to control even mappings memory access?


We're using sysret and syscall already to do the transition which are 
the fast system call operations. I don't have actual benchmark values 
for their execution time though. We map the depriv code, stack and data 
sections into the monitor table when initialising the HVM guest (user 
mode mapping) so Xen doesn't need to worry about those mappings whilst 
executing a depriv operation.



Is there any possible future hardware technology or set of instructions
for take needed informations from hypervisor for executing directly all
needed checks, them if ok and any possible exceptions/protections or
delegate this to xen for each instruction with a tremendous impact on
the efficiency can not be improved?
I'm not quite sure what you're asking here, sorry! Are you asking if we 
can take an HVM guest instruction, analyse it to determine if it's safe 
to execute and then execute it rather than emulating it? If so:


QEMU handles device emulation and this is deliberately not done in Xen 
to reduce the attack surface of the hypervisor and keep it minimal. We 
do need to analyse instructions at some points (x86 emulate) but this is 
error prone (there's a paper or two on exploits of this feature). This 
is one of the reasons for considering a depriv mode in the first pace, 
by moving such code into a deprivileged area, we can prevent a bug in 
this code from leading to hypervisor compromise. I'm not aware of any 
future hardware or set of instructions but that doesn't mean there 
aren't/won't be!



If I said only absurd things because of my knowledge too low about sorry
for having wasted your time.

Thanks for any reply and sorry for my bad english.

np, I hope I've understood correctly!




Performance testing
---
Performance testing indicates that the overhead for this deprivileged
mode
depend heavily upon the processor. This overhead is the cost of moving
into
deprivileged mode and then fully back out of deprivileged mode. The
conclusions
are that the overheads are not negligible and that operations using this
mechanism would benefit from being long running or be high risk
components. It
will need to be evaluated on a case-by-case basis.

I performed 10 writes to a single I/O port on an Intel 2.2GHz Xeon
E5-2407 0 processor and an AMD Opteron 2376. This was done from a
python script
within the HVM guest using time.time() and running Debian Jessie. Each
write was
trapped to cause a vmexit and the time for each write was calculated.
The port
operation is bypassed so that no portio is actually performed. Thus, the
differences in the measurements below can be taken as the pure
overhead. These
experiments were repeated. Note that only the host and this HVM guest
were
running (both Debian Jessie) during the experiments.

Intel Intel 2.2GHz Xeon E5-2407 0 processor:

1.55e-06 seconds was the average time for performing the write without
the
  deprivileged code running.

5.75e-06 seconds was the average time for performing the write with the
  deprivileged code running.

So approximately 351% overhead

AMD Opteron 2376:
-
1.74e-06 seconds was the average time for performing the write without
the
  deprivileged code running.
3.10e-06 seconds was the average time for performing the write with an
entry and
  exit from deprvileged mode.

So approximately 178% overhead.

Signed-off-by: Ben Catterall 


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




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

Re: [Xen-devel] [OSSTEST PATCH 25/29] Manual allocation: Break out manual_allocation_base_jobinfo from mg-blockage

[Ian Campbell]

On Mon, 2015-09-07 at 17:08 +0100, Ian Jackson wrote:
> This is called `jobinfo' because it ought to be used in
> alloc_resources's JobInfo xparam, rather than an Xinfo in the booking:
> JobInfo is per planning client; Xinfo is per individual resource.
> 
> mg-blockage currently gets this wrong; we will fix that shortly.
> 
> Signed-off-by: Ian Jackson 
> ---
> v2: New patch
> ---
>  Osstest/Executive.pm |7 +++
>  mg-blockage  |5 ++---
>  2 files changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/Osstest/Executive.pm b/Osstest/Executive.pm
> index 4f51d70..1efcfd4 100644
> --- a/Osstest/Executive.pm
> +++ b/Osstest/Executive.pm
> @@ -51,6 +51,7 @@ BEGIN {
>report_altchangecolour
>report_blessingscond report_find_push_age_info
>tcpconnect_queuedaemon plan_search
> +  manual_allocation_base_jobinfo
>alloc_resources
> alloc_resources_rollback_begin_work
>resource_check_allocated
> resource_shared_mark_ready
>duration_estimator
> @@ -494,6 +495,12 @@ END
>  return $taskid;
>  }
>  
> +sub manual_allocation_base_jobinfo () {
> +my $whoami = `whoami`; chomp $whoami;
> +my $hostname = `uname -n`; chomp $hostname;
> +return "$whoami\@$hostname";
> +}
> +
>  sub alloc_resources_rollback_begin_work () {
>  $dbh_tests->rollback();
>  db_begin_work($dbh_tests, \@all_lock_tables);
> diff --git a/mg-blockage b/mg-blockage
> index 1f66d8e..0286c27 100755
> --- a/mg-blockage
> +++ b/mg-blockage
> @@ -24,9 +24,8 @@ sub parsedate ($) {
>  return $r;
>  }
>  
> -my $whoami = `whoami`; chomp $whoami;
> -my $hostname = `uname -n`; chomp $hostname;
> -my $xinfo = "blockage $whoami\@$hostname [$start .. $end]";
> +my $basexinfo = manual_allocation_base_joinfo();

missing a b in jobinfo I think.

> +my $xinfo = "blockage $basexinfo [$start .. $end]";
>  $xinfo .= " $mxinfo" if defined $mxinfo;
>  
>  $start = parsedate $start;

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

Re: [Xen-devel] Asus X99-A VT-d problems

[Jan Beulich]

>>> On 07.09.15 at 20:28,  wrote:
> On Mon, Sep 07, 2015 at 08:45:20PM +0300, Valtteri Kiviniemi wrote:
>>I'm happy to help to debug this further if needed, but so far I'm not able
>>to boot the system at all without iommu=0 boot parameter.
>> 
> 
> It'd be helpful if you could use a serial console (PCI serial card perhaps? 
> Or if your motherboard has a built-in IPMI/BMC/AMT management processor with 
> Serial-Over-LAN port that works aswell..) and capture a logfile from the full 
> Xen + Linux boot.. with all the verbose/debugging options enabled.

Indeed - without seeing a log of what goes wrong I don't think there's
much we can do. (One thing that might help is to post a native Linux
boot log with the IOMMU fully enabled, provided of course that one
boots up. This might provide hints at workarounds they have an place
but we don't.)

Jan


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

Re: [Xen-devel] [PATCH] xen-blkback: free requests on disconnection

[Roger Pau Monné]

El 07/09/15 a les 13.35, Bob Liu ha escrit:
> 
> On 09/07/2015 07:10 PM, Julien Grall wrote:
>> On 07/09/15 07:07, Bob Liu wrote:
>>> Hi Julien,
>>
>> Hi Bob,
>>
>>> On 09/04/2015 09:51 PM, Julien Grall wrote:
 Hi Roger,

 On 04/09/15 11:08, Roger Pau Monne wrote:
> Request allocation has been moved to connect_ring, which is called every
> time blkback connects to the frontend (this can happen multiple times 
> during
> a blkback instance life cycle). On the other hand, request freeing has not
> been moved, so it's only called when destroying the backend instance. Due 
> to
> this mismatch, blkback can allocate the request pool multiple times, 
> without
> freeing it.
>
> In order to fix it, move the freeing of requests to xen_blkif_disconnect 
> to
> restore the symmetry between request allocation and freeing.
>
> Reported-by: Julien Grall 
> Signed-off-by: Roger Pau Monné 
> Cc: Julien Grall 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Boris Ostrovsky 
> Cc: David Vrabel 
> Cc: xen-de...@lists.xenproject.org

 The patch is fixing my problem when using UEFI in the guest. Thank you!

>>>
>>> Could you please explain the problem you met a bit more?
>>> So that I can know back port this patch if met similar issue.
>>
>> This is related to commit 86839c56dee28c315a4c19b7bfee450ccd84cd25
>> "xen/block: add multi-page ring support" (Roger, it may be worth to
>> indicate the offending commit in you commit message).
>>
>> When starting a guest using UEFI. After the domain is destroyed I get
>> the following warning from blkback:
>>
>>
>> [ cut here ]
>> WARNING: CPU: 2 PID: 95 at
>> /home/julien/works/linux/drivers/block/xen-blkback/xenbus.c:274
>> xen_blkif_deferred_free+0x1f4/0x1f8()
>> Modules linked in:
>> CPU: 2 PID: 95 Comm: kworker/2:1 Tainted: GW   4.2.0 #85
>> Hardware name: APM X-Gene Mustang board (DT)
>> Workqueue: events xen_blkif_deferred_free
>> Call trace:
>> [] dump_backtrace+0x0/0x124
>> [] show_stack+0x10/0x1c
>> [] dump_stack+0x78/0x98
>> [] warn_slowpath_common+0x9c/0xd4
>> [] warn_slowpath_null+0x14/0x20
>> [] xen_blkif_deferred_free+0x1f0/0x1f8
>> [] process_one_work+0x160/0x3b4
>> [] worker_thread+0x140/0x494
>> [] kthread+0xd8/0xf0
>> ---[ end trace 6f859b7883c88cdd ]---
>>
>> This is because the allocation of the requests are done during the
>> connection but the free is done when the domain is destroyed. Therefore
>> if the domain is re-initializing the connection (because UEFI or PV Grub
>> is used), the request won't be free and kept until the end.
>>
> 
> Thank you!
> Roger, I think it's better to have this information in your commit message 
> too.

Konrad, would you like me to resend the patch with the modified commit
message, or do you plan to amend it yourself while committing?

Roger.


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

[Xen-devel] [linux-3.10 test] 61520: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qcow2 9 debian-di-install fail REGR. vs. 60670
 test-amd64-amd64-xl-vhd   9 debian-di-install fail REGR. vs. 60670
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
60670
 test-amd64-amd64-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
60670
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install 
fail REGR. vs. 60670
 test-amd64-i386-qemut-rhel6hvm-intel 10 guest-stopfail REGR. vs. 60670
 test-amd64-i386-xl-qcow2 10 guest-start   fail REGR. vs. 60670
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 12 guest-saverestore fail REGR. 
vs. 60670
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 60670
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 60670
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install fail REGR. vs. 60670
 test-amd64-i386-xl-qemuu-winxpsp3  9 windows-install  fail REGR. vs. 60670
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 60670
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 60670
 test-amd64-amd64-xl-qemut-win7-amd64  9 windows-install   fail REGR. vs. 60670
 test-amd64-amd64-xl-qemuu-winxpsp3  9 windows-install fail REGR. vs. 60670
 test-amd64-i386-xl-qemuu-win7-amd64  9 windows-installfail REGR. vs. 60670
 test-amd64-amd64-xl-qemuu-win7-amd64  9 windows-install   fail REGR. vs. 60670
 test-amd64-i386-xl-qemut-win7-amd64  9 windows-installfail REGR. vs. 60670
 test-amd64-i386-xl-qemut-debianhvm-amd64 15 guest-localmigrate.2 fail in 60748 
REGR. vs. 60670
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 12 guest-saverestore fail 
in 60748 REGR. vs. 60670
 test-amd64-i386-qemuu-rhel6hvm-intel 12 guest-start/redhat.repeat fail in 
60790 REGR. vs. 60670
 test-amd64-i386-qemut-rhel6hvm-amd 10 guest-stop fail in 60790 REGR. vs. 60670
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 13 guest-localmigrate fail in 
60790 REGR. vs. 60670
 test-amd64-i386-freebsd10-i386 14 guest-localmigrate fail in 60865 REGR. vs. 
60670
 test-amd64-i386-qemuu-rhel6hvm-amd 12 guest-start/redhat.repeat fail in 60865 
REGR. vs. 60670
 test-amd64-i386-xl-qemuu-ovmf-amd64 14 guest-saverestore.2 fail in 60950 REGR. 
vs. 60670
 test-amd64-i386-xl-vhd   10 guest-start  fail in 60950 REGR. vs. 60670
 test-amd64-i386-xl-qemut-winxpsp3 12 guest-saverestore fail in 60992 REGR. vs. 
60670
 test-amd64-i386-freebsd10-amd64 14 guest-localmigrate fail in 61268 REGR. vs. 
60670
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 12 guest-saverestore fail in 
61268 REGR. vs. 60670

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-raw  3 host-install(3)   broken pass in 61268
 test-amd64-i386-xl6 xen-boot   fail in 60748 pass in 61520
 test-amd64-i386-xl-qemuu-debianhvm-amd64 12 guest-saverestore fail in 60790 
pass in 60865
 test-amd64-i386-libvirt  16 guest-stop fail in 60790 pass in 60865
 test-amd64-amd64-libvirt-xsm 14 guest-saverestore  fail in 60790 pass in 61520
 test-amd64-i386-rumpuserxen-i386 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail in 60790 pass in 61520
 test-amd64-i386-qemuu-rhel6hvm-intel 10 guest-stop fail in 60865 pass in 60950
 test-amd64-i386-libvirt-xsm 15 guest-saverestore.2 fail in 60865 pass in 60992
 test-amd64-i386-qemut-rhel6hvm-intel 9 redhat-install fail in 60865 pass in 
61520
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail in 
60865 pass in 61520
 test-amd64-i386-qemuu-rhel6hvm-intel 11 guest-start.2 fail in 60950 pass in 
60790
 test-amd64-i386-libvirt  14 guest-saverestore  fail in 60950 pass in 61520
 test-amd64-i386-xl-qcow2  9 debian-di-install  fail in 60950 pass in 61520
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 12 guest-saverestore fail in 
60992 pass in 60790
 test-amd64-i386-qemuu-rhel6hvm-amd 10 guest-stop   fail in 61268 pass in 60950
 test-amd64-i386-libvirt-qcow2  9 debian-di-install fail in 61268 pass in 61520
 test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail pass in 
60748
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
pass in 60748
 test-amd64-i386-qemut-rhel6hvm-amd  9 redhat-installfail pass in 60790
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail pass in 
60865
 test-amd64-i386-libvirt  15 guest-saverestore.2 fail pass in 60865
 test-amd64-i386-freebsd10-i386 13 guest-saverestore fail pass in 60865
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install   fail pass in 60950
 test-amd64-i386-xl-vhd9 debian-di-install   fail pass in 60950
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 

Re: [Xen-devel] [Xen-users] Xen bridging issue.

[Wei Liu]

On Tue, Sep 08, 2015 at 12:59:39PM +0300, johnny Strom wrote:
> On 09/08/2015 12:13 PM, Wei Liu wrote:
> >  xenstore-ls/local/domain/$DOMID/
> 
> Here is the output of xenstore-ls only one network card is working.
> 
> xenstore-ls  /local/domain/1
> 
[...]
>  vif = ""
>   0 = ""
>backend = "/local/domain/0/backend/vif/1/0"
>backend-id = "0"
>state = "4"
>handle = "0"
>mac = "00:16:3e:ee:aa:aa"
>multi-queue-num-queues = "17"

OK so the number of queues is 17. You probably don't need that many
queues.

Set module parameter "xenvif_max_queues" of netback to something like 4
should work around the problem for you.

Wei.

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

Re: [Xen-devel] [Xen-users] Xen bridging issue.

[johnny Strom]

On 09/08/2015 12:13 PM, Wei Liu wrote:

  xenstore-ls/local/domain/$DOMID/


Here is the output of xenstore-ls only one network card is working.

xenstore-ls  /local/domain/1

vm = "/vm/63d68f91-093d-4cf2-8c8e-28c7bd8028ab"
name = "test-debian-jessie"
cpu = ""
 0 = ""
  availability = "online"
 1 = ""
  availability = "online"
 2 = ""
  availability = "online"
 3 = ""
  availability = "online"
 4 = ""
  availability = "online"
 5 = ""
  availability = "online"
 6 = ""
  availability = "online"
 7 = ""
  availability = "online"
 8 = ""
  availability = "online"
 9 = ""
  availability = "online"
 10 = ""
  availability = "online"
 11 = ""
  availability = "online"
 12 = ""
  availability = "online"
 13 = ""
  availability = "online"
 14 = ""
  availability = "online"
 15 = ""
  availability = "online"
 16 = ""
  availability = "online"
 17 = ""
  availability = "online"
 18 = ""
  availability = "online"
 19 = ""
  availability = "online"
 20 = ""
  availability = "online"
 21 = ""
  availability = "online"
 22 = ""
  availability = "online"
 23 = ""
  availability = "online"
 24 = ""
  availability = "online"
 25 = ""
  availability = "online"
 26 = ""
  availability = "online"
 27 = ""
  availability = "online"
 28 = ""
  availability = "online"
 29 = ""
  availability = "online"
 30 = ""
  availability = "online"
 31 = ""
  availability = "online"
 32 = ""
  availability = "online"
 33 = ""
  availability = "online"
 34 = ""
  availability = "online"
 35 = ""
  availability = "online"
 36 = ""
  availability = "online"
 37 = ""
  availability = "online"
 38 = ""
  availability = "online"
 39 = ""
  availability = "online"
memory = ""
 static-max = "4194304"
 target = "4194305"
 videoram = "-1"
device = ""
 suspend = ""
  event-channel = ""
 vbd = ""
  51713 = ""
   backend = "/local/domain/0/backend/qdisk/1/51713"
   backend-id = "0"
   state = "4"
   virtual-device = "51713"
   device-type = "disk"
   protocol = "x86_64-abi"
   ring-ref = "8"
   event-channel = "243"
   feature-persistent = "1"
  51714 = ""
   backend = "/local/domain/0/backend/qdisk/1/51714"
   backend-id = "0"
   state = "4"
   virtual-device = "51714"
   device-type = "disk"
   protocol = "x86_64-abi"
   ring-ref = "9"
   event-channel = "244"
   feature-persistent = "1"
 vif = ""
  0 = ""
   backend = "/local/domain/0/backend/vif/1/0"
   backend-id = "0"
   state = "4"
   handle = "0"
   mac = "00:16:3e:ee:aa:aa"
   multi-queue-num-queues = "17"
   queue-0 = ""
tx-ring-ref = "8960"
rx-ring-ref = "8961"
event-channel-tx = "245"
event-channel-rx = "246"
   queue-1 = ""
tx-ring-ref = "8962"
rx-ring-ref = "8963"
event-channel-tx = "247"
event-channel-rx = "248"
   queue-2 = ""
tx-ring-ref = "8964"
rx-ring-ref = "8965"
event-channel-tx = "249"
event-channel-rx = "250"
   queue-3 = ""
tx-ring-ref = "8966"
rx-ring-ref = "8967"
event-channel-tx = "251"
event-channel-rx = "252"
   queue-4 = ""
tx-ring-ref = "8968"
rx-ring-ref = "8969"
event-channel-tx = "253"
event-channel-rx = "254"
   queue-5 = ""
tx-ring-ref = "8970"
rx-ring-ref = "8971"
event-channel-tx = "255"
event-channel-rx = "256"
   queue-6 = ""
tx-ring-ref = "8972"
rx-ring-ref = "8973"
event-channel-tx = "257"
event-channel-rx = "258"
   queue-7 = ""
tx-ring-ref = "8974"
rx-ring-ref = "8975"
event-channel-tx = "259"
event-channel-rx = "260"
   queue-8 = ""
tx-ring-ref = "8976"
rx-ring-ref = "8977"
event-channel-tx = "261"
event-channel-rx = "262"
   queue-9 = ""
tx-ring-ref = "8978"
rx-ring-ref = "8979"
event-channel-tx = "263"
event-channel-rx = "264"
   queue-10 = ""
tx-ring-ref = "8980"
rx-ring-ref = "8981"
event-channel-tx = "265"
event-channel-rx = "266"
   queue-11 = ""
tx-ring-ref = "8982"
rx-ring-ref = "8983"
event-channel-tx = "267"
event-channel-rx = "268"
   queue-12 = ""
tx-ring-ref = "8984"
rx-ring-ref = "8985"
event-channel-tx = "269"
event-channel-rx = "270"
   queue-13 = ""
tx-ring-ref = "8986"
rx-ring-ref = "8987"
event-channel-tx = "271"
event-channel-rx = "272"
   queue-14 = ""
tx-ring-ref = "8988"
rx-ring-ref = "8989"
event-channel-tx = "273"
event-channel-rx = "274"
   queue-15 = ""
tx-ring-ref = "8990"
rx-ring-ref = "8991"
event-channel-tx = "275"
event-channel-rx = "276"
   queue-16 = ""
tx-ring-ref = "8992"
rx-ring-ref = "8993"
event-channel-tx = "277"
event-channel-rx = "278"
   request-rx-copy = "1"
   feature-rx-notify = "1"
   feature-sg = "1"
   feature-gso-tcpv4 = "1"
   feature-gso-tcpv6 = "1"
   feature-ipv6-csum-offload = "1"
  1 = ""
   backend = "/local/domain/0/backend/vif/1/1"
   backend-id = "0"
   state = "1"
   handle = "1"
   mac = "00:16:3e:ec:a7:b5"
control = ""
 shutdown = ""
 platform-feature-multiprocessor-suspend = "1"
 platform-feature-xs_reset_watches = "1"
data = 

Re: [Xen-devel] [Xen-users] Xen bridging issue.

[Wei Liu]

On Tue, Sep 08, 2015 at 02:07:21PM +0300, johnny Strom wrote:
> On 09/08/2015 01:06 PM, Wei Liu wrote:
> >On Tue, Sep 08, 2015 at 12:59:39PM +0300, johnny Strom wrote:
> >>On 09/08/2015 12:13 PM, Wei Liu wrote:
> >>>  xenstore-ls/local/domain/$DOMID/
> >>Here is the output of xenstore-ls only one network card is working.
> >>
> >>xenstore-ls  /local/domain/1
> >>
> >[...]
> >>  vif = ""
> >>   0 = ""
> >>backend = "/local/domain/0/backend/vif/1/0"
> >>backend-id = "0"
> >>state = "4"
> >>handle = "0"
> >>mac = "00:16:3e:ee:aa:aa"
> >>multi-queue-num-queues = "17"
> >OK so the number of queues is 17. You probably don't need that many
> >queues.
> >
> >Set module parameter "xenvif_max_queues" of netback to something like 4
> >should work around the problem for you.
> 
> Hello
> 
> I tried to set it to 4 in  /etc/modprobe.d/xen_netback.conf
> 
> rmmod xen_netback
> 
> modprobe -v xen_netback
> insmod
> /lib/modules/3.16.0-4-amd64/kernel/drivers/net/xen-netback/xen-netback.ko
> xenvif_max_queues=4
> 
> 
> 
> But it is still the same issue..
> 
> Is xenvif_max_queues supported in Linux kernel 3.16?
> 
> modinfo -p xen_netback
> 
> separate_tx_rx_irq: (bool)
> rx_drain_timeout_msecs: (uint)
> rx_stall_timeout_msecs: (uint)
> max_queues:Maximum number of queues per virtual interface (uint)

Oh, right, the parameter name should be "max_queues".

Sorry about that!

Wei.

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

Re: [Xen-devel] [PULL 0/19] xen-2015-09-08-tag

[Peter Maydell]

On 8 September 2015 at 18:21, Stefano Stabellini
 wrote:
> The following changes since commit 8611280505119e296757a60711a881341603fa5a:
>
>   target-microblaze: Use setcond for pcmp* (2015-09-08 08:49:33 +0200)
>
> are available in the git repository at:
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-2015-09-08-tag
>
> for you to fetch changes up to ba2250ad148997b1352aba976aac66b55410e7e4:
>
>   xen/pt: Use XEN_PT_LOG properly to guard against compiler warnings. 
> (2015-09-08 15:21:56 +)
>
> 
> Xen branch xen-2015-09-08
>
> 

Hi. I'm afraid this fails to build on OSX (and probably Windows too,
though that build hasn't run yet):

  CCi386-softmmu/hw/i386/pci-assign-load-rom.o
/Users/pm215/src/qemu/hw/i386/pci-assign-load-rom.c:6:10: fatal error:
  'sys/io.h' file not found
#include 
 ^
  CCalpha-softmmu/hw/alpha/pci.o
1 error generated.

thanks
-- PMM

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

[Xen-devel] [linux-3.14 test] 61522: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-vhd   13 guest-saverestore fail REGR. vs. 60666
 test-amd64-i386-xl-qcow2 13 guest-saverestore fail REGR. vs. 60666
 test-amd64-amd64-xl-vhd  19 guest-start.2fail in 61263 REGR. vs. 60666
 test-amd64-amd64-xl-qcow219 guest-start.2fail in 61263 REGR. vs. 60666

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemut-rhel6hvm-intel 3 host-install(3) broken in 61316 pass in 
61522
 test-amd64-i386-xl-vhd3 host-install(3)  broken in 61316 pass in 61522
 test-amd64-i386-xl-qcow2  3 host-install(3)  broken in 61316 pass in 61522
 test-amd64-amd64-xl-vhd   3 host-install(3)  broken in 61316 pass in 61522
 test-amd64-amd64-libvirt-qcow2 3 host-install(3) broken in 61316 pass in 61522
 test-amd64-i386-libvirt   3 host-install(3)  broken in 61316 pass in 61522
 test-amd64-amd64-xl-pvh-intel  3 host-install(3) broken in 61316 pass in 61522
 test-amd64-i386-xl-xsm3 host-install(3)  broken in 61316 pass in 61522
 test-amd64-i386-xl3 host-install(3)  broken in 61316 pass in 61522
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 3 host-install(3) broken 
in 61316 pass in 61522
 test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken in 61316 pass in 
61522
 test-amd64-amd64-xl-credit2   3 host-install(3)  broken in 61316 pass in 61522
 test-amd64-i386-qemut-rhel6hvm-amd 3 host-install(3) broken in 61316 pass in 
61522
 test-amd64-amd64-libvirt-raw  3 host-install(3)  broken in 61316 pass in 61522
 test-amd64-i386-xl-qemuu-win7-amd64 3 host-install(3) broken in 61316 pass in 
61522
 test-amd64-amd64-xl-pvh-amd   3 host-install(3)  broken in 61316 pass in 61522
 test-amd64-i386-freebsd10-i386 3 host-install(3) broken in 61316 pass in 61522
 test-amd64-amd64-libvirt-vhd  3 host-install(3)  broken in 61316 pass in 61522
 test-amd64-i386-libvirt-xsm   3 host-install(3)  broken in 61316 pass in 61522
 test-amd64-i386-libvirt-vhd   3 host-install(3)  broken in 61316 pass in 61522
 test-amd64-i386-xl-qemuu-debianhvm-amd64 3 host-install(3) broken in 61316 
pass in 61522
 test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken in 61316 pass in 
61522
 test-amd64-i386-xl-raw3 host-install(3)  broken in 61316 pass in 61522
 test-amd64-amd64-rumpuserxen-amd64 3 host-install(3) broken in 61316 pass in 
61522
 test-amd64-i386-rumpuserxen-i386 3 host-install(3) broken in 61316 pass in 
61522
 test-amd64-amd64-libvirt  3 host-install(3)  broken in 61316 pass in 61522
 test-amd64-amd64-xl-qemut-winxpsp3 3 host-install(3) broken in 61316 pass in 
61522
 test-amd64-i386-libvirt-raw   3 host-install(3)  broken in 61316 pass in 61522
 test-amd64-amd64-xl-xsm   3 host-install(3)  broken in 61316 pass in 61522
 test-amd64-i386-qemuu-rhel6hvm-intel 3 host-install(3) broken in 61316 pass in 
61522
 test-amd64-i386-freebsd10-amd64 3 host-install(3) broken in 61316 pass in 61522
 test-amd64-i386-xl-qemut-debianhvm-amd64 3 host-install(3) broken in 61316 
pass in 61522
 test-amd64-i386-xl-qemut-win7-amd64 3 host-install(3) broken in 61316 pass in 
61522
 test-amd64-amd64-xl-qcow2 3 host-install(3)  broken in 61316 pass in 61522
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken in 61316 
pass in 61522
 test-amd64-amd64-xl-qemuu-win7-amd64 3 host-install(3) broken in 61316 pass in 
61522
 test-amd64-amd64-xl-multivcpu  3 host-install(3) broken in 61316 pass in 61522
 test-amd64-amd64-i386-pvgrub  3 host-install(3)  broken in 61316 pass in 61522
 test-amd64-amd64-xl-qemut-win7-amd64 3 host-install(3) broken in 61316 pass in 
61522
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken in 
61316 pass in 61522
 test-amd64-i386-libvirt-qcow2  3 host-install(3) broken in 61316 pass in 61522
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 3 host-install(3) broken 
in 61316 pass in 61522
 test-amd64-amd64-amd64-pvgrub  3 host-install(3) broken in 61316 pass in 61522
 test-amd64-amd64-pygrub   3 host-install(3)  broken in 61316 pass in 61522
 test-amd64-amd64-xl-qemut-debianhvm-amd64 3 host-install(3) broken in 61316 
pass in 61522
 test-amd64-amd64-xl-raw   3 host-install(3)  broken in 61316 pass in 61522
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken in 61316 
pass in 61522
 test-amd64-amd64-xl-rtds  3 host-install(3)  broken in 61316 pass in 61522
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 3 host-install(3) broken in 
61316 pass in 61522
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 3 host-install(3) broken in 61316 
pass in 61522
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken in 61316 
pass in 61522
 test-amd64-amd64-xl-qemuu-ovmf-amd64 3 host-install(3) broken in 61316 pass in 
61522
 

Re: [Xen-devel] On distro packaging of stub domains (Re: Notes from Xen BoF at Debconf15)

[Antti Kantee]

On 08/09/15 16:15, Ian Campbell wrote:

On Tue, 2015-09-08 at 15:03 +, Antti Kantee wrote:


For unikernels, the rump kernel project provides Rumprun, which can
provide you with a near-full POSIX'y interface.


I'm not 100% clear: Does rumprun _build_ or _run_ the application? It sound
s like it builds but the name suggests otherwise.


For all practical purposes, Rumprun is an OS, except that you always 
cross-compile for it.  So, I'd say "yes", but it depends on how you want 
to interpret the situation.  We could spend days writing emails back and 
forth, but there's really no substitute for an hour of hands-on 
experimentation.


(nb. the launch tool for launching Rumprun instances is currently called 
rumprun.  It's on my todo list to propose changing the name of the tool 
to e.g. rumprunner or runrump or something which is distinct from the OS 
name, since similarity causes some confusion)



Do these wrappers make a rump kernel build target look just like any other
ross build target? (I've just got to the end and found my answer, which was
yes. I've left this next section in since I think it's a nice summary of
why it matters that the answer is yes)

e.g. I have aarch64-linux-gnu-{gcc,as,ld,ar,etc} which I can use to build
aarch64 binaries on my x86_64 host, including picking up aarch64 libraries
and headers from the correct arch specific patch.

Do these rumprun-provided wrappers provide x86_64-rumpkernel
-{gcc,as,ld,ar,etc} ?


No, like I said and which you discovered later, 
x86_64-rumprun-netbsd-{gcc,as,ld,ar,etc}.  aarch64 would be 
aarch64-rumprun-netbsd-{...}.



Appearing as a regular cross-compilation target is, I think, going to be
important to being able to create rumpkernel based versions of distro
packages.

I think that package maintainers ideally won't want to have to include a
bunch of rumpkernel specific code in their package, they just want to
leverage the existing cross-compilability of their package.


Yes, that is critical.  We bled to achieve that goal.  It looks obvious 
now, but I can assure you it wasn't obvious a year ago.



$ ldd /usr/bin/qemu-system-x86_64  | wc -l
87
$


Heh, that's quite a lot.


If the above didn't explain the grand scheme of things clearly, have a
look at http://wiki.rumpkernel.org/Repo and especially the picture.  If
things are still not clear after that, please point out matters of
confusion and I will try to improve the explanations.


I think that wiki page is clear, but I think it's orthogonal to the issue
with distro packaging of rump kernels.


Sure, but I wanted to get the concepts right.  And they're still not 
right.  We're talking about packaging for *Rumprun*, not rump kernels in 
general.



   However, since a) nobody (else) ships applications as relocatable
static objects b) Rumprun does not support shared libraries, I don't
know how helpful the fact of ABI compatibility is.  IMO, adding shared
library support would be a backwards way to go: increasing runtime
processing and memory requirements to solve a build problem sounds plain
weird.  So, I don't think you can leverage anything existing.


This is an interesting point, since not building a shared library is
already therefore requiring packaging changes which are going to be at
least a little bit rumpkernel specific.

Is it at all possible (even theoretically) to take a shared library (which
is relocatable as required) and to do a compile time static linking pass on
it? i.e. use libfoo.so but still do static linking?


But shared libraries aren't "relocatable", that's the whole point of 
shared libraries! ;) ;)


I guess you could theoretically link shared libs with a different ld, 
and I don't think it would be very different from prelinking shared 
libs, but as Samuel demonstrated, it won't work at least with an 
out-of-the-box ld.


I think it's easier to blame Solaris for the world going bonkers with 
shared libs, bite the bullet, and start adding static linking back where 
it's been ripped out from.  Shared libs make zero sense for unikernels 
since you don't have anyone to share them with, so you're just paying 
extra for PIC for absolutely no return.  (dynamically loadable code is a 
separate issue, if you even want to go there ... I wouldn't)



I don't really have good solutions for the packaging problem.  Building
a "full distro" around rump kernels certainly sounds interesting,


FWIW I don't think we need a full distro, just sufficient build
dependencies for the actual useful things (maybe that converges on to a
full distro though).


By "full distro" I meant "enough to get a majority of the useful 
services going".  Seems like once qemu works, we're 99% there ;)



Debian are (most likely) not going to accept a second copy of the QEMU
source in the archive and likewise they wouldn't want a big source package
which was "qemu + all its build dependencies" or anything like that,
especially when "all its build dependencies" is duplicating the source of
dozens of 

[Xen-devel] vTPM ownership problem

[Zhenyang Feng]

Hello everyone, I need to use vTPM to finish a project but I encounter the
same problem as
http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg03930.html

I followed the steps explained in
https://mhsamsal.wordpress.com/2013/12/05/configuring-virtual-tpm-vtpm-for-xen-4-3-guest-virtual-machines/
.

I'm running Ubuntu 14.04 as Dom0 on Dell. I compiled Xen 4.3.0 from source.
After creating vtpmmgr and vtpm stubdoms, and DomU, I can invoke
tpm_version as well as cat /sys/class/misc/tpm0/device/pcrs from DomU:

However, I cannot take ownership of vTPM and thus I fail to execute the
commands required ownership of vTPM. When I invoke takeownership(I set SRK
password to null) I get the following error:


root@tpm-guest:~# 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


root@tpm-guest:~# tpm_takeownership -z -y -l debug
Tspi_Context_Create success
Tspi_Context_Connect success
Tspi_Context_GetTpmObject success
Tspi_GetPolicyObject success
Tspi_Policy_SetSecret success
Tspi_Context_CreateObject success
Tspi_GetPolicyObject success
Tspi_Policy_SetSecret success
Tspi_TPM_TakeOwnership failed: 0x2004 - layer=tcs, code=0004 (4),
Internal software error
Tspi_Context_CloseObject success
Tspi_Context_FreeMemory success
Tspi_Context_Close success

I have just upgraded to Ubuntu 15.04 as the reply said but get the same
error again. Could you help me handle it? Thank you very much.

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

Re: [Xen-devel] Asus X99-A VT-d problems

[Jan Beulich]

>>> On 08.09.15 at 15:12,  wrote:
> Sorry about that, I'm using gmail and misclicked reply instead of
> reply-all. No Idea how to fix the line wrapping though.
> 
> Any ideas how to enable IOMMU in vanilla kernel? I checked from kernel
> documentation that the parameters are intel_iommu=on and iommu=force and
> they were passed as a boot parameters.

Yes, that's how it ought to work (and how it works for me). I suppose
you checked that your kernel configuration has CONFIG_INTEL_IOMMU=y?
In which case the most likely reason for the missing messages is that
your log level doesn't allow them to go to wherever you collect the log.

Jan


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

Re: [Xen-devel] Asus X99-A VT-d problems

[Valtteri Kiviniemi]

Hi,

I got Xen booting now with VT-d enabled, lot's of errors and the system is
unstable. xl dmesg output:

 Xen 4.6.0-rc
(XEN) Xen version 4.6.0-rc (r...@easyanticheat.net) (gcc (Debian 4.9.2-10)
4.9.2) debug=y Mon Sep  7 20:46:47 EEST 2015
(XEN) Latest ChangeSet: Fri Aug 28 16:01:55 2015 +0100 hg:0b7f5657e0d1-dirty
(XEN) Console output is synchronous.
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: dom0_mem=2048M dom0pvh=0 cpufreq=xen:performance
loglevel=all guest_loglevel=all iommu=verbose,debug sync_console
lapic=debug apic_verbosity=debug apic=debug
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 3 MBR signatures
(XEN)  Found 4 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)   - 0009e800 (usable)
(XEN)  0009e800 - 000a (reserved)
(XEN)  000e - 0010 (reserved)
(XEN)  0010 - b9bec000 (usable)
(XEN)  b9bec000 - ba761000 (reserved)
(XEN)  ba761000 - ba7af000 (ACPI data)
(XEN)  ba7af000 - bc9b3000 (ACPI NVS)
(XEN)  bc9b3000 - bd078000 (reserved)
(XEN)  bd078000 - bd079000 (usable)
(XEN)  bd079000 - bd0ff000 (reserved)
(XEN)  bd0ff000 - bd318000 (usable)
(XEN)  bd318000 - bdff9000 (reserved)
(XEN)  bdff9000 - be00 (usable)
(XEN)  e000 - f000 (reserved)
(XEN)  fed1c000 - fed2 (reserved)
(XEN)  ff00 - 0001 (reserved)
(XEN)  0001 - 00084000 (usable)
(XEN) ACPI: RSDP 000F0540, 0024 (r2 ALASKA)
(XEN) ACPI: XSDT BA770098, 00A4 (r1 ALASKA   A M I   1072009 AMI 10013)
(XEN) ACPI: FACP BA79F6E8, 010C (r5 ALASKA   A M I   1072009 AMI 10013)
(XEN) ACPI: DSDT BA7701D0, 2F515 (r2 ALASKA   A M I   1072009 INTL 20091013)
(XEN) ACPI: FACS BC9AFF80, 0040
(XEN) ACPI: APIC BA79F7F8, 0100 (r3 ALASKA   A M I   1072009 AMI 10013)
(XEN) ACPI: FPDT BA79F8F8, 0044 (r1 ALASKA   A M I   1072009 AMI 10013)
(XEN) ACPI: FIDT BA79F940, 009C (r1 ALASKA   A M I   1072009 AMI 10013)
(XEN) ACPI: MCFG BA79F9E0, 003C (r1 ALASKAA M I  1072009 MSFT   97)
(XEN) ACPI: ASF! BA7AE218, 00A0 (r32 INTEL   HCG1 TFSMF4240)
(XEN) ACPI: UEFI BA79FA78, 0042 (r1 ALASKA   A M I   1072009 0)
(XEN) ACPI: BDAT BA79FAC0, 0030 (r1 ALASKA   A M I 0 INTL 20091013)
(XEN) ACPI: HPET BA79FAF0, 0038 (r1 ALASKA   A M I 1 INTL 20091013)
(XEN) ACPI: MSCT BA79FB28, 0090 (r1 ALASKA   A M I 1 INTL 20091013)
(XEN) ACPI: PMCT BA79FBB8, 0064 (r1 ALASKA   A M I 0 INTL 20091013)
(XEN) ACPI: SLIT BA79FC20, 002D (r1 ALASKA   A M I 1 INTL 20091013)
(XEN) ACPI: SRAT BA79FC50, 0E58 (r3 ALASKA   A M I 1 INTL 20091013)
(XEN) ACPI: WDDT BA7A0AA8, 0040 (r1 ALASKA   A M I 0 INTL 20091013)
(XEN) ACPI: SSDT BA7A0AE8, D647 (r1 ALASKAPmMgt1 INTL 20120913)
(XEN) ACPI: DMAR BA7AE130, 00E4 (r1 ALASKA   A M I 1 INTL 20091013)
(XEN) System RAM: 32669MB (33453740kB)
(XEN) SRAT: PXM 0 -> APIC 0 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 2 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 4 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 6 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 8 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 10 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 1 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 3 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 5 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 7 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 9 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 11 -> Node 0
(XEN) SRAT: Node 0 PXM 0 0-c000
(XEN) SRAT: Node 0 PXM 0 1-84000
(XEN) NUMA: Using 20 for the hash shift.
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000fd8b0
(XEN) DMI 2.7 present.
(XEN) APIC boot state is 'xapic'
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x408
(XEN) ACPI: v5 SLEEP INFO: control[0:0], status[0:0]
(XEN) ACPI: SLEEP INFO: pm1x_cnt[1:404,1:0], pm1x_evt[1:400,1:0]
(XEN) ACPI: 32/64X FACS address mismatch in FADT -
bc9aff80/, using 32
(XEN) ACPI: wakeup_vec[bc9aff8c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee0
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 7:15 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 7:15 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] enabled)
(XEN) Processor #4 7:15 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x06] enabled)
(XEN) Processor #6 7:15 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x08] enabled)
(XEN) Processor #8 7:15 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x0a] enabled)
(XEN) Processor #10 7:15 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
(XEN) 

Re: [Xen-devel] [PATCH] MAINTAINERS: stable backports should be requested on xen-devel

[Ian Campbell]

On Tue, 2015-09-08 at 14:20 +0100, Wei Liu wrote:
> On Tue, Sep 08, 2015 at 12:37:04PM +0100, Ian Campbell wrote:
> > On Sat, 2015-07-25 at 09:25 +0100, Ian Campbell wrote:
> > > As well as CC-ing the correct people. I just saw such a request on
> > > xen-users and thought this was worth clarifying here too.
> > > 
> > > Signed-off-by: Ian Campbell 
> > 
> > Just found this in my folder, do we want to take it for 4.6?
> > 
> 
> Fine by me of course.

AIUI the branching process involves tweaking this text to refer to the
specific maintainers of the given stable branch.

IOW I think the "backport" of this might be a little more involved, but
hopefully fairly obvious -- Ian, do you think you can deal with it?

$ git diff origin/staging-4.5 origin/staging -- MAINTAINERS | filterdiff -#1
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -49,14 +49,9 @@ for inclusion in xen-unstable.
 Please see http://wiki.xen.org/wiki/Xen_Maintenance_Releases for more
 information.
 
-Remember to copy the stable branch maintainer. The maintainer for this
-branch is:
-
-   Jan Beulich 
-
-Tools backport requests should also be copied to:
-
-   Ian Jackson 
+Remember to copy the appropriate stable branch maintainer who will be
+listed in this section of the MAINTAINERS file in the appropriate
+branch.
 
Unstable Subsystem Maintainers
==
> 
> > > ---
> > >  MAINTAINERS | 7 ---
> > >  1 file changed, 4 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index a4e64ea..156a95f 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -49,9 +49,10 @@ for inclusion in xen-unstable.
> > >  Please see http://wiki.xen.org/wiki/Xen_Maintenance_Releases for
> > > more
> > >  information.
> > >  
> > > -Remember to copy the appropriate stable branch maintainer who will
> > > be
> > > -listed in this section of the MAINTAINERS file in the appropriate
> > > -branch.
> > > +Backport requests should be made on the 
> > > xen-de...@lists.xenproject.org
> > > +list. Remember to copy the appropriate stable branch maintainer who
> > > +will be listed in this section of the MAINTAINERS file in the
> > > +appropriate branch.
> > >  
> > >   Unstable Subsystem Maintainers
> > >   ==

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

[Xen-devel] [PATCH v2 1/6] xen/pt: Update comments with proper function name.

[Konrad Rzeszutek Wilk]

It has changed but the comments still refer to the old names.

Reviewed-by: Stefano Stabellini 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 hw/xen/xen_pt.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index ed5fcae..706e3d9 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -378,7 +378,7 @@ static void xen_pt_pci_write_config(PCIDevice *d, uint32_t 
addr,
 }
 }
 
-/* need to shift back before passing them to xen_host_pci_device */
+/* need to shift back before passing them to xen_host_pci_set_block. */
 val >>= (addr & 3) << 3;
 
 memory_region_transaction_commit();
@@ -406,7 +406,7 @@ out:
 (uint8_t *) + index, len);
 
 if (rc < 0) {
-XEN_PT_ERR(d, "pci_write_block failed. return value: %d.\n", rc);
+XEN_PT_ERR(d, "xen_host_pci_set_block failed. return value: 
%d.\n", rc);
 }
 }
 }
-- 
2.1.0


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-debianhvm-amd64 19 guest-start/debianhvm.repeat fail 
REGR. vs. 61059

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start.2fail blocked in 61059
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail blocked in 61059
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
like 61059
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail like 61059
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 61059
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 61059

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 11 guest-start  fail  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-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-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-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail never 
pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail never pass
 test-amd64-amd64-libvirt-xsm 12 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 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-raw  11 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-amd64-libvirt-raw 11 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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail 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-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-i386-libvirt-qcow2 11 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-i386-xl-qemut-win7-amd64 17 guest-stop  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-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-libvirt-qcow2 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

version targeted for testing:
 xen  a7b39c8bd6cba3fe1c8012987b9e28bdbac7e92d
baseline version:
 xen  801ab48e5556cb54f67e3cb57f077f47e8663ced

Last test of basis61059  2015-08-30 15:26:08 Z8 days
Failing since 61248  2015-09-01 10:13:44 Z7 days3 attempts
Testing same since61521  2015-09-07 11:46:37 Z1 days1 attempts


People who touched revisions under test:
  Daniel De Graaf 
  David Scott 
  David Scott 
  David Scott 
  Doug Goldstein 

Re: [Xen-devel] [PATCH OSSTEST v2 5/6] ts-openstack-tempest: Run Tempest to check OpenStack

[Ian Campbell]

On Thu, 2015-08-06 at 18:03 +0100, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD 
> ---
>  sg-run-job   |  1 +
>  ts-openstack-tempest | 35 +++
>  2 files changed, 36 insertions(+)
>  create mode 100755 ts-openstack-tempest
> 
> diff --git a/sg-run-job b/sg-run-job
> index 5320d62..0b2184b 100755
> --- a/sg-run-job
> +++ b/sg-run-job
> @@ -363,6 +363,7 @@ proc run-job/test-rumpuserxen {} {
>  proc need-hosts/test-devstack {} { return host }
>  proc run-job/test-devstack {} {
>run-ts . = ts-openstack-devstack
> +  run-ts . = ts-openstack-tempest

As before I think you need "host"
>  }
>  
>  #-- builds --
> diff --git a/ts-openstack-tempest b/ts-openstack-tempest
> new file mode 100755
> index 000..2bc07c3
> --- /dev/null
> +++ b/ts-openstack-tempest
> @@ -0,0 +1,35 @@
> +#!/usr/bin/perl
> +# This is part of "osstest", an automated testing framework for Xen.
> +# Copyright (C) 2015 Citrix Inc.
> +#
> +# This program is free software: you can redistribute it and/or modify
> +# it under the terms of the GNU Affero General Public License as
> published by
> +# the Free Software Foundation, either version 3 of the License, or
> +# (at your option) any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +# GNU Affero General Public License for more details.
> +#
> +# You should have received a copy of the GNU Affero General Public
> License
> +# along with this program.  If not, see .
> +
> +use strict qw(vars);
> +use Osstest;
> +use Osstest::TestSupport;
> +use Osstest::BuildSupport;
> +
> +tsreadconfig();
> +our ($ho,$gho) = ts_get_host_guest(@ARGV);

And here like before just selecthost since you don't use $gho

> +builddirsprops();
> +
> +sub tempest() {
> +  # The regex is the default one + avoid the two tests know to not work
> +  # which are two variations of test_volume_boot_pattern.
> +  target_cmd($ho, < +$builddir/tempest/run_tempest.sh

Is $builddir here inherited from the previous script? I'm not sure how that
works?


>  -V -- --concurrency=2
> '(?!.*\\[.*\\bslow\\b.*\\]|.*test_volume_boot_pattern)(^tempest\\.(api|sc
> enario|thirdparty))'

I think think ought to at least be in a variable with a comment explaining
why each one is omitted.

It could go into a runvar, but I'm not too sure about that.


> +END
> +}
> +
> +tempest();

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

Re: [Xen-devel] [PATCH] MAINTAINERS: stable backports should be requested on xen-devel

[Jan Beulich]

>>> On 08.09.15 at 13:37,  wrote:
> On Sat, 2015-07-25 at 09:25 +0100, Ian Campbell wrote:
>> As well as CC-ing the correct people. I just saw such a request on
>> xen-users and thought this was worth clarifying here too.
>> 
>> Signed-off-by: Ian Campbell 
> 
> Just found this in my folder, do we want to take it for 4.6?

Yes, I think this is worthwhile to clarify.

Jan

>> ---
>>  MAINTAINERS | 7 ---
>>  1 file changed, 4 insertions(+), 3 deletions(-)
>> 
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index a4e64ea..156a95f 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -49,9 +49,10 @@ for inclusion in xen-unstable.
>>  Please see http://wiki.xen.org/wiki/Xen_Maintenance_Releases for more
>>  information.
>>  
>> -Remember to copy the appropriate stable branch maintainer who will be
>> -listed in this section of the MAINTAINERS file in the appropriate
>> -branch.
>> +Backport requests should be made on the xen-de...@lists.xenproject.org 
>> +list. Remember to copy the appropriate stable branch maintainer who
>> +will be listed in this section of the MAINTAINERS file in the
>> +appropriate branch.
>>  
>>  Unstable Subsystem Maintainers
>>  ==




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

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

[Ian Campbell]

On Mon, 2015-09-07 at 15:25 +0100, Stefano Stabellini wrote:
> Free the memory used for the compressed kernel and update the relative
> mod->start and mod->size parameters with the uncompressed ones.
> 
> Signed-off-by: Stefano Stabellini 
> Reviewed-by: Julien Grall 
> CC: ian.campb...@citrix.com
> 
> ---
> 
> Changes in v5:
> - code style
> 
> Changes in v4:
> - return uint32_t from output_length
> - __init kernel_decompress
> - code style
> - add comment
> - if kernel_decompress fails with error, return
> 
> Changes in v3:
> - better error checks in kernel_decompress
> - free unneeded pages between output_size and kernel_order_out
> - alloc pages from domheap
> 
> Changes in v2:
> - use gzip_check
> - avoid useless casts
> - free original kernel image and update the mod with the new address and
> size
> - remove changes to common Makefile
> - remove CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> ---
>  xen/arch/arm/kernel.c   |   75
> +++
>  xen/arch/arm/setup.c|2 +-
>  xen/include/asm-arm/setup.h |2 ++
>  3 files changed, 78 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
> index f641b12..baa5717 100644
> --- a/xen/arch/arm/kernel.c
> +++ b/xen/arch/arm/kernel.c
> @@ -13,6 +13,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #include "kernel.h"
>  
> @@ -257,6 +259,63 @@ static int kernel_uimage_probe(struct kernel_info
> *info,
>  return 0;
>  }
>  
> +static __init uint32_t output_length(char *image, unsigned long
> image_len)
> +{
> +return *(uint32_t *)[image_len - 4];
> +}
> +
> +static __init int kernel_decompress(struct kernel_info *info,
> + paddr_t *addr, paddr_t *size)
> +{
> +char *output, *input, *end;
> +char magic[2];
> +int rc;
> +unsigned kernel_order_out;
> +paddr_t output_size;
> +struct page_info *pages;
> +
> +if ( *size < 2 )
> +return -EINVAL;
> +
> +copy_from_paddr(magic, *addr, sizeof(magic));
> +
> +/* only gzip is supported */
> +if ( !gzip_check(magic, *size) )
> +return -EINVAL;
> +
> +input = ioremap_cache(*addr, *size);
> +if ( input == NULL )
> +return -EFAULT;
> +
> +output_size = output_length(input, *size);
> +kernel_order_out = get_order_from_bytes(output_size);
> +pages = alloc_domheap_pages(NULL, kernel_order_out, 0);
> +if ( pages == NULL )
> +{
> +iounmap(input);
> +return -ENOMEM;
> +}
> +output = page_to_virt(pages);
> +
> +rc = perform_gunzip(output, input, *size);
> +clean_dcache_va_range(output, output_size);
> +iounmap(input);
> +
> +*addr = virt_to_maddr(output);

I don't think virt_to_maddr is strictly speaking valid (at the arch
interface level, our actual implementation may happen to cope) for domheap
pages, it's only valid for things which are in the linear 1:1 map (~=
xenheap).

I think you need page_to_maddr(pages) instead.


> +*size = output_size;
> +
> +end = output + (1 << (kernel_order_out + PAGE_SHIFT));
> +/* 
> + * Need to free pages after output_size here because they won't be
> + * freed by discard_initial_modules
> + */
> +output += (output_size + PAGE_SIZE - 1) & PAGE_MASK;
> +for ( ; output < end; output += PAGE_SIZE )
> +free_domheap_page(virt_to_page(output));

And here again I don't think you can use virt_to_page.

> +
> +return 0;
> +}
> +
>  #ifdef CONFIG_ARM_64
>  /*
>   * Check if the image is a 64-bit Image.
> @@ -463,6 +522,22 @@ int kernel_probe(struct kernel_info *info)
>  printk("Loading ramdisk from boot module @ %"PRIpaddr"\n",
> info->initrd_bootmodule->start);
>  
> +/* if it is a gzip'ed image, 32bit or 64bit, uncompress it */
> +rc = kernel_decompress(info, , );
> +if (rc < 0 && rc != -EINVAL)

IMHO kernel_decompress should return success when the decompress is a nop
(as represented by EINVAL here) and an error only when the thing needs to
be decompressed but cannot be.

That would mean putting the free of the original kernel and the updates of
mod->* into kernel_decompress. But I think that also makes more sense
because it confines the "ol' switcheroo" to the one place instead of mostly
up there and then the tail end cleanup down here. i.e. you call
kernel_decompress with everything in a consistent and valid state and
return with everything also in a (possibly different) consistent and valid
state.

I wouldn't have bothered commenting on this if I weren't already commenting
on the above, since it's not a huge deal if you think this is the wrong
direction.

Ian.

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

[Xen-devel] [PATCHv1] x86/xen/p2m: hint at the last populated P2M entry

[David Vrabel]

With commit 633d6f17cd91ad5bf2370265946f716e42d388c6 (x86/xen: prepare
p2m list for memory hotplug) the P2M may be sized to accomdate a much
larger amount of memory than the domain currently has.

When saving a domain, the toolstack must scan all the P2M looking for
populated pages.  This results in a performance regression due to the
unnecessary scanning.

Instead of reporting (via shared_info) the maximum possible size of
the P2M, hint at the last PFN which might be populated.  This hint is
increased as new leaves are added to the P2M (in the expectation that
they will be used for populated entries).

Signed-off-by: David Vrabel 
---
 arch/x86/xen/p2m.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 8b7f18e..b228bc9 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -108,6 +108,15 @@ static unsigned long *p2m_identity;
 static pte_t *p2m_missing_pte;
 static pte_t *p2m_identity_pte;
 
+/*
+ * Hint at last populated PFN.
+ *
+ * Used to set HYPERVISOR_shared_info->arch.max_pfn so the toolstack
+ * can avoid scanning the whole P2M (which may be sized to account for
+ * hotplugged memory).
+ */
+static unsigned long xen_p2m_last_pfn;
+
 static inline unsigned p2m_top_index(unsigned long pfn)
 {
BUG_ON(pfn >= MAX_P2M_PFN);
@@ -262,7 +271,7 @@ void xen_setup_mfn_list_list(void)
 
HYPERVISOR_shared_info->arch.pfn_to_mfn_frame_list_list =
virt_to_mfn(p2m_top_mfn);
-   HYPERVISOR_shared_info->arch.max_pfn = xen_max_p2m_pfn;
+   HYPERVISOR_shared_info->arch.max_pfn = xen_p2m_last_pfn;
 }
 
 /* Set up p2m_top to point to the domain-builder provided p2m pages */
@@ -394,6 +403,8 @@ void __init xen_vmalloc_p2m_tree(void)
static struct vm_struct vm;
unsigned long p2m_limit;
 
+   xen_p2m_last_pfn = xen_max_p2m_pfn;
+
p2m_limit = (phys_addr_t)P2M_LIMIT * 1024 * 1024 * 1024 / PAGE_SIZE;
vm.flags = VM_ALLOC;
vm.size = ALIGN(sizeof(unsigned long) * max(xen_max_p2m_pfn, p2m_limit),
@@ -590,6 +601,12 @@ static bool alloc_p2m(unsigned long pfn)
free_p2m_page(p2m);
}
 
+   /* Expanded the p2m? */
+   if (pfn >= xen_p2m_last_pfn) {
+   xen_p2m_last_pfn = pfn;
+   HYPERVISOR_shared_info->arch.max_pfn = xen_p2m_last_pfn;
+   }
+
return true;
 }
 
-- 
2.1.4


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

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

[Jan Beulich]

>>> On 08.09.15 at 15:35,  wrote:
> On Mon, 2015-09-07 at 15:25 +0100, Stefano Stabellini wrote:
>> +static __init int kernel_decompress(struct kernel_info *info,
>> + paddr_t *addr, paddr_t *size)
>> +{
>> +char *output, *input, *end;
>> +char magic[2];
>> +int rc;
>> +unsigned kernel_order_out;
>> +paddr_t output_size;
>> +struct page_info *pages;
>> +
>> +if ( *size < 2 )
>> +return -EINVAL;
>> +
>> +copy_from_paddr(magic, *addr, sizeof(magic));
>> +
>> +/* only gzip is supported */
>> +if ( !gzip_check(magic, *size) )
>> +return -EINVAL;
>> +
>> +input = ioremap_cache(*addr, *size);
>> +if ( input == NULL )
>> +return -EFAULT;
>> +
>> +output_size = output_length(input, *size);
>> +kernel_order_out = get_order_from_bytes(output_size);
>> +pages = alloc_domheap_pages(NULL, kernel_order_out, 0);
>> +if ( pages == NULL )
>> +{
>> +iounmap(input);
>> +return -ENOMEM;
>> +}
>> +output = page_to_virt(pages);
>> +
>> +rc = perform_gunzip(output, input, *size);
>> +clean_dcache_va_range(output, output_size);
>> +iounmap(input);
>> +
>> +*addr = virt_to_maddr(output);
> 
> I don't think virt_to_maddr is strictly speaking valid (at the arch
> interface level, our actual implementation may happen to cope) for domheap
> pages, it's only valid for things which are in the linear 1:1 map (~=
> xenheap).
> 
> I think you need page_to_maddr(pages) instead.

Indeed, but then the page_to_virt() a few lines up isn't valid either.

Jan


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

[Xen-devel] [PATCH v2 03/10] xen/pt: Check if reg->init function sets the 'data' past the reg->size

[Konrad Rzeszutek Wilk]

It should never happen, but in case it does (an developer adds
a new register and the 'init_val' expands past the register
size) we want to report. The code will only write up to
reg->size so there is no runtime danger of the register spilling
across other ones - however to catch this sort of thing
we still return an error.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 hw/xen/xen_pt_config_init.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index aff51b8..55be4ee 100644
--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -1912,9 +1912,15 @@ static int xen_pt_config_reg_init(XenPCIPassthroughState 
*s,
 } else
 val = data;
 
+if (val & ~size_mask) {
+XEN_PT_ERR(>dev,"Offset 0x%04x:0x%04x expands past register 
size(%d)!\n",
+   offset, val, reg->size);
+g_free(reg_entry);
+return -ENXIO;
+}
 /* This could be just pci_set_long as we don't modify the bits
- * past reg->size, but in case this routine is run in parallel
- * we do not want to over-write other registers. */
+ * past reg->size, but in case this routine is run in parallel or the
+ * init value is larger, we do not want to over-write registers. */
 switch (reg->size) {
 case 1: pci_set_byte(s->dev.config + offset, (uint8_t)val);
 break;
-- 
2.1.0


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

[Xen-devel] [PATCH v2 05/10] xen/pt: Log xen_host_pci_get in two init functions

[Konrad Rzeszutek Wilk]

To help with troubleshooting in the field.

Acked-by: Stefano Stabellini 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 hw/xen/xen_pt_config_init.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index 727f814..67ecc71 100644
--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -1791,6 +1791,8 @@ static int xen_pt_ptr_reg_init(XenPCIPassthroughState *s,
 rc = xen_host_pci_get_byte(>real_device,
reg_field + PCI_CAP_LIST_ID, _id);
 if (rc) {
+XEN_PT_ERR(>dev, "Failed to read capability @0x%x 
(rc:%d)\n",
+   reg_field + PCI_CAP_LIST_ID, rc);
 return rc;
 }
 if (xen_pt_emu_reg_grps[i].grp_id == cap_id) {
@@ -1990,6 +1992,9 @@ int xen_pt_config_init(XenPCIPassthroughState *s)
   reg_grp_offset,
   _grp_entry->size);
 if (rc < 0) {
+XEN_PT_LOG(>dev, "Failed to initialize %d/%ld, type=0x%x, 
rc:%d\n",
+   i, ARRAY_SIZE(xen_pt_emu_reg_grps),
+   xen_pt_emu_reg_grps[i].grp_type, rc);
 xen_pt_config_delete(s);
 return rc;
 }
@@ -2004,6 +2009,10 @@ int xen_pt_config_init(XenPCIPassthroughState *s)
 /* initialize capability register */
 rc = xen_pt_config_reg_init(s, reg_grp_entry, regs);
 if (rc < 0) {
+XEN_PT_LOG(>dev, "Failed to initialize %d/%ld reg 
0x%x in grp_type=0x%x (%d/%ld), rc=%d\n",
+   j, 
ARRAY_SIZE(xen_pt_emu_reg_grps[i].emu_regs),
+   regs->offset, 
xen_pt_emu_reg_grps[i].grp_type,
+   i, ARRAY_SIZE(xen_pt_emu_reg_grps), rc);
 xen_pt_config_delete(s);
 return rc;
 }
-- 
2.1.0


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

[Xen-devel] [PATCH v2 04/10] xen/pt: Remove XenPTReg->data field.

[Konrad Rzeszutek Wilk]

We do not want to have two entries to cache the guest configuration
registers: XenPTReg->data and dev.config. Instead we want to use
only the dev.config.

To do without much complications we rip out the ->data field
and replace it with an pointer to the dev.config. This way we
have the type-checking (uint8_t, uint16_t, etc) and as well
and pre-computed location.

Alternatively we could compute the offset in dev.config by
using the XenPTRRegInfo and XenPTRegGroup every time but
this way we have the pre-computed values.

This change also exposes some mis-use:
 - In 'xen_pt_status_reg_init' we used u32 for the Capabilities Pointer
   register, but said register is an an u16.
 - In 'xen_pt_msgdata_reg_write' we used u32 but should have only use u16.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 hw/xen/xen_pt.h |  6 +++-
 hw/xen/xen_pt_config_init.c | 73 +++--
 2 files changed, 49 insertions(+), 30 deletions(-)

diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
index 09358b1..4bf9e80 100644
--- a/hw/xen/xen_pt.h
+++ b/hw/xen/xen_pt.h
@@ -134,7 +134,11 @@ struct XenPTRegInfo {
 struct XenPTReg {
 QLIST_ENTRY(XenPTReg) entries;
 XenPTRegInfo *reg;
-uint32_t data; /* emulated value */
+union {
+uint8_t *byte;
+uint16_t *half_word;
+uint32_t *word;
+} ptr; /* pointer to dev.config. */
 };
 
 typedef const struct XenPTRegGroupInfo XenPTRegGroupInfo;
diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index 55be4ee..727f814 100644
--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -128,10 +128,11 @@ static int xen_pt_byte_reg_read(XenPCIPassthroughState 
*s, XenPTReg *cfg_entry,
 {
 XenPTRegInfo *reg = cfg_entry->reg;
 uint8_t valid_emu_mask = 0;
+uint8_t *data = cfg_entry->ptr.byte;
 
 /* emulate byte register */
 valid_emu_mask = reg->emu_mask & valid_mask;
-*value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+*value = XEN_PT_MERGE_VALUE(*value, *data, ~valid_emu_mask);
 
 return 0;
 }
@@ -140,10 +141,11 @@ static int xen_pt_word_reg_read(XenPCIPassthroughState 
*s, XenPTReg *cfg_entry,
 {
 XenPTRegInfo *reg = cfg_entry->reg;
 uint16_t valid_emu_mask = 0;
+uint16_t *data = cfg_entry->ptr.half_word;
 
 /* emulate word register */
 valid_emu_mask = reg->emu_mask & valid_mask;
-*value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+*value = XEN_PT_MERGE_VALUE(*value, *data, ~valid_emu_mask);
 
 return 0;
 }
@@ -152,10 +154,11 @@ static int xen_pt_long_reg_read(XenPCIPassthroughState 
*s, XenPTReg *cfg_entry,
 {
 XenPTRegInfo *reg = cfg_entry->reg;
 uint32_t valid_emu_mask = 0;
+uint32_t *data = cfg_entry->ptr.word;
 
 /* emulate long register */
 valid_emu_mask = reg->emu_mask & valid_mask;
-*value = XEN_PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+*value = XEN_PT_MERGE_VALUE(*value, *data, ~valid_emu_mask);
 
 return 0;
 }
@@ -169,10 +172,11 @@ static int xen_pt_byte_reg_write(XenPCIPassthroughState 
*s, XenPTReg *cfg_entry,
 XenPTRegInfo *reg = cfg_entry->reg;
 uint8_t writable_mask = 0;
 uint8_t throughable_mask = get_throughable_mask(s, reg, valid_mask);
+uint8_t *data = cfg_entry->ptr.byte;
 
 /* modify emulate register */
 writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
-cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+*data = XEN_PT_MERGE_VALUE(*val, *data, writable_mask);
 
 /* create value for writing to I/O device register */
 *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
@@ -186,10 +190,11 @@ static int xen_pt_word_reg_write(XenPCIPassthroughState 
*s, XenPTReg *cfg_entry,
 XenPTRegInfo *reg = cfg_entry->reg;
 uint16_t writable_mask = 0;
 uint16_t throughable_mask = get_throughable_mask(s, reg, valid_mask);
+uint16_t *data = cfg_entry->ptr.half_word;
 
 /* modify emulate register */
 writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
-cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+*data = XEN_PT_MERGE_VALUE(*val, *data, writable_mask);
 
 /* create value for writing to I/O device register */
 *val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
@@ -203,10 +208,11 @@ static int xen_pt_long_reg_write(XenPCIPassthroughState 
*s, XenPTReg *cfg_entry,
 XenPTRegInfo *reg = cfg_entry->reg;
 uint32_t writable_mask = 0;
 uint32_t throughable_mask = get_throughable_mask(s, reg, valid_mask);
+uint32_t *data = cfg_entry->ptr.word;
 
 /* modify emulate register */
 writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
-cfg_entry->data = XEN_PT_MERGE_VALUE(*val, cfg_entry->data, writable_mask);
+*data = XEN_PT_MERGE_VALUE(*val, *data, writable_mask);
 
 /* create value for writing to I/O device register 

[Xen-devel] [PATCH v2 01/10] xen/pt: Use xen_host_pci_get_[byte|word] instead of dev.config

[Konrad Rzeszutek Wilk]

During init time we treat the dev.config area as a cache
of the host view. However during execution time we treat it
as guest view (by the generic PCI API). We need to sync Xen's
code to the generic PCI API view. This is the first step
by replacing all of the code that uses dev.config or
pci_get_[byte|word] to get host value to actually use the
xen_host_pci_get_[byte|word] functions.

Interestingly in 'xen_pt_ptr_reg_init' we also needed to swap
reg_field from uint32_t to uint8_t - since the access is only
for one byte not four bytes. We can split this as a seperate
patch however we would have to use a cast to thwart compiler
warnings in the meantime.

We also truncated 'flags' to 'flag' to make the code fit within
the 80 characters.

Reviewed-by: Stefano Stabellini 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 hw/xen/xen_pt.c | 24 +++---
 hw/xen/xen_pt_config_init.c | 77 +++--
 2 files changed, 73 insertions(+), 28 deletions(-)

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index ea1ceda..7575311 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -689,7 +689,7 @@ static int xen_pt_initfn(PCIDevice *d)
 {
 XenPCIPassthroughState *s = XEN_PT_DEVICE(d);
 int rc = 0;
-uint8_t machine_irq = 0;
+uint8_t machine_irq = 0, scratch;
 uint16_t cmd = 0;
 int pirq = XEN_PT_UNASSIGNED_PIRQ;
 
@@ -735,7 +735,12 @@ static int xen_pt_initfn(PCIDevice *d)
 }
 
 /* Bind interrupt */
-if (!s->dev.config[PCI_INTERRUPT_PIN]) {
+rc = xen_host_pci_get_byte(>real_device, PCI_INTERRUPT_PIN, );
+if (rc) {
+XEN_PT_ERR(d, "Failed to read PCI_INTERRUPT_PIN! (rc:%d)\n", rc);
+scratch = 0;
+}
+if (!scratch) {
 XEN_PT_LOG(d, "no pin interrupt\n");
 goto out;
 }
@@ -785,8 +790,19 @@ static int xen_pt_initfn(PCIDevice *d)
 
 out:
 if (cmd) {
-xen_host_pci_set_word(>real_device, PCI_COMMAND,
-  pci_get_word(d->config + PCI_COMMAND) | cmd);
+uint16_t val;
+
+rc = xen_host_pci_get_word(>real_device, PCI_COMMAND, );
+if (rc) {
+XEN_PT_ERR(d, "Failed to read PCI_COMMAND! (rc: %d)\n", rc);
+} else {
+val |= cmd;
+rc = xen_host_pci_set_word(>real_device, PCI_COMMAND, val);
+if (rc) {
+XEN_PT_ERR(d, "Failed to write PCI_COMMAND val=0x%x!(rc: 
%d)\n",
+   val, rc);
+}
+}
 }
 
 memory_listener_register(>memory_listener, >dev.bus_master_as);
diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index 21d4938..e34f9f8 100644
--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -800,15 +800,21 @@ static XenPTRegInfo xen_pt_emu_reg_vendor[] = {
 static inline uint8_t get_capability_version(XenPCIPassthroughState *s,
  uint32_t offset)
 {
-uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
-return flags & PCI_EXP_FLAGS_VERS;
+uint8_t flag;
+if (xen_host_pci_get_byte(>real_device, offset + PCI_EXP_FLAGS, )) 
{
+return 0;
+}
+return flag & PCI_EXP_FLAGS_VERS;
 }
 
 static inline uint8_t get_device_type(XenPCIPassthroughState *s,
   uint32_t offset)
 {
-uint8_t flags = pci_get_byte(s->dev.config + offset + PCI_EXP_FLAGS);
-return (flags & PCI_EXP_FLAGS_TYPE) >> 4;
+uint8_t flag;
+if (xen_host_pci_get_byte(>real_device, offset + PCI_EXP_FLAGS, )) 
{
+return 0;
+}
+return (flag & PCI_EXP_FLAGS_TYPE) >> 4;
 }
 
 /* initialize Link Control register */
@@ -857,8 +863,14 @@ static int 
xen_pt_linkctrl2_reg_init(XenPCIPassthroughState *s,
 reg_field = XEN_PT_INVALID_REG;
 } else {
 /* set Supported Link Speed */
-uint8_t lnkcap = pci_get_byte(s->dev.config + real_offset - reg->offset
-  + PCI_EXP_LNKCAP);
+uint8_t lnkcap;
+int rc;
+rc = xen_host_pci_get_byte(>real_device,
+   real_offset - reg->offset + PCI_EXP_LNKCAP,
+   );
+if (rc) {
+return rc;
+}
 reg_field |= PCI_EXP_LNKCAP_SLS & lnkcap;
 }
 
@@ -1039,13 +1051,15 @@ static int 
xen_pt_msgctrl_reg_init(XenPCIPassthroughState *s,
XenPTRegInfo *reg, uint32_t real_offset,
uint32_t *data)
 {
-PCIDevice *d = >dev;
 XenPTMSI *msi = s->msi;
-uint16_t reg_field = 0;
+uint16_t reg_field;
+int rc;
 
 /* use I/O device register's value as initial value */
-reg_field = pci_get_word(d->config + real_offset);
-
+rc = xen_host_pci_get_word(>real_device, real_offset, _field);
+if (rc) {
+return rc;
+}
 if (reg_field & 

[Xen-devel] [PATCH v2 08/10] xen/pt: Move bulk of xen_pt_unregister_device in its own routine.

[Konrad Rzeszutek Wilk]

This way we can call it if we fail during init.

This code movement introduces no changes.

Acked-by: Stefano Stabellini 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 hw/xen/xen_pt.c | 115 +---
 1 file changed, 60 insertions(+), 55 deletions(-)

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index c80b755..5a49a86 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -683,6 +683,65 @@ static const MemoryListener xen_pt_io_listener = {
 .priority = 10,
 };
 
+/* destroy. */
+static void xen_pt_destroy(PCIDevice *d) {
+
+XenPCIPassthroughState *s = XEN_PT_DEVICE(d);
+uint8_t machine_irq = s->machine_irq;
+uint8_t intx;
+int rc;
+
+if (machine_irq && !xen_host_pci_device_closed(>real_device)) {
+intx = xen_pt_pci_intx(s);
+rc = xc_domain_unbind_pt_irq(xen_xc, xen_domid, machine_irq,
+ PT_IRQ_TYPE_PCI,
+ pci_bus_num(d->bus),
+ PCI_SLOT(s->dev.devfn),
+ intx,
+ 0 /* isa_irq */);
+if (rc < 0) {
+XEN_PT_ERR(d, "unbinding of interrupt INT%c failed."
+   " (machine irq: %i, err: %d)"
+   " But bravely continuing on..\n",
+   'a' + intx, machine_irq, errno);
+}
+}
+
+/* N.B. xen_pt_config_delete takes care of freeing them. */
+if (s->msi) {
+xen_pt_msi_disable(s);
+}
+if (s->msix) {
+xen_pt_msix_disable(s);
+}
+
+if (machine_irq) {
+xen_pt_mapped_machine_irq[machine_irq]--;
+
+if (xen_pt_mapped_machine_irq[machine_irq] == 0) {
+rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq);
+
+if (rc < 0) {
+XEN_PT_ERR(d, "unmapping of interrupt %i failed. (err: %d)"
+   " But bravely continuing on..\n",
+   machine_irq, errno);
+}
+}
+s->machine_irq = 0;
+}
+
+/* delete all emulated config registers */
+xen_pt_config_delete(s);
+
+if (s->listener_set) {
+memory_listener_unregister(>memory_listener);
+memory_listener_unregister(>io_listener);
+s->listener_set = false;
+}
+if (!xen_host_pci_device_closed(>real_device)) {
+xen_host_pci_device_put(>real_device);
+}
+}
 /* init */
 
 static int xen_pt_initfn(PCIDevice *d)
@@ -817,61 +876,7 @@ out:
 
 static void xen_pt_unregister_device(PCIDevice *d)
 {
-XenPCIPassthroughState *s = XEN_PT_DEVICE(d);
-uint8_t machine_irq = s->machine_irq;
-uint8_t intx;
-int rc;
-
-if (machine_irq && !xen_host_pci_device_closed(>real_device)) {
-intx = xen_pt_pci_intx(s);
-rc = xc_domain_unbind_pt_irq(xen_xc, xen_domid, machine_irq,
- PT_IRQ_TYPE_PCI,
- pci_bus_num(d->bus),
- PCI_SLOT(s->dev.devfn),
- intx,
- 0 /* isa_irq */);
-if (rc < 0) {
-XEN_PT_ERR(d, "unbinding of interrupt INT%c failed."
-   " (machine irq: %i, err: %d)"
-   " But bravely continuing on..\n",
-   'a' + intx, machine_irq, errno);
-}
-}
-
-/* N.B. xen_pt_config_delete takes care of freeing them. */
-if (s->msi) {
-xen_pt_msi_disable(s);
-}
-if (s->msix) {
-xen_pt_msix_disable(s);
-}
-
-if (machine_irq) {
-xen_pt_mapped_machine_irq[machine_irq]--;
-
-if (xen_pt_mapped_machine_irq[machine_irq] == 0) {
-rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq);
-
-if (rc < 0) {
-XEN_PT_ERR(d, "unmapping of interrupt %i failed. (err: %d)"
-   " But bravely continuing on..\n",
-   machine_irq, errno);
-}
-}
-s->machine_irq = 0;
-}
-
-/* delete all emulated config registers */
-xen_pt_config_delete(s);
-
-if (s->listener_set) {
-memory_listener_unregister(>memory_listener);
-memory_listener_unregister(>io_listener);
-s->listener_set = false;
-}
-if (!xen_host_pci_device_closed(>real_device)) {
-xen_host_pci_device_put(>real_device);
-}
+xen_pt_destroy(d);
 }
 
 static Property xen_pci_passthrough_properties[] = {
-- 
2.1.0


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

Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API

[Ian Campbell]

On Mon, 2015-08-10 at 18:35 +0800, Chunyan Liu wrote:

Sorry for the delay, between 4.6 freeze crunch, conference and vacation
I've been a bit swamped.

I'm just going to comment on the APIs (mainly public libxl.h and .idl) in
this pass.

> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 5f9047c..05b6331 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -123,6 +123,23 @@
>  #define LIBXL_HAVE_DOMAIN_NODEAFFINITY 1
>  
>  /*
> + * LIBXL_HAVE_PVUSB indicates the functions for doing hot-plug of

And cold-plug, no?

> + * USB devices through pvusb.
> + *
> + * With this functionality, one can add/remove USB controllers to/from
> + * guest, and attach/detach USB devices to/from USB controllers. To add
> + * USB controllers and USB devices, one can either adding USB controllers
> + * first and then attaching USB devices to some USB controller, or adding
> + * USB devices to guest directly, it will automatically create a USB
> + * controller for USB devices to attach. To remove USB controllers or USB
> + * devices, one can either remove USB devices under USB controller one by
> + * one and then remove USB controller, or remove USB controller directly,
> + * it will remove all USB devices under it automatically.

I think this API documentation belongs alongside the API declarations (i.e
the prototypes) rather than hidden away next to the feature flag.

> + *
> + */
> +#define LIBXL_HAVE_PVUSB 1
> +
> +/*
>   * LIBXL_HAVE_BUILDINFO_HVM_VENDOR_DEVICE indicates that the
>   * libxl_vendor_device field is present in the hvm sections of
>   * libxl_domain_build_info. This field tells libxl which
> @@ -1389,6 +1406,54 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t
> domid, libxl_device_disk *disk,
> const libxl_asyncop_how *ao_how)
> LIBXL_EXTERNAL_CALLERS_ONLY;
>  
> +/* USB Controllers*/
> 
[]

Seem fine.

> +
> +/* USB Devices */
> +int libxl_device_usb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_usb 
> *usb,
> + const libxl_asyncop_how *ao_how)
> + LIBXL_EXTERNAL_CALLERS_ONLY;
> +
> +int libxl_device_usb_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_usb 
> *usb,
> +const libxl_asyncop_how *ao_how)
> +LIBXL_EXTERNAL_CALLERS_ONLY;
> +
> +libxl_device_usb *
> +libxl_device_usb_list(libxl_ctx *ctx, uint32_t domid, int *num);
> +
> +libxl_device_usb *
> +libxl_device_usb_list_per_usbctrl(libxl_ctx *ctx, uint32_t domid,
> +  libxl_devid usbctrl, int *num);

I'd probably say "..._for_usbctrl" or "..._by_usbctrl", but that's just
nitpicking.

> +
> +void libxl_device_usb_list_free(libxl_device_usb *list, int nr);
> +
> +int libxl_device_usb_getinfo(libxl_ctx *ctx, uint32_t domid,
> + libxl_device_usb *usb,
> + libxl_usbinfo *usbinfo);
> +
>  /* Network Interfaces */
>  int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid,
> libxl_device_nic *nic,
>   const libxl_asyncop_how *ao_how)
[...]
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index ef346e7..ef10484 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -594,6 +594,37 @@ libxl_device_rdm = Struct("device_rdm", [
>  ("policy", libxl_rdm_reserve_policy),
>  ])
>  
> +libxl_usbctrl_type = Enumeration("usbctrl_type", [
> +(0, "AUTO"),

What are the proposed semantics of using LIBXL_USBCTRL_TYPE_AUTO?

> +(1, "PV"),
> +(2, "QEMU"),

Is "QEMU" what we want here, as opposed to, say, "EMU" (similar to NICs)?

I think we probably don't want to go as fine grained as "XHCI" and "EHCI"
etc, do we? I see we have a version field below, is it intended that there
be some way to select between e.g. UHCI and OHCI (which IIRC are different
USB 1.0 controllers).

Maybe these questions should all be left aside for when QMEU support is
actually added (AFAICT this field is just a placeholder)? In fact I glanced
at the code and was surprised to find nothing checking for
LIBXL_USBCTRL_TYPE at all, did I miss something?

I think the two choices are:

We can decide quickly and easily what the option(s) other than PV should be
here and you include it in the IDL, but you would then need to check
usbctrl->type == PV at various points, not silently treat all options as
PV.

Or this becomes a long conversation in which case I think your best bet
would be to leave the enum with just the PV (and maybe AUTO) entries and
leave the decision on the name for the emulated option to the series which
implements that.

> +])
> +
> +libxl_usbdev_type = Enumeration("usbdev_type", [
> +(0, "invalid"),
> +(1, "hostdev"),
> +])
> +
> +libxl_device_usbctrl = Struct("device_usbctrl", [
> +("type", libxl_usbctrl_type),
> +("devid", libxl_devid),
> +("version", integer),
> +("ports", integer),
> 

[Xen-devel] [PATCHv1 net] xen-netback: require fewer guest Rx slots when not using GSO

[David Vrabel]

Commit f48da8b14d04ca87ffcffe68829afd45f926ec6a (xen-netback: fix
unlimited guest Rx internal queue and carrier flapping) introduced a
regression.

The PV frontend in IPXE only places 4 requests on the guest Rx ring.
Since netback required at least (MAX_SKB_FRAGS + 1) slots, IPXE could
not receive any packets.

a) If GSO is not enabled on the VIF, fewer guest Rx slots are required
   for the largest possible packet.  Calculate the required slots
   based on the maximum GSO size or the MTU.

   This calculation of the number of required slots relies on
   1650d5455bd2 (xen-netback: always fully coalesce guest Rx packets)
   which present in 4.0-rc1 and later.

b) Reduce the Rx stall detection to checking for at least one
   available Rx request.  This is fine since we're predominately
   concerned with detecting interfaces which are down and thus have
   zero available Rx requests.

Signed-off-by: David Vrabel 
---
 drivers/net/xen-netback/common.h  | 10 --
 drivers/net/xen-netback/netback.c | 23 ---
 2 files changed, 16 insertions(+), 17 deletions(-)

Note that this can only be backported as-is on top of
1650d5455bd2dc6b5ee134bd6fc1a3236c266b5b (xen-netback: always fully
coalesce guest Rx packets) which is in 4.0 and later.

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 8a495b3..25990b1 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -200,11 +200,6 @@ struct xenvif_queue { /* Per-queue data for xenvif */
struct xenvif_stats stats;
 };
 
-/* Maximum number of Rx slots a to-guest packet may use, including the
- * slot needed for GSO meta-data.
- */
-#define XEN_NETBK_RX_SLOTS_MAX (MAX_SKB_FRAGS + 1)
-
 enum state_bit_shift {
/* This bit marks that the vif is connected */
VIF_STATUS_CONNECTED,
@@ -306,11 +301,6 @@ int xenvif_dealloc_kthread(void *data);
 
 void xenvif_rx_queue_tail(struct xenvif_queue *queue, struct sk_buff *skb);
 
-/* Determine whether the needed number of slots (req) are available,
- * and set req_event if not.
- */
-bool xenvif_rx_ring_slots_available(struct xenvif_queue *queue, int needed);
-
 void xenvif_carrier_on(struct xenvif *vif);
 
 /* Callback from stack when TX packet can be released */
diff --git a/drivers/net/xen-netback/netback.c 
b/drivers/net/xen-netback/netback.c
index 3f44b52..e791930 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -149,9 +149,20 @@ static inline pending_ring_idx_t pending_index(unsigned i)
return i & (MAX_PENDING_REQS-1);
 }
 
-bool xenvif_rx_ring_slots_available(struct xenvif_queue *queue, int needed)
+static int xenvif_rx_ring_slots_needed(struct xenvif *vif)
+{
+   if (vif->gso_mask)
+   return DIV_ROUND_UP(vif->dev->gso_max_size, PAGE_SIZE) + 1;
+   else
+   return DIV_ROUND_UP(vif->dev->mtu, PAGE_SIZE);
+}
+
+static bool xenvif_rx_ring_slots_available(struct xenvif_queue *queue)
 {
RING_IDX prod, cons;
+   int needed;
+
+   needed = xenvif_rx_ring_slots_needed(queue->vif);
 
do {
prod = queue->rx.sring->req_prod;
@@ -513,7 +524,7 @@ static void xenvif_rx_action(struct xenvif_queue *queue)
 
skb_queue_head_init();
 
-   while (xenvif_rx_ring_slots_available(queue, XEN_NETBK_RX_SLOTS_MAX)
+   while (xenvif_rx_ring_slots_available(queue)
   && (skb = xenvif_rx_dequeue(queue)) != NULL) {
queue->last_rx_time = jiffies;
 
@@ -1839,8 +1850,7 @@ static bool xenvif_rx_queue_stalled(struct xenvif_queue 
*queue)
prod = queue->rx.sring->req_prod;
cons = queue->rx.req_cons;
 
-   return !queue->stalled
-   && prod - cons < XEN_NETBK_RX_SLOTS_MAX
+   return !queue->stalled && prod - cons < 1
&& time_after(jiffies,
  queue->last_rx_time + queue->vif->stall_timeout);
 }
@@ -1852,14 +1862,13 @@ static bool xenvif_rx_queue_ready(struct xenvif_queue 
*queue)
prod = queue->rx.sring->req_prod;
cons = queue->rx.req_cons;
 
-   return queue->stalled
-   && prod - cons >= XEN_NETBK_RX_SLOTS_MAX;
+   return queue->stalled && prod - cons >= 1;
 }
 
 static bool xenvif_have_rx_work(struct xenvif_queue *queue)
 {
return (!skb_queue_empty(>rx_queue)
-   && xenvif_rx_ring_slots_available(queue, 
XEN_NETBK_RX_SLOTS_MAX))
+   && xenvif_rx_ring_slots_available(queue))
|| (queue->vif->stall_timeout &&
(xenvif_rx_queue_stalled(queue)
 || xenvif_rx_queue_ready(queue)))
-- 
2.1.4


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

[Xen-devel] [PATCH v2 09/10] xen/pt: Check for return values for xen_host_pci_[get|set] in init

[Konrad Rzeszutek Wilk]

and if we have failures we call xen_pt_destroy introduced in
'xen/pt: Move bulk of xen_pt_unregister_device in its own routine.'
and free all of the allocated structures.

Acked-by: Stefano Stabellini 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 hw/xen/xen_pt.c | 24 
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index 5a49a86..80b687f 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -774,10 +774,11 @@ static int xen_pt_initfn(PCIDevice *d)
 }
 
 /* Initialize virtualized PCI configuration (Extended 256 Bytes) */
-if (xen_host_pci_get_block(>real_device, 0, d->config,
-   PCI_CONFIG_SPACE_SIZE) < 0) {
-xen_host_pci_device_put(>real_device);
-return -1;
+rc = xen_host_pci_get_block(>real_device, 0, d->config,
+PCI_CONFIG_SPACE_SIZE);
+if (rc < 0) {
+XEN_PT_ERR(d,"Could not read PCI_CONFIG space! (rc:%d)\n", rc);
+goto err_out;
 }
 
 s->memory_listener = xen_pt_memory_listener;
@@ -787,17 +788,17 @@ static int xen_pt_initfn(PCIDevice *d)
 xen_pt_register_regions(s, );
 
 /* reinitialize each config register to be emulated */
-if (xen_pt_config_init(s)) {
+rc = xen_pt_config_init(s);
+if (rc) {
 XEN_PT_ERR(d, "PCI Config space initialisation failed.\n");
-xen_host_pci_device_put(>real_device);
-return -1;
+goto err_out;
 }
 
 /* Bind interrupt */
 rc = xen_host_pci_get_byte(>real_device, PCI_INTERRUPT_PIN, );
 if (rc) {
 XEN_PT_ERR(d, "Failed to read PCI_INTERRUPT_PIN! (rc:%d)\n", rc);
-scratch = 0;
+goto err_out;
 }
 if (!scratch) {
 XEN_PT_LOG(d, "no pin interrupt\n");
@@ -854,12 +855,14 @@ out:
 rc = xen_host_pci_get_word(>real_device, PCI_COMMAND, );
 if (rc) {
 XEN_PT_ERR(d, "Failed to read PCI_COMMAND! (rc: %d)\n", rc);
+goto err_out;
 } else {
 val |= cmd;
 rc = xen_host_pci_set_word(>real_device, PCI_COMMAND, val);
 if (rc) {
 XEN_PT_ERR(d, "Failed to write PCI_COMMAND val=0x%x!(rc: 
%d)\n",
val, rc);
+goto err_out;
 }
 }
 }
@@ -872,6 +875,11 @@ out:
s->hostaddr.bus, s->hostaddr.slot, s->hostaddr.function);
 
 return 0;
+
+err_out:
+xen_pt_destroy(d);
+assert(rc);
+return rc;
 }
 
 static void xen_pt_unregister_device(PCIDevice *d)
-- 
2.1.0


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

[Xen-devel] [PATCH v2 10/10] xen/pt: Don't slurp wholesale the PCI configuration registers

[Konrad Rzeszutek Wilk]

Instead we have the emulation registers ->init functions which
consult the host values to see what the initial value should be
and they are responsible for populating the dev.config.

Reviewed-by: Stefano Stabellini 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 hw/xen/xen_pt.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index 80b687f..0f66ea1 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -774,12 +774,7 @@ static int xen_pt_initfn(PCIDevice *d)
 }
 
 /* Initialize virtualized PCI configuration (Extended 256 Bytes) */
-rc = xen_host_pci_get_block(>real_device, 0, d->config,
-PCI_CONFIG_SPACE_SIZE);
-if (rc < 0) {
-XEN_PT_ERR(d,"Could not read PCI_CONFIG space! (rc:%d)\n", rc);
-goto err_out;
-}
+memset(d->config, 0, PCI_CONFIG_SPACE_SIZE);
 
 s->memory_listener = xen_pt_memory_listener;
 s->io_listener = xen_pt_io_listener;
-- 
2.1.0


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

[Xen-devel] [PATCH v2 07/10] xen/pt: Make xen_pt_unregister_device idempotent

[Konrad Rzeszutek Wilk]

To deal with xen_host_pci_[set|get]_ functions returning error values
and clearing ourselves in the init function we should make the
.exit (xen_pt_unregister_device) function be idempotent in case
the generic code starts calling .exit (or for fun does it before
calling .init!).

Reviewed-by: Stefano Stabellini 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 hw/xen/xen-host-pci-device.c |  5 +
 hw/xen/xen-host-pci-device.h |  1 +
 hw/xen/xen_pt.c  | 20 ++--
 hw/xen/xen_pt.h  |  2 ++
 4 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/hw/xen/xen-host-pci-device.c b/hw/xen/xen-host-pci-device.c
index 743b37b..5b20570 100644
--- a/hw/xen/xen-host-pci-device.c
+++ b/hw/xen/xen-host-pci-device.c
@@ -387,6 +387,11 @@ error:
 return rc;
 }
 
+bool xen_host_pci_device_closed(XenHostPCIDevice *d)
+{
+return d->config_fd == -1;
+}
+
 void xen_host_pci_device_put(XenHostPCIDevice *d)
 {
 if (d->config_fd >= 0) {
diff --git a/hw/xen/xen-host-pci-device.h b/hw/xen/xen-host-pci-device.h
index c2486f0..16f4805 100644
--- a/hw/xen/xen-host-pci-device.h
+++ b/hw/xen/xen-host-pci-device.h
@@ -38,6 +38,7 @@ typedef struct XenHostPCIDevice {
 int xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t domain,
 uint8_t bus, uint8_t dev, uint8_t func);
 void xen_host_pci_device_put(XenHostPCIDevice *pci_dev);
+bool xen_host_pci_device_closed(XenHostPCIDevice *d);
 
 int xen_host_pci_get_byte(XenHostPCIDevice *d, int pos, uint8_t *p);
 int xen_host_pci_get_word(XenHostPCIDevice *d, int pos, uint16_t *p);
diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index 7575311..c80b755 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -807,6 +807,7 @@ out:
 
 memory_listener_register(>memory_listener, >dev.bus_master_as);
 memory_listener_register(>io_listener, _space_io);
+s->listener_set = true;
 XEN_PT_LOG(d,
"Real physical device %02x:%02x.%d registered successfully!\n",
s->hostaddr.bus, s->hostaddr.slot, s->hostaddr.function);
@@ -818,10 +819,11 @@ static void xen_pt_unregister_device(PCIDevice *d)
 {
 XenPCIPassthroughState *s = XEN_PT_DEVICE(d);
 uint8_t machine_irq = s->machine_irq;
-uint8_t intx = xen_pt_pci_intx(s);
+uint8_t intx;
 int rc;
 
-if (machine_irq) {
+if (machine_irq && !xen_host_pci_device_closed(>real_device)) {
+intx = xen_pt_pci_intx(s);
 rc = xc_domain_unbind_pt_irq(xen_xc, xen_domid, machine_irq,
  PT_IRQ_TYPE_PCI,
  pci_bus_num(d->bus),
@@ -836,6 +838,7 @@ static void xen_pt_unregister_device(PCIDevice *d)
 }
 }
 
+/* N.B. xen_pt_config_delete takes care of freeing them. */
 if (s->msi) {
 xen_pt_msi_disable(s);
 }
@@ -855,15 +858,20 @@ static void xen_pt_unregister_device(PCIDevice *d)
machine_irq, errno);
 }
 }
+s->machine_irq = 0;
 }
 
 /* delete all emulated config registers */
 xen_pt_config_delete(s);
 
-memory_listener_unregister(>memory_listener);
-memory_listener_unregister(>io_listener);
-
-xen_host_pci_device_put(>real_device);
+if (s->listener_set) {
+memory_listener_unregister(>memory_listener);
+memory_listener_unregister(>io_listener);
+s->listener_set = false;
+}
+if (!xen_host_pci_device_closed(>real_device)) {
+xen_host_pci_device_put(>real_device);
+}
 }
 
 static Property xen_pci_passthrough_properties[] = {
diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
index 4bf9e80..bdd9c3b 100644
--- a/hw/xen/xen_pt.h
+++ b/hw/xen/xen_pt.h
@@ -221,6 +221,7 @@ struct XenPCIPassthroughState {
 
 MemoryListener memory_listener;
 MemoryListener io_listener;
+bool listener_set;
 };
 
 int xen_pt_config_init(XenPCIPassthroughState *s);
@@ -286,6 +287,7 @@ static inline uint8_t 
xen_pt_pci_intx(XenPCIPassthroughState *s)
" value=%i, acceptable range is 1 - 4\n", r_val);
 r_val = 0;
 } else {
+/* Note that if s.real_device.config_fd is closed we make 0xff. */
 r_val -= 1;
 }
 
-- 
2.1.0


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

[Xen-devel] [PATCH v2 06/10] xen/pt: Log xen_host_pci_get/set errors in MSI code.

[Konrad Rzeszutek Wilk]

We seem to only use these functions when de-activating the
MSI - so just log errors.

Reviewed-by: Stefano Stabellini 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 hw/xen/xen_pt_msi.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/hw/xen/xen_pt_msi.c b/hw/xen/xen_pt_msi.c
index 5822df5..e3d7194 100644
--- a/hw/xen/xen_pt_msi.c
+++ b/hw/xen/xen_pt_msi.c
@@ -75,19 +75,29 @@ static int msi_msix_enable(XenPCIPassthroughState *s,
bool enable)
 {
 uint16_t val = 0;
+int rc;
 
 if (!address) {
 return -1;
 }
 
-xen_host_pci_get_word(>real_device, address, );
+rc = xen_host_pci_get_word(>real_device, address, );
+if (rc) {
+XEN_PT_ERR(>dev, "Failed to read MSI/MSI-X register (0x%x), 
rc:%d\n",
+   address, rc);
+return rc;
+}
 if (enable) {
 val |= flag;
 } else {
 val &= ~flag;
 }
-xen_host_pci_set_word(>real_device, address, val);
-return 0;
+rc = xen_host_pci_set_word(>real_device, address, val);
+if (rc) {
+XEN_PT_ERR(>dev, "Failed to write MSI/MSI-X register (0x%x), 
rc:%d\n",
+   address, rc);
+}
+return rc;
 }
 
 static int msi_msix_setup(XenPCIPassthroughState *s,
@@ -276,7 +286,7 @@ void xen_pt_msi_disable(XenPCIPassthroughState *s)
 return;
 }
 
-xen_pt_msi_set_enable(s, false);
+(void)xen_pt_msi_set_enable(s, false);
 
 msi_msix_disable(s, msi_addr64(msi), msi->data, msi->pirq, false,
  msi->initialized);
-- 
2.1.0


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

[Xen-devel] [PATCH v2] Remove XenPTReg->data and use dev.config for guest configuration values.

[Konrad Rzeszutek Wilk]

Hey!

Since v1: (http://lists.xen.org/archives/html/xen-devel/2015-07/msg00442.html)
 - Acked on review.
RFC [https://lists.gnu.org/archive/html/qemu-devel/2015-06/msg07350.html]
 - Added Acks
 - Fixed bugs

This patchset is dependent on the "Cleanups + various fixes due to libxl ABI
more logging on errors" which is located at 
git://xenbits.xen.org/people/konradwilk/qemu.git 
v2-cleanups-fixes-due-to-libxlABI
(or http://lists.xen.org/archives/html/xen-devel/2015-09/msg00935.html)

The status of the patches is as follow:

 R xen/pt: Use xen_host_pci_get_[byte|word] instead of dev.config
 R xen/pt: Sync up the dev.config and data values.
   xen/pt: Check if reg->init function sets the 'data' past the reg->size
   xen/pt: Remove XenPTReg->data field.
 A xen/pt: Log xen_host_pci_get in two init functions
 R xen/pt: Log xen_host_pci_get/set errors in MSI code.
 R xen/pt: Make xen_pt_unregister_device idempotent
 A xen/pt: Move bulk of xen_pt_unregister_device in its own routine.
 A xen/pt: Check for return values for xen_host_pci_[get|set] in init
 R xen/pt: Don't slurp wholesale the PCI configuration registers

Where 'A' - Acked-by, 'R' - Reviewed-by.

The two patches:
 [PATCH v2 03/10] xen/pt: Check if reg->init function sets the 'data' past the 
reg->size

Stefano asked me to make this a build time check but I could not figure
out how. See http://lists.xen.org/archives/html/xen-devel/2015-08/msg01547.html 
for details.

 [PATCH v2 04/10] xen/pt: Remove XenPTReg->data field.

Stefano asked me to s/word/half-word/g s/dbword/word/ - which this does.

Please review.

The patches are also available at:
>From Konrad Rzeszutek Wilk  # This line is ignored.
From: Konrad Rzeszutek Wilk 
Subject: [PATCH v2]  Remove XenPTReg->data and use dev.config for guest 
configuration values.
In-Reply-To: 

Hey!

Since v1: (http://lists.xen.org/archives/html/xen-devel/2015-07/msg00442.html)
 - Acked on review.
RFC [https://lists.gnu.org/archive/html/qemu-devel/2015-06/msg07350.html]
 - Added Acks
 - Fixed bugs

This patchset is dependent on the "Cleanups + various fixes due to libxl ABI
more logging on errors" which is located at 
git://xenbits.xen.org/people/konradwilk/qemu.git 
v2-cleanups-fixes-due-to-libxlABI
(or http://lists.xen.org/archives/html/xen-devel/2015-09/msg00935.html)

The status of the patches is as follow:

 R xen/pt: Use xen_host_pci_get_[byte|word] instead of dev.config
 R xen/pt: Sync up the dev.config and data values.
   xen/pt: Check if reg->init function sets the 'data' past the reg->size
   xen/pt: Remove XenPTReg->data field.
 A xen/pt: Log xen_host_pci_get in two init functions
 R xen/pt: Log xen_host_pci_get/set errors in MSI code.
 R xen/pt: Make xen_pt_unregister_device idempotent
 A xen/pt: Move bulk of xen_pt_unregister_device in its own routine.
 A xen/pt: Check for return values for xen_host_pci_[get|set] in init
 R xen/pt: Don't slurp wholesale the PCI configuration registers

Where 'A' - Acked-by, 'R' - Reviewed-by.

The two patches:
 [PATCH v2 03/10] xen/pt: Check if reg->init function sets the 'data' past the 
reg->size

Stefano asked me to make this a build time check but I could not figure
out how. See http://lists.xen.org/archives/html/xen-devel/2015-08/msg01547.html 
for details.

 [PATCH v2 04/10] xen/pt: Remove XenPTReg->data field.

Stefano asked me to s/word/half-word/g s/dbword/word/ - which this does.

Please review.

The patches are also available at:

 git://xenbits.xen.org/people/konradwilk/qemu.git postxsa120.v2

Thank you!


 hw/xen/xen-host-pci-device.c |   5 +
 hw/xen/xen-host-pci-device.h |   1 +
 hw/xen/xen_pt.c  | 152 +
 hw/xen/xen_pt.h  |   8 +-
 hw/xen/xen_pt_config_init.c  | 222 ---
 hw/xen/xen_pt_msi.c  |  18 +++-
 6 files changed, 288 insertions(+), 118 deletions(-)

Konrad Rzeszutek Wilk (10):
  xen/pt: Use xen_host_pci_get_[byte|word] instead of dev.config
  xen/pt: Sync up the dev.config and data values.
  xen/pt: Check if reg->init function sets the 'data' past the reg->size
  xen/pt: Remove XenPTReg->data field.
  xen/pt: Log xen_host_pci_get in two init functions
  xen/pt: Log xen_host_pci_get/set errors in MSI code.
  xen/pt: Make xen_pt_unregister_device idempotent
  xen/pt: Move bulk of xen_pt_unregister_device in its own routine.
  xen/pt: Check for return values for xen_host_pci_[get|set] in init
  xen/pt: Don't slurp wholesale the PCI configuration registers

 git://xenbits.xen.org/people/konradwilk/qemu.git postxsa120.v2

Thank you!


 hw/xen/xen-host-pci-device.c |   5 +
 hw/xen/xen-host-pci-device.h |   1 +
 hw/xen/xen_pt.c  | 152 +
 hw/xen/xen_pt.h  |   8 +-
 hw/xen/xen_pt_config_init.c  | 222 ---
 hw/xen/xen_pt_msi.c  |  18 +++-
 6 files changed, 288 insertions(+), 

[Xen-devel] [PATCH v2 02/10] xen/pt: Sync up the dev.config and data values.

[Konrad Rzeszutek Wilk]

For a passthrough device we maintain a state of emulated
registers value contained within d->config. We also consult
the host registers (and apply ro and write masks) whenever
the guest access the registers. This is done in xen_pt_pci_write_config
and xen_pt_pci_read_config.

Also in this picture we call pci_default_write_config which
updates the d->config and if the d->config[PCI_COMMAND] register
has PCI_COMMAND_MEMORY (or PCI_COMMAND_IO) acts on those changes.

On startup the d->config[PCI_COMMAND] are the host values, not
what the guest initial values should be, which is exactly what
we do _not_ want to do for 64-bit BARs when the guest just wants
to read the size of the BAR. Huh you say?

To get the size of 64-bit memory space BARs,  the guest has
to calculate ((BAR[x] & 0xFFF0) + ((BAR[x+1] & 0x) << 32))
which means it has to do two writes of ~0 to BARx and BARx+1.

prior to this patch and with XSA120-addendum patch (Linux kernel)
the PCI_COMMAND register is copied from the host it can have
PCI_COMMAND_MEMORY bit set which means that QEMU will try to
update the hypervisor's P2M with BARx+1 value to ~0 (0x)
(to sync the guest state to host) instead of just having
xen_pt_pci_write_config and xen_pt_bar_reg_write apply the
proper masks and return the size to the guest.

To thwart this, this patch syncs up the host values with the
guest values taking into account the emu_mask (bit set means
we emulate, PCI_COMMAND_MEMORY and PCI_COMMAND_IO are set).
That is we copy the host values - masking out any bits which
we will emulate. Then merge it with the initial emulation register
values. Lastly this value is then copied both in
dev.config _and_ XenPTReg->data field.

There is also reg->size accounting taken into consideration
that ends up being used in patch.
 xen/pt: Check if reg->init function sets the 'data' past the reg->size

This fixes errors such as these:

(XEN) memory_map:add: dom2 gfn=fffe0 mfn=fbce0 nr=20
(DEBUG) 189 pci dev 04:0 BAR16 wrote ~0.
(DEBUG) 200 pci dev 04:0 BAR16 read 0x0fffe0004.
(XEN) memory_map:remove: dom2 gfn=fffe0 mfn=fbce0 nr=20
(DEBUG) 204 pci dev 04:0 BAR16 wrote 0x0fffe0004.
(DEBUG) 217 pci dev 04:0 BAR16 read upper 0x0.
(XEN) memory_map:add: dom2 gfn=0 mfn=fbce0 nr=20
(XEN) p2m.c:883:d0v0 p2m_set_entry failed! mfn= rc:-22
(XEN) memory_map:fail: dom2 gfn=0 mfn=fbce0 nr=20 ret:-22
(XEN) memory_map:remove: dom2 gfn=0 mfn=fbce0 nr=20
(XEN) p2m.c:920:d0v0 gfn_to_mfn failed! gfn=0 type:4
(XEN) p2m.c:920:d0v0 gfn_to_mfn failed! gfn=1 type:4
..
(XEN) memory_map: error -22 removing dom2 access to [fbce0,fbcff]
(DEBUG) 222 pci dev 04:0 BAR16 read upper 0x0.
(XEN) memory_map:remove: dom2 gfn=0 mfn=fbce0 nr=20
(XEN) memory_map: error -22 removing dom2 access to [fbce0,fbcff]

[The DEBUG is to illustate what the hvmloader was doing]

Also we swap from xen_host_pci_long to using xen_host_pci_get_[byte,word,long].

Otherwise we get:

xen_pt_config_reg_init: Offset 0x0004 mismatch! Emulated=0x, 
host=0x2300017, syncing to 0x2300014.
xen_pt_config_reg_init: Error: Offset 0x0004:0x2300014 expands past register 
size(2)!

which is not surprising. We read the value as an 32-bit (from host),
then operate it as a 16-bit - and the remainder is left unchanged.

We end up writing the value as 16-bit (so 0014) to dev.config
(as we use proper xen_set_host_[byte,word,long] so we don't spill
to other registers) but in XenPTReg->data it is as 32-bit (0x2300014)!

It is harmless as the read/write functions end up using an size mask
and never modify the bits past 16-bit (reg->size is 2).

This patch fixes the warnings by reading the value using the
proper size.

Note that the check for size is still left in-case the developer
sets bits past the reg->size in the ->init routines. The author
tried to fiddle with QEMU_BUILD_BUG to make this work but failed.

Reviewed-by: Stefano Stabellini 
Reported-by: Sander Eikelenboom 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 hw/xen/xen_pt_config_init.c | 59 -
 1 file changed, 58 insertions(+), 1 deletion(-)

diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index e34f9f8..aff51b8 100644
--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -1856,6 +1856,10 @@ static int xen_pt_config_reg_init(XenPCIPassthroughState 
*s,
 reg_entry->reg = reg;
 
 if (reg->init) {
+uint32_t host_mask, size_mask;
+unsigned int offset;
+uint32_t val;
+
 /* initialize emulate register */
 rc = reg->init(s, reg_entry->reg,
reg_grp->base_offset + reg->offset, );
@@ -1868,8 +1872,61 @@ static int xen_pt_config_reg_init(XenPCIPassthroughState 
*s,
 g_free(reg_entry);
 return 0;
 }
+/* Sync up the 

Re: [Xen-devel] [PATCH OSSTEST v2 6/6] Create a flight to test OpenStack with xen-unstable and libvirt

[Ian Campbell]

On Thu, 2015-08-06 at 18:03 +0100, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD 
> ---
>  ap-common|  9 +
>  ap-fetch-version |  4 
>  ap-fetch-version-old |  5 +
>  ap-print-url |  3 +++
>  cri-common   |  1 +
>  make-flight  | 42 +-
>  mfi-common   |  5 +
>  7 files changed, 68 insertions(+), 1 deletion(-)
> 
> diff --git a/ap-common b/ap-common
> index dfeab9e..40eda02 100644
> --- a/ap-common
> +++ b/ap-common
> @@ -57,6 +57,14 @@
>  : ${PUSH_TREE_OVMF:=$XENBITS:/home/xen/git/osstest/ovmf.git}
>  : ${BASE_TREE_OVMF:=git://xenbits.xen.org/osstest/ovmf.git}
>  
> +: ${TREE_DEVSTACK:=git://git.openstack.org/openstack-dev/devstack.git}
> +:
> ${TREE_OPENSTACK_REQUIREMENTS:=git://git.openstack.org/openstack/requirem
> ents.git}
> +: ${TREE_KEYSTONE:=git://git.openstack.org/openstack/keystone.git}
> +: ${TREE_GLANCE:=git://git.openstack.org/openstack/glance.git}
> +: ${TREE_CINDER:=git://git.openstack.org/openstack/cinder.git}
> +: ${TREE_NOVA:=git://git.openstack.org/openstack/nova.git}
> +: ${TREE_TEMPEST:=git://git.openstack.org/openstack/tempest.git}

Maybe these should all be TREE_OPENSTACK_FOO? And perhaps put git
://git.openstack.org/openstack/ into a variable (like $XENBITS or
$GIT_KERNEL_ORG)

> +
>  : ${TREE_LINUXFIRMWARE:=git://xenbits.xen.org/osstest/linux
> -firmware.git}
>  : ${PUSH_TREE_LINUXFIRMWARE:=$XENBITS:/home/osstest/ext/linux
> -firmware.git}
>  :
> ${UPSTREAM_TREE_LINUXFIRMWARE:=$GIT_KERNEL_ORG/pub/scm/linux/kernel/git/f
> irmware/linux-firmware.git}
> @@ -84,6 +92,7 @@ fi
>  : ${LOCALREV_RUMPUSERXEN:=daily-cron.$branch}
>  : ${LOCALREV_SEABIOS:=daily-cron.$branch}
>  : ${LOCALREV_OVMF:=daily-cron.$branch}
> +: ${LOCALREV_DEVSTACK:=daily-cron.$branch}
>  
>  : ${TREEBASE_LINUX_XCP:=
> http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27}
>  
> diff --git a/ap-fetch-version b/ap-fetch-version
> index 8b41acf..9aba511 100755
> --- a/ap-fetch-version
> +++ b/ap-fetch-version
> @@ -89,6 +89,10 @@ ovmf)
>   repo_tree_rev_fetch_git ovmf \
>   $TREE_OVMF_UPSTREAM master $LOCALREV_OVMF
>   ;;
> +openstack)
> + repo_tree_rev_fetch_git devstack \
> + $TREE_DEVSTACK master $LOCALREV_DEVSTACK
> + ;;
>  osstest)
>  if [ "x$OSSTEST_USE_HEAD" = "xy" ] ; then
>   git update-ref -m "Arranging to test HEAD" \
> diff --git a/ap-fetch-version-old b/ap-fetch-version-old
> index 0b4739b..d12c753 100755
> --- a/ap-fetch-version-old
> +++ b/ap-fetch-version-old
> @@ -31,6 +31,7 @@ select_xenbranch
>  : ${BASE_LOCALREV_RUMPUSERXEN:=daily-cron.$branch.old}
>  : ${BASE_LOCALREV_SEABIOS:=daily-cron.$branch.old}
>  : ${BASE_LOCALREV_OVMF:=daily-cron.$branch.old}
> +: ${BASE_LOCALREV_DEVSTACK:=daily-cron.$branch.old}
>  
>  : ${BASE_TREE_QEMU_UPSTREAM:=${TREE_QEMU_UPSTREAM/\/staging\//\/}}
>  
> @@ -97,6 +98,10 @@ ovmf)
>   repo_tree_rev_fetch_git ovmf \
>   $BASE_TREE_OVMF xen-tested-master $BASE_LOCALREV_OVMF
>   ;;
> +openstack)
> + repo_tree_rev_fetch_git devstack \
> + $TREE_DEVSTACK master $BASE_LOCALREV_DEVSTACK

This one should be pulling from the gate output on xenbits not from
upstream. See e.g. BASE_TREE_OVMF.

Actually, I think you've missed the ap-push changes needed to populate that
tree, you need this in order to have a baseline.
 
>  if [ x$buildflight = x ]; then
> @@ -101,6 +108,20 @@ job_create_test_filter_callback () {
>  *) return 1;;
>esac
>;;
> +openstack)
> +  if [ x$toolstack != xlibvirt ] ; then return 1; fi
> +  case "$job" in
> +test-*-libvirt*) return 1;;
> +  esac
> +  case $xenarch in
> +  amd64) ;;
> +  *) return 1;;
> +  esac
> +  case $dom0arch in
> +  amd64) ;;
> +  *) return 1;;
> +  esac
> +  ;;


Do you not want to only accept *-devstack here and reject everything else?

Otherwise don't you end up with various xl and HVM tests?

Ian.


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

Re: [Xen-devel] [PATCH] MAINTAINERS: stable backports should be requested on xen-devel

[Wei Liu]

On Tue, Sep 08, 2015 at 12:37:04PM +0100, Ian Campbell wrote:
> On Sat, 2015-07-25 at 09:25 +0100, Ian Campbell wrote:
> > As well as CC-ing the correct people. I just saw such a request on
> > xen-users and thought this was worth clarifying here too.
> > 
> > Signed-off-by: Ian Campbell 
> 
> Just found this in my folder, do we want to take it for 4.6?
> 

Fine by me of course.

> > ---
> >  MAINTAINERS | 7 ---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index a4e64ea..156a95f 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -49,9 +49,10 @@ for inclusion in xen-unstable.
> >  Please see http://wiki.xen.org/wiki/Xen_Maintenance_Releases for more
> >  information.
> >  
> > -Remember to copy the appropriate stable branch maintainer who will be
> > -listed in this section of the MAINTAINERS file in the appropriate
> > -branch.
> > +Backport requests should be made on the xen-de...@lists.xenproject.org
> > +list. Remember to copy the appropriate stable branch maintainer who
> > +will be listed in this section of the MAINTAINERS file in the
> > +appropriate branch.
> >  
> > Unstable Subsystem Maintainers
> > ==

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

[Xen-devel] [PATCH v2 4/6] xen: use errno instead of rc for xc_domain_add_to_physmap

[Konrad Rzeszutek Wilk]

In Xen 4.6 commit cd2f100f0f61b3f333d52d1737dd73f02daee592
"libxc: Fix do_memory_op to return negative value on errors"
made the libxc API less odd-ball: On errors, return value is
-1 and error code is in errno. On success the return value
is either 0 or an positive value.

Since we could be running with an old toolstack in which the
Exx value is in rc or the newer, we add an wrapper around
the xc_domain_add_to_physmap (called xen_xc_domain_add_to_physmap)
which will always return the EXX.

Xen 4.6 did not change the libxc functions mentioned (same parameters)
so we piggyback on the fact that Xen 4.6 has a new function:
commit 504ed2053362381ac01b98db9313454488b7db40 "tools/libxc: Expose
new hypercall xc_reserved_device_memory_map" and check for that.

Suggested-by: Stefano Stabellini 
Signed-off-by: Konrad Rzeszutek Wilk 
Reviewed-by: Stefano Stabellini 
---
 configure   | 26 ++
 include/hw/xen/xen_common.h | 22 ++
 xen-hvm.c   |  4 ++--
 3 files changed, 50 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index d854936..f162025 100755
--- a/configure
+++ b/configure
@@ -1889,6 +1889,32 @@ int main(void) {
   xc_gnttab_open(NULL, 0);
   xc_domain_add_to_physmap(0, 0, XENMAPSPACE_gmfn, 0, 0);
   xc_hvm_inject_msi(xc, 0, 0xf000, 0x);
+  xc_reserved_device_memory_map(xc, 0, 0, 0, 0, NULL, 0);
+  return 0;
+}
+EOF
+  compile_prog "" "$xen_libs"
+then
+xen_ctrl_version=460
+xen=yes
+
+  elif
+  cat > $TMPC <
+#include 
+#include 
+#include 
+#if !defined(HVM_MAX_VCPUS)
+# error HVM_MAX_VCPUS not defined
+#endif
+int main(void) {
+  xc_interface *xc;
+  xs_daemon_open();
+  xc = xc_interface_open(0, 0, 0);
+  xc_hvm_set_mem_type(0, 0, HVMMEM_ram_ro, 0, 0);
+  xc_gnttab_open(NULL, 0);
+  xc_domain_add_to_physmap(0, 0, XENMAPSPACE_gmfn, 0, 0);
+  xc_hvm_inject_msi(xc, 0, 0xf000, 0x);
   xc_hvm_create_ioreq_server(xc, 0, 0, NULL);
   return 0;
 }
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index ed5fd3e..3cd5875 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -407,4 +407,26 @@ static inline int xen_set_ioreq_server_state(XenXC xc, 
domid_t dom,
 
 #endif
 
+#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 460
+static inline int xen_xc_domain_add_to_physmap(XenXC xch, uint32_t domid,
+   unsigned int space,
+   unsigned long idx,
+   xen_pfn_t gpfn)
+{
+return xc_domain_add_to_physmap(xch, domid, space, idx, gpfn);
+}
+#else
+static inline int xen_xc_domain_add_to_physmap(XenXC xch, uint32_t domid,
+   unsigned int space,
+   unsigned long idx,
+   xen_pfn_t gpfn)
+{
+/* In Xen 4.6 rc is -1 and errno contains the error value. */
+int rc = xc_domain_add_to_physmap(xch, domid, space, idx, gpfn);
+if (rc == -1)
+return errno;
+return rc;
+}
+#endif
+
 #endif /* QEMU_HW_XEN_COMMON_H */
diff --git a/xen-hvm.c b/xen-hvm.c
index 0408462..fae2d22 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -345,7 +345,7 @@ go_physmap:
 unsigned long idx = pfn + i;
 xen_pfn_t gpfn = start_gpfn + i;
 
-rc = xc_domain_add_to_physmap(xen_xc, xen_domid, XENMAPSPACE_gmfn, 
idx, gpfn);
+rc = xen_xc_domain_add_to_physmap(xen_xc, xen_domid, XENMAPSPACE_gmfn, 
idx, gpfn);
 if (rc) {
 DPRINTF("add_to_physmap MFN %"PRI_xen_pfn" to PFN %"
 PRI_xen_pfn" failed: %d\n", idx, gpfn, rc);
@@ -422,7 +422,7 @@ static int xen_remove_from_physmap(XenIOState *state,
 xen_pfn_t idx = start_addr + i;
 xen_pfn_t gpfn = phys_offset + i;
 
-rc = xc_domain_add_to_physmap(xen_xc, xen_domid, XENMAPSPACE_gmfn, 
idx, gpfn);
+rc = xen_xc_domain_add_to_physmap(xen_xc, xen_domid, XENMAPSPACE_gmfn, 
idx, gpfn);
 if (rc) {
 fprintf(stderr, "add_to_physmap MFN %"PRI_xen_pfn" to PFN %"
 PRI_xen_pfn" failed: %d\n", idx, gpfn, rc);
-- 
2.1.0


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

[Xen-devel] [PATCH v2] Cleanups + various fixes due to libxl ABI + more logging on errors.

[Konrad Rzeszutek Wilk]

Hey!

Since v2 (http://lists.xen.org/archives/html/xen-devel/2015-07/msg00431.html)
 - Added Reviewed-by.

since RFC [https://lists.gnu.org/archive/html/qemu-devel/2015-06/msg07326.html]
 - Added Acks
 - Followed 'xen: Print and use errno where applicable.' suggestion by Stefano
   and added a wrapper.

As I am in the process of syncing the 'dev.config' and Xen's internal
cache of the PCI config space I noticed that some oddities
in the code and figured that having them in would be easier
for me (so I don't have to handle 20 odd patches).

Stefano, patch 

 [PATCH v2 4/6] xen: use errno instead of rc for

was the only one that changed - where I implemented the configure script
as you suggested. All the rest are the same.

Please review or git pull the following tag:

git://xenbits.xen.org/people/konradwilk/qemu.git 
v2-cleanups-fixes-due-to-libxlABI


 configure   | 26 ++
 hw/xen/xen_pt.c |  6 +++---
 hw/xen/xen_pt.h |  1 -
 hw/xen/xen_pt_config_init.c |  8 
 hw/xen/xen_pt_msi.c |  2 +-
 include/hw/xen/xen_common.h | 22 ++
 xen-hvm.c   |  4 ++--
 7 files changed, 58 insertions(+), 11 deletions(-)

Konrad Rzeszutek Wilk (6):
  xen/pt: Update comments with proper function name.
  xen/pt: Make xen_pt_msi_set_enable static
  xen/pt: xen_host_pci_config_read returns -errno, not -1 on failure
  xen: use errno instead of rc for xc_domain_add_to_physmap
  xen/pt/msi: Add the register value when printing logging and error 
messages
  xen/pt: Use XEN_PT_LOG properly to guard against compiler warnings.


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

[Xen-devel] [PATCH v2 6/6] xen/pt: Use XEN_PT_LOG properly to guard against compiler warnings.

[Konrad Rzeszutek Wilk]

If XEN_PT_LOGGING_ENABLED is enabled the XEN_PT_LOG macros start
using the first argument. Which means if within the function there
is only one user of the argument ('d') and XEN_PT_LOGGING_ENABLED
is not set, we get compiler warnings. This is not the case now
but with the "xen/pt: Use xen_host_pci_get_[byte|word] instead of dev.config"
we will hit - so this sync up the function to the rest of them.

Reviewed-by: Stefano Stabellini 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 hw/xen/xen_pt_config_init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index 462e1b9..21d4938 100644
--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -1418,7 +1418,7 @@ static int 
xen_pt_msixctrl_reg_init(XenPCIPassthroughState *s,
 reg_field = pci_get_word(d->config + real_offset);
 
 if (reg_field & PCI_MSIX_FLAGS_ENABLE) {
-XEN_PT_LOG(d, "MSIX already enabled, disabling it first\n");
+XEN_PT_LOG(>dev, "MSIX already enabled, disabling it first\n");
 xen_host_pci_set_word(>real_device, real_offset,
   reg_field & ~PCI_MSIX_FLAGS_ENABLE);
 }
-- 
2.1.0


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

[Xen-devel] [PATCH v2 2/6] xen/pt: Make xen_pt_msi_set_enable static

[Konrad Rzeszutek Wilk]

As we do not use it outside our code.

Reviewed-by: Stefano Stabellini 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 hw/xen/xen_pt.h | 1 -
 hw/xen/xen_pt_msi.c | 2 +-
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
index 393f36c..09358b1 100644
--- a/hw/xen/xen_pt.h
+++ b/hw/xen/xen_pt.h
@@ -289,7 +289,6 @@ static inline uint8_t 
xen_pt_pci_intx(XenPCIPassthroughState *s)
 }
 
 /* MSI/MSI-X */
-int xen_pt_msi_set_enable(XenPCIPassthroughState *s, bool en);
 int xen_pt_msi_setup(XenPCIPassthroughState *s);
 int xen_pt_msi_update(XenPCIPassthroughState *d);
 void xen_pt_msi_disable(XenPCIPassthroughState *s);
diff --git a/hw/xen/xen_pt_msi.c b/hw/xen/xen_pt_msi.c
index 263e051..5822df5 100644
--- a/hw/xen/xen_pt_msi.c
+++ b/hw/xen/xen_pt_msi.c
@@ -220,7 +220,7 @@ static int msi_msix_disable(XenPCIPassthroughState *s,
  * MSI virtualization functions
  */
 
-int xen_pt_msi_set_enable(XenPCIPassthroughState *s, bool enable)
+static int xen_pt_msi_set_enable(XenPCIPassthroughState *s, bool enable)
 {
 XEN_PT_LOG(>dev, "%s MSI.\n", enable ? "enabling" : "disabling");
 
-- 
2.1.0


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

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

[osstest service owner]

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

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-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 58558
 test-armhf-armhf-libvirt  6 xen-boot  fail REGR. vs. 58581
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
baseline untested
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail baseline untested
 test-armhf-armhf-xl-credit2   6 xen-boot fail   like 58581
 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-amd64-amd64-xl-qemut-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-qemuu-win7-amd64 17 guest-stop fail like 58581

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

version targeted for testing:
 linuxfcd9bfdb9d884f1aab89124dee894e7d821bb5dc
baseline version:
 linuxd048c068d00da7d4cfa5ea7651933b99026958cf

Last test of basis58581  2015-06-15 09:42:22 Z   85 days
Failing since 58976  2015-06-29 19:43:23 Z   71 days   55 attempts
Testing same since61524  2015-09-07 11:48:03 Z1 days1 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
 

Re: [Xen-devel] [PATCH v2 03/10] xen/pt: Check if reg->init function sets the 'data' past the reg->size

[Stefano Stabellini]

On Tue, 8 Sep 2015, Konrad Rzeszutek Wilk wrote:
> It should never happen, but in case it does (an developer adds
> a new register and the 'init_val' expands past the register
> size) we want to report. The code will only write up to
> reg->size so there is no runtime danger of the register spilling
> across other ones - however to catch this sort of thing
> we still return an error.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 

Acked-by: Stefano Stabellini 


>  hw/xen/xen_pt_config_init.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
> index aff51b8..55be4ee 100644
> --- a/hw/xen/xen_pt_config_init.c
> +++ b/hw/xen/xen_pt_config_init.c
> @@ -1912,9 +1912,15 @@ static int 
> xen_pt_config_reg_init(XenPCIPassthroughState *s,
>  } else
>  val = data;
>  
> +if (val & ~size_mask) {
> +XEN_PT_ERR(>dev,"Offset 0x%04x:0x%04x expands past register 
> size(%d)!\n",
> +   offset, val, reg->size);
> +g_free(reg_entry);
> +return -ENXIO;
> +}
>  /* This could be just pci_set_long as we don't modify the bits
> - * past reg->size, but in case this routine is run in parallel
> - * we do not want to over-write other registers. */
> + * past reg->size, but in case this routine is run in parallel or the
> + * init value is larger, we do not want to over-write registers. */
>  switch (reg->size) {
>  case 1: pci_set_byte(s->dev.config + offset, (uint8_t)val);
>  break;
> -- 
> 2.1.0
> 

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

[Xen-devel] [GIT PULL] xen: features and fixes for 4.3-rc0

[David Vrabel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.3-rc0-tag

xen: features and fixes for 4.3-rc0

- - Convert xen-blkfront to the multiqueue API
- - [arm] Support binding event channels to different VCPUs.
- - [x86] Support > 512 GiB in a PV guests (off by default as such a
  guest cannot be migrated with the current toolstack).
- - [x86] PMU support for PV dom0 (limited support for using perf with
  Xen and other guests).

Thanks.

David

 Documentation/ABI/testing/sysfs-hypervisor-pmu |  23 +
 Documentation/kernel-parameters.txt|   7 +
 arch/arm/include/asm/xen/events.h  |   6 +
 arch/arm/include/asm/xen/page.h|  16 +-
 arch/arm/xen/enlighten.c   |   7 -
 arch/arm64/include/asm/xen/events.h|   6 +
 arch/x86/include/asm/xen/events.h  |  11 +
 arch/x86/include/asm/xen/hypercall.h   |   6 +
 arch/x86/include/asm/xen/interface.h   | 219 +-
 arch/x86/include/asm/xen/page.h|   8 +-
 arch/x86/xen/Kconfig   |  21 +-
 arch/x86/xen/Makefile  |   2 +-
 arch/x86/xen/apic.c|   6 +
 arch/x86/xen/enlighten.c   |  20 +-
 arch/x86/xen/mmu.c | 399 +++--
 arch/x86/xen/p2m.c |  43 +-
 arch/x86/xen/p2m.h |  15 -
 arch/x86/xen/platform-pci-unplug.c |   2 +-
 arch/x86/xen/pmu.c | 570 +
 arch/x86/xen/pmu.h |  15 +
 arch/x86/xen/setup.c   | 496 +++--
 arch/x86/xen/smp.c |  29 +-
 arch/x86/xen/suspend.c |  23 +-
 arch/x86/xen/xen-head.S|   2 +
 arch/x86/xen/xen-ops.h |   7 +
 drivers/block/xen-blkfront.c   | 146 +++
 drivers/xen/Kconfig|  11 +
 drivers/xen/balloon.c  |   6 +-
 drivers/xen/events/events_base.c   |   6 +-
 drivers/xen/sys-hypervisor.c   | 136 +-
 drivers/xen/xenfs/Makefile |   1 +
 drivers/xen/xenfs/super.c  |   3 +
 drivers/xen/xenfs/xenfs.h  |   1 +
 drivers/xen/xenfs/xensyms.c| 152 +++
 include/asm-generic/early_ioremap.h|   2 +
 include/asm-generic/fixmap.h   |   3 +
 include/xen/events.h   |   1 -
 include/xen/interface/platform.h   |  18 +
 include/xen/interface/xen.h|  37 +-
 include/xen/interface/xenpmu.h |  94 
 include/xen/page.h |   4 +-
 mm/early_ioremap.c |  12 +
 42 files changed, 2229 insertions(+), 363 deletions(-)

Bob Liu (1):
  xen-blkfront: convert to blk-mq APIs

Boris Ostrovsky (7):
  xen: xensyms support
  xen/PMU: Sysfs interface for setting Xen PMU mode
  xen/PMU: Initialization code for Xen PMU
  xen/PMU: Describe vendor-specific PMU registers
  xen/PMU: Intercept PMU-related MSR and APIC accesses
  xen/PMU: PMU emulation code
  xen/x86: Don't try to set PCE bit in CR4

Colin Ian King (1):
  x86/xen: fix non-ANSI declaration of xen_has_pv_devices()

Juergen Gross (20):
  xen: sync with xen headers
  xen: save linear p2m list address in shared info structure
  xen: don't build mfn tree if tools don't need it
  xen: eliminate scalability issues from initial mapping setup
  xen: move static e820 map to global scope
  xen: split counting of extra memory pages from remapping
  xen: check memory area against e820 map
  xen: find unused contiguous memory area
  xen: check for kernel memory conflicting with memory layout
  xen: check pre-allocated page tables for conflict with memory map
  xen: check for initrd conflicting with e820 map
  mm: provide early_memremap_ro to establish read-only mapping
  xen: add explicit memblock_reserve() calls for special pages
  xen: move p2m list if conflicting with e820 map
  xen: allow more than 512 GB of RAM for 64 bit pv-domains
  xen: remove no longer needed p2m.h
  xen: avoid early crash of memory limited dom0
  xen: avoid another early crash of memory limited dom0
  xen: limit memory to architectural maximum
  xen: switch extra memory accounting to use pfns

Julien Grall (3):
  xen/events: Support event channel rebind on ARM
  arm/xen: Drop the definition of xen_pci_platform_unplug
  arm/xen: Remove helpers which are PV specific

Konstantin Khlebnikov (1):
  xen/preempt: use need_resched() instead of should_resched()
-BEGIN PGP 

Re: [Xen-devel] Notes from Xen BoF at Debconf15

[Doug Goldstein]

On 9/8/15 5:55 AM, Jan Beulich wrote:
 On 08.09.15 at 12:49,  wrote:
>> Jan Beulich writes ("Re: [Xen-devel] Notes from Xen BoF at Debconf15"):
>>> Right - 4.4.3 already was released with just one RC, and indeed I
>>> meant to stay with that model considering the little (if any) feedback
>>> we get on these RCs. I personally could live without doing any RCs,
>>> but [...]
>>
>> Having had the chance to reflect I am convinced that we should stop
>> doing RCs for point releases.
>>
>>> [I] thought so far that doing at least one kind of publicly indicates
>>> the intention of doing a release soon.
>>
>> You might hope that it would have that effect, but I don't think it is
>> working.  Also, if it does work, all it does is generate more patches,
>> making the `rc' more of a `prod to get your stuff shoveled in'.
> 
> Well, okay - no RCs anymore then unless someone offers a
> convincing reason to have them.
> 
> Jan
> 

So I'll just toss in a late thumbs up here. For libvirt we maintain
stable branches that are mostly just security fixes and other important
fixes. We tag these will without RCs and all the downstream distros (and
myself as the downstream maintainer for 3 distros) are happy with that
situation.

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [xen-unstable test] 61521: regressions - FAIL

[Ian Campbell]

On Tue, 2015-09-08 at 15:52 +0100, Wei Liu wrote:
> On Tue, Sep 08, 2015 at 02:30:30PM +, osstest service owner wrote:
> > flight 61521 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/61521/
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-amd64-xl-qemut-debianhvm-amd64 19 guest
> > -start/debianhvm.repeat fail REGR. vs. 61059
> > 
> 
> I suspect this failure is due to infrastructure problem.

Actually I think it is more likely that the qemut-debianhvm test is just
not 100% reliable.

Unless you have observed something in the logs which points specifically to
wards an infrastructure failure? In which case you should have mentioned it
here.

> 
> Same test job passed in
> http://logs.test-lab.xenproject.org/osstest/logs/61306/
> 
> The differences of xen-unstable between 61306 and this flight are:
> 
> a7b39c8bd libxc: add assertion to avoid setting same bit more than once
> e8e9f830d libxc: don't populate same pfn more than once in populate_pfns
> e00f8a1a7 libxc: fix indentation
> 76d75222a libxc: migration v2 prefix Memory -> Frames
> 477619384 libxc: clearer migration v2 debug message
> 
> Tested in migration jobs and passed.
> 
> b2700877a public/io/netif.h: move and amend multicast control
> documentation
> 09e2a619a MAINTAINERS: tools/ocaml: update David Scott's email address
> 06925643c build: update top-level make help
> 
> Doc update, irrelevant to failure.
> 
> f42f2cbe5 xen/dt: Handle correctly node without interrupt-map in
> dt_for_each_irq_map
> 
> ARM, irrelevant to failure.
> 
> d9be0990f tools/xen-access: use PRI_xen_pfn
> 
> Not tested in OSSTest
> 
> 0a7167d9b xen/arm64: do not (incorrectly) limit size of xenheap
> 
> ARM, irrelevant to failure.
> 
> 8747dba3b Merge branch 'staging' of
> ssh://xenbits.xen.org/home/xen/git/xen into staging
> 076cd5065 tmem: Spelling and full stop surgery.
> fee800b94 tmem: Remove extra spaces at end and some hard tabbing.
> 880699a8b tmem: Use 'struct xen_tmem_oid' in tmem_handle and move it to
> sysctl header.
> b657a8ad1 tmem: Use 'struct xen_tmem_oid' for every user.
> 987e64e05 tmem: Make the uint64_t oid[3] a proper structure: xen_tmem_oid
> ad1b7a139 tmem: Remove the old tmem control XSM checks as it is part of
> sysctl hypercall.
> d0edc15a6 tmem: Move TMEM_CONTROL subop of tmem hypercall to sysctl.
> 54a51b176 tmem: Remove xc_tmem_control mystical arg3
> 1682d2fdf tmem: Remove in xc_tmem_control_oid duplicate
> set_xen_guest_handle call
> 7646da32f tmem: Add ASSERT in obj_rb_insert for pool->rwlock lock.
> 7ec4b2f89 tmem: Don't crash/hang/leak hypervisor when using shared pools
> within an guest.
> 
> Not tested in OSSTest.
> 
> 16181cbb1 tools: Honor Config.mk debug value, rather than setting our own
> 
> Passed, and irrelevant to failure.
> 
> Wei.

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

Re: [Xen-devel] [xen-unstable test] 61521: regressions - FAIL

[Jan Beulich]

>>> On 08.09.15 at 16:52,  wrote:
> On Tue, Sep 08, 2015 at 02:30:30PM +, osstest service owner wrote:
>> flight 61521 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/61521/ 
>> 
>> Regressions :-(
>> 
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  test-amd64-amd64-xl-qemut-debianhvm-amd64 19 guest-start/debianhvm.repeat 
>> fail 
> REGR. vs. 61059
>> 
> 
> I suspect this failure is due to infrastructure problem.

This or some random (but reoccurring) failure. Not so long ago I
already mentioned that for the purpose of just determining whether
a guest is up

ssh: connect to host 172.16.145.6 port 22: Connection refused

is sufficient, as that means there was a response (albeit a
negative one). But whether the refusal is due to something
getting corrupted in the networking stack or due to an
infrastructure problem is rather hard to tell.

Jan


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

Re: [Xen-devel] [PATCH] MAINTAINERS: stable backports should be requested on xen-devel

[Ian Jackson]

Ian Campbell writes ("Re: [PATCH] MAINTAINERS: stable backports should be 
requested on xen-devel"):
> AIUI the branching process involves tweaking this text to refer to the
> specific maintainers of the given stable branch.

Yes.  Sometimes older stable branches have different maintainers.

> IOW I think the "backport" of this might be a little more involved, but
> hopefully fairly obvious -- Ian, do you think you can deal with it?

Yes.

Ian.

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

Re: [Xen-devel] [xen-unstable test] 61521: regressions - FAIL

[Ian Jackson]

Ian Jackson writes ("Re: [Xen-devel] [xen-unstable test] 61521: regressions - 
FAIL"):
> A more likely explanation is that the host sometimes fails to complete
> its bootup within a reasonable time.

Actually, looking at a bit more of the osstest transcript:

2015-09-08 09:14:32 Z guest debianhvm.guest.osstest 5a:36:0e:51:00:2a 22 
link/ip/tcp: ok. (18s)
2015-09-08 09:14:33 Z executing ssh ... root@172.16.145.6 echo guest 
debianhvm.guest.osstest: ok
ssh: connect to host 172.16.145.6 port 22: Connection refused

The first message means that
  nc -n -v -z -w $interval $ho->{Ip} $ho->{TcpCheckPort}
succeeded.  The IP address is the one from DHCP and the port is 22
as you see printed.  $interval is 5.

So what this means is that the osstest controller successfully made a
tcp connection to the guest's port 22.  It then went on to the next
check which is actually to try ssh'ing to the host.  But ssh got
ECONNREFUSED.

This means that the guest was accepting connections on 172.16.145.6:22
and then stopped doing so (perhaps only briefly).

Ian.

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

Re: [Xen-devel] [xen-unstable test] 61521: regressions - FAIL

[Jan Beulich]

>>> On 08.09.15 at 17:45,  wrote:
> Ian Jackson writes ("Re: [Xen-devel] [xen-unstable test] 61521: regressions - 
> FAIL"):
>> A more likely explanation is that the host sometimes fails to complete
>> its bootup within a reasonable time.
> 
> Actually, looking at a bit more of the osstest transcript:
> 
> 2015-09-08 09:14:32 Z guest debianhvm.guest.osstest 5a:36:0e:51:00:2a 22 
> link/ip/tcp: ok. (18s)
> 2015-09-08 09:14:33 Z executing ssh ... root@172.16.145.6 echo guest 
> debianhvm.guest.osstest: ok
> ssh: connect to host 172.16.145.6 port 22: Connection refused
> 
> The first message means that
>   nc -n -v -z -w $interval $ho->{Ip} $ho->{TcpCheckPort}
> succeeded.  The IP address is the one from DHCP and the port is 22
> as you see printed.  $interval is 5.
> 
> So what this means is that the osstest controller successfully made a
> tcp connection to the guest's port 22.  It then went on to the next
> check which is actually to try ssh'ing to the host.  But ssh got
> ECONNREFUSED.
> 
> This means that the guest was accepting connections on 172.16.145.6:22
> and then stopped doing so (perhaps only briefly).

That's what I was about to say in a reply to your earlier mail. To me
this still means the guest booted up successfully (or else it wouldn't
have accepted the TCP connection). I agree its "ssh server" service
is unavailable (or unreliable), which is bad, but which then again we
have no real handle to deal with without someone running into it
outside of osstest.

Whether to use this as justification for a force push I'm not sure
anyway.

Jan


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

[Xen-devel] [v2][PATCH] xen/vtd/iommu: permit group devices to passthrough in relaxed mode

[Tiejun Chen]

Currently we don't allow passing through any group devices which are
sharing same RMRR entry since it would break security among VMs. And
indeed, we expect we can figure out a better way to handle this kind
of case completely.

But before the group assignment gets implemented, we might make this
permission dependent on our RMRR policy. So, now it would be allowed
in the relaxed mode.

CC: Yang Zhang 
CC: Kevin Tian 
CC: Jan Beulich 
CC: Wei Liu 
Signed-off-by: Tiejun Chen 
---
v2:

* Sync code comments
* refactor vaiable "relaxed" as bool_t
* s/XENLOG_G_ERR VTDPREFIX/XENLOG_G_WARNING VTDPREFIX
* Try to refine print message

 xen/drivers/passthrough/vtd/iommu.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index 836aed5..7b45bff 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2297,7 +2297,9 @@ static int intel_iommu_assign_device(
 /*
  * In rare cases one given rmrr is shared by multiple devices but
  * obviously this would put the security of a system at risk. So
- * we should prevent from this sort of device assignment.
+ * we would prevent from this sort of device assignment. But this
+ * can be permitted if user set
+ *  "pci = [ 'sbdf, rdm_policy=relaxed' ]"
  *
  * TODO: in the future we can introduce group device assignment
  * interface to make sure devices sharing RMRR are assigned to the
@@ -2310,12 +2312,16 @@ static int intel_iommu_assign_device(
  PCI_DEVFN2(bdf) == devfn &&
  rmrr->scope.devices_cnt > 1 )
 {
-printk(XENLOG_G_ERR VTDPREFIX
-   " cannot assign %04x:%02x:%02x.%u"
+bool_t relaxed = !!(flag & XEN_DOMCTL_DEV_RDM_RELAXED);
+
+printk(XENLOG_G_WARNING VTDPREFIX
+   " It's %s to assign %04x:%02x:%02x.%u"
" with shared RMRR at %"PRIx64" for Dom%d.\n",
+   relaxed ? "risky" : "disallowed",
seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
rmrr->base_address, d->domain_id);
-return -EPERM;
+if ( !relaxed )
+return -EPERM;
 }
 }
 
-- 
1.9.1


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

[Xen-devel] [linux-3.4 test] 61526: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  6 xen-boot fail REGR. vs. 30511
 test-amd64-amd64-xl-qemuu-winxpsp3  6 xen-bootfail REGR. vs. 30511
 test-amd64-amd64-xl-qemut-debianhvm-amd64  6 xen-boot fail REGR. vs. 30511
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot fail REGR. vs. 30511
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  6 xen-boot  fail REGR. vs. 30511
 test-amd64-i386-xl-qemut-winxpsp3  6 xen-boot fail REGR. vs. 30511
 test-amd64-amd64-rumpuserxen-amd64  6 xen-bootfail REGR. vs. 30511
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot   fail REGR. vs. 30511
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 30511
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot  fail REGR. vs. 30511
 test-amd64-amd64-xl-qemut-winxpsp3  6 xen-bootfail REGR. vs. 30511
 test-amd64-i386-freebsd10-i386  6 xen-bootfail REGR. vs. 30511
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot  fail REGR. vs. 30511
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot  fail REGR. vs. 30511
 test-amd64-i386-rumpuserxen-i386  6 xen-boot  fail REGR. vs. 30511
 test-amd64-amd64-xl-qemut-win7-amd64  6 xen-boot  fail REGR. vs. 30511
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-boot  fail REGR. vs. 30511
 test-amd64-i386-freebsd10-amd64  6 xen-boot   fail REGR. vs. 30511
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 30511

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin  6 xen-boot   fail in 58831 pass in 58798
 test-amd64-i386-xl-qemuu-win7-amd64 9 windows-install fail in 58961 pass in 
61526
 test-amd64-i386-pair 10 xen-boot/dst_host   fail pass in 58831
 test-amd64-i386-pair  9 xen-boot/src_host   fail pass in 58831
 test-amd64-i386-xl6 xen-bootfail pass in 58961
 test-amd64-amd64-xl   6 xen-bootfail pass in 59576
 test-amd64-amd64-pair10 xen-boot/dst_host   fail pass in 59961
 test-amd64-amd64-libvirt  6 xen-bootfail pass in 60064
 test-amd64-amd64-pair 9 xen-boot/src_host   fail pass in 60953

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail baseline untested
 test-amd64-amd64-xl-multivcpu  6 xen-boot   fail baseline untested
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail baseline untested
 test-amd64-amd64-xl-credit2   6 xen-bootfail baseline untested
 test-amd64-amd64-xl-xsm   6 xen-bootfail baseline untested
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail baseline untested
 test-amd64-amd64-i386-pvgrub  6 xen-bootfail baseline untested
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail baseline 
untested
 test-amd64-i386-libvirt-xsm   6 xen-bootfail baseline untested
 test-amd64-amd64-libvirt-qcow2  6 xen-boot  fail baseline untested
 test-amd64-amd64-xl-rtds  6 xen-bootfail baseline untested
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail baseline untested
 test-amd64-amd64-xl-qcow2 6 xen-bootfail baseline untested
 test-amd64-i386-xl-xsm6 xen-bootfail baseline untested
 test-amd64-amd64-pygrub   6 xen-bootfail baseline untested
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 
fail baseline untested
 test-amd64-amd64-xl-sedf  6 xen-boot  fail in 58831 like 30406
 test-amd64-amd64-libvirt-xsm  6 xen-boot   fail in 59576 baseline untested
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 12 guest-localmigrate 
fail in 59576 baseline untested
 test-amd64-amd64-libvirt 11 guest-start   fail in 59576 like 30511
 test-amd64-i386-libvirt  11 guest-start   fail in 59576 like 30511
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 11 guest-saverestore fail 
in 59961 baseline untested
 test-amd64-i386-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail in 59961 
like 30394
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail in 60064 
blocked in 30511
 test-amd64-amd64-libvirt-raw  6 xen-boot   fail in 60953 baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 30511
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 30511

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-check fail in 58831 never pass
 test-amd64-amd64-xl-pvh-amd