Re: [Xen-devel] [PATCH 24/29] drivers: convert iblock_req.pending from atomic_t to refcount_t

[Nicholas A. Bellinger]

Hi Elena,

On Mon, 2017-03-06 at 16:21 +0200, Elena Reshetova wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
> 
> Signed-off-by: Elena Reshetova 
> Signed-off-by: Hans Liljestrand 
> Signed-off-by: Kees Cook 
> Signed-off-by: David Windsor 
> ---
>  drivers/target/target_core_iblock.c | 12 ++--
>  drivers/target/target_core_iblock.h |  3 ++-
>  2 files changed, 8 insertions(+), 7 deletions(-)

For the target_core_iblock part:

Acked-by: Nicholas Bellinger 


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

Re: [Xen-devel] [PATCH v3] xen: Allow a default compiled-in command line using Kconfig

[Zhongze Liu]

So, taking all of the conversations above into consideration, the
following changes
should be done to this patch:

1. According to Andrew and Jan's suggestions, I'll remove the
CMDLINE_BOOL option,
and deal with CMDLINE without the #ifdef-ary's.

2. Make the option CMDLINE_OVERRIDE depends on EXPERT.

3. Move the duplicated code in the various setup.c's into
common/kernel.c; Introduce a wrapper
to common/kernel.c:cmdline_parse(), and let that wrapper
automatically deal with CONFIG_CMDLINE,
so the start_xen()'s won't be bothered to do the concatenation by
themselves.

4. As for the different behavior between arm and x86 on handling the
dom0 options after " -- " in the
command line, I will left this difference as untouched, coz
whether to add this feature to arm or to remove
this feature from x86 is beyond the scope of this patch.

But there's one thing that I'm not quite sure. Since currently there
isn't any cumulative options in
Xen, I just can't deal with them - Jan?

2017-03-08 5:37 GMT+08:00 Stefano Stabellini :
> On Tue, 7 Mar 2017, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 03/07/2017 07:54 PM, Stefano Stabellini wrote:
>> > On Tue, 7 Mar 2017, Julien Grall wrote:
>> > Given that upstream GRUB doesn't yet support booting Xen on ARM (without
>> > any additional patches), I think that the ability to completely change
>> > the command line from the EFI shell would be useful. Besides, although
>> > it is not mandatory, I think it would be best not to unnecessarily
>> > diverge from x86 in terms of EFI booting.
>>
>> I don't consider x86 solution as granted for ARM, and I would have thought it
>> was the same on your side given the change you requested for dom0_mem
>> recently.
>
> I agree. I am only saying that all things being equal, we might as well
> keep compatibility. If nothing else, it will be easier to write docs.
> The dom0_mem case is an example where things are not equal between x86
> and arm, but the parameter still works similarly across the two archs.
>
>
>> I still don't see a reason to override the command line option as usually the
>> issue will not be because of the command line but the kernel itself. At least
>> this is my experience on ARM so far.
>
> I think it can be useful, even just for tests, especially given that
> grub is still unable to boot Xen.
>
>
>> Anyway, I am not going to argue on this. If you think it should be done, then
>> it should be in a separate patch.
>
> That would be best.

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

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

[osstest service owner]

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 106491
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106491
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 106491
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 106491
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 106491
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 106491

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   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-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu43c227f9dd7945bb4a895f841ecdb957bd8a12da
baseline version:
 qemuufbddc2e5608eb655493253d080598375db61a748

Last test of basis   106491  2017-03-06 13:14:18 Z1 days
Failing since106508  2017-03-06 21:44:30 Z1 days3 attempts
Testing same since   106532  2017-03-07 17:15:28 Z0 days1 attempts


People who touched revisions under test:
  Bruce Rogers 
  Cédric Le Goater 
  David Gibson 

Re: [Xen-devel] [PATCH v16 4/9] x86: add multiboot2 protocol support for EFI platforms

[Konrad Rzeszutek Wilk]

On Tue, Mar 07, 2017 at 12:39:04AM +0100, Daniel Kiper wrote:
> On Wed, Feb 22, 2017 at 09:04:17AM -0800, Doug Goldstein wrote:
> 
> [...]
> 
> > I'm currently at ELC and then on vacation so I don't have access to any
> > of the machines currently myself. However the machine I most use to test
> > is a NUC5i5MYHE and a NUC5i3MYHE if you want to ask around if someone
> > has one internally. But that's why I gave QEMU as an example.
> >
> > I was using qemu master from a few weeks ago. I'll have to find the
> > revision for you. But the command line I use is:
> >
> > -enable-kvm -M pc-q35-2.8 -device intel-iommu -cpu host -m 2048 -smp 2
> > -drive if=pflash,format=raw,file=/tmp/tmp.EiR6ixmYzV -global
> > isa-debugcon.iobase=0x402 -debugcon file:/tmp/tmp.nuvEXUWfnA -monitor
> > stdio -chardev socket,host=127.0.0.1,port=25914,id=S0,server,nowait
> > -device isa-serial,chardev=S0 -device piix3-usb-uhci -device usb-tablet
> > -netdev id=net0,type=tap -device
> > virtio-net-pci,netdev=net0,mac=52:54:00:12:34:56 -boot order=n -device
> > qxl-vga -gdb tcp::14952
> 
> Sadly, my colleagues and I are not able to reproduce the problem on any of
> machines available for us (available on the market and some development
> stuff in our labs). I did tests with QEMU (I am not able to run it with
> "-device intel-iommu" on my machine; I have to investigate this). Everything
> works. Joao did some tests on Intel NUC D34010WYK second generation.
> Everything works. So, Konrad ordered Intel NUC NUC5i3MYHE for me. I am
> waiting for delivery. Doug, could you tell me what distro, Xen, etc. you
> have installed on that NUC? I would like to test same config as yours on
> this machine.

I had a chat with Doug on IRC and:
 - I had tested earlier on AMD, while he has only Intel boxes,
 - He was wondering if this was an IOMMU issue.

So to double-check that, I installed Ubuntu 16.10 on my X11SAE
SuperMicro, which has an Haswell E3-1245 v5 and with IOMMU enabled.

I tested the 'origin/staging' xen.gz build with the upstream grub2
(I just used the 'master' branch) first and also just booting xen.efi.

Both worked fine.

Then I used v16 of Daniel's patches (this thread). They are also
now on  git://xenbits.xen.org/people/konradwilk/xen.git mb2.v16
also the same way - as xen.efi and then using grub.efi and booting it
(see below)

All worked fine.

Now in the process I discovered that my patch for grub-mkconfig to
detect multiboot2 payloads and use those instead of multiboot never
made it upstream, so I had to modify my grub.cfg by hand (see below).

xen.cfg:
[global]
default=ubuntu

[ubuntu]
options=console=vga,com1 com1=115200,8n1 iommu=verbose ucode=scan 
flask=disabled conring_size=2097152  loglvl=all
kernel=vmlinuz root=UUID=3f1e35fb-9907-48d1-b621-42369d5ad88f ro quiet 
vt.handoff=7 console=hvc0
ramdisk=initrd.img


fs0:\EFI\xen> xen
Xen 4.9-unstable
(XEN) Xen version 4.9-unstable (konrad@) (gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 
20161005) debug=y  Tue Mar  7 22:13:08 EST 2017
(XEN) Latest ChangeSet: Tue Feb 21 20:19:58 2017 +0100 git:e4ccbd0
(XEN) Bootloader: EFI
(XEN) Command line: console=vga,com1 com1=115200,8n1 iommu=verbose ucode=scan 
flask=disabled conring_size=2097152  loglvl=all
(XEN) Xen image load base address: 0x2980
(XEN) Video information:
(XEN)  VGA is graphics mode 1280x1024, 32 bpp
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) EFI RAM map:
(XEN)   - 00058000 (usable)
(XEN)  00058000 - 00059000 (reserved)
(XEN)  00059000 - 0009f000 (usable)
(XEN)  0009f000 - 000a (reserved)
(XEN)  0010 - 2ae33000 (usable)
(XEN)  2ae33000 - 2ae34000 (ACPI NVS)
(XEN)  2ae34000 - 2ae7e000 (reserved)
(XEN)  2ae7e000 - 2e8c1000 (usable)
(XEN)  2e8c1000 - 2ec64000 (reserved)
(XEN)  2ec64000 - 2eddf000 (usable)
(XEN)  2eddf000 - 2f3eb000 (ACPI NVS)
(XEN)  2f3eb000 - 2000 (reserved)
(XEN)  2000 - 3000 (usable)
(XEN)  3000 - 3800 (reserved)
(XEN)  e000 - f000 (reserved)
(XEN)  fe00 - fe011000 (reserved)
(XEN)  fec0 - fec01000 (reserved)
(XEN)  fee0 - fee01000 (reserved)
(XEN)  ff00 - 0001 (reserved)
(XEN)  0001 - 0008c340 (usable)
(XEN) ACPI: RSDP 2EE67000, 0024 (r2 SUPERM)
(XEN) ACPI: XSDT 2EE670B0, 00DC (r1 SUPERM   SUPERM  1072009 AMI 10013)
(XEN)1072009 AMI 10013)
(XEN) ACPI: FPDT 2EE8A778, 0044 (r1  1072009 AMI 10013)
(XEN) ACPI: FIDT 2EE8A7C0, 009C (r1  1072009 AMI 10013)
(XEN) ACPI: MCFG 2EE8A860, 003C (r1 SUPERM SMCI--MB  1072009 MSFT   97)
(XEN) ACPI: HPET 2EE8A8A0, 0038 (r1 SUPERM SMCI--MB  1072009 AMI.

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

[Xuquan (Quan Xu)]

On March 07, 2017 12:24 PM, Chao Gao wrote:
>On Tue, Mar 07, 2017 at 02:16:50AM -0700, Jan Beulich wrote:
> On 07.03.17 at 06:52,  wrote:
>>> flight 106504 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/106504/
>>>
>>> Regressions :-(
>>>
>>> Tests which did not succeed and are blocking, including tests which
>>> could not be run:
>>>  [...]
>>>  test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 16 guest-stop fail
>REGR. vs.
>>> 106482
>>
>>Here we go:
>>
>>(XEN) d15v0: intack: 02:48 pt: 38
>>(XEN) vIRR:      
>>0001 
>>(XEN)  PIR:     
>
>> 
>>(XEN) Assertion 'intack.vector >= pt_vector' failed at intr.c:360
>>(XEN) [ Xen-4.9-unstable  x86_64  debug=y   Not tainted ]
>>(XEN) CPU:0
>>(XEN) RIP:e008:[] vmx_intr_assist+0x5fa/0x61a
>>(XEN) RFLAGS: 00010292   CONTEXT: hypervisor (d15v0)
>>(XEN) rax: 82d0804754a8   rbx: 83007f375680   rcx:
>
>>(XEN) rdx: 83007cd3   rsi: 000a   rdi:
>82d0803316d8
>>(XEN) rbp: 83007cd3ff08   rsp: 83007cd3fea8   r8:
>830277db8000
>>(XEN) r9:  0001   r10:    r11:
>0001
>>(XEN) r12:    r13: 82d0802b5b02   r14:
>82d0802b5b02
>>(XEN) r15: 83027d82e000   cr0: 80050033   cr4:
>001526e0
>>(XEN) cr3: 000259135000   cr2: 0164f034
>>(XEN) ds:    es:    fs:    gs:    ss:    cs: e008
>>(XEN) Xen code around  (vmx_intr_assist+0x5fa/0x61a):
>>(XEN)  fb ff ff e9 49 fc ff ff <0f> 0b 89 ce 48 89 df e8 2a 21 00 00 e9
>>49 fe ff
>>(XEN) Xen stack trace from rsp=83007cd3fea8:
>>(XEN)82d08044ab00 0038 83007cd3
>83027d82e000
>>(XEN)83007cd3fef8 82d080133a3d 83007f375000
>83007f375000
>>(XEN)83007f7fc000 83026df78000 
>83027d82e000
>>(XEN)83007cd3fdb0 82d080213191 0004
>00c2
>>(XEN)0020 0002 880029994000
>81ade0a0
>>(XEN)0246  88002d08
>0004
>>(XEN)006c  03f8
>03f8
>>(XEN)81ade0a0 beefbeef 81389ac4
>00bfbeef
>>(XEN)0002 88002f403e08 beef
>beef
>>(XEN)beef beef beef
>
>>(XEN)83007f375000  001526e0
>>(XEN) Xen call trace:
>>(XEN)[] vmx_intr_assist+0x5fa/0x61a
>>(XEN)[] vmx_asm_vmexit_handler+0x41/0x120
>>(XEN)
>>(XEN)
>>(XEN) 
>>(XEN) Panic on CPU 0:
>>(XEN) Assertion 'intack.vector >= pt_vector' failed at intr.c:360
>>(XEN) 
>>
>>I didn't make an attempt at interpreting this yet, but I wonder if it
>>is more than coincidence that - just like the first time the ASSERT()
>>triggered - this is again a guest-stop of a qemuu-debianhvm.
>>
>
>Cc: xuquan.
Also Cc: Andrew, who is really a debug expert :)..

>
>Exciting! I have been monitoring osstest for about one months through a
>python script. But I always crawl the flights one time a day.
>
>From the output, the pt_vector is 0x38 and the intack.vector is 0x30. these
>two values are same with they were in the first time.
>And only one bit 0x30 is set in vIRR. PIR is NULL. So maybe our suspicion that
>PIR is not synced to vIRR is wrong. The 0x38 bit is not present in vIRR is
>strange. Is it possible that we clear the 0x38 bit just after we return from
>pt_update_irq()? Or, just like I suspected that it is caused by pt_update_irq()
>sets 0x30 but wrongly returns 0x38.
>Do you think it worths a try to disable guest's LAPIC timer and force it use
>IRQ0 along with changing RTE very frequently?
>If yes, I am glad to do it.
>

I can't find a reasonable explanation for this regression.. However I found 
that self-ipi virtualization also sets 1 to 'VIRR[vector]'..
It might be a corner case with some special guest, such as mentioned above, 
debian.. 


Quan

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

[Xen-devel] [PATCH v3 6/7] xen/mce: remove ASSERT's about mce_[u|d]handler_num in mce_action()

[Haozhong Zhang]

Those assertions as well as mce_[u|d]handlers[], mce_[u|d]handler_num
and mce_action() were intel only and lifted to the common code by c/s
3a91769d6e1. However, MCE handling on AMD does not use mce_[u|d]handlers[]
before and after that commit, so assertions in mce_action() about their
size do not make sense for AMD. To be worse, they can crash the debug
build on AMD. Remove them to make the debug build work on AMD.

Signed-off-by: Haozhong Zhang 
---
Cc: Christoph Egger 
Cc: Jan Beulich 
Cc: Andrew Cooper 

Changes in v3:
 * Explain the reason in the commit message.

Because other patches in v2 have got R-b or A-b, I only send v3 patch 6.
---
 xen/arch/x86/cpu/mcheck/mce.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 35117f8..cd4f0ee 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1616,9 +1616,6 @@ static enum mce_result mce_action(const struct 
cpu_user_regs *regs,
 handlers = mce_uhandlers;
 }
 
-/* At least a default handler should be registerd */
-ASSERT(handler_num);
-
 local_mi = (struct mc_info*)mctelem_dataptr(mctc);
 x86_mcinfo_lookup(mic, local_mi, MC_TYPE_GLOBAL);
 if (mic == NULL) {
@@ -1651,7 +1648,6 @@ static enum mce_result mce_action(const struct 
cpu_user_regs *regs,
 break;
 }
 }
-ASSERT(i != handler_num);
 }
 
 return worst_result;
-- 
2.10.1


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

[Xen-devel] [xen-4.6-testing test] 106529: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
105991

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 105991
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 105991
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 105991
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 105991
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 105991
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 105991
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 105991

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-1   63 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-2   63 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-5   63 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-3   63 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-xtf-amd64-amd64-4   63 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
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-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  abb5a1291555d0e33a19e2a252f00852a9026f98
baseline version:
 xen  e9fbb8eb834b21a6f0ed18f41e35baa74ada3205

Last test of basis   105991  2017-02-22 17:09:42 Z   13 days
Testing same since   106529  2017-03-07 16:41:56 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

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

Re: [Xen-devel] [PATCH 6/7] xen/9pfs: receive responses

[Stefano Stabellini]

On Tue, 7 Mar 2017, Stefano Stabellini wrote:
> > > +
> > > + ring = container_of(work, struct xen_9pfs_dataring, work);
> > > + priv = ring->priv;
> > > +
> > > + while (1) {
> > > + cons = ring->intf->in_cons;
> > > + prod = ring->intf->in_prod;
> > > + rmb();
> > 
> > 
> > Is this rmb() or mb()? (Or, in fact, virt_XXX()?) You used mb() in the
> > previous patch.
>  
> I think they should all be virt_XXX, thanks.

regarding mb() vs. rmb(), give a look at the workflow at the end of
docs/misc/9pfs.markdown, under "Ring Usage".

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

Re: [Xen-devel] [PATCH 6/7] xen/9pfs: receive responses

[Stefano Stabellini]

On Tue, 7 Mar 2017, Boris Ostrovsky wrote:
> On 03/06/2017 03:01 PM, Stefano Stabellini wrote:
> > Upon receiving a notification from the backend, schedule the
> > p9_xen_response work_struct. p9_xen_response checks if any responses are
> > available, if so, it reads them one by one, calling p9_client_cb to send
> > them up to the 9p layer (p9_client_cb completes the request). Handle the
> > ring following the Xen 9pfs specification.
> > 
> > Signed-off-by: Stefano Stabellini 
> > CC: boris.ostrov...@oracle.com
> > CC: jgr...@suse.com
> > CC: Eric Van Hensbergen 
> > CC: Ron Minnich 
> > CC: Latchesar Ionkov 
> > CC: v9fs-develo...@lists.sourceforge.net
> > ---
> >  net/9p/trans_xen.c | 53 
> > +
> >  1 file changed, 53 insertions(+)
> > 
> > diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
> > index 4e26556..1ca9246 100644
> > --- a/net/9p/trans_xen.c
> > +++ b/net/9p/trans_xen.c
> > @@ -149,6 +149,59 @@ static int p9_xen_request(struct p9_client *client, 
> > struct p9_req_t *p9_req)
> >  
> >  static void p9_xen_response(struct work_struct *work)
> >  {
> > +   struct xen_9pfs_front_priv *priv;
> > +   struct xen_9pfs_dataring *ring;
> > +   RING_IDX cons, prod, masked_cons, masked_prod;
> > +   struct xen_9pfs_header h;
> > +   struct p9_req_t *req;
> > +   int status = REQ_STATUS_ERROR;
> 
> 
> Doesn't this need to go inside the loop?

Yes, thank you!


> > +
> > +   ring = container_of(work, struct xen_9pfs_dataring, work);
> > +   priv = ring->priv;
> > +
> > +   while (1) {
> > +   cons = ring->intf->in_cons;
> > +   prod = ring->intf->in_prod;
> > +   rmb();
> 
> 
> Is this rmb() or mb()? (Or, in fact, virt_XXX()?) You used mb() in the
> previous patch.
 
I think they should all be virt_XXX, thanks.


> > +
> > +   if (xen_9pfs_queued(prod, cons, XEN_9PFS_RING_SIZE) < 
> > sizeof(h)) {
> > +   notify_remote_via_irq(ring->irq);
> > +   return;
> > +   }
> > +
> > +   masked_prod = xen_9pfs_mask(prod, XEN_9PFS_RING_SIZE);
> > +   masked_cons = xen_9pfs_mask(cons, XEN_9PFS_RING_SIZE);
> > +
> > +   xen_9pfs_read_packet(ring->ring.in,
> > +   masked_prod, _cons,
> > +   XEN_9PFS_RING_SIZE, , sizeof(h));
> > +
> > +   req = p9_tag_lookup(priv->client, h.tag);
> > +   if (!req || req->status != REQ_STATUS_SENT) {
> > +   dev_warn(>dev->dev, "Wrong req tag=%x\n", h.tag);
> > +   cons += h.size;
> > +   mb();
> > +   ring->intf->in_cons = cons;
> > +   continue;
> 
> 
> I don't know what xen_9pfs_read_packet() does so perhaps it's done there
> but shouldn't the pointers be updated regardless of the 'if' condition?

This is the error path - the index is increased immediately. In the
non-error case, we do that right after the next read_packet call, few
lines below.


> > +   }
> > +
> > +   memcpy(req->rc, , sizeof(h));
> > +   req->rc->offset = 0;
> > +
> > +   masked_cons = xen_9pfs_mask(cons, XEN_9PFS_RING_SIZE);
> > +   xen_9pfs_read_packet(ring->ring.in,
> > +   masked_prod, _cons,
> > +   XEN_9PFS_RING_SIZE, req->rc->sdata, h.size);
> > +
> > +   mb();
> > +   cons += h.size;
> > +   ring->intf->in_cons = cons;

   Here ^


> > +   if (req->status != REQ_STATUS_ERROR)
> > +   status = REQ_STATUS_RCVD;
> > +
> > +   p9_client_cb(priv->client, req, status);
> > +   }
> >  }
> >  
> >  static irqreturn_t xen_9pfs_front_event_handler(int irq, void *r)
> > 
> 

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail   like 68637
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail   like 68637
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail   like 68637
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 68637
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 68637
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  9 windows-installfail like 68637
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-installfail like 68637
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 68637

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-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-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 xen  caf053fb545329e58ac891d197f96503e3121049
baseline version:
 xen  6d55c0c316357a412526b9dccd45d3c3abb75227

Last test of basis68637  2017-03-05 01:44:37 Z2 days
Testing same since68642  2017-03-07 15:13:58 Z0 days1 attempts


People who touched revisions under test:
  Edgar E. Iglesias 
  Jan Beulich 

Re: [Xen-devel] [PATCH 5/7] xen/9pfs: send requests to the backend

[Stefano Stabellini]

On Tue, 7 Mar 2017, Boris Ostrovsky wrote:
> On 03/06/2017 03:01 PM, Stefano Stabellini wrote:
> > Implement struct p9_trans_module create and close functions by looking
> > at the available Xen 9pfs frontend-backend connections. We don't expect
> > many frontend-backend connections, thus walking a list is OK.
> > 
> > Send requests to the backend by copying each request to one of the
> > available rings (each frontend-backend connection comes with multiple
> > rings). Handle the ring and notifications following the 9pfs
> > specification. If there are not enough free bytes on the ring for the
> > request, wait on the wait_queue: the backend will send a notification
> > after consuming more requests.
> > 
> > Signed-off-by: Stefano Stabellini 
> > CC: boris.ostrov...@oracle.com
> > CC: jgr...@suse.com
> > CC: Eric Van Hensbergen 
> > CC: Ron Minnich 
> > CC: Latchesar Ionkov 
> > CC: v9fs-develo...@lists.sourceforge.net
> > ---
> >  net/9p/trans_xen.c | 83 
> > +-
> >  1 file changed, 82 insertions(+), 1 deletion(-)
> > 
> > diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
> > index 9f6cf8d..4e26556 100644
> > --- a/net/9p/trans_xen.c
> > +++ b/net/9p/trans_xen.c
> > @@ -47,22 +47,103 @@ struct xen_9pfs_front_priv {
> >  };
> >  static LIST_HEAD(xen_9pfs_devs);
> >  
> > +/* We don't currently allow canceling of requests */
> >  static int p9_xen_cancel(struct p9_client *client, struct p9_req_t *req)
> >  {
> > -   return 0;
> > +   return 1;
> >  }
> >  
> >  static int p9_xen_create(struct p9_client *client, const char *addr, char 
> > *args)
> >  {
> > +   struct xen_9pfs_front_priv *priv = NULL;
> > +
> > +   list_for_each_entry(priv, _9pfs_devs, list) {
> > +   if (!strcmp(priv->tag, addr))
> > +   break;
> > +   }
> 
> 
> You could simplify this (and p9_xen_close()) but assigning client and
> returning from inside the 'if' statement.

I'll do that.


> I am also not sure you need to initialize priv.
 
With the new changes, I won't need to.

 
> > +   if (!priv || strcmp(priv->tag, addr))
> > +   return -EINVAL;
> > +
> > +   priv->client = client; 
> > return 0;
> >  }
> >  
> >  static void p9_xen_close(struct p9_client *client)
> >  {
> > +   struct xen_9pfs_front_priv *priv = NULL;
> > +
> > +   list_for_each_entry(priv, _9pfs_devs, list) {
> > +   if (priv->client == client)
> > +   break;
> > +   }
> > +   if (!priv || priv->client != client)
> > +   return;
> > +
> > +   priv->client = NULL; 
> > +   return;
> > +}
> > +
> > +static int p9_xen_write_todo(struct xen_9pfs_dataring *ring, RING_IDX size)
> > +{
> > +   RING_IDX cons, prod;
> > +
> > +   cons = ring->intf->out_cons;
> > +   prod = ring->intf->out_prod;
> > +   mb();
> > +
> > +   if (XEN_9PFS_RING_SIZE - xen_9pfs_queued(prod, cons, 
> > XEN_9PFS_RING_SIZE) >= size)
> > +   return 1;
> > +   else
> > +   return 0;
> >  }
> >  
> >  static int p9_xen_request(struct p9_client *client, struct p9_req_t 
> > *p9_req)
> >  {
> > +   struct xen_9pfs_front_priv *priv = NULL;
> > +   RING_IDX cons, prod, masked_cons, masked_prod;
> > +   unsigned long flags;
> > +   uint32_t size = p9_req->tc->size;
> > +   struct xen_9pfs_dataring *ring;
> > +   int num;
> > +
> > +   list_for_each_entry(priv, _9pfs_devs, list) {
> > +   if (priv->client == client)
> > +   break;
> > +   }
> > +   if (priv == NULL || priv->client != client)
> > +   return -EINVAL;
> > +
> > +   num = p9_req->tc->tag % priv->num_rings;
> > +   ring = >rings[num];
> > +
> > +again:
> > +   while (wait_event_interruptible(ring->wq,
> > +   p9_xen_write_todo(ring, size) > 0) != 0);
> > +
> > +   spin_lock_irqsave(>lock, flags);
> > +   cons = ring->intf->out_cons;
> > +   prod = ring->intf->out_prod;
> > +   mb();
> > +
> > +   if (XEN_9PFS_RING_SIZE - xen_9pfs_queued(prod, cons, 
> > XEN_9PFS_RING_SIZE) < size) {
> 
> 
> This looks like p9_xen_write_todo().

p9_xen_write_todo is just a wrapper around xen_9pfs_queued to provide
a return value that works well with wait_event_interruptible.

I would prefer not to call p9_xen_write_todo here, because it's simpler
if we don't read prod and cons twice.


> BTW, where is xen_9pfs_queued()
> defined? I couldn't find it. Same for xen_9pfs_mask() and
> xen_9pfs_write_packet().

They are provided by the new ring macros, see
include/xen/interface/io/ring.h (the first patch).


> > +   spin_unlock_irqrestore(>lock, flags);
> > +   goto again;
> > +   }
> > +
> > +   masked_prod = xen_9pfs_mask(prod, XEN_9PFS_RING_SIZE);
> > +   masked_cons = xen_9pfs_mask(cons, XEN_9PFS_RING_SIZE);
> > +
> > +   xen_9pfs_write_packet(ring->ring.out,
> > +   _prod, masked_cons,
> > +   XEN_9PFS_RING_SIZE, p9_req->tc->sdata, 

Re: [Xen-devel] [PATCH 4/7] xen/9pfs: connect to the backend

[Stefano Stabellini]

On Tue, 7 Mar 2017, Julien Grall wrote:
> Hi Stefano,
> 
> On 03/06/2017 08:01 PM, Stefano Stabellini wrote:
> > +static int xen_9pfs_front_alloc_dataring(struct xenbus_device *dev,
> > +   struct xen_9pfs_dataring *ring)
> > +{
> > +   int i;
> > +   int ret = -ENOMEM;
> > +
> > +   init_waitqueue_head(>wq);
> > +   spin_lock_init(>lock);
> > +   INIT_WORK(>work, p9_xen_response);
> > +
> > +   ring->intf = (struct xen_9pfs_data_intf *) __get_free_page(GFP_KERNEL
> > | __GFP_ZERO);
> > +   if (!ring->intf)
> > +   goto error;
> > +   memset(ring->intf, 0, XEN_PAGE_SIZE);
> > +   ring->bytes = (void*)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
> > XEN_9PFS_RING_ORDER);
> 
> The ring order will be in term of Xen page size and not Linux. So you are
> going to allocate much more memory than expected on 64KB kernel.

I'll fix.


> > +   if (ring->bytes == NULL)
> > +   goto error;
> > +   for (i = 0; i < (1 << XEN_9PFS_RING_ORDER); i++)
> > +   ring->intf->ref[i] =
> > gnttab_grant_foreign_access(dev->otherend_id,
> > pfn_to_gfn(virt_to_pfn((void*)ring->bytes) + i), 0);.
> 
> Please use virt_to_gfn rather than pfn_to_gfn(virt_to_pfn).

OK


> Also, this is not going to work on 64K kernel because you will grant access to
> noncontiguous memory (e.g 0-4K, 64K-68K,...).

By using virt_to_gfn like you suggested, the loop will correctly iterate
on a 4K by 4K basis, even on a 64K kernel:

  ring->bytes = (void*)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
  XEN_9PFS_RING_ORDER - (PAGE_SHIFT - XEN_PAGE_SHIFT));
  for (i = 0; i < (1 << XEN_9PFS_RING_ORDER); i++)
  ring->intf->ref[i] = gnttab_grant_foreign_access(dev->otherend_id, 
virt_to_gfn((void*)ring->bytes) + i, 0);

where XEN_9PFS_RING_ORDER specifies the order at 4K granularity. Am I
missing something?


> We have various helper to break-down the page for you, see
> gnttab_for_one_grant, gnttab_foreach_grant, gnttab_count_grant,
> xen_for_each_gfn (though this one it is internal to xlate_mmu.c so far)
> 
> Please use them to avoid any further.
>
> > +   ring->ref = gnttab_grant_foreign_access(dev->otherend_id,
> > pfn_to_gfn(virt_to_pfn((void*)ring->intf)), 0);
> 
> Please use virt_to_gfn rather than pfn_to_gfn(virt_to_pfn).

Sure


> > +   ring->ring.in = ring->bytes;
> > +   ring->ring.out = ring->bytes + XEN_9PFS_RING_SIZE;
> > +
> > +   ret = xenbus_alloc_evtchn(dev, >evtchn);
> > +   if (ret)
> > +   goto error;
> > +   ring->irq = bind_evtchn_to_irqhandler(ring->evtchn,
> > xen_9pfs_front_event_handler,
> > +   0, "xen_9pfs-frontend", ring);
> > +   if (ring->irq < 0) {
> > +   xenbus_free_evtchn(dev, ring->evtchn);
> > +   ret = ring->irq;
> > +   goto error;
> > +   }
> > return 0;
> > +
> > +error:
> > +   if (ring->intf != NULL)
> > +   kfree(ring->intf);
> > +   if (ring->bytes != NULL)
> > +   kfree(ring->bytes);
> > +   return ret;
> >  }

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

Re: [Xen-devel] [PATCH 1/7] xen: import new ring macros in ring.h

[Stefano Stabellini]

On Tue, 7 Mar 2017, Julien Grall wrote:
> Hi Stefano,
> 
> On 03/06/2017 08:01 PM, Stefano Stabellini wrote:
> > Sync the ring.h file with upstream Xen, to introduce the new ring macros.
> > They will be used by the Xen transport for 9pfs.
> > 
> > Signed-off-by: Stefano Stabellini 
> > CC: konrad.w...@oracle.com
> > CC: boris.ostrov...@oracle.com
> > CC: jgr...@suse.com
> > 
> > ---
> > NB: The new macros have not been committed to Xen yet. Do not apply this
> > patch until they do.
> > ---
> > ---
> >  include/xen/interface/io/ring.h | 131
> > 
> >  1 file changed, 131 insertions(+)
> > 
> > diff --git a/include/xen/interface/io/ring.h
> > b/include/xen/interface/io/ring.h
> > index 21f4fbd..e16aa92 100644
> > --- a/include/xen/interface/io/ring.h
> > +++ b/include/xen/interface/io/ring.h
> 
> [...]
> 
> > +#define XEN_FLEX_RING_SIZE(order)
> > \
> > +(1UL << (order + PAGE_SHIFT - 1))
> 
> This will need to be XEN_PAGE_SHIFT in order to works with 64K kernel.

Good point! I had it right at the beginning but I lost the change in one
of the updates from xen.git.

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

Re: [Xen-devel] [PATCH 4/7] xen/9pfs: connect to the backend

[Stefano Stabellini]

On Tue, 7 Mar 2017, Boris Ostrovsky wrote:
> > +static int xen_9pfs_front_free(struct xen_9pfs_front_priv *priv)
> > +{
> > +   int i, j;
> > +
> > +   list_del(>list);
> > +
> > +   for (i = 0; i < priv->num_rings; i++) {
> > +   if (priv->rings[i].intf == NULL)
> > +   break;
> 
> Are we guaranteed that all subsequent entries are not allocated (i.e.
> this shouldn't be 'continue')?

Yes, we are guaranteed that all subsequent entries are NULL because they
are allocated in order until an error occurs.


> > +   if (priv->rings[i].irq > 0)
> > +   unbind_from_irqhandler(priv->rings[i].irq, priv->dev);
> > +   if (priv->rings[i].bytes != NULL) {
> > +   for (j = 0; j < (1 << XEN_9PFS_RING_ORDER); j++)
> > +   
> > gnttab_end_foreign_access(priv->rings[i].intf->ref[j], 0, 0);
> > +   free_pages((unsigned long)priv->rings[i].bytes, 
> > XEN_9PFS_RING_ORDER);
> > +   }
> > +   gnttab_end_foreign_access(priv->rings[i].ref, 0, 0);
> > +   free_page((unsigned long)priv->rings[i].intf);
> > +   }
> > +   kfree(priv->rings);
> > +   kfree(priv);
> > +
> > +   return 0;
> > +}
> > +
> >  static int xen_9pfs_front_remove(struct xenbus_device *dev)
> >  {
> > +   int ret;
> > +   struct xen_9pfs_front_priv *priv = dev_get_drvdata(>dev);
> > +
> > +   dev_set_drvdata(>dev, NULL);
> > +   ret = xen_9pfs_front_free(priv);
> > +   return ret;
> > +}
> > +
> > +static int xen_9pfs_front_alloc_dataring(struct xenbus_device *dev,
> > +   struct xen_9pfs_dataring *ring)
> > +{
> > +   int i;
> > +   int ret = -ENOMEM;
> > +
> > +   init_waitqueue_head(>wq);
> > +   spin_lock_init(>lock);
> > +   INIT_WORK(>work, p9_xen_response);
> > +
> > +   ring->intf = (struct xen_9pfs_data_intf *) __get_free_page(GFP_KERNEL | 
> > __GFP_ZERO);
> > +   if (!ring->intf)
> > +   goto error;
> > +   memset(ring->intf, 0, XEN_PAGE_SIZE);
> 
> get_zeroed_page()?  (especially given that __get_free_page() returns
> PAGE_SIZE, not XEN_PAGE_SIZE)

Yes, good point.


 
> > +   ring->bytes = (void*)__get_free_pages(GFP_KERNEL | __GFP_ZERO, 
> > XEN_9PFS_RING_ORDER);
> > +   if (ring->bytes == NULL)
> > +   goto error;
> > +   for (i = 0; i < (1 << XEN_9PFS_RING_ORDER); i++)
> > +   ring->intf->ref[i] = 
> > gnttab_grant_foreign_access(dev->otherend_id, 
> > pfn_to_gfn(virt_to_pfn((void*)ring->bytes) + i), 0);
> > +   ring->ref = gnttab_grant_foreign_access(dev->otherend_id, 
> > pfn_to_gfn(virt_to_pfn((void*)ring->intf)), 0);
> > +   ring->ring.in = ring->bytes;
> > +   ring->ring.out = ring->bytes + XEN_9PFS_RING_SIZE;
> > +
> > +   ret = xenbus_alloc_evtchn(dev, >evtchn);
> > +   if (ret)
> > +   goto error;
> > +   ring->irq = bind_evtchn_to_irqhandler(ring->evtchn, 
> > xen_9pfs_front_event_handler,
> > +   0, "xen_9pfs-frontend", ring);
> > +   if (ring->irq < 0) {
> > +   xenbus_free_evtchn(dev, ring->evtchn);
> > +   ret = ring->irq;
> > +   goto error;
> > +   }
> > return 0;
> > +
> > +error:
> 
> You may need to gnttab_end_foreign_access().

Actually this error path is unnecessary because it will be handled by
xen_9pfs_front_probe, that calls xen_9pfs_front_free on errors. I'll
remove it.


> > +   if (ring->intf != NULL)
> > +   kfree(ring->intf);
> > +   if (ring->bytes != NULL)
> > +   kfree(ring->bytes);
> > +   return ret;
> >  }
> >  
> >  static int xen_9pfs_front_probe(struct xenbus_device *dev,
> > const struct xenbus_device_id *id)
> >  {
> > +   int ret = -EFAULT, i;
> 
> Unnecessary initialization.

I'll remove it.


> > +   struct xenbus_transaction xbt;
> > +   struct xen_9pfs_front_priv *priv = NULL;
> > +   char *versions;
> > +   unsigned int max_rings, max_ring_order, len;
> > +
> > +   versions = xenbus_read(XBT_NIL, dev->otherend, "versions", );
> > +   if (!len || strcmp(versions, "1"))
> > +   return -EINVAL;
> > +   kfree(versions);
> > +   ret = xenbus_scanf(XBT_NIL, dev->otherend, "max-rings", "%u", 
> > _rings);
> > +   if (ret < 0 || max_rings < XEN_9PFS_NUM_RINGS)
> > +   return -EINVAL;
> > +   ret = xenbus_scanf(XBT_NIL, dev->otherend, "max-ring-page-order", "%u", 
> > _ring_order);
> > +   if (ret < 0|| max_ring_order < XEN_9PFS_RING_ORDER)
> > +   return -EINVAL;
> > +
> > +
> > +   priv = kzalloc(sizeof(struct xen_9pfs_front_priv), GFP_KERNEL);
> > +   if (!priv)
> > +   return -ENOMEM;
> > +
> > +   priv->dev = dev;
> > +   priv->num_rings = XEN_9PFS_NUM_RINGS;
> > +   priv->rings = kzalloc(sizeof(struct xen_9pfs_dataring) * 
> > priv->num_rings,
> > +   GFP_KERNEL);
> > +   if (!priv->rings) {
> > +   kfree(priv);
> > +   return -ENOMEM;
> > +   }
> > +
> > + again:
> > +   ret = xenbus_transaction_start();
> > +   if (ret) {
> > +   

[Xen-devel] [PATCH 2/2] x86/emul: Avoid #UD when emulating v{, u}comis{s, d}

[Andrew Cooper]

v{,u}comis{s,d} have two operands, so require vex.reg set to ~0.

Spotted by AFL
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/x86_emulate/x86_emulate.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c 
b/xen/arch/x86/x86_emulate/x86_emulate.c
index e09975c..08bd818 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -5673,6 +5673,7 @@ x86_emulate(
 }
 else
 {
+generate_exception_if(vex.reg != 0xf, EXC_UD);
 host_and_vcpu_must_have(avx);
 get_fpu(X86EMUL_FPU_ymm, );
 }
-- 
2.1.4


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

[Xen-devel] [PATCH 1/2] break

[Andrew Cooper]

---
 xen/arch/x86/x86_emulate/x86_emulate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c 
b/xen/arch/x86/x86_emulate/x86_emulate.c
index 1b507f7..e09975c 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -7920,7 +7920,7 @@ int x86_emulate_wrapper(
  * called hvm_inject_hw_exception() rather than using
  * x86_emul_hw_exception().)
  */
-ASSERT(ctxt->event_pending == (rc == X86EMUL_EXCEPTION));
+/* ASSERT(ctxt->event_pending == (rc == X86EMUL_EXCEPTION)); */
 
 return rc;
 }
-- 
2.1.4


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

[Xen-devel] [xen-4.7-testing test] 106528: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
106251

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  9 debian-install  fail blocked in 106251
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 106251
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 106251
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 106251
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106251
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 106251
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 106251

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

version targeted for testing:
 xen  3905d1e5f2746ffb0444fce51e61df6c8851daec
baseline version:
 xen  8550b69ba41a5b3a0aa766b91d041eeb2bc4993e

Last test of basis   106251  2017-02-28 10:11:09 Z7 days
Testing same since   106528  2017-03-07 16:41:45 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

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

[Xen-devel] [xen-unstable-smoke test] 106536: tolerable trouble: broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  4361e80d228655b100bae5d19b489b39d20aa68d
baseline version:
 xen  4036e7c592905c2292cdeba8269e969959427237

Last test of basis   106530  2017-03-07 17:04:01 Z0 days
Testing same since   106536  2017-03-07 20:01:30 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Paul Durrant 

jobs:
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [PATCH v3] xen: Allow a default compiled-in command line using Kconfig

[Stefano Stabellini]

On Tue, 7 Mar 2017, Julien Grall wrote:
> Hi Stefano,
> 
> On 03/07/2017 07:54 PM, Stefano Stabellini wrote:
> > On Tue, 7 Mar 2017, Julien Grall wrote:
> > Given that upstream GRUB doesn't yet support booting Xen on ARM (without
> > any additional patches), I think that the ability to completely change
> > the command line from the EFI shell would be useful. Besides, although
> > it is not mandatory, I think it would be best not to unnecessarily
> > diverge from x86 in terms of EFI booting.
> 
> I don't consider x86 solution as granted for ARM, and I would have thought it
> was the same on your side given the change you requested for dom0_mem
> recently.

I agree. I am only saying that all things being equal, we might as well
keep compatibility. If nothing else, it will be easier to write docs.
The dom0_mem case is an example where things are not equal between x86
and arm, but the parameter still works similarly across the two archs.


> I still don't see a reason to override the command line option as usually the
> issue will not be because of the command line but the kernel itself. At least
> this is my experience on ARM so far.

I think it can be useful, even just for tests, especially given that
grub is still unable to boot Xen.


> Anyway, I am not going to argue on this. If you think it should be done, then
> it should be in a separate patch.

That would be best.

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

[Xen-devel] [ovmf test] 106527: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 105963
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 105963

version targeted for testing:
 ovmf 7babb4372e6a34cbbc54249b25056272a5a9924c
baseline version:
 ovmf e0307a7dad02aa8c0cd8b3b0b9edce8ddb3fef2e

Last test of basis   105963  2017-02-21 21:43:31 Z   13 days
Failing since105980  2017-02-22 10:03:53 Z   13 days   38 attempts
Testing same since   106527  2017-03-07 14:19:16 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Ard Biesheuvel 
  Bi, Dandan 
  Brijesh Singh 
  Chao Zhang 
  Chen A Chen 
  Dandan Bi 
  edk2-devel On Behalf Of rthomaiy <[mailto:edk2-devel-boun...@lists.01.org]>
  Fu Siyuan 
  Hao Wu 
  Hegde Nagaraj P 
  Jeff Fan 
  Jiaxin Wu 
  Jiewen Yao 
  Laszlo Ersek 
  Leo Duran 
  Paolo Bonzini 
  Qin Long 
  Richard Thomaiyar 
  Ruiyu Ni 
  Star Zeng 
  Wu Jiaxin 
  Yonghong Zhu 
  Zhang Lubo 
  Zhang, Chao B 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



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

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

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

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


Not pushing.

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

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

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

[osstest service owner]

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

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. 59254
 test-armhf-armhf-xl  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck 11 guest-start fail REGR. vs. 59254
 test-armhf-armhf-libvirt 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu 11 guest-start  fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-armhf-armhf-xl-vhd   9 debian-di-install   fail baseline untested
 test-armhf-armhf-libvirt-raw  9 debian-di-install   fail baseline untested
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254

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

version targeted for testing:
 linuxc1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  607 days
Failing since 59348  2015-07-10 04:24:05 Z  606 days  319 attempts
Testing same since   106480  2017-03-05 23:48:45 Z1 days5 attempts


8045 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  fail
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  blocked 
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  pass
 

Re: [Xen-devel] [PATCH v3] xen: Allow a default compiled-in command line using Kconfig

[Julien Grall]

Hi Stefano,

On 03/07/2017 07:54 PM, Stefano Stabellini wrote:

On Tue, 7 Mar 2017, Julien Grall wrote:
Given that upstream GRUB doesn't yet support booting Xen on ARM (without
any additional patches), I think that the ability to completely change
the command line from the EFI shell would be useful. Besides, although
it is not mandatory, I think it would be best not to unnecessarily
diverge from x86 in terms of EFI booting.


I don't consider x86 solution as granted for ARM, and I would have 
thought it was the same on your side given the change you requested for 
dom0_mem recently.


I still don't see a reason to override the command line option as 
usually the issue will not be because of the command line but the kernel 
itself. At least this is my experience on ARM so far.


Anyway, I am not going to argue on this. If you think it should be done, 
then it should be in a separate patch.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3] xen: Allow a default compiled-in command line using Kconfig

[Stefano Stabellini]

On Tue, 7 Mar 2017, Julien Grall wrote:
> Hi Jan,
> 
> On 03/07/2017 02:52 PM, Jan Beulich wrote:
> > > > > On 07.03.17 at 15:41,  wrote:
> > > Hi Jan,
> > > 
> > > On 03/07/2017 02:18 PM, Jan Beulich wrote:
> > > > > > > On 07.03.17 at 14:48,  wrote:
> > > > > On 03/07/2017 12:52 PM, Jan Beulich wrote:
> > > > > > > > > On 07.03.17 at 12:21,  wrote:
> > > > > > > 2017-03-07 17:36 GMT+08:00 Jan Beulich :
> > > > > > > > > > > On 07.03.17 at 09:34,  wrote:
> > > > > > > > > +static inline char* __init extract_dom0_options(char
> > > > > > > > > *cmdline)
> > > > > > > > > +{
> > > > > > > > > +char *kextra;
> > > > > > > > > +
> > > > > > > > > +if ( (kextra = strstr(cmdline, " -- ")) != NULL )
> > > > > > > > > +{
> > > > > > > > > +*kextra = '\0';
> > > > > > > > > +kextra += 3;
> > > > > > > > > +while ( kextra[1] == ' ' ) kextra++;
> > > > > > > > 
> > > > > > > > The body of the while() wants to go on its own line.
> > > > > > > > 
> > > > > > > > And then - why is this Dom0 option handling done only on x86?
> > > > > > > > 
> > > > > > > 
> > > > > > > As you might have noticed, there isn't any code dealing with the
> > > > > > > dom0
> > > options
> > > > > > > in arch/arm/setup.c, and the arm version of construct_dom0()
> > > > > > > doesn't take
> > > any
> > > > > > > command line options as its parameter,
> > > > > > > so I have the reason to believe that this feature is not available
> > > > > > > under the arm architecture.
> > > > > > 
> > > > > > Looks like an omission to me - Julien, Stefano?
> > > > > 
> > > > > DOM0 and Xen command line are passed separately through either Device
> > > > > Tree or for UEFI xen configuration file (see -cfg=...).
> > > > > 
> > > > > So I am not sure to understand what would be the benefits to handle
> > > > > DOM0
> > > > > parameters after -- on Xen command line.
> > > > 
> > > > So you have no case of a boot loader which allows you to type in
> > > > extra options on just a single line? On x86 the feature had originally
> > > > been added because old grub didn't have a separate line for Dom0
> > > > options in its graphical menu. Nowadays the functionality is handy
> > > > namely when starting xen.efi from the EFI shell (where again you
> > > > obviously only have a single command line), but quite likely this may
> > > > also be of use with grub's chain loading model (which I simply don't
> > > > use very often, so I'm not finally sure on that one).
> > > 
> > > My knowledge is quite limited on boot process for x86. How do you pass
> > > the kernel/initrd/xsm blob on UEFI? Can you do it from the command line
> > > or are you using the -cfg=... and specify it in a file?
> > 
> > Only the latter.
> > 
> > > On ARM we have two way to boot Xen:
> > >   - Using UEFI bootloader with either Device-Tree or ACPI
> > >   - Using non-UEFI bootloader with Device-Tree only
> > > 
> > > In the case of UEFI bootloader, we are using the xen configuration file
> > > to describe the modules (e.g kernel, initramfs, XSM) and the both xen
> > > and DOM0 command line.
> > > 
> > > For non-UEFI bootloader, we have designed the boot protocol based on the
> > > device-tree and will allows you to specify both xen and DOM0 and all the
> > > modules (see [1]). The bootloader needs to be able to modify the
> > > device-tree (such via a shell like on U-boot) or the user needs to
> > > modify the device-tree before hand.
> > 
> > All fine, but this doesn't tell me what interactive change options a
> > user has _after_ having set up the config file (or alike), while the
> > system is booting.
> 
> Here some concrete examples. The major bootloaders on ARM today are:
>   * UEFI
>   * U-boot
>   * GRUB
> 
> I will leave UEFI aside as people will usually chainload to GRUB and then boot
> whatever they want.
> 
> In both GRUB and U-boot a user will be able to modify the command line from
> the bootloader shell.

Given that upstream GRUB doesn't yet support booting Xen on ARM (without
any additional patches), I think that the ability to completely change
the command line from the EFI shell would be useful. Besides, although
it is not mandatory, I think it would be best not to unnecessarily
diverge from x86 in terms of EFI booting.

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

Re: [Xen-devel] [PATCH v4 5/5] xen: use libxendevicemodel when available

[Stefano Stabellini]

On Tue, 7 Mar 2017, Paul Durrant wrote:
> This patch modifies the wrapper functions in xen_common.h to use the
> new xendevicemodel interface if it is available along with compatibility
> code to use the old libxenctrl interface if it is not.
> 
> Signed-off-by: Paul Durrant 
> Reviewed-by: Anthony Perard 

Reviewed-by: Stefano Stabellini 

However, QEMU is in soft-freeze, so I'll wait until the merge window
open again before sending the pull request.


> Cc: Stefano Stabellini 
> 
> v4:
> - Fix typo causing build failures on < 490
> - Fix building on < 450
> - Build-tested against 4.2.5 and 4.8.0
> 
> v3:
> - Switch from macros to static inlines.
> 
> v2:
> - Add a compat define for xenforeignmemory_close() since this is now
>   used.
> ---
>  include/hw/xen/xen_common.h | 203 
> +---
>  xen-common.c|   8 ++
>  2 files changed, 178 insertions(+), 33 deletions(-)
> 
> diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
> index 31cf25f..274accc 100644
> --- a/include/hw/xen/xen_common.h
> +++ b/include/hw/xen/xen_common.h
> @@ -9,6 +9,7 @@
>  #undef XC_WANT_COMPAT_EVTCHN_API
>  #undef XC_WANT_COMPAT_GNTTAB_API
>  #undef XC_WANT_COMPAT_MAP_FOREIGN_API
> +#undef XC_WANT_COMPAT_DEVICEMODEL_API
>  
>  #include 
>  #include 
> @@ -26,48 +27,183 @@ extern xc_interface *xen_xc;
>   * We don't support Xen prior to 4.2.0.
>   */
>  
> +#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 490
> +
> +typedef xc_interface xendevicemodel_handle;
> +
> +static inline xendevicemodel_handle *xendevicemodel_open(
> +struct xentoollog_logger *logger, unsigned int open_flags)
> +{
> +return xen_xc;
> +}
> +
> +#if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 450
> +
> +static inline int xendevicemodel_create_ioreq_server(
> +xendevicemodel_handle *dmod, domid_t domid, int handle_bufioreq,
> +ioservid_t *id)
> +{
> +return xc_hvm_create_ioreq_server(dmod, domid, handle_bufioreq,
> +  id);
> +}
> +
> +static inline int xendevicemodel_get_ioreq_server_info(
> +xendevicemodel_handle *dmod, domid_t domid, ioservid_t id,
> +xen_pfn_t *ioreq_pfn, xen_pfn_t *bufioreq_pfn,
> +evtchn_port_t *bufioreq_port)
> +{
> +return xc_hvm_get_ioreq_server_info(dmod, domid, id, ioreq_pfn,
> +bufioreq_pfn, bufioreq_port);
> +}
> +
> +static inline int xendevicemodel_map_io_range_to_ioreq_server(
> +xendevicemodel_handle *dmod, domid_t domid, ioservid_t id, int is_mmio,
> +uint64_t start, uint64_t end)
> +{
> +return xc_hvm_map_io_range_to_ioreq_server(dmod, domid, id, is_mmio,
> +   start, end);
> +}
> +
> +static inline int xendevicemodel_unmap_io_range_from_ioreq_server(
> +xendevicemodel_handle *dmod, domid_t domid, ioservid_t id, int is_mmio,
> +uint64_t start, uint64_t end)
> +{
> +return xc_hvm_unmap_io_range_from_ioreq_server(dmod, domid, id, is_mmio,
> +   start, end);
> +}
> +
> +static inline int xendevicemodel_map_pcidev_to_ioreq_server(
> +xendevicemodel_handle *dmod, domid_t domid, ioservid_t id,
> +uint16_t segment, uint8_t bus, uint8_t device, uint8_t function)
> +{
> +return xc_hvm_map_pcidev_to_ioreq_server(dmod, domid, id, segment,
> + bus, device, function);
> +}
> +
> +static inline int xendevicemodel_unmap_pcidev_from_ioreq_server(
> +xendevicemodel_handle *dmod, domid_t domid, ioservid_t id,
> +uint16_t segment, uint8_t bus, uint8_t device, uint8_t function)
> +{
> +return xc_hvm_unmap_pcidev_from_ioreq_server(dmod, domid, id, segment,
> + bus, device, function);
> +}
> +
> +static inline int xendevicemodel_destroy_ioreq_server(
> +xendevicemodel_handle *dmod, domid_t domid, ioservid_t id)
> +{
> +return xc_hvm_destroy_ioreq_server(dmod, domid, id);
> +}
> +
> +static inline int xendevicemodel_set_ioreq_server_state(
> +xendevicemodel_handle *dmod, domid_t domid, ioservid_t id, int enabled)
> +{
> +return xc_hvm_set_ioreq_server_state(dmod, domid, id, enabled);
> +}
> +
> +#endif /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 450 */
> +
> +static inline int xendevicemodel_set_pci_intx_level(
> +xendevicemodel_handle *dmod, domid_t domid, uint16_t segment,
> +uint8_t bus, uint8_t device, uint8_t intx, unsigned int level)
> +{
> +return xc_hvm_set_pci_intx_level(dmod, domid, segment, bus, device,
> + intx, level);
> +}
> +
> +static inline int xendevicemodel_set_isa_irq_level(
> +xendevicemodel_handle *dmod, domid_t domid, uint8_t irq,
> +unsigned int level)
> +{
> +return xc_hvm_set_isa_irq_level(dmod, domid, irq, level);
> +}
> +
> +static inline int 

Re: [Xen-devel] [PATCH 10/29] drivers, md: convert stripe_head.count from atomic_t to refcount_t

[Shaohua Li]

On Mon, Mar 06, 2017 at 04:20:57PM +0200, Elena Reshetova wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
> 
> Signed-off-by: Elena Reshetova 
> Signed-off-by: Hans Liljestrand 
> Signed-off-by: Kees Cook 
> Signed-off-by: David Windsor 
> ---
>  drivers/md/raid5-cache.c |  8 +++---
>  drivers/md/raid5.c   | 66 
> 
>  drivers/md/raid5.h   |  3 ++-
>  3 files changed, 39 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c
> index 3f307be..6c05e12 100644
> --- a/drivers/md/raid5-cache.c
> +++ b/drivers/md/raid5-cache.c

snip
>  sh->check_state, sh->reconstruct_state);
>  
>   analyse_stripe(sh, );
> @@ -4924,7 +4924,7 @@ static void activate_bit_delay(struct r5conf *conf,
>   struct stripe_head *sh = list_entry(head.next, struct 
> stripe_head, lru);
>   int hash;
>   list_del_init(>lru);
> - atomic_inc(>count);
> + refcount_inc(>count);
>   hash = sh->hash_lock_index;
>   __release_stripe(conf, sh, _inactive_list[hash]);
>   }
> @@ -5240,7 +5240,7 @@ static struct stripe_head *__get_priority_stripe(struct 
> r5conf *conf, int group)
>   sh->group = NULL;
>   }
>   list_del_init(>lru);
> - BUG_ON(atomic_inc_return(>count) != 1);
> + BUG_ON(refcount_inc_not_zero(>count));

This changes the behavior. refcount_inc_not_zero doesn't inc if original value 
is 0

Thanks,
Shaohua

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

Re: [Xen-devel] [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t

[Shaohua Li]

On Mon, Mar 06, 2017 at 04:20:55PM +0200, Elena Reshetova wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.

Looks good. Let me know how do you want to route the patch to upstream.
 
> Signed-off-by: Elena Reshetova 
> Signed-off-by: Hans Liljestrand 
> Signed-off-by: Kees Cook 
> Signed-off-by: David Windsor 
> ---
>  drivers/md/md.c | 6 +++---
>  drivers/md/md.h | 3 ++-
>  2 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 985374f..94c8ebf 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -449,7 +449,7 @@ EXPORT_SYMBOL(md_unplug);
>  
>  static inline struct mddev *mddev_get(struct mddev *mddev)
>  {
> - atomic_inc(>active);
> + refcount_inc(>active);
>   return mddev;
>  }
>  
> @@ -459,7 +459,7 @@ static void mddev_put(struct mddev *mddev)
>  {
>   struct bio_set *bs = NULL;
>  
> - if (!atomic_dec_and_lock(>active, _mddevs_lock))
> + if (!refcount_dec_and_lock(>active, _mddevs_lock))
>   return;
>   if (!mddev->raid_disks && list_empty(>disks) &&
>   mddev->ctime == 0 && !mddev->hold_active) {
> @@ -495,7 +495,7 @@ void mddev_init(struct mddev *mddev)
>   INIT_LIST_HEAD(>all_mddevs);
>   setup_timer(>safemode_timer, md_safemode_timeout,
>   (unsigned long) mddev);
> - atomic_set(>active, 1);
> + refcount_set(>active, 1);
>   atomic_set(>openers, 0);
>   atomic_set(>active_io, 0);
>   spin_lock_init(>lock);
> diff --git a/drivers/md/md.h b/drivers/md/md.h
> index b8859cb..4811663 100644
> --- a/drivers/md/md.h
> +++ b/drivers/md/md.h
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -360,7 +361,7 @@ struct mddev {
>*/
>   struct mutexopen_mutex;
>   struct mutexreconfig_mutex;
> - atomic_tactive; /* general refcount */
> + refcount_t  active; /* general refcount */
>   atomic_topeners;/* number of active 
> opens */
>  
>   int changed;/* True if we might 
> need to
> -- 
> 2.7.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

Re: [Xen-devel] [PATCHv4 18/33] x86/xen: convert __xen_pgd_walk() and xen_cleanmfnmap() to support p4d

[Boris Ostrovsky]

On 03/07/2017 01:26 PM, Andrew Cooper wrote:
> On 07/03/17 18:18, Boris Ostrovsky wrote:
 Don't we need to pass vaddr down to all routines so that they select
 appropriate tables? You seem to always be choosing the first one.
>>> IIUC, we clear whole page table subtree covered by one pgd entry.
>>> So, no, there's no need to pass vaddr down. Just pointer to page table
>>> entry is enough.
>>>
>>> But I know virtually nothing about Xen. Please re-check my reasoning.
>> Yes, we effectively remove the whole page table for vaddr so I guess
>> it's OK.
>>
>>> I would also appreciate help with getting x86 Xen code work with 5-level
>>> paging enabled. For now I make CONFIG_XEN dependent on !CONFIG_X86_5LEVEL.
>> Hmmm... that's a problem since this requires changes in the hypervisor
>> and even if/when these changes are made older version of hypervisor
>> still will not be able to run those guests.
>>
>> This affects only PV guests and there is a series under review that
>> provides clean code separation with CONFIG_XEN_PV but because, for
>> example, dom0 (Xen control domain) is PV this will significantly limit
>> availability of dom0-capable kernels (because I assume distros will want
>> to have CONFIG_X86_5LEVEL).
> Wasn't the plan to be able to automatically detect 4 vs 5 level support,
> and cope either way, so distros didn't have to ship two different builds
> of Linux?
>
> If so, all we need to do git things to compile sensibly, and have the PV
> entry code in Linux configure the rest of the kernel appropriately.

I am not aware of any plans but this would obviously be the preferred route.

-boris


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

[Xen-devel] [xen-unstable-smoke test] 106530: tolerable trouble: broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  4036e7c592905c2292cdeba8269e969959427237
baseline version:
 xen  caf053fb545329e58ac891d197f96503e3121049

Last test of basis   106505  2017-03-06 20:01:08 Z0 days
Testing same since   106530  2017-03-07 17:04:01 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Roger Pau Monné 

jobs:
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [PATCH 0/7] Xen transport for 9pfs frontend driver

[Stefano Stabellini]

On Tue, 7 Mar 2017, Roger Pau Monné wrote:
> On Mon, Mar 06, 2017 at 12:00:41PM -0800, Stefano Stabellini wrote:
> > Hi all,
> > 
> > This patch series implements a new transport for 9pfs, aimed at Xen
> > systems.
> > 
> > The transport is based on a traditional Xen frontend and backend drivers
> > pair. This patch series implements the frontend, which typically runs in
> > a regular unprivileged guest.
> > 
> > I'll follow up with another series that implements the backend in
> > userspace in QEMU, which typically runs in Dom0 (but could also run in
> > a another guest).
> > 
> > The frontend complies to the Xen transport for 9pfs specification
> > version 1, available here:
> > 
> > http://xenbits.xen.org/gitweb/?p=xen.git;a=blob_plain;f=docs/misc/9pfs.markdown;hb=HEAD
> 
> Kind of tangential to this series, but maybe it would make sense to implement
> this transport in a fuse based 9pfs driver? I see there are already several
> fuse-9pfs implementations around. Something for a GSoC/Outreach project?

Sure. Additionally, with open source frontends and backends already
available, it should be easier to code. I am happy to co-mentor the
project with you, if you feel like it.___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCHv4 18/33] x86/xen: convert __xen_pgd_walk() and xen_cleanmfnmap() to support p4d

[Andrew Cooper]

On 07/03/17 18:18, Boris Ostrovsky wrote:
>>> Don't we need to pass vaddr down to all routines so that they select
>>> appropriate tables? You seem to always be choosing the first one.
>> IIUC, we clear whole page table subtree covered by one pgd entry.
>> So, no, there's no need to pass vaddr down. Just pointer to page table
>> entry is enough.
>>
>> But I know virtually nothing about Xen. Please re-check my reasoning.
> Yes, we effectively remove the whole page table for vaddr so I guess
> it's OK.
>
>> I would also appreciate help with getting x86 Xen code work with 5-level
>> paging enabled. For now I make CONFIG_XEN dependent on !CONFIG_X86_5LEVEL.
> Hmmm... that's a problem since this requires changes in the hypervisor
> and even if/when these changes are made older version of hypervisor
> still will not be able to run those guests.
>
> This affects only PV guests and there is a series under review that
> provides clean code separation with CONFIG_XEN_PV but because, for
> example, dom0 (Xen control domain) is PV this will significantly limit
> availability of dom0-capable kernels (because I assume distros will want
> to have CONFIG_X86_5LEVEL).

Wasn't the plan to be able to automatically detect 4 vs 5 level support,
and cope either way, so distros didn't have to ship two different builds
of Linux?

If so, all we need to do git things to compile sensibly, and have the PV
entry code in Linux configure the rest of the kernel appropriately.

(If not, please ignore me.)

~Andrew

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

Re: [Xen-devel] [PATCHv4 18/33] x86/xen: convert __xen_pgd_walk() and xen_cleanmfnmap() to support p4d

[Boris Ostrovsky]

>> Don't we need to pass vaddr down to all routines so that they select
>> appropriate tables? You seem to always be choosing the first one.
> IIUC, we clear whole page table subtree covered by one pgd entry.
> So, no, there's no need to pass vaddr down. Just pointer to page table
> entry is enough.
>
> But I know virtually nothing about Xen. Please re-check my reasoning.

Yes, we effectively remove the whole page table for vaddr so I guess
it's OK.

>
> I would also appreciate help with getting x86 Xen code work with 5-level
> paging enabled. For now I make CONFIG_XEN dependent on !CONFIG_X86_5LEVEL.

Hmmm... that's a problem since this requires changes in the hypervisor
and even if/when these changes are made older version of hypervisor
still will not be able to run those guests.

This affects only PV guests and there is a series under review that
provides clean code separation with CONFIG_XEN_PV but because, for
example, dom0 (Xen control domain) is PV this will significantly limit
availability of dom0-capable kernels (because I assume distros will want
to have CONFIG_X86_5LEVEL).


>
> Fixup:

Yes, that works. (But then it worked even without this change because
problems caused by missing the flush would be intermittent. And a joy to
debug).

-boris


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

Re: [Xen-devel] [PATCH] Allow installation on CentOS

[Stefano Stabellini]

On Tue, 7 Mar 2017, Géza Gémes wrote:
> Add $DISTRO = "CentOS"
> to the rpm installation targets
> complementing Fedora
> 
> Signed-off-by: Géza Gémes 

Reviewed-by: Stefano Stabellini 

Thanks for the patch!

>  lib/common-functions.sh | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/common-functions.sh b/lib/common-functions.sh
> index 19434c2..d4476f3 100644
> --- a/lib/common-functions.sh
> +++ b/lib/common-functions.sh
> @@ -420,7 +420,7 @@ function install_package() {
>  if [[ $DISTRO = "Debian" ]]
>  then
>  $SUDO dpkg -i "$1".deb
> -elif [[  $DISTRO = "Fedora" ]]
> +elif [[  $DISTRO = "Fedora" || $DISTRO = "CentOS" ]]
>  then
>  $SUDO rpm -i --force "$1"-`git show --oneline | head -1 | cut -d " " 
> -f 1`-0.$RAISIN_ARCH.rpm
>  else
> @@ -432,7 +432,7 @@ function uninstall_package() {
>  if [[ $DISTRO = "Debian" ]]
>  then
>  $SUDO dpkg -r "$1"
> -elif [[ $DISTRO = "Fedora" ]]
> +elif [[ $DISTRO = "Fedora" || $DISTRO = "CentOS" ]]
>  then
>  $SUDO rpm -e "$1"
>  else
> -- 
> 2.7.4
> ___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] Fix typo in function install

[Stefano Stabellini]

On Tue, 7 Mar 2017, Géza Gémes wrote:
> Signed-off-by: Géza Gémes 

Reviewed-by: Stefano Stabellini 

I'll commmit

> ---
>  lib/commands.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/commands.sh b/lib/commands.sh
> index be445a7..5b653b3 100755
> --- a/lib/commands.sh
> +++ b/lib/commands.sh
> @@ -70,7 +70,7 @@ function unraise() {
>  
>  function install() {
>  # need single braces for filename matching expansion
> -if [ ! -f xen-sytem*rpm ] && [ ! -f xen-system*deb ]
> +if [ ! -f xen-system*rpm ] && [ ! -f xen-system*deb ]
>  then
>  error_echo You need to raise build first.
>  exit 1
> -- 
> 2.7.4
> ___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 06/28] ARM: GICv3 ITS: introduce ITS command handling

[Andre Przywara]

Hi Julien,

On 06/02/17 19:16, Julien Grall wrote:
> Hi Andre,
> 
> On 30/01/17 18:31, Andre Przywara wrote:
>> To be able to easily send commands to the ITS, create the respective
>> wrapper functions, which take care of the ring buffer.
>> The first two commands we implement provide methods to map a collection
>> to a redistributor (aka host core) and to flush the command queue (SYNC).
>> Start using these commands for mapping one collection to each host CPU.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  xen/arch/arm/gic-v3-its.c | 142
>> +-
>>  xen/arch/arm/gic-v3-lpi.c |  20 ++
>>  xen/arch/arm/gic-v3.c |  18 -
>>  xen/include/asm-arm/gic_v3_defs.h |   2 +
>>  xen/include/asm-arm/gic_v3_its.h  |  36 ++
>>  5 files changed, 215 insertions(+), 3 deletions(-)
>>
>> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
>> index ad7cd2a..6578e8a 100644
>> --- a/xen/arch/arm/gic-v3-its.c
>> +++ b/xen/arch/arm/gic-v3-its.c
>> @@ -19,6 +19,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -29,6 +30,98 @@
>>
>>  #define ITS_CMD_QUEUE_SZSZ_64K
>>
>> +#define BUFPTR_MASK GENMASK(19, 5)
>> +static int its_send_command(struct host_its *hw_its, const void
>> *its_cmd)
>> +{
>> +uint64_t readp, writep;
>> +
>> +spin_lock(_its->cmd_lock);
> 
> Do you never expect a command to be sent in an interrupt path? I could
> see at least one, we may decide to throttle the number of LPIs received
> by a guest so this would involve disabling the interrupt.

I take it you are asking for spin_lock_irq[save]()?
I don't think queuing ITS commands in interrupt context is a good idea,
especially since I just introduced a grace period to wait for a draining
command queue.
I am happy to revisit this when needed.

>> +
>> +readp = readq_relaxed(hw_its->its_base + GITS_CREADR) & BUFPTR_MASK;
>> +writep = readq_relaxed(hw_its->its_base + GITS_CWRITER) &
>> BUFPTR_MASK;
>> +
>> +if ( ((writep + ITS_CMD_SIZE) % ITS_CMD_QUEUE_SZ) == readp )
>> +{
> 
> I look at all the series applied and there is no error message at all
> when the queue is full. This will make difficult to see what's going on.
> 
> Furthermore, this limit could be easily reached. Furthermore, this could
> happen easily if you decide to map a device with thousands of
> interrupts. For instance the function gicv3_map_its_map_host_events will
> issue 2 commands per event (MAPTI and INV).
> 
> So how do you plan to address this?

So I changed this now to wait for 1 ms (or whatever value you prefer) in
hope the command queue drains. In the end the ITS is hardware, so
processing commands it's the only thing it does and I don't expect it to
be seriously stalled, usually. So waiting a tiny bit to cover this odd
case of command queue contention seems useful to me, especially since we
only send commands from non-critical Dom0 code.
The command queue is now 1 MB in size, so we have 32,768 commands in
there. Should be enough for everybody ;-)

>> +spin_unlock(_its->cmd_lock);
>> +return -EBUSY;
>> +}
>> +
>> +memcpy(hw_its->cmd_buf + writep, its_cmd, ITS_CMD_SIZE);
>> +if ( hw_its->flags & HOST_ITS_FLUSH_CMD_QUEUE )
>> +__flush_dcache_area(hw_its->cmd_buf + writep, ITS_CMD_SIZE);
> 
> Please use dcache_ helpers.
> 
>> +else
>> +dsb(ishst);
>> +
>> +writep = (writep + ITS_CMD_SIZE) % ITS_CMD_QUEUE_SZ;
>> +writeq_relaxed(writep & BUFPTR_MASK, hw_its->its_base +
>> GITS_CWRITER);
>> +
>> +spin_unlock(_its->cmd_lock);
>> +
>> +return 0;
>> +}
>> +
>> +static uint64_t encode_rdbase(struct host_its *hw_its, int cpu,
>> uint64_t reg)
> 
> s/int cpu/unsigned int cpu/

So it's easy to do so, but why is that actually?
I see that both "processor" and "vcpu_id" are "int" in struct vcpu, so I
was using int as the type for CPUs here as well.

>> +{
>> +reg &= ~GENMASK(51, 16);
>> +
>> +reg |= gicv3_get_redist_address(cpu, hw_its->flags &
>> HOST_ITS_USES_PTA);
>> +
>> +return reg;
>> +}
>> +
>> +static int its_send_cmd_sync(struct host_its *its, int cpu)
> 
> s/int cpu/unsigned int cpu/
> 
>> +{
>> +uint64_t cmd[4];
>> +
>> +cmd[0] = GITS_CMD_SYNC;
>> +cmd[1] = 0x00;
>> +cmd[2] = encode_rdbase(its, cpu, 0x0);
>> +cmd[3] = 0x00;
>> +
>> +return its_send_command(its, cmd);
>> +}
>> +
>> +static int its_send_cmd_mapc(struct host_its *its, int collection_id,
>> int cpu)
> 
> s/int/unsigned int/ for both collection_id and cpu.
> 
>> +{
>> +uint64_t cmd[4];
>> +
>> +cmd[0] = GITS_CMD_MAPC;
>> +cmd[1] = 0x00;
>> +cmd[2] = encode_rdbase(its, cpu, (collection_id & GENMASK(15, 0)));
> 
> Please drop the mask here.
> 
>> +cmd[2] |= GITS_VALID_BIT;
>> +cmd[3] = 0x00;
>> +
>> +return its_send_command(its, cmd);
>> +}
>> +
>> +/* Set up the (1:1) 

Re: [Xen-devel] [PATCH v3] xen: Allow a default compiled-in command line using Kconfig

[Julien Grall]

Hi Jan,

On 03/07/2017 02:52 PM, Jan Beulich wrote:

On 07.03.17 at 15:41,  wrote:

Hi Jan,

On 03/07/2017 02:18 PM, Jan Beulich wrote:

On 07.03.17 at 14:48,  wrote:

On 03/07/2017 12:52 PM, Jan Beulich wrote:

On 07.03.17 at 12:21,  wrote:

2017-03-07 17:36 GMT+08:00 Jan Beulich :

On 07.03.17 at 09:34,  wrote:

+static inline char* __init extract_dom0_options(char *cmdline)
+{
+char *kextra;
+
+if ( (kextra = strstr(cmdline, " -- ")) != NULL )
+{
+*kextra = '\0';
+kextra += 3;
+while ( kextra[1] == ' ' ) kextra++;


The body of the while() wants to go on its own line.

And then - why is this Dom0 option handling done only on x86?



As you might have noticed, there isn't any code dealing with the dom0

options

in arch/arm/setup.c, and the arm version of construct_dom0() doesn't take

any

command line options as its parameter,
so I have the reason to believe that this feature is not available
under the arm architecture.


Looks like an omission to me - Julien, Stefano?


DOM0 and Xen command line are passed separately through either Device
Tree or for UEFI xen configuration file (see -cfg=...).

So I am not sure to understand what would be the benefits to handle DOM0
parameters after -- on Xen command line.


So you have no case of a boot loader which allows you to type in
extra options on just a single line? On x86 the feature had originally
been added because old grub didn't have a separate line for Dom0
options in its graphical menu. Nowadays the functionality is handy
namely when starting xen.efi from the EFI shell (where again you
obviously only have a single command line), but quite likely this may
also be of use with grub's chain loading model (which I simply don't
use very often, so I'm not finally sure on that one).


My knowledge is quite limited on boot process for x86. How do you pass
the kernel/initrd/xsm blob on UEFI? Can you do it from the command line
or are you using the -cfg=... and specify it in a file?


Only the latter.


On ARM we have two way to boot Xen:
- Using UEFI bootloader with either Device-Tree or ACPI
- Using non-UEFI bootloader with Device-Tree only

In the case of UEFI bootloader, we are using the xen configuration file
to describe the modules (e.g kernel, initramfs, XSM) and the both xen
and DOM0 command line.

For non-UEFI bootloader, we have designed the boot protocol based on the
device-tree and will allows you to specify both xen and DOM0 and all the
modules (see [1]). The bootloader needs to be able to modify the
device-tree (such via a shell like on U-boot) or the user needs to
modify the device-tree before hand.


All fine, but this doesn't tell me what interactive change options a
user has _after_ having set up the config file (or alike), while the
system is booting.


Here some concrete examples. The major bootloaders on ARM today are:
* UEFI
* U-boot
* GRUB

I will leave UEFI aside as people will usually chainload to GRUB and 
then boot whatever they want.


In both GRUB and U-boot a user will be able to modify the command line 
from the bootloader shell.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 4/7] xen/9pfs: connect to the backend

[Julien Grall]

Hi Stefano,

On 03/06/2017 08:01 PM, Stefano Stabellini wrote:

+static int xen_9pfs_front_alloc_dataring(struct xenbus_device *dev,
+   struct xen_9pfs_dataring *ring)
+{
+   int i;
+   int ret = -ENOMEM;
+
+   init_waitqueue_head(>wq);
+   spin_lock_init(>lock);
+   INIT_WORK(>work, p9_xen_response);
+
+   ring->intf = (struct xen_9pfs_data_intf *) __get_free_page(GFP_KERNEL | 
__GFP_ZERO);
+   if (!ring->intf)
+   goto error;
+   memset(ring->intf, 0, XEN_PAGE_SIZE);
+   ring->bytes = (void*)__get_free_pages(GFP_KERNEL | __GFP_ZERO, 
XEN_9PFS_RING_ORDER);


The ring order will be in term of Xen page size and not Linux. So you 
are going to allocate much more memory than expected on 64KB kernel.



+   if (ring->bytes == NULL)
+   goto error;
+   for (i = 0; i < (1 << XEN_9PFS_RING_ORDER); i++)
+   ring->intf->ref[i] = gnttab_grant_foreign_access(dev->otherend_id, 
pfn_to_gfn(virt_to_pfn((void*)ring->bytes) + i), 0);.


Please use virt_to_gfn rather than pfn_to_gfn(virt_to_pfn).

Also, this is not going to work on 64K kernel because you will grant 
access to noncontiguous memory (e.g 0-4K, 64K-68K,...).


We have various helper to break-down the page for you, see 
gnttab_for_one_grant, gnttab_foreach_grant, gnttab_count_grant, 
xen_for_each_gfn (though this one it is internal to xlate_mmu.c so far)


Please use them to avoid any further.


+   ring->ref = gnttab_grant_foreign_access(dev->otherend_id, 
pfn_to_gfn(virt_to_pfn((void*)ring->intf)), 0);


Please use virt_to_gfn rather than pfn_to_gfn(virt_to_pfn).


+   ring->ring.in = ring->bytes;
+   ring->ring.out = ring->bytes + XEN_9PFS_RING_SIZE;
+
+   ret = xenbus_alloc_evtchn(dev, >evtchn);
+   if (ret)
+   goto error;
+   ring->irq = bind_evtchn_to_irqhandler(ring->evtchn, 
xen_9pfs_front_event_handler,
+   0, "xen_9pfs-frontend", ring);
+   if (ring->irq < 0) {
+   xenbus_free_evtchn(dev, ring->evtchn);
+   ret = ring->irq;
+   goto error;
+   }
return 0;
+
+error:
+   if (ring->intf != NULL)
+   kfree(ring->intf);
+   if (ring->bytes != NULL)
+   kfree(ring->bytes);
+   return ret;
 }


Cheers,

--
Julien Grall

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

[Xen-devel] [RFC] linkage: new macros for functions and data

[Jiri Slaby]

SYM_LOCAL_ALIAS_START -- use where there are two local names for one
  code
SYM_ALIAS_START -- use where there are two global names for one code
SYM_LOCAL_FUNC_START -- use for local functions
SYM_FUNCTION_START -- use for global functions
SYM_WEAK_FUNC_START -- use for weak functions
SYM_ALIAS_END -- the end of LOCALALIASed or ALIASed code
SYM_FUNCTION_END -- the end of SYM_LOCAL_FUNC_START, SYM_FUNCTION_START,
  SYM_WEAK_FUNC_START, ...
SYM_DATA_START -- global data symbol
SYM_DATA_END -- the end of SYM_DATA_START symbol

Signed-off-by: Jiri Slaby 
Cc: Andrew Morton 
Cc: Boris Ostrovsky 
Cc: h...@zytor.com
Cc: Ingo Molnar 
Cc: jpoim...@redhat.com
Cc: Juergen Gross 
Cc: Len Brown 
Cc: Linus Torvalds 
Cc: linux-ker...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: mi...@redhat.com
Cc: Pavel Machek 
Cc: Peter Zijlstra 
Cc: "Rafael J. Wysocki" 
Cc: Thomas Gleixner 
Cc: xen-de...@lists.xenproject.org
Cc: x...@kernel.org
---

So this is what I have ATM.

 include/linux/linkage.h | 87 -
 1 file changed, 72 insertions(+), 15 deletions(-)

diff --git a/include/linux/linkage.h b/include/linux/linkage.h
index a6a42dd02466..79f634a57466 100644
--- a/include/linux/linkage.h
+++ b/include/linux/linkage.h
@@ -78,33 +78,90 @@
 #define ALIGN __ALIGN
 #define ALIGN_STR __ALIGN_STR
 
-#ifndef ENTRY
-#define ENTRY(name) \
-   .globl name ASM_NL \
+#ifndef ENTRY /* deprecated, use SYM_FUNCTION_START */
+#define ENTRY(name)SYM_FUNCTION_START(name)
+#endif
+#endif /* LINKER_SCRIPT */
+
+/* === code annotations === */
+
+/* SYM_LOCAL_ALIAS_START -- use where there are two local names for one code */
+#ifndef SYM_LOCAL_ALIAS_START
+#define SYM_LOCAL_ALIAS_START(name) \
ALIGN ASM_NL \
name:
 #endif
-#endif /* LINKER_SCRIPT */
 
-#ifndef WEAK
-#define WEAK(name)\
+/* SYM_ALIAS_START -- use where there are two global names for one code */
+#ifndef SYM_ALIAS_START
+#define SYM_ALIAS_START(name) \
+   .globl name ASM_NL \
+   SYM_LOCAL_ALIAS_START(name)
+#endif
+
+/*
+ * so far the same as SYM_LOCAL_ALIAS_START, but we will need to distinguish
+ * them later
+ */
+/* SYM_LOCAL_FUNC_START -- use for local functions */
+#ifndef SYM_LOCAL_FUNC_START
+#define SYM_LOCAL_FUNC_START(name) \
+   SYM_LOCAL_ALIAS_START(name)
+#endif
+
+/* SYM_FUNCTION_START -- use for global functions */
+#ifndef SYM_FUNCTION_START
+#define SYM_FUNCTION_START(name) \
+   .globl name ASM_NL \
+   SYM_LOCAL_FUNC_START(name)
+#endif
+
+/* SYM_WEAK_FUNC_START -- use for weak functions */
+#ifndef SYM_WEAK_FUNC_START
+#define SYM_WEAK_FUNC_START(name) \
.weak name ASM_NL   \
name:
 #endif
 
-#ifndef END
-#define END(name) \
-   .size name, .-name
+/* SYM_ALIAS_END -- the end of LOCALALIASed or ALIASed code */
+#ifndef SYM_ALIAS_END
+#define SYM_ALIAS_END(name) \
+   .type name, @function ASM_NL \
+   SYM_DATA_END(name)
 #endif
 
 /* If symbol 'name' is treated as a subroutine (gets called, and returns)
- * then please use ENDPROC to mark 'name' as STT_FUNC for the benefit of
- * static analysis tools such as stack depth analyzer.
+ * then please use SYM_FUNCTION_END to mark 'name' as STT_FUNC for the benefit
+ * of static analysis tools such as stack depth analyzer.
  */
-#ifndef ENDPROC
-#define ENDPROC(name) \
-   .type name, @function ASM_NL \
-   END(name)
+/*
+ * SYM_FUNCTION_END -- the end of SYM_LOCAL_FUNC_START, SYM_FUNCTION_START,
+ * SYM_WEAK_FUNC_START, ...
+ */
+#ifndef SYM_FUNCTION_END
+#define SYM_FUNCTION_END(name) \
+   SYM_ALIAS_END(name) /* the same as for SYM_LOCAL_FUNC_START */
+#endif
+
+#ifndef WEAK /* deprecated, use SYM_WEAK_FUNC_START */
+#define WEAK(name) SYM_WEAK_FUNC_START(name)
+#endif
+
+/* === data annotations === */
+
+/* SYM_DATA_START -- global data symbol */
+#ifndef SYM_DATA_START
+#define SYM_DATA_START(name)   SYM_FUNCTION_START(name)
+#endif
+
+/* SYM_DATA_END -- the end of SYM_DATA_START symbol */
+#ifndef SYM_DATA_END
+#define SYM_DATA_END(name) \
+   .size name, .-name
+#endif
+
+#ifndef END /* deprecated, use SYM_DATA_END */
+#define END(name) SYM_DATA_END(name)
 #endif
 
 #endif
-- 
2.12.0


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

Re: [Xen-devel] [PATCH 1/7] xen: import new ring macros in ring.h

[Julien Grall]

Hi Stefano,

On 03/06/2017 08:01 PM, Stefano Stabellini wrote:

Sync the ring.h file with upstream Xen, to introduce the new ring macros.
They will be used by the Xen transport for 9pfs.

Signed-off-by: Stefano Stabellini 
CC: konrad.w...@oracle.com
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com

---
NB: The new macros have not been committed to Xen yet. Do not apply this
patch until they do.
---
---
 include/xen/interface/io/ring.h | 131 
 1 file changed, 131 insertions(+)

diff --git a/include/xen/interface/io/ring.h b/include/xen/interface/io/ring.h
index 21f4fbd..e16aa92 100644
--- a/include/xen/interface/io/ring.h
+++ b/include/xen/interface/io/ring.h


[...]


+#define XEN_FLEX_RING_SIZE(order) \
+(1UL << (order + PAGE_SHIFT - 1))


This will need to be XEN_PAGE_SHIFT in order to works with 64K kernel.

Cheers,

--
Julien Grall

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-debianhvm-amd64 16 guest-stop   fail REGR. vs. 106491

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 106491
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106491
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 106491
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 106491
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 106491
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 106491

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   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-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
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
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 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-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuueba44e9339fc13c36e24c8c59e2b73ea231b46a1
baseline version:
 qemuufbddc2e5608eb655493253d080598375db61a748

Last test of basis   106491  2017-03-06 13:14:18 Z1 days
Failing since106508  2017-03-06 21:44:30 Z0 days2 attempts
Testing same since   106515  2017-03-07 08:41:01 Z0 days1 attempts


People who touched revisions under test:
  Cédric Le Goater 
  David Gibson 
  Dmitry Fleytman 
  Dr. David Alan Gilbert 
  Fam Zheng 
  Igor Mammedov 
  Jason Wang 
  Nikunj A Dadhania 
  Peter Maydell 
  Thomas 

Re: [Xen-devel] [PATCH 3/3] x86: drop underscore prefixed 32-bit register names

[Andrew Cooper]

On 07/03/17 16:43, Jan Beulich wrote:
> Now that all underscore prefixed instances have been replaced, this
> concludes the register renaming project.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH 2/3] x86/hypercall: switch away from temporary 32-bit register names

[Andrew Cooper]

On 07/03/17 16:42, Jan Beulich wrote:
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH 1/3] x86emul: switch away from temporary 32-bit register names

[Andrew Cooper]

On 07/03/17 16:42, Jan Beulich wrote:
> @@ -3266,36 +3266,36 @@ x86_emulate(
>  case 0x27: /* daa */
>  case 0x2f: /* das */ {
>  uint8_t al = _regs.al;
> -unsigned int eflags = _regs._eflags;
> +unsigned int eflags = _regs.eflags;
>  
> -_regs._eflags &= ~(X86_EFLAGS_CF | X86_EFLAGS_AF | X86_EFLAGS_SF |
> +_regs.eflags &= ~(X86_EFLAGS_CF | X86_EFLAGS_AF | X86_EFLAGS_SF |
> X86_EFLAGS_ZF | X86_EFLAGS_PF);

This line needs indenting accordingly.

> @@ -6395,20 +6395,20 @@ x86_emulate(
> ((dst.orig_val << shift) |
>  ((src.val >> (width - shift)) & ((1ull << shift) - 1;
>  dst.val = truncate_word(dst.val, dst.bytes);
> -_regs._eflags &= ~(X86_EFLAGS_OF | X86_EFLAGS_SF | X86_EFLAGS_ZF |
> +_regs.eflags &= ~(X86_EFLAGS_OF | X86_EFLAGS_SF | X86_EFLAGS_ZF |
> X86_EFLAGS_PF | X86_EFLAGS_CF);

And here.

Otherwise, Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH 0/7] Xen transport for 9pfs frontend driver

[Roger Pau Monné]

On Mon, Mar 06, 2017 at 12:00:41PM -0800, Stefano Stabellini wrote:
> Hi all,
> 
> This patch series implements a new transport for 9pfs, aimed at Xen
> systems.
> 
> The transport is based on a traditional Xen frontend and backend drivers
> pair. This patch series implements the frontend, which typically runs in
> a regular unprivileged guest.
> 
> I'll follow up with another series that implements the backend in
> userspace in QEMU, which typically runs in Dom0 (but could also run in
> a another guest).
> 
> The frontend complies to the Xen transport for 9pfs specification
> version 1, available here:
> 
> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob_plain;f=docs/misc/9pfs.markdown;hb=HEAD

Kind of tangential to this series, but maybe it would make sense to implement
this transport in a fuse based 9pfs driver? I see there are already several
fuse-9pfs implementations around. Something for a GSoC/Outreach project?

Roger.

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

[Xen-devel] [PATCH 3/3] x86: drop underscore prefixed 32-bit register names

[Jan Beulich]

Now that all underscore prefixed instances have been replaced, this
concludes the register renaming project.

Signed-off-by: Jan Beulich 

--- a/xen/include/public/arch-x86/xen-x86_32.h
+++ b/xen/include/public/arch-x86/xen-x86_32.h
@@ -114,7 +114,7 @@
 #elif defined(__XEN__) || defined(__XEN_TOOLS__)
 /* Anonymous unions include all permissible names (e.g., al/ah/ax/eax). */
 #define __DECL_REG_LO8(which) union { \
-uint32_t e ## which ## x, _e ## which ## x; \
+uint32_t e ## which ## x; \
 uint16_t which ## x; \
 struct { \
 uint8_t which ## l; \
--- a/xen/include/public/arch-x86/xen-x86_64.h
+++ b/xen/include/public/arch-x86/xen-x86_64.h
@@ -134,7 +134,7 @@ struct iret_context {
 /* Anonymous unions include all permissible names (e.g., al/ah/ax/eax/rax). */
 #define __DECL_REG_LOHI(which) union { \
 uint64_t r ## which ## x; \
-uint32_t e ## which ## x, _e ## which ## x; \
+uint32_t e ## which ## x; \
 uint16_t which ## x; \
 struct { \
 uint8_t which ## l; \
@@ -143,13 +143,13 @@ struct iret_context {
 }
 #define __DECL_REG_LO8(name) union { \
 uint64_t r ## name; \
-uint32_t e ## name, _e ## name; \
+uint32_t e ## name; \
 uint16_t name; \
 uint8_t name ## l; \
 }
 #define __DECL_REG_LO16(name) union { \
 uint64_t r ## name; \
-uint32_t e ## name, _e ## name; \
+uint32_t e ## name; \
 uint16_t name; \
 }
 #define __DECL_REG_HI(num) union { \
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -58,15 +58,15 @@
 
 #if defined(__i386__)
 # ifdef __XEN__
-__DeFiNe__ __DECL_REG_LO8(which) uint32_t _e ## which ## x
-__DeFiNe__ __DECL_REG_LO16(name) union { uint32_t e ## name, _e ## name; }
+__DeFiNe__ __DECL_REG_LO8(which) uint32_t e ## which ## x
+__DeFiNe__ __DECL_REG_LO16(name) union { uint32_t e ## name; }
 # endif
 #include "xen-x86_32.h"
 # ifdef __XEN__
 __UnDeF__ __DECL_REG_LO8
 __UnDeF__ __DECL_REG_LO16
-__DeFiNe__ __DECL_REG_LO8(which) _e ## which ## x
-__DeFiNe__ __DECL_REG_LO16(name) _e ## name
+__DeFiNe__ __DECL_REG_LO8(which) e ## which ## x
+__DeFiNe__ __DECL_REG_LO16(name) e ## name
 # endif
 #elif defined(__x86_64__)
 #include "xen-x86_64.h"



x86: drop underscore prefixed 32-bit register names

Now that all underscore prefixed instances have been replaced, this
concludes the register renaming project.

Signed-off-by: Jan Beulich 

--- a/xen/include/public/arch-x86/xen-x86_32.h
+++ b/xen/include/public/arch-x86/xen-x86_32.h
@@ -114,7 +114,7 @@
 #elif defined(__XEN__) || defined(__XEN_TOOLS__)
 /* Anonymous unions include all permissible names (e.g., al/ah/ax/eax). */
 #define __DECL_REG_LO8(which) union { \
-uint32_t e ## which ## x, _e ## which ## x; \
+uint32_t e ## which ## x; \
 uint16_t which ## x; \
 struct { \
 uint8_t which ## l; \
--- a/xen/include/public/arch-x86/xen-x86_64.h
+++ b/xen/include/public/arch-x86/xen-x86_64.h
@@ -134,7 +134,7 @@ struct iret_context {
 /* Anonymous unions include all permissible names (e.g., al/ah/ax/eax/rax). */
 #define __DECL_REG_LOHI(which) union { \
 uint64_t r ## which ## x; \
-uint32_t e ## which ## x, _e ## which ## x; \
+uint32_t e ## which ## x; \
 uint16_t which ## x; \
 struct { \
 uint8_t which ## l; \
@@ -143,13 +143,13 @@ struct iret_context {
 }
 #define __DECL_REG_LO8(name) union { \
 uint64_t r ## name; \
-uint32_t e ## name, _e ## name; \
+uint32_t e ## name; \
 uint16_t name; \
 uint8_t name ## l; \
 }
 #define __DECL_REG_LO16(name) union { \
 uint64_t r ## name; \
-uint32_t e ## name, _e ## name; \
+uint32_t e ## name; \
 uint16_t name; \
 }
 #define __DECL_REG_HI(num) union { \
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -58,15 +58,15 @@
 
 #if defined(__i386__)
 # ifdef __XEN__
-__DeFiNe__ __DECL_REG_LO8(which) uint32_t _e ## which ## x
-__DeFiNe__ __DECL_REG_LO16(name) union { uint32_t e ## name, _e ## name; }
+__DeFiNe__ __DECL_REG_LO8(which) uint32_t e ## which ## x
+__DeFiNe__ __DECL_REG_LO16(name) union { uint32_t e ## name; }
 # endif
 #include "xen-x86_32.h"
 # ifdef __XEN__
 __UnDeF__ __DECL_REG_LO8
 __UnDeF__ __DECL_REG_LO16
-__DeFiNe__ __DECL_REG_LO8(which) _e ## which ## x
-__DeFiNe__ __DECL_REG_LO16(name) _e ## name
+__DeFiNe__ __DECL_REG_LO8(which) e ## which ## x
+__DeFiNe__ __DECL_REG_LO16(name) e ## name
 # endif
 #elif defined(__x86_64__)
 #include "xen-x86_64.h"
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 1/3] x86emul: switch away from temporary 32-bit register names

[Jan Beulich]

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -811,7 +811,7 @@ do{ asm volatile (
 unsigned long tmp;  \
 invoke_stub(_PRE_EFLAGS("[efl]", "[msk]", "[tmp]"), \
 _POST_EFLAGS("[efl]", "[msk]", "[tmp]"),\
-dst, [tmp] "=" (tmp), [efl] "+g" (_regs._eflags)  \
+dst, [tmp] "=" (tmp), [efl] "+g" (_regs.eflags)   \
 : [msk] "i" (EFLAGS_MASK), ## src); \
 } while (0)
 
@@ -890,7 +890,7 @@ do {
 } while (0)
 #define register_address_adjust(reg, adj)   \
 _register_address_increment(reg,\
-_regs._eflags & X86_EFLAGS_DF ? \
+_regs.eflags & X86_EFLAGS_DF ?  \
 -(adj) : (adj), \
 ad_bytes)
 
@@ -914,7 +914,7 @@ do {
 rc = ops->insn_fetch(x86_seg_cs, ip, NULL, 0, ctxt);\
 if ( rc ) goto done;\
 _regs.r(ip) = ip;   \
-singlestep = _regs._eflags & X86_EFLAGS_TF; \
+singlestep = _regs.eflags & X86_EFLAGS_TF;  \
 } while (0)
 
 #define validate_far_branch(cs, ip) ({  \
@@ -931,7 +931,7 @@ do {
 #define commit_far_branch(cs, newip) ({ \
 validate_far_branch(cs, newip); \
 _regs.r(ip) = (newip);  \
-singlestep = _regs._eflags & X86_EFLAGS_TF; \
+singlestep = _regs.eflags & X86_EFLAGS_TF;  \
 ops->write_segment(x86_seg_cs, cs, ctxt);   \
 })
 
@@ -984,7 +984,7 @@ static int _get_fpu(
 if ( type >= X86EMUL_FPU_ymm )
 {
 /* Should be unreachable if VEX decoding is working correctly. */
-ASSERT((cr0 & X86_CR0_PE) && !(ctxt->regs->_eflags & 
X86_EFLAGS_VM));
+ASSERT((cr0 & X86_CR0_PE) && !(ctxt->regs->eflags & 
X86_EFLAGS_VM));
 }
 if ( cr0 & X86_CR0_EM )
 {
@@ -1071,7 +1071,7 @@ do {
 memcpy(get_stub(stub), ((uint8_t[]){ bytes, 0xc3 }), nr_ + 1);  \
 invoke_stub(_PRE_EFLAGS("[eflags]", "[mask]", "[tmp]"), \
 _POST_EFLAGS("[eflags]", "[mask]", "[tmp]"),\
-[eflags] "+g" (_regs._eflags), [tmp] "=" (tmp_),  \
+[eflags] "+g" (_regs.eflags), [tmp] "=" (tmp_),   \
 "+m" (fic)  \
 : [mask] "i" (X86_EFLAGS_ZF|X86_EFLAGS_PF|X86_EFLAGS_CF)); \
 put_stub(stub); \
@@ -1082,7 +1082,7 @@ static inline unsigned long get_loop_cou
 int ad_bytes)
 {
 return (ad_bytes > 4) ? regs->r(cx)
-  : (ad_bytes < 4) ? regs->cx : regs->_ecx;
+  : (ad_bytes < 4) ? regs->cx : regs->ecx;
 }
 
 static inline void put_loop_count(
@@ -1110,12 +1110,12 @@ static inline void put_loop_count(
 if ( mode_64bit() && ad_bytes == 4 )\
 {   \
 _regs.r(cx) = 0;\
-if ( using_si ) _regs.r(si) = _regs._esi;   \
-if ( using_di ) _regs.r(di) = _regs._edi;   \
+if ( using_si ) _regs.r(si) = _regs.esi;\
+if ( using_di ) _regs.r(di) = _regs.edi;\
 }   \
 goto complete_insn; \
 }   \
-if ( max_reps > 1 && (_regs._eflags & X86_EFLAGS_TF) && \
+if ( max_reps > 1 && (_regs.eflags & X86_EFLAGS_TF) &&  \
  !is_branch_step(ctxt, ops) )   \
 max_reps = 1;   \
 max_reps;   \
@@ -1149,7 +1149,7 @@ static void __put_rep_prefix(
 /* Clip maximum repetitions so that the index register at most just wraps. */
 #define truncate_ea_and_reps(ea, reps, bytes_per_rep) ({  \
 unsigned long todo__, ea__ = truncate_word(ea, ad_bytes); \
-if ( !(_regs._eflags & X86_EFLAGS_DF) )   \
+if ( !(_regs.eflags & X86_EFLAGS_DF) )

[Xen-devel] [PATCH 2/3] x86/hypercall: switch away from temporary 32-bit register names

[Jan Beulich]

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -146,7 +146,7 @@ int hvm_hypercall(struct cpu_user_regs *
 struct vcpu *curr = current;
 struct domain *currd = curr->domain;
 int mode = hvm_guest_x86_mode(curr);
-unsigned long eax = regs->_eax;
+unsigned long eax = regs->eax;
 
 switch ( mode )
 {
@@ -226,12 +226,12 @@ int hvm_hypercall(struct cpu_user_regs *
 }
 else
 {
-unsigned int ebx = regs->_ebx;
-unsigned int ecx = regs->_ecx;
-unsigned int edx = regs->_edx;
-unsigned int esi = regs->_esi;
-unsigned int edi = regs->_edi;
-unsigned int ebp = regs->_ebp;
+unsigned int ebx = regs->ebx;
+unsigned int ecx = regs->ecx;
+unsigned int edx = regs->edx;
+unsigned int esi = regs->esi;
+unsigned int edi = regs->edi;
+unsigned int ebp = regs->ebp;
 
 HVM_DBG_LOG(DBG_LEVEL_HCALL, "hcall%lu(%x, %x, %x, %x, %x, %x)", eax,
 ebx, ecx, edx, esi, edi, ebp);
--- a/xen/arch/x86/pv/hypercall.c
+++ b/xen/arch/x86/pv/hypercall.c
@@ -94,7 +94,7 @@ void pv_hypercall(struct cpu_user_regs *
 
 ASSERT(guest_kernel_mode(curr, regs));
 
-eax = is_pv_32bit_vcpu(curr) ? regs->_eax : regs->rax;
+eax = is_pv_32bit_vcpu(curr) ? regs->eax : regs->rax;
 
 BUILD_BUG_ON(ARRAY_SIZE(pv_hypercall_table) >
  ARRAY_SIZE(hypercall_args_table));
@@ -156,12 +156,12 @@ void pv_hypercall(struct cpu_user_regs *
 }
 else
 {
-unsigned int ebx = regs->_ebx;
-unsigned int ecx = regs->_ecx;
-unsigned int edx = regs->_edx;
-unsigned int esi = regs->_esi;
-unsigned int edi = regs->_edi;
-unsigned int ebp = regs->_ebp;
+unsigned int ebx = regs->ebx;
+unsigned int ecx = regs->ecx;
+unsigned int edx = regs->edx;
+unsigned int esi = regs->esi;
+unsigned int edi = regs->edi;
+unsigned int ebp = regs->ebp;
 
 #ifndef NDEBUG
 /* Deliberately corrupt parameter regs not used by this hypercall. */
@@ -184,7 +184,7 @@ void pv_hypercall(struct cpu_user_regs *
 }
 
 curr->hcall_compat = true;
-regs->_eax = pv_hypercall_table[eax].compat(ebx, ecx, edx, esi, edi, 
ebp);
+regs->eax = pv_hypercall_table[eax].compat(ebx, ecx, edx, esi, edi, 
ebp);
 curr->hcall_compat = false;
 
 #ifndef NDEBUG
@@ -193,12 +193,12 @@ void pv_hypercall(struct cpu_user_regs *
 /* Deliberately corrupt parameter regs used by this hypercall. */
 switch ( hypercall_args_table[eax].compat )
 {
-case 6: regs->_ebp = 0xdeadf00d;
-case 5: regs->_edi = 0xdeadf00d;
-case 4: regs->_esi = 0xdeadf00d;
-case 3: regs->_edx = 0xdeadf00d;
-case 2: regs->_ecx = 0xdeadf00d;
-case 1: regs->_ebx = 0xdeadf00d;
+case 6: regs->ebp = 0xdeadf00d;
+case 5: regs->edi = 0xdeadf00d;
+case 4: regs->esi = 0xdeadf00d;
+case 3: regs->edx = 0xdeadf00d;
+case 2: regs->ecx = 0xdeadf00d;
+case 1: regs->ebx = 0xdeadf00d;
 }
 }
 #endif



x86/hypercall: switch away from temporary 32-bit register names

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -146,7 +146,7 @@ int hvm_hypercall(struct cpu_user_regs *
 struct vcpu *curr = current;
 struct domain *currd = curr->domain;
 int mode = hvm_guest_x86_mode(curr);
-unsigned long eax = regs->_eax;
+unsigned long eax = regs->eax;
 
 switch ( mode )
 {
@@ -226,12 +226,12 @@ int hvm_hypercall(struct cpu_user_regs *
 }
 else
 {
-unsigned int ebx = regs->_ebx;
-unsigned int ecx = regs->_ecx;
-unsigned int edx = regs->_edx;
-unsigned int esi = regs->_esi;
-unsigned int edi = regs->_edi;
-unsigned int ebp = regs->_ebp;
+unsigned int ebx = regs->ebx;
+unsigned int ecx = regs->ecx;
+unsigned int edx = regs->edx;
+unsigned int esi = regs->esi;
+unsigned int edi = regs->edi;
+unsigned int ebp = regs->ebp;
 
 HVM_DBG_LOG(DBG_LEVEL_HCALL, "hcall%lu(%x, %x, %x, %x, %x, %x)", eax,
 ebx, ecx, edx, esi, edi, ebp);
--- a/xen/arch/x86/pv/hypercall.c
+++ b/xen/arch/x86/pv/hypercall.c
@@ -94,7 +94,7 @@ void pv_hypercall(struct cpu_user_regs *
 
 ASSERT(guest_kernel_mode(curr, regs));
 
-eax = is_pv_32bit_vcpu(curr) ? regs->_eax : regs->rax;
+eax = is_pv_32bit_vcpu(curr) ? regs->eax : regs->rax;
 
 BUILD_BUG_ON(ARRAY_SIZE(pv_hypercall_table) >
  ARRAY_SIZE(hypercall_args_table));
@@ -156,12 +156,12 @@ void pv_hypercall(struct cpu_user_regs *
 }
 else
 {
-unsigned int ebx = regs->_ebx;
-unsigned int ecx = 

[Xen-devel] [PATCH 0/3] x86: finish 32-bit register renaming

[Jan Beulich]

This is concluding the exercise, perhaps with the exception of seeing
whether some of the auxiliary stuff added to the public header can
now be removed again (which may require tweaking some of the
scripts parsing the headers).

1: x86emul: switch away from temporary 32-bit register names
2: x86/hypercall: switch away from temporary 32-bit register names
3: x86: drop underscore prefixed 32-bit register names

Signed-off-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v2] x86/emul: Correct the decoding of mov to/from cr/dr

[Jan Beulich]

>>> On 07.03.17 at 17:23,  wrote:
> The mov to/from cr/dr behave as if they were encoded with Mod = 3.  When
> encoded with Mod != 3, no displacement or SIB bytes are fetched.
> 
> Add a test with a deliberately malformed ModRM byte.  (Also add the
> automatically-generated simd.h to .gitignore.)
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH] vlapic/viridian: abort existing APIC assist if any vector is pending in ISR

[Jan Beulich]

>>> On 07.03.17 at 15:58,  wrote:
> The vlapic code already aborts an APIC assist if an interrupt is deferred
> because a higher priority interrupt has already been delivered (and hence
> its vector is pending in the ISR).
> 
> However, it is also necessary to abort an APIC assist in the case where a
> higher priority is about to be delivered because, in either case, at least
> two vectors will be pending in the ISR and hence an EOI is necessary.
> 
> Also, following on from the above reasoning, the decision to start a new
> APIC assist should clearly be based upon whether any other vector is
> pending in the ISR, regardless of whether it is lower or higher in
> priority. (In fact the code in question cannot be reached if the
> vector is lower in priority). Thus the single use of
> vlapic_find_lowest_vector() can be replaced with a call to
> vlapic_find_highest_isr() and the former function removed.
> 
> Without this patch, because the logic is flawed, a domain_crash() results
> when an attempt is made to erroneously start a new APIC assist.
> 
> Reported-by: Andrew Cooper 
> Signed-off-by: Paul Durrant 

Reviewed-by: Jan Beulich 



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

[Xen-devel] [PATCH v2] x86/emul: Correct the decoding of mov to/from cr/dr

[Andrew Cooper]

The mov to/from cr/dr behave as if they were encoded with Mod = 3.  When
encoded with Mod != 3, no displacement or SIB bytes are fetched.

Add a test with a deliberately malformed ModRM byte.  (Also add the
automatically-generated simd.h to .gitignore.)

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

v2:
 * Rebase over SSE series.
 * oct => hex
---
 .gitignore   |  1 +
 tools/tests/x86_emulator/test_x86_emulator.c | 21 +
 xen/arch/x86/x86_emulate/x86_emulate.c   | 20 +++-
 3 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/.gitignore b/.gitignore
index 443b12a..4567de7 100644
--- a/.gitignore
+++ b/.gitignore
@@ -217,6 +217,7 @@ tools/security/xensec_tool
 tools/tests/x86_emulator/asm
 tools/tests/x86_emulator/blowfish.bin
 tools/tests/x86_emulator/blowfish.h
+tools/tests/x86_emulator/simd.h
 tools/tests/x86_emulator/test_x86_emulator
 tools/tests/x86_emulator/x86_emulate
 tools/tests/xen-access/xen-access
diff --git a/tools/tests/x86_emulator/test_x86_emulator.c 
b/tools/tests/x86_emulator/test_x86_emulator.c
index c5467a0..1e416fc 100644
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -1000,6 +1000,27 @@ int main(int argc, char **argv)
 }
 printf("okay\n");
 
+printf("%-40s", "Testing mov %%cr4,%%esi (bad ModRM)...");
+/*
+ * Mod = 1, Reg = 4, R/M = 6 would normally encode a memory reference of
+ * disp8(%esi), but mov to/from cr/dr are special and behave as if they
+ * were encoded with Mod == 3.
+ */
+instr[0] = 0x0f; instr[1] = 0x20, instr[2] = 0x66;
+instr[3] = 0; /* Supposed disp8. */
+regs.esi = 0;
+regs.eip = (unsigned long)[0];
+rc = x86_emulate(, );
+/*
+ * We don't care precicely what gets read from %cr4 into %esi, just so
+ * long as ModRM is treated as a register operand and 0(%esi) isn't
+ * followed as a memory reference.
+ */
+if ( (rc != X86EMUL_OKAY) ||
+ (regs.eip != (unsigned long)[3]) )
+goto fail;
+printf("okay\n");
+
 #define decl_insn(which) extern const unsigned char which[], \
  which##_end[] asm ( ".L" #which "_end" )
 #define put_insn(which, insn) ".pushsection .test, \"ax\", @progbits\n" \
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c 
b/xen/arch/x86/x86_emulate/x86_emulate.c
index 63e4d89..1b507f7 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -2269,7 +2269,8 @@ x86_decode_twobyte(
 }
 /* fall through */
 case 0x21: case 0x23: /* mov to/from dr */
-generate_exception_if(lock_prefix || ea.type != OP_REG, EXC_UD);
+ASSERT(ea.type == OP_REG); /* Early operand adjustment ensures this. */
+generate_exception_if(lock_prefix, EXC_UD);
 op_bytes = mode_64bit() ? 8 : 4;
 break;
 
@@ -2685,6 +2686,23 @@ x86_decode(
 }
 break;
 
+case ext_0f:
+switch ( b )
+{
+case 0x20: /* mov cr,reg */
+case 0x21: /* mov dr,reg */
+case 0x22: /* mov reg,cr */
+case 0x23: /* mov reg,dr */
+/*
+ * Mov to/from cr/dr ignore the encoding of Mod, and behave as
+ * if they were encoded as reg/reg instructions.  No futher
+ * disp/SIB bytes are fetched.
+ */
+modrm_mod = 3;
+break;
+}
+break;
+
 case vex_0f38:
 d = ext0f38_table[b].to_mem ? DstMem | SrcReg
 : DstReg | SrcMem;
-- 
2.1.4


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

Re: [Xen-devel] [PATCH 6/7] xen/9pfs: receive responses

[Boris Ostrovsky]

On 03/06/2017 03:01 PM, Stefano Stabellini wrote:
> Upon receiving a notification from the backend, schedule the
> p9_xen_response work_struct. p9_xen_response checks if any responses are
> available, if so, it reads them one by one, calling p9_client_cb to send
> them up to the 9p layer (p9_client_cb completes the request). Handle the
> ring following the Xen 9pfs specification.
> 
> Signed-off-by: Stefano Stabellini 
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
> CC: Eric Van Hensbergen 
> CC: Ron Minnich 
> CC: Latchesar Ionkov 
> CC: v9fs-develo...@lists.sourceforge.net
> ---
>  net/9p/trans_xen.c | 53 +
>  1 file changed, 53 insertions(+)
> 
> diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
> index 4e26556..1ca9246 100644
> --- a/net/9p/trans_xen.c
> +++ b/net/9p/trans_xen.c
> @@ -149,6 +149,59 @@ static int p9_xen_request(struct p9_client *client, 
> struct p9_req_t *p9_req)
>  
>  static void p9_xen_response(struct work_struct *work)
>  {
> + struct xen_9pfs_front_priv *priv;
> + struct xen_9pfs_dataring *ring;
> + RING_IDX cons, prod, masked_cons, masked_prod;
> + struct xen_9pfs_header h;
> + struct p9_req_t *req;
> + int status = REQ_STATUS_ERROR;


Doesn't this need to go inside the loop?

> +
> + ring = container_of(work, struct xen_9pfs_dataring, work);
> + priv = ring->priv;
> +
> + while (1) {
> + cons = ring->intf->in_cons;
> + prod = ring->intf->in_prod;
> + rmb();


Is this rmb() or mb()? (Or, in fact, virt_XXX()?) You used mb() in the
previous patch.


> +
> + if (xen_9pfs_queued(prod, cons, XEN_9PFS_RING_SIZE) < 
> sizeof(h)) {
> + notify_remote_via_irq(ring->irq);
> + return;
> + }
> +
> + masked_prod = xen_9pfs_mask(prod, XEN_9PFS_RING_SIZE);
> + masked_cons = xen_9pfs_mask(cons, XEN_9PFS_RING_SIZE);
> +
> + xen_9pfs_read_packet(ring->ring.in,
> + masked_prod, _cons,
> + XEN_9PFS_RING_SIZE, , sizeof(h));
> +
> + req = p9_tag_lookup(priv->client, h.tag);
> + if (!req || req->status != REQ_STATUS_SENT) {
> + dev_warn(>dev->dev, "Wrong req tag=%x\n", h.tag);
> + cons += h.size;
> + mb();
> + ring->intf->in_cons = cons;
> + continue;


I don't know what xen_9pfs_read_packet() does so perhaps it's done there
but shouldn't the pointers be updated regardless of the 'if' condition?

-boris


> + }
> +
> + memcpy(req->rc, , sizeof(h));
> + req->rc->offset = 0;
> +
> + masked_cons = xen_9pfs_mask(cons, XEN_9PFS_RING_SIZE);
> + xen_9pfs_read_packet(ring->ring.in,
> + masked_prod, _cons,
> + XEN_9PFS_RING_SIZE, req->rc->sdata, h.size);
> +
> + mb();
> + cons += h.size;
> + ring->intf->in_cons = cons;
> +
> + if (req->status != REQ_STATUS_ERROR)
> + status = REQ_STATUS_RCVD;
> +
> + p9_client_cb(priv->client, req, status);
> + }
>  }
>  
>  static irqreturn_t xen_9pfs_front_event_handler(int irq, void *r)
> 


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

Re: [Xen-devel] [OSSTEST PATCH] ts-xtf-run: Understand ./xtf-runner returning CRASH

[Ian Jackson]

Andrew Cooper writes ("[OSSTEST PATCH] ts-xtf-run: Understand ./xtf-runner 
returning CRASH"):
> ./xtf-runner wants to distinguish between a clean and unclean exits of the
> test.  OSSTest doesn't care, so map unclean exit to failure.

Acked-by: Ian Jackson 

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

[Xen-devel] [OSSTEST PATCH] ts-xtf-run: Understand ./xtf-runner returning CRASH

[Andrew Cooper]

./xtf-runner wants to distinguish between a clean and unclean exits of the
test.  OSSTest doesn't care, so map unclean exit to failure.

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
CC: Wei Liu 
---
 ts-xtf-run | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ts-xtf-run b/ts-xtf-run
index d405bfb..c95ec5f 100755
--- a/ts-xtf-run
+++ b/ts-xtf-run
@@ -39,6 +39,7 @@ sub xtf_result_to_osstest_result ($) {
 return "skip" if $xret == 3; # XTF SKIP
 return "fail" if $xret == 4; # XTF ERROR
 return "fail" if $xret == 5; # XTF FAILURE
+return "fail" if $xret == 6; # XTF CRASH
 die "xtf runner gave unexpected result $xret";
 }
 
-- 
2.1.4


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

Re: [Xen-devel] [PATCH 5/7] xen/9pfs: send requests to the backend

[Boris Ostrovsky]

On 03/06/2017 03:01 PM, Stefano Stabellini wrote:
> Implement struct p9_trans_module create and close functions by looking
> at the available Xen 9pfs frontend-backend connections. We don't expect
> many frontend-backend connections, thus walking a list is OK.
> 
> Send requests to the backend by copying each request to one of the
> available rings (each frontend-backend connection comes with multiple
> rings). Handle the ring and notifications following the 9pfs
> specification. If there are not enough free bytes on the ring for the
> request, wait on the wait_queue: the backend will send a notification
> after consuming more requests.
> 
> Signed-off-by: Stefano Stabellini 
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
> CC: Eric Van Hensbergen 
> CC: Ron Minnich 
> CC: Latchesar Ionkov 
> CC: v9fs-develo...@lists.sourceforge.net
> ---
>  net/9p/trans_xen.c | 83 
> +-
>  1 file changed, 82 insertions(+), 1 deletion(-)
> 
> diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
> index 9f6cf8d..4e26556 100644
> --- a/net/9p/trans_xen.c
> +++ b/net/9p/trans_xen.c
> @@ -47,22 +47,103 @@ struct xen_9pfs_front_priv {
>  };
>  static LIST_HEAD(xen_9pfs_devs);
>  
> +/* We don't currently allow canceling of requests */
>  static int p9_xen_cancel(struct p9_client *client, struct p9_req_t *req)
>  {
> - return 0;
> + return 1;
>  }
>  
>  static int p9_xen_create(struct p9_client *client, const char *addr, char 
> *args)
>  {
> + struct xen_9pfs_front_priv *priv = NULL;
> +
> + list_for_each_entry(priv, _9pfs_devs, list) {
> + if (!strcmp(priv->tag, addr))
> + break;
> + }


You could simplify this (and p9_xen_close()) but assigning client and
returning from inside the 'if' statement.

I am also not sure you need to initialize priv.


> + if (!priv || strcmp(priv->tag, addr))
> + return -EINVAL;
> +
> + priv->client = client; 
>   return 0;
>  }
>  
>  static void p9_xen_close(struct p9_client *client)
>  {
> + struct xen_9pfs_front_priv *priv = NULL;
> +
> + list_for_each_entry(priv, _9pfs_devs, list) {
> + if (priv->client == client)
> + break;
> + }
> + if (!priv || priv->client != client)
> + return;
> +
> + priv->client = NULL; 
> + return;
> +}
> +
> +static int p9_xen_write_todo(struct xen_9pfs_dataring *ring, RING_IDX size)
> +{
> + RING_IDX cons, prod;
> +
> + cons = ring->intf->out_cons;
> + prod = ring->intf->out_prod;
> + mb();
> +
> + if (XEN_9PFS_RING_SIZE - xen_9pfs_queued(prod, cons, 
> XEN_9PFS_RING_SIZE) >= size)
> + return 1;
> + else
> + return 0;
>  }
>  
>  static int p9_xen_request(struct p9_client *client, struct p9_req_t *p9_req)
>  {
> + struct xen_9pfs_front_priv *priv = NULL;
> + RING_IDX cons, prod, masked_cons, masked_prod;
> + unsigned long flags;
> + uint32_t size = p9_req->tc->size;
> + struct xen_9pfs_dataring *ring;
> + int num;
> +
> + list_for_each_entry(priv, _9pfs_devs, list) {
> + if (priv->client == client)
> + break;
> + }
> + if (priv == NULL || priv->client != client)
> + return -EINVAL;
> +
> + num = p9_req->tc->tag % priv->num_rings;
> + ring = >rings[num];
> +
> +again:
> + while (wait_event_interruptible(ring->wq,
> + p9_xen_write_todo(ring, size) > 0) != 0);
> +
> + spin_lock_irqsave(>lock, flags);
> + cons = ring->intf->out_cons;
> + prod = ring->intf->out_prod;
> + mb();
> +
> + if (XEN_9PFS_RING_SIZE - xen_9pfs_queued(prod, cons, 
> XEN_9PFS_RING_SIZE) < size) {


This looks like p9_xen_write_todo(). BTW, where is xen_9pfs_queued()
defined? I couldn't find it. Same for xen_9pfs_mask() and
xen_9pfs_write_packet().

-boris


> + spin_unlock_irqrestore(>lock, flags);
> + goto again;
> + }
> +
> + masked_prod = xen_9pfs_mask(prod, XEN_9PFS_RING_SIZE);
> + masked_cons = xen_9pfs_mask(cons, XEN_9PFS_RING_SIZE);
> +
> + xen_9pfs_write_packet(ring->ring.out,
> + _prod, masked_cons,
> + XEN_9PFS_RING_SIZE, p9_req->tc->sdata, size);
> +
> + p9_req->status = REQ_STATUS_SENT;
> + wmb();  /* write ring before updating pointer */
> + prod += size;
> + ring->intf->out_prod = prod;
> + spin_unlock_irqrestore(>lock, flags);
> + notify_remote_via_irq(ring->irq);
> +
>   return 0;
>  }
>  
> 


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 106482
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106482
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 106482
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 106482
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 106482
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 106482
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 106482
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 106482

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   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-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-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-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  caf053fb545329e58ac891d197f96503e3121049
baseline version:
 xen  6d55c0c316357a412526b9dccd45d3c3abb75227

Last test of basis   106482  2017-03-06 01:57:48 Z1 days
Failing since106504  2017-03-06 19:44:53 Z0 days2 attempts
Testing same since   106513  2017-03-07 05:59:24 Z0 days1 attempts


People who touched revisions under test:
  Edgar E. Iglesias 
  Jan Beulich 
  Razvan Cojocaru 
  Stefano Stabellini 
  Tamas K Lengyel 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  fail   

Re: [Xen-devel] [PATCH 4/7] xen/9pfs: connect to the backend

[Boris Ostrovsky]

>  
> +static int xen_9pfs_front_free(struct xen_9pfs_front_priv *priv)
> +{
> + int i, j;
> +
> + list_del(>list);
> +
> + for (i = 0; i < priv->num_rings; i++) {
> + if (priv->rings[i].intf == NULL)
> + break;

Are we guaranteed that all subsequent entries are not allocated (i.e.
this shouldn't be 'continue')?

> + if (priv->rings[i].irq > 0)
> + unbind_from_irqhandler(priv->rings[i].irq, priv->dev);
> + if (priv->rings[i].bytes != NULL) {
> + for (j = 0; j < (1 << XEN_9PFS_RING_ORDER); j++)
> + 
> gnttab_end_foreign_access(priv->rings[i].intf->ref[j], 0, 0);
> + free_pages((unsigned long)priv->rings[i].bytes, 
> XEN_9PFS_RING_ORDER);
> + }
> + gnttab_end_foreign_access(priv->rings[i].ref, 0, 0);
> + free_page((unsigned long)priv->rings[i].intf);
> + }
> + kfree(priv->rings);
> + kfree(priv);
> +
> + return 0;
> +}
> +
>  static int xen_9pfs_front_remove(struct xenbus_device *dev)
>  {
> + int ret;
> + struct xen_9pfs_front_priv *priv = dev_get_drvdata(>dev);
> +
> + dev_set_drvdata(>dev, NULL);
> + ret = xen_9pfs_front_free(priv);
> + return ret;
> +}
> +
> +static int xen_9pfs_front_alloc_dataring(struct xenbus_device *dev,
> + struct xen_9pfs_dataring *ring)
> +{
> + int i;
> + int ret = -ENOMEM;
> +
> + init_waitqueue_head(>wq);
> + spin_lock_init(>lock);
> + INIT_WORK(>work, p9_xen_response);
> +
> + ring->intf = (struct xen_9pfs_data_intf *) __get_free_page(GFP_KERNEL | 
> __GFP_ZERO);
> + if (!ring->intf)
> + goto error;
> + memset(ring->intf, 0, XEN_PAGE_SIZE);

get_zeroed_page()?  (especially given that __get_free_page() returns
PAGE_SIZE, not XEN_PAGE_SIZE)


> + ring->bytes = (void*)__get_free_pages(GFP_KERNEL | __GFP_ZERO, 
> XEN_9PFS_RING_ORDER);
> + if (ring->bytes == NULL)
> + goto error;
> + for (i = 0; i < (1 << XEN_9PFS_RING_ORDER); i++)
> + ring->intf->ref[i] = 
> gnttab_grant_foreign_access(dev->otherend_id, 
> pfn_to_gfn(virt_to_pfn((void*)ring->bytes) + i), 0);
> + ring->ref = gnttab_grant_foreign_access(dev->otherend_id, 
> pfn_to_gfn(virt_to_pfn((void*)ring->intf)), 0);
> + ring->ring.in = ring->bytes;
> + ring->ring.out = ring->bytes + XEN_9PFS_RING_SIZE;
> +
> + ret = xenbus_alloc_evtchn(dev, >evtchn);
> + if (ret)
> + goto error;
> + ring->irq = bind_evtchn_to_irqhandler(ring->evtchn, 
> xen_9pfs_front_event_handler,
> + 0, "xen_9pfs-frontend", ring);
> + if (ring->irq < 0) {
> + xenbus_free_evtchn(dev, ring->evtchn);
> + ret = ring->irq;
> + goto error;
> + }
>   return 0;
> +
> +error:

You may need to gnttab_end_foreign_access().

> + if (ring->intf != NULL)
> + kfree(ring->intf);
> + if (ring->bytes != NULL)
> + kfree(ring->bytes);
> + return ret;
>  }
>  
>  static int xen_9pfs_front_probe(struct xenbus_device *dev,
>   const struct xenbus_device_id *id)
>  {
> + int ret = -EFAULT, i;

Unnecessary initialization.

> + struct xenbus_transaction xbt;
> + struct xen_9pfs_front_priv *priv = NULL;
> + char *versions;
> + unsigned int max_rings, max_ring_order, len;
> +
> + versions = xenbus_read(XBT_NIL, dev->otherend, "versions", );
> + if (!len || strcmp(versions, "1"))
> + return -EINVAL;
> + kfree(versions);
> + ret = xenbus_scanf(XBT_NIL, dev->otherend, "max-rings", "%u", 
> _rings);
> + if (ret < 0 || max_rings < XEN_9PFS_NUM_RINGS)
> + return -EINVAL;
> + ret = xenbus_scanf(XBT_NIL, dev->otherend, "max-ring-page-order", "%u", 
> _ring_order);
> + if (ret < 0|| max_ring_order < XEN_9PFS_RING_ORDER)
> + return -EINVAL;
> +
> +
> + priv = kzalloc(sizeof(struct xen_9pfs_front_priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->dev = dev;
> + priv->num_rings = XEN_9PFS_NUM_RINGS;
> + priv->rings = kzalloc(sizeof(struct xen_9pfs_dataring) * 
> priv->num_rings,
> + GFP_KERNEL);
> + if (!priv->rings) {
> + kfree(priv);
> + return -ENOMEM;
> + }
> +
> + again:
> + ret = xenbus_transaction_start();
> + if (ret) {
> + xenbus_dev_fatal(dev, ret, "starting transaction");
> + goto error;
> + }
> + ret = xenbus_printf(xbt, dev->nodename, "version", "%u", 1);
> + if (ret)
> + goto error_xenbus;
> + ret = xenbus_printf(xbt, dev->nodename, "num-rings", "%u", 
> priv->num_rings);
> + if (ret)
> + goto error_xenbus;
> + for (i = 0; i < priv->num_rings; i++) {
> + char str[16];
> +
> + 

Re: [Xen-devel] [PATCH 1/7] x86/hvm: Correctly identify implicit supervisor accesses

[Paul Durrant]

> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 27 February 2017 14:03
> To: Xen-devel 
> Cc: Andrew Cooper ; Jan Beulich
> ; Paul Durrant ; George
> Dunlap ; Tim (Xen.org) 
> Subject: [PATCH 1/7] x86/hvm: Correctly identify implicit supervisor accesses
> 
> All actions which refer to the active ldt/gdt/idt or task register
> (e.g. loading a new segment selector) are known as implicit supervisor
> accesses, even when the access originates from user code.
> 
> The distinction is necessary in the pagewalk when SMAP is enabled.  Refer to
> Intel SDM Vol 3 "Access Rights" for the exact details.
> 
> Introduce a new pagewalk input, and make use of the new system segment
> references in hvmemul_{read,write}().  While modifying those areas, move
> the
> calculation of the appropriate pagewalk input before its first use.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Paul Durrant 

> ---
> CC: Jan Beulich 
> CC: Paul Durrant 
> CC: George Dunlap 
> CC: Tim Deegan 
> ---
>  xen/arch/x86/hvm/emulate.c  | 18 ++
>  xen/arch/x86/mm/guest_walk.c|  4 
>  xen/include/asm-x86/processor.h |  1 +
>  3 files changed, 15 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> index f24d289..9b32bca 100644
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -783,6 +783,11 @@ static int __hvmemul_read(
>  struct hvm_vcpu_io *vio = >arch.hvm_vcpu.hvm_io;
>  int rc;
> 
> +if ( is_x86_system_segment(seg) )
> +pfec |= PFEC_implicit;
> +else if ( hvmemul_ctxt->seg_reg[x86_seg_ss].attr.fields.dpl == 3 )
> +pfec |= PFEC_user_mode;
> +
>  rc = hvmemul_virtual_to_linear(
>  seg, offset, bytes, , access_type, hvmemul_ctxt, );
>  if ( rc != X86EMUL_OKAY || !bytes )
> @@ -793,10 +798,6 @@ static int __hvmemul_read(
>   (vio->mmio_gla == (addr & PAGE_MASK)) )
>  return hvmemul_linear_mmio_read(addr, bytes, p_data, pfec,
> hvmemul_ctxt, 1);
> 
> -if ( (seg != x86_seg_none) &&
> - (hvmemul_ctxt->seg_reg[x86_seg_ss].attr.fields.dpl == 3) )
> -pfec |= PFEC_user_mode;
> -
>  rc = ((access_type == hvm_access_insn_fetch) ?
>hvm_fetch_from_guest_linear(p_data, addr, bytes, pfec, ) :
>hvm_copy_from_guest_linear(p_data, addr, bytes, pfec, ));
> @@ -893,6 +894,11 @@ static int hvmemul_write(
>  struct hvm_vcpu_io *vio = >arch.hvm_vcpu.hvm_io;
>  int rc;
> 
> +if ( is_x86_system_segment(seg) )
> +pfec |= PFEC_implicit;
> +else if ( hvmemul_ctxt->seg_reg[x86_seg_ss].attr.fields.dpl == 3 )
> +pfec |= PFEC_user_mode;
> +
>  rc = hvmemul_virtual_to_linear(
>  seg, offset, bytes, , hvm_access_write, hvmemul_ctxt, );
>  if ( rc != X86EMUL_OKAY || !bytes )
> @@ -902,10 +908,6 @@ static int hvmemul_write(
>   (vio->mmio_gla == (addr & PAGE_MASK)) )
>  return hvmemul_linear_mmio_write(addr, bytes, p_data, pfec,
> hvmemul_ctxt, 1);
> 
> -if ( (seg != x86_seg_none) &&
> - (hvmemul_ctxt->seg_reg[x86_seg_ss].attr.fields.dpl == 3) )
> -pfec |= PFEC_user_mode;
> -
>  rc = hvm_copy_to_guest_linear(addr, p_data, bytes, pfec, );
> 
>  switch ( rc )
> diff --git a/xen/arch/x86/mm/guest_walk.c
> b/xen/arch/x86/mm/guest_walk.c
> index faaf70c..4f8d0e3 100644
> --- a/xen/arch/x86/mm/guest_walk.c
> +++ b/xen/arch/x86/mm/guest_walk.c
> @@ -161,6 +161,10 @@ guest_walk_tables(struct vcpu *v, struct
> p2m_domain *p2m,
>  bool_t pse1G = 0, pse2M = 0;
>  p2m_query_t qt = P2M_ALLOC | P2M_UNSHARE;
> 
> +/* Only implicit supervisor data accesses exist. */
> +ASSERT(!(pfec & PFEC_implicit) ||
> +   !(pfec & (PFEC_insn_fetch|PFEC_user_mode)));
> +
>  perfc_incr(guest_walk);
>  memset(gw, 0, sizeof(*gw));
>  gw->va = va;
> diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-
> x86/processor.h
> index dda8b83..d3ba8ea 100644
> --- a/xen/include/asm-x86/processor.h
> +++ b/xen/include/asm-x86/processor.h
> @@ -76,6 +76,7 @@
>  /* Internally used only flags. */
>  #define PFEC_page_paged (1U<<16)
>  #define PFEC_page_shared(1U<<17)
> +#define PFEC_implicit   (1U<<18) /* Pagewalk input for ldt/gdt/idt/tr
> accesses. */
> 
>  /* Other exception error code values. */
>  #define X86_XEC_EXT (_AC(1,U) << 0)
> --
> 2.1.4


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

[Xen-devel] [PATCH] vlapic/viridian: abort existing APIC assist if any vector is pending in ISR

[Paul Durrant]

The vlapic code already aborts an APIC assist if an interrupt is deferred
because a higher priority interrupt has already been delivered (and hence
its vector is pending in the ISR).

However, it is also necessary to abort an APIC assist in the case where a
higher priority is about to be delivered because, in either case, at least
two vectors will be pending in the ISR and hence an EOI is necessary.

Also, following on from the above reasoning, the decision to start a new
APIC assist should clearly be based upon whether any other vector is
pending in the ISR, regardless of whether it is lower or higher in
priority. (In fact the code in question cannot be reached if the
vector is lower in priority). Thus the single use of
vlapic_find_lowest_vector() can be replaced with a call to
vlapic_find_highest_isr() and the former function removed.

Without this patch, because the logic is flawed, a domain_crash() results
when an attempt is made to erroneously start a new APIC assist.

Reported-by: Andrew Cooper 
Signed-off-by: Paul Durrant 
---
Cc: Andrew Cooper 
Cc: Jan Beulich 
---
 xen/arch/x86/hvm/vlapic.c | 54 +--
 1 file changed, 19 insertions(+), 35 deletions(-)

diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 3fa3727..14356a7 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -95,19 +95,6 @@ static int vlapic_find_highest_vector(const void *bitmap)
 return (fls(word[word_offset*4]) - 1) + (word_offset * 32);
 }
 
-static int vlapic_find_lowest_vector(const void *bitmap)
-{
-const uint32_t *word = bitmap;
-unsigned int word_offset;
-
-/* Work forwards through the bitmap (first 32-bit word in every four). */
-for ( word_offset = 0; word_offset < NR_VECTORS / 32; word_offset++)
-if ( word[word_offset * 4] )
-return (ffs(word[word_offset * 4]) - 1) + (word_offset * 32);
-
-return -1;
-}
-
 /*
  * IRR-specific bitmap update & search routines.
  */
@@ -1201,19 +1188,17 @@ int vlapic_has_pending_irq(struct vcpu *v)
 vlapic_clear_vector(vector, >regs->data[APIC_ISR]);
 
 isr = vlapic_find_highest_isr(vlapic);
-isr = (isr != -1) ? isr : 0;
-if ( (isr & 0xf0) >= (irr & 0xf0) )
-{
-/*
- * There's already a higher priority vector pending so
- * we need to abort any previous APIC assist to ensure there
- * is an EOI.
- */
-viridian_abort_apic_assist(v);
-return -1;
-}
+if ( isr == -1 )
+return irr;
 
-return irr;
+/*
+ * A vector is pending in the ISR so, regardless of whether the new
+ * vector in the IRR is lower or higher in priority, any pending
+ * APIC assist must be aborted to ensure an EOI.
+ */
+viridian_abort_apic_assist(v);
+
+return ((isr & 0xf0) < (irr & 0xf0)) ? irr : -1;
 }
 
 int vlapic_ack_pending_irq(struct vcpu *v, int vector, bool_t force_ack)
@@ -1230,16 +1215,15 @@ int vlapic_ack_pending_irq(struct vcpu *v, int vector, 
bool_t force_ack)
  vlapic_test_vector(vector, >regs->data[APIC_TMR]) )
 goto done;
 
-isr = vlapic_find_lowest_vector(>regs->data[APIC_ISR]);
-if ( isr >= 0 && isr < vector )
-goto done;
-
-/*
- * This vector is edge triggered and there are no lower priority
- * vectors pending, so we can use APIC assist to avoid exiting
- * for EOI.
- */
-viridian_start_apic_assist(v, vector);
+isr = vlapic_find_highest_isr(vlapic);
+if ( isr == -1 )
+{
+/*
+ * This vector is edge triggered and no other vectors are pending
+ * in the ISR so we can use APIC assist to avoid exiting for EOI.
+ */
+viridian_start_apic_assist(v, vector);
+}
 
  done:
 vlapic_set_vector(vector, >regs->data[APIC_ISR]);
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v3] xen: Allow a default compiled-in command line using Kconfig

[Jan Beulich]

>>> On 07.03.17 at 15:41,  wrote:
> Hi Jan,
> 
> On 03/07/2017 02:18 PM, Jan Beulich wrote:
> On 07.03.17 at 14:48,  wrote:
>>> On 03/07/2017 12:52 PM, Jan Beulich wrote:
>>> On 07.03.17 at 12:21,  wrote:
> 2017-03-07 17:36 GMT+08:00 Jan Beulich :
> On 07.03.17 at 09:34,  wrote:
>>> +static inline char* __init extract_dom0_options(char *cmdline)
>>> +{
>>> +char *kextra;
>>> +
>>> +if ( (kextra = strstr(cmdline, " -- ")) != NULL )
>>> +{
>>> +*kextra = '\0';
>>> +kextra += 3;
>>> +while ( kextra[1] == ' ' ) kextra++;
>>
>> The body of the while() wants to go on its own line.
>>
>> And then - why is this Dom0 option handling done only on x86?
>>
>
> As you might have noticed, there isn't any code dealing with the dom0 
> options
> in arch/arm/setup.c, and the arm version of construct_dom0() doesn't take 
> any
> command line options as its parameter,
> so I have the reason to believe that this feature is not available
> under the arm architecture.

 Looks like an omission to me - Julien, Stefano?
>>>
>>> DOM0 and Xen command line are passed separately through either Device
>>> Tree or for UEFI xen configuration file (see -cfg=...).
>>>
>>> So I am not sure to understand what would be the benefits to handle DOM0
>>> parameters after -- on Xen command line.
>>
>> So you have no case of a boot loader which allows you to type in
>> extra options on just a single line? On x86 the feature had originally
>> been added because old grub didn't have a separate line for Dom0
>> options in its graphical menu. Nowadays the functionality is handy
>> namely when starting xen.efi from the EFI shell (where again you
>> obviously only have a single command line), but quite likely this may
>> also be of use with grub's chain loading model (which I simply don't
>> use very often, so I'm not finally sure on that one).
> 
> My knowledge is quite limited on boot process for x86. How do you pass 
> the kernel/initrd/xsm blob on UEFI? Can you do it from the command line 
> or are you using the -cfg=... and specify it in a file?

Only the latter.

> On ARM we have two way to boot Xen:
>   - Using UEFI bootloader with either Device-Tree or ACPI
>   - Using non-UEFI bootloader with Device-Tree only
> 
> In the case of UEFI bootloader, we are using the xen configuration file 
> to describe the modules (e.g kernel, initramfs, XSM) and the both xen 
> and DOM0 command line.
> 
> For non-UEFI bootloader, we have designed the boot protocol based on the 
> device-tree and will allows you to specify both xen and DOM0 and all the 
> modules (see [1]). The bootloader needs to be able to modify the 
> device-tree (such via a shell like on U-boot) or the user needs to 
> modify the device-tree before hand.

All fine, but this doesn't tell me what interactive change options a
user has _after_ having set up the config file (or alike), while the
system is booting.

> To answer your question, a bootloader supporting only a single line 
> would still need to be modified to provide the various modules. At that 
> stage, adding DOM0 command line is very easy.

But aiui that's again needed to be done _before_ the system is
rebooted.

> Now, if you tell me that all the modules can be described on the UEFI 
> command line, then I think handling '--' would be nice. If not, I don't 
> think it is worth it.

As per above I'm getting the impression that we're talking of
different scenarios - I don't think I've yet understood what options
of adding to or editing of any of the command lines you have on
ARM _during_ the boot process of a system.

Jan


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

Re: [Xen-devel] [PATCH 13/29] drivers, media: convert vb2_vmarea_handler.refcount from atomic_t to refcount_t

[Reshetova, Elena]

> Hi Elena,
> 
> On Mon, Mar 06, 2017 at 04:21:00PM +0200, Elena Reshetova wrote:
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-after-free
> > situations.
> >
> > Signed-off-by: Elena Reshetova 
> > Signed-off-by: Hans Liljestrand 
> > Signed-off-by: Kees Cook 
> > Signed-off-by: David Windsor 
> > ---
> >  drivers/media/v4l2-core/videobuf2-memops.c | 6 +++---
> >  include/media/videobuf2-memops.h   | 3 ++-
> >  2 files changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/media/v4l2-core/videobuf2-memops.c 
> > b/drivers/media/v4l2-
> core/videobuf2-memops.c
> > index 1cd322e..4bb8424 100644
> > --- a/drivers/media/v4l2-core/videobuf2-memops.c
> > +++ b/drivers/media/v4l2-core/videobuf2-memops.c
> > @@ -96,10 +96,10 @@ static void vb2_common_vm_open(struct
> vm_area_struct *vma)
> > struct vb2_vmarea_handler *h = vma->vm_private_data;
> >
> > pr_debug("%s: %p, refcount: %d, vma: %08lx-%08lx\n",
> > -  __func__, h, atomic_read(h->refcount), vma->vm_start,
> > +  __func__, h, refcount_read(h->refcount), vma->vm_start,
> >vma->vm_end);
> >
> > -   atomic_inc(h->refcount);
> > +   refcount_inc(h->refcount);
> >  }
> >
> >  /**
> > @@ -114,7 +114,7 @@ static void vb2_common_vm_close(struct
> vm_area_struct *vma)
> > struct vb2_vmarea_handler *h = vma->vm_private_data;
> >
> > pr_debug("%s: %p, refcount: %d, vma: %08lx-%08lx\n",
> > -  __func__, h, atomic_read(h->refcount), vma->vm_start,
> > +  __func__, h, refcount_read(h->refcount), vma->vm_start,
> >vma->vm_end);
> >
> > h->put(h->arg);
> > diff --git a/include/media/videobuf2-memops.h b/include/media/videobuf2-
> memops.h
> > index 36565c7a..a6ed091 100644
> > --- a/include/media/videobuf2-memops.h
> > +++ b/include/media/videobuf2-memops.h
> > @@ -16,6 +16,7 @@
> >
> >  #include 
> >  #include 
> > +#include 
> >
> >  /**
> >   * struct vb2_vmarea_handler - common vma refcount tracking handler
> > @@ -25,7 +26,7 @@
> >   * @arg:   argument for @put callback
> >   */
> >  struct vb2_vmarea_handler {
> > -   atomic_t*refcount;
> > +   refcount_t  *refcount;
> 
> This is a pointer to refcount, not refcount itself. The refcount is part of
> a memory type specific struct, the types that you change in the following
> three patches. I guess it would still compile and work as separate patches
> but you'd sure get warnings at least.

Actually it doesn't compile without this patch if I remember it correctly back 
in past when I was initially splitting the patches per variable. 

> 
> How about merging this and the three following patches that change the memop
> refcount types?

Sounds good!

Best Regards,
Elena.
> 
> > void(*put)(void *arg);
> > void*arg;
> >  };
> 
> --
> Kind regards,
> 
> Sakari Ailus
> e-mail: sakari.ai...@iki.fi   XMPP: sai...@retiisi.org.uk

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

Re: [Xen-devel] [PATCH 12/29] drivers, media: convert s2255_dev.num_channels from atomic_t to refcount_t

[Reshetova, Elena]

> Hi Elena,
> 
> On Mon, Mar 06, 2017 at 04:20:59PM +0200, Elena Reshetova wrote:
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-after-free
> > situations.
> >
> > Signed-off-by: Elena Reshetova 
> > Signed-off-by: Hans Liljestrand 
> > Signed-off-by: Kees Cook 
> > Signed-off-by: David Windsor 
> > ---
> ...
> > @@ -1688,7 +1689,7 @@ static int s2255_probe_v4l(struct s2255_dev *dev)
> > "failed to register
> video device!\n");
> > break;
> > }
> > -   atomic_inc(>num_channels);
> > +   refcount_set(>num_channels, 1);
> 
> That's not right. The loop runs four iterations and the value after the
> loop should be indeed the number of channels.

Oh, yes, I was blind here, sorry. The problem why it cannot be left as inc is 
because it would do increment from zero here, which is not allowed by 
refcount_t interface. 

> atomic_t isn't really used for reference counting here, but storing out how
> many "channels" there are per hardware device, with maximum number of four
> (4). I'd leave this driver using atomic_t.
Yes, sounds like the best thing to do. I will drop this patch. 

Thank you for reviews!

Best Regards,
Elena.
> 
> > v4l2_info(>v4l2_dev, "V4L2 device registered
> as %s\n",
> >   video_device_node_name(
> >vdev));
> >
> 
> --
> Kind regards,
> 
> Sakari Ailus
> e-mail: sakari.ai...@iki.fi   XMPP: sai...@retiisi.org.uk

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

Re: [Xen-devel] [PATCH v3] xen: Allow a default compiled-in command line using Kconfig

[Julien Grall]

Hi Jan,

On 03/07/2017 02:18 PM, Jan Beulich wrote:

On 07.03.17 at 14:48,  wrote:

On 03/07/2017 12:52 PM, Jan Beulich wrote:

On 07.03.17 at 12:21,  wrote:

2017-03-07 17:36 GMT+08:00 Jan Beulich :

On 07.03.17 at 09:34,  wrote:

+static inline char* __init extract_dom0_options(char *cmdline)
+{
+char *kextra;
+
+if ( (kextra = strstr(cmdline, " -- ")) != NULL )
+{
+*kextra = '\0';
+kextra += 3;
+while ( kextra[1] == ' ' ) kextra++;


The body of the while() wants to go on its own line.

And then - why is this Dom0 option handling done only on x86?



As you might have noticed, there isn't any code dealing with the dom0 options
in arch/arm/setup.c, and the arm version of construct_dom0() doesn't take any
command line options as its parameter,
so I have the reason to believe that this feature is not available
under the arm architecture.


Looks like an omission to me - Julien, Stefano?


DOM0 and Xen command line are passed separately through either Device
Tree or for UEFI xen configuration file (see -cfg=...).

So I am not sure to understand what would be the benefits to handle DOM0
parameters after -- on Xen command line.


So you have no case of a boot loader which allows you to type in
extra options on just a single line? On x86 the feature had originally
been added because old grub didn't have a separate line for Dom0
options in its graphical menu. Nowadays the functionality is handy
namely when starting xen.efi from the EFI shell (where again you
obviously only have a single command line), but quite likely this may
also be of use with grub's chain loading model (which I simply don't
use very often, so I'm not finally sure on that one).


My knowledge is quite limited on boot process for x86. How do you pass 
the kernel/initrd/xsm blob on UEFI? Can you do it from the command line 
or are you using the -cfg=... and specify it in a file?


On ARM we have two way to boot Xen:
- Using UEFI bootloader with either Device-Tree or ACPI
- Using non-UEFI bootloader with Device-Tree only

In the case of UEFI bootloader, we are using the xen configuration file 
to describe the modules (e.g kernel, initramfs, XSM) and the both xen 
and DOM0 command line.


For non-UEFI bootloader, we have designed the boot protocol based on the 
device-tree and will allows you to specify both xen and DOM0 and all the 
modules (see [1]). The bootloader needs to be able to modify the 
device-tree (such via a shell like on U-boot) or the user needs to 
modify the device-tree before hand.


To answer your question, a bootloader supporting only a single line 
would still need to be modified to provide the various modules. At that 
stage, adding DOM0 command line is very easy.


Now, if you tell me that all the modules can be described on the UEFI 
command line, then I think handling '--' would be nice. If not, I don't 
think it is worth it.


Cheers,

[1] http://xenbits.xen.org/docs/unstable/misc/arm/device-tree/booting.txt
--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 016/17] x86emul: support AESNI insns

[Andrew Cooper]

On 03/03/17 15:07, Jan Beulich wrote:
> ... and their AVX equivalents.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v5 12/17] x86emul: support SSE4.1 insns

[Andrew Cooper]

On 03/03/17 15:04, Jan Beulich wrote:
> ... and their AVX equivalents.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v5 15/17] x86emul: support PCLMULQDQ

[Andrew Cooper]

On 03/03/17 15:07, Jan Beulich wrote:
> ... and its AVX equivalent.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v5 10/17] x86emul: add tables for 0f38 and 0f3a extension space

[Andrew Cooper]

On 03/03/17 15:03, Jan Beulich wrote:
> Convert the few existing opcodes so far supported.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v3] xen: Allow a default compiled-in command line using Kconfig

[Jan Beulich]

>>> On 07.03.17 at 14:48,  wrote:
> On 03/07/2017 12:52 PM, Jan Beulich wrote:
> On 07.03.17 at 12:21,  wrote:
>>> 2017-03-07 17:36 GMT+08:00 Jan Beulich :
>>> On 07.03.17 at 09:34,  wrote:
> +static inline char* __init extract_dom0_options(char *cmdline)
> +{
> +char *kextra;
> +
> +if ( (kextra = strstr(cmdline, " -- ")) != NULL )
> +{
> +*kextra = '\0';
> +kextra += 3;
> +while ( kextra[1] == ' ' ) kextra++;

 The body of the while() wants to go on its own line.

 And then - why is this Dom0 option handling done only on x86?

>>>
>>> As you might have noticed, there isn't any code dealing with the dom0 
>>> options
>>> in arch/arm/setup.c, and the arm version of construct_dom0() doesn't take 
>>> any
>>> command line options as its parameter,
>>> so I have the reason to believe that this feature is not available
>>> under the arm architecture.
>>
>> Looks like an omission to me - Julien, Stefano?
> 
> DOM0 and Xen command line are passed separately through either Device 
> Tree or for UEFI xen configuration file (see -cfg=...).
> 
> So I am not sure to understand what would be the benefits to handle DOM0 
> parameters after -- on Xen command line.

So you have no case of a boot loader which allows you to type in
extra options on just a single line? On x86 the feature had originally
been added because old grub didn't have a separate line for Dom0
options in its graphical menu. Nowadays the functionality is handy
namely when starting xen.efi from the EFI shell (where again you
obviously only have a single command line), but quite likely this may
also be of use with grub's chain loading model (which I simply don't
use very often, so I'm not finally sure on that one).

Jan


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

Re: [Xen-devel] [PATCH v5 04/17] x86emul: support {, V}{, U}COMIS{S, D}

[Andrew Cooper]

On 03/03/17 14:59, Jan Beulich wrote:
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

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

[Jan Beulich]

>>> On 07.03.17 at 05:24,  wrote:
> On Tue, Mar 07, 2017 at 02:16:50AM -0700, Jan Beulich wrote:
> On 07.03.17 at 06:52,  wrote:
>>> flight 106504 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/106504/ 
>>> 
>>> Regressions :-(
>>> 
>>> Tests which did not succeed and are blocking,
>>> including tests which could not be run:
>>>  [...]
>>>  test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 16 guest-stop fail REGR. vs. 
>>> 106482
>>
>>Here we go:
>>
>>(XEN) d15v0: intack: 02:48 pt: 38
>>(XEN) vIRR:       0001 
> 
>>(XEN)  PIR:        
> 
>>(XEN) Assertion 'intack.vector >= pt_vector' failed at intr.c:360
>>(XEN) [ Xen-4.9-unstable  x86_64  debug=y   Not tainted ]
>>(XEN) CPU:0
>>(XEN) RIP:e008:[] vmx_intr_assist+0x5fa/0x61a
>>(XEN) RFLAGS: 00010292   CONTEXT: hypervisor (d15v0)
>>(XEN) rax: 82d0804754a8   rbx: 83007f375680   rcx: 
>>(XEN) rdx: 83007cd3   rsi: 000a   rdi: 82d0803316d8
>>(XEN) rbp: 83007cd3ff08   rsp: 83007cd3fea8   r8:  830277db8000
>>(XEN) r9:  0001   r10:    r11: 0001
>>(XEN) r12:    r13: 82d0802b5b02   r14: 82d0802b5b02
>>(XEN) r15: 83027d82e000   cr0: 80050033   cr4: 001526e0
>>(XEN) cr3: 000259135000   cr2: 0164f034
>>(XEN) ds:    es:    fs:    gs:    ss:    cs: e008
>>(XEN) Xen code around  (vmx_intr_assist+0x5fa/0x61a):
>>(XEN)  fb ff ff e9 49 fc ff ff <0f> 0b 89 ce 48 89 df e8 2a 21 00 00 e9 49 fe 
> ff
>>(XEN) Xen stack trace from rsp=83007cd3fea8:
>>(XEN)82d08044ab00 0038 83007cd3 83027d82e000
>>(XEN)83007cd3fef8 82d080133a3d 83007f375000 83007f375000
>>(XEN)83007f7fc000 83026df78000  83027d82e000
>>(XEN)83007cd3fdb0 82d080213191 0004 00c2
>>(XEN)0020 0002 880029994000 81ade0a0
>>(XEN)0246  88002d08 0004
>>(XEN)006c  03f8 03f8
>>(XEN)81ade0a0 beefbeef 81389ac4 00bfbeef
>>(XEN)0002 88002f403e08 beef beef
>>(XEN)beef beef beef 
>>(XEN)83007f375000  001526e0
>>(XEN) Xen call trace:
>>(XEN)[] vmx_intr_assist+0x5fa/0x61a
>>(XEN)[] vmx_asm_vmexit_handler+0x41/0x120
>>(XEN) 
>>(XEN) 
>>(XEN) 
>>(XEN) Panic on CPU 0:
>>(XEN) Assertion 'intack.vector >= pt_vector' failed at intr.c:360
>>(XEN) 
>>
>>I didn't make an attempt at interpreting this yet, but I wonder if it
>>is more than coincidence that - just like the first time the ASSERT()
>>triggered - this is again a guest-stop of a qemuu-debianhvm.
>>
> 
> Cc: xuquan.
> 
> Exciting! I have been monitoring osstest for about one months through
> a python script. But I always crawl the flights one time a day.
> 
> From the output, the pt_vector is 0x38 and the intack.vector is
> 0x30. these two values are same with they were in the first time.
> And only one bit 0x30 is set in vIRR. PIR is NULL. So maybe
> our suspicion that PIR is not synced to vIRR is wrong. The 0x38 bit
> is not present in vIRR is strange. Is it possible that we clear the 0x38 bit
> just after we return from pt_update_irq()?

That would be done how?

> Or, just like I suspected that
> it is caused by pt_update_irq() sets 0x30 but wrongly returns 0x38.

Same here, and as expressed earlier: I'm lacking a plausible theory
on how this could be happening. In particular ...

> Do you think it worths a try to disable guest's LAPIC timer and
> force it use IRQ0 along with changing RTE very frequently?

... if this is the LAPIC timer, then the RTE isn't being read afaics
(pt_irq_vector() should be taking its very first return path in that
case). Nor am I aware that any Linux version would move around
one of its timer interrupts very frequently. But then again 0x30
or 0x38 wouldn't be use for the LAPIC timer anyway, but rather
a vector in the fixed range (0xEF on 4.10). So I think part of the
problem is to understand which timer's vector we're dealing with
here.

Jan

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

Re: [Xen-devel] [PATCH v5 02/17] x86emul: support MMX/SSE{, 2, 3} moves

[Andrew Cooper]

On 03/03/17 14:58, Jan Beulich wrote:
> Previously supported insns are being converted to the new model, and
> several new ones are being added.
>
> To keep the stub handling reasonably simple, integrate SET_SSE_PREFIX()
> into copy_REX_VEX(), at once switching the stubs to use an empty REX
> prefix instead of a double DS: one (no byte registers are being
> accessed, so an empty REX prefix has no effect), except (of course) for
> the 32-bit test harness build.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v3] xen: Allow a default compiled-in command line using Kconfig

[Julien Grall]

Hi Jan,

On 03/07/2017 12:52 PM, Jan Beulich wrote:

On 07.03.17 at 12:21,  wrote:

2017-03-07 17:36 GMT+08:00 Jan Beulich :

On 07.03.17 at 09:34,  wrote:

+static inline char* __init extract_dom0_options(char *cmdline)
+{
+char *kextra;
+
+if ( (kextra = strstr(cmdline, " -- ")) != NULL )
+{
+*kextra = '\0';
+kextra += 3;
+while ( kextra[1] == ' ' ) kextra++;


The body of the while() wants to go on its own line.

And then - why is this Dom0 option handling done only on x86?



As you might have noticed, there isn't any code dealing with the dom0 options
in arch/arm/setup.c, and the arm version of construct_dom0() doesn't take any
command line options as its parameter,
so I have the reason to believe that this feature is not available
under the arm architecture.


Looks like an omission to me - Julien, Stefano?


DOM0 and Xen command line are passed separately through either Device 
Tree or for UEFI xen configuration file (see -cfg=...).


So I am not sure to understand what would be the benefits to handle DOM0 
parameters after -- on Xen command line.


Cheers,

--
Julien Grall

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

[Xen-devel] [ovmf test] 106524: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a

version targeted for testing:
 ovmf 8aab575c26e94c65b8cb3a44dc944c3c47ee1c07
baseline version:
 ovmf e0307a7dad02aa8c0cd8b3b0b9edce8ddb3fef2e

Last test of basis   105963  2017-02-21 21:43:31 Z   13 days
Failing since105980  2017-02-22 10:03:53 Z   13 days   37 attempts
Testing same since   106524  2017-03-07 12:45:35 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Ard Biesheuvel 
  Brijesh Singh 
  Chao Zhang 
  Chen A Chen 
  Dandan Bi 
  edk2-devel On Behalf Of rthomaiy <[mailto:edk2-devel-boun...@lists.01.org]>
  Fu Siyuan 
  Hao Wu 
  Hegde Nagaraj P 
  Jeff Fan 
  Jiaxin Wu 
  Jiewen Yao 
  Laszlo Ersek 
  Leo Duran 
  Paolo Bonzini 
  Qin Long 
  Richard Thomaiyar 
  Ruiyu Ni 
  Star Zeng 
  Wu Jiaxin 
  Yonghong Zhu 
  Zhang Lubo 
  Zhang, Chao B 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  fail
 build-i386   pass
 build-amd64-libvirt  blocked 
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] [PATCHv4 18/33] x86/xen: convert __xen_pgd_walk() and xen_cleanmfnmap() to support p4d

[Kirill A. Shutemov]

On Mon, Mar 06, 2017 at 03:48:24PM -0500, Boris Ostrovsky wrote:
> 
> > +static int xen_p4d_walk(struct mm_struct *mm, p4d_t *p4d,
> > +   int (*func)(struct mm_struct *mm, struct page *, enum pt_level),
> > +   bool last, unsigned long limit)
> > +{
> > +   int i, nr, flush = 0;
> > +
> > +   nr = last ? p4d_index(limit) + 1 : PTRS_PER_P4D;
> > +   for (i = 0; i < nr; i++) {
> > +   pud_t *pud;
> > +
> > +   if (p4d_none(p4d[i]))
> > +   continue;
> > +
> > +   pud = pud_offset([i], 0);
> > +   if (PTRS_PER_PUD > 1)
> > +   flush |= (*func)(mm, virt_to_page(pud), PT_PUD);
> > +   xen_pud_walk(mm, pud, func, last && i == nr - 1, limit);
> > +   }
> > +   return flush;
> > +}
> 
> ..
> 
> > +   p4d = p4d_offset([i], 0);
> > +   if (PTRS_PER_P4D > 1)
> > +   flush |= (*func)(mm, virt_to_page(p4d), PT_P4D);
> > +   xen_p4d_walk(mm, p4d, func, i == nr - 1, limit);
> 
> 
> We are losing flush status at all levels so we need something like
> 
> flush |= xen_XXX_walk(...)

+ Xiong.

Thanks for noticing this. The fixup is below.

Please test, I don't have a setup for this.

> 
> 
> 
> > }
> >  
> > -out:
> > /* Do the top level last, so that the callbacks can use it as
> >a cue to do final things like tlb flushes. */
> > flush |= (*func)(mm, virt_to_page(pgd), PT_PGD);
> > @@ -1150,57 +1161,97 @@ static void __init xen_cleanmfnmap_free_pgtbl(void 
> > *pgtbl, bool unpin)
> > xen_free_ro_pages(pa, PAGE_SIZE);
> >  }
> >  
> > +static void __init xen_cleanmfnmap_pmd(pmd_t *pmd, bool unpin)
> > +{
> > +   unsigned long pa;
> > +   pte_t *pte_tbl;
> > +   int i;
> > +
> > +   if (pmd_large(*pmd)) {
> > +   pa = pmd_val(*pmd) & PHYSICAL_PAGE_MASK;
> > +   xen_free_ro_pages(pa, PMD_SIZE);
> > +   return;
> > +   }
> > +
> > +   pte_tbl = pte_offset_kernel(pmd, 0);
> > +   for (i = 0; i < PTRS_PER_PTE; i++) {
> > +   if (pte_none(pte_tbl[i]))
> > +   continue;
> > +   pa = pte_pfn(pte_tbl[i]) << PAGE_SHIFT;
> > +   xen_free_ro_pages(pa, PAGE_SIZE);
> > +   }
> > +   set_pmd(pmd, __pmd(0));
> > +   xen_cleanmfnmap_free_pgtbl(pte_tbl, unpin);
> > +}
> > +
> > +static void __init xen_cleanmfnmap_pud(pud_t *pud, bool unpin)
> > +{
> > +   unsigned long pa;
> > +   pmd_t *pmd_tbl;
> > +   int i;
> > +
> > +   if (pud_large(*pud)) {
> > +   pa = pud_val(*pud) & PHYSICAL_PAGE_MASK;
> > +   xen_free_ro_pages(pa, PUD_SIZE);
> > +   return;
> > +   }
> > +
> > +   pmd_tbl = pmd_offset(pud, 0);
> > +   for (i = 0; i < PTRS_PER_PMD; i++) {
> > +   if (pmd_none(pmd_tbl[i]))
> > +   continue;
> > +   xen_cleanmfnmap_pmd(pmd_tbl + i, unpin);
> > +   }
> > +   set_pud(pud, __pud(0));
> > +   xen_cleanmfnmap_free_pgtbl(pmd_tbl, unpin);
> > +}
> > +
> > +static void __init xen_cleanmfnmap_p4d(p4d_t *p4d, bool unpin)
> > +{
> > +   unsigned long pa;
> > +   pud_t *pud_tbl;
> > +   int i;
> > +
> > +   if (p4d_large(*p4d)) {
> > +   pa = p4d_val(*p4d) & PHYSICAL_PAGE_MASK;
> > +   xen_free_ro_pages(pa, P4D_SIZE);
> > +   return;
> > +   }
> > +
> > +   pud_tbl = pud_offset(p4d, 0);
> > +   for (i = 0; i < PTRS_PER_PUD; i++) {
> > +   if (pud_none(pud_tbl[i]))
> > +   continue;
> > +   xen_cleanmfnmap_pud(pud_tbl + i, unpin);
> > +   }
> > +   set_p4d(p4d, __p4d(0));
> > +   xen_cleanmfnmap_free_pgtbl(pud_tbl, unpin);
> > +}
> > +
> >  /*
> >   * Since it is well isolated we can (and since it is perhaps large we 
> > should)
> >   * also free the page tables mapping the initial P->M table.
> >   */
> >  static void __init xen_cleanmfnmap(unsigned long vaddr)
> >  {
> > -   unsigned long va = vaddr & PMD_MASK;
> > -   unsigned long pa;
> > -   pgd_t *pgd = pgd_offset_k(va);
> > -   pud_t *pud_page = pud_offset(pgd, 0);
> > -   pud_t *pud;
> > -   pmd_t *pmd;
> > -   pte_t *pte;
> > +   pgd_t *pgd;
> > +   p4d_t *p4d;
> > unsigned int i;
> > bool unpin;
> >  
> > unpin = (vaddr == 2 * PGDIR_SIZE);
> > -   set_pgd(pgd, __pgd(0));
> > -   do {
> > -   pud = pud_page + pud_index(va);
> > -   if (pud_none(*pud)) {
> > -   va += PUD_SIZE;
> > -   } else if (pud_large(*pud)) {
> > -   pa = pud_val(*pud) & PHYSICAL_PAGE_MASK;
> > -   xen_free_ro_pages(pa, PUD_SIZE);
> > -   va += PUD_SIZE;
> > -   } else {
> > -   pmd = pmd_offset(pud, va);
> > -   if (pmd_large(*pmd)) {
> > -   pa = pmd_val(*pmd) & PHYSICAL_PAGE_MASK;
> > -   xen_free_ro_pages(pa, PMD_SIZE);
> > -   } else if (!pmd_none(*pmd)) {
> > -   pte = pte_offset_kernel(pmd, va);
> > -   set_pmd(pmd, __pmd(0));
> > -   

Re: [Xen-devel] [PATCH 7/7] x86/pagewalk: Re-implement the pagetable walker

[George Dunlap]

On 27/02/17 14:03, Andrew Cooper wrote:
> The existing pagetable walker has complicated return semantics, which squeeze
> multiple pieces of information into single integer.  This would be fine if the
> information didn't overlap, but it does.
> 
> Specifically, _PAGE_INVALID_BITS for 3-level guests alias _PAGE_PAGED and
> _PAGE_SHARED.  A guest which constructs a PTE with bits 52 or 53 set (the
> start of the upper software-available range) will create a virtual address
> which, when walked by Xen, tricks Xen into believing the frame is paged or
> shared.  This behaviour was introduced by XSA-173 (c/s 8b17648).
> 
> It is also complicated to turn rc back into a normal pagefault error code.
> Instead, change the calling semantics to return a boolean indicating success,
> and have the function accumulate a real pagefault error code as it goes
> (including synthetic error codes, which do not alias hardware ones).  This
> requires an equivalent adjustment to map_domain_gfn().
> 
> Issues fixed:
>  * 2-level PSE36 superpages now return the correct translation.
>  * 2-level L2 superpages without CR0.PSE now return the correct translation.
>  * SMEP now inhibits a user instruction fetch even if NX isn't active.
>  * Supervisor writes without CR0.WP now set the leaf dirty bit.
>  * L4e._PAGE_GLOBAL is strictly reserved on AMD.
>  * 3-level l3 entries have all reserved bits checked.
>  * 3-level entries can no longer alias Xen's idea of paged or shared.
> 
> Signed-off-by: Andrew Cooper 

Looks good -- thanks for doing this.

One tiny comment...

> @@ -372,15 +387,16 @@ static inline unsigned int 
> guest_walk_to_page_order(const walk_t *gw)
>   * we go.  For the purposes of reading pagetables we treat all non-RAM
>   * memory as contining zeroes.
>   * 
> - * Returns 0 for success, or the set of permission bits that we failed on 
> - * if the walk did not complete. */
> + * Returns a boolean indicating success or failure.  walk_t.pfec contains
> + * the accumulated error code on failure.
> + */

Nit: You add the "wing" to the bottom of the comment here, but not to
the top.

Other than that:

Reviewed-by: George Dunlap 


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

Re: [Xen-devel] [PATCH v3] xen: Allow a default compiled-in command line using Kconfig

[Jan Beulich]

>>> On 07.03.17 at 12:21,  wrote:
> 2017-03-07 17:36 GMT+08:00 Jan Beulich :
> On 07.03.17 at 09:34,  wrote:
>>> +#endif /* CONFIG_CMDLINE_OVERRIDE */
>>> +#endif /* CONFIG_CMDLINE_BOOL */
>>
>> I think this #ifdef-ary can be reduced, along the lines of Andrew's
>> earlier suggestion. But my main complaint remains that this
>> continues to be duplicated between ARM and x86.
>>
> 
> I think wrapping CMDLINE and CMDLINE_OVERRIDE in
> a #ifdef CONFIG_CMDLINE_BOOL block makes the struture more clear,
> and makes the code easier to read, because CMDLINE and CMDLINE_OVERRIDE
> should be grouped together. BTW, this is exactly what linux did:
> 
> See https://github.com/torvalds/linux/blob/master/arch/x86/Kconfig#L2193 ,
> https://github.com/torvalds/linux/blob/master/arch/x86/kernel/setup.c#L237,
> https://github.com/torvalds/linux/blob/master/arch/x86/kernel/setup.c#L963,
> https://github.com/torvalds/linux/blob/master/arch/mips/kernel/setup.c#L70 
> and 
> https://github.com/torvalds/linux/blob/master/arch/mips/kernel/setup.c#L807.

Well, we don't have to slavishly follow what Linux does. I'd be
interested to hear particularly Doug's and Andrew's opinions.

>>> --- a/xen/arch/x86/setup.c
>>> +++ b/xen/arch/x86/setup.c
>>> @@ -636,10 +636,41 @@ static char * __init cmdline_cook(char *p, const char 
>>> *loader_name)
>>>  return p;
>>>  }
>>>
>>> +/*
>>> + * Extracts dom0 options from the commandline.
>>> + *
>>> + * Options after ' -- ' separator belong to dom0.
>>> + *  1. Orphan dom0's options from Xen's command line.
>>> + *  2. Skip all but final leading space from dom0's options.
>>> + */
>>> +
>>> +static inline char* __init extract_dom0_options(char *cmdline)
>>> +{
>>> +char *kextra;
>>> +
>>> +if ( (kextra = strstr(cmdline, " -- ")) != NULL )
>>> +{
>>> +*kextra = '\0';
>>> +kextra += 3;
>>> +while ( kextra[1] == ' ' ) kextra++;
>>
>> The body of the while() wants to go on its own line.
>>
>> And then - why is this Dom0 option handling done only on x86?
>>
> 
> As you might have noticed, there isn't any code dealing with the dom0 options
> in arch/arm/setup.c, and the arm version of construct_dom0() doesn't take any
> command line options as its parameter,
> so I have the reason to believe that this feature is not available
> under the arm architecture.

Looks like an omission to me - Julien, Stefano?

> As for the duplicated code. What do you say if I add a wrapper to
> common/kernerl.c:cmdline_parse(). The wrapper automatically deals
> with the CMDLINE_BOOL option, if toggled, and call the original 
> cmdline_parser
> on the concatenated line. The wrapper could be something like:
> void cmdline_parse(char *cmdline, char *kextra);
> where kextra will be filed with the concatenated dom0_options, if presented.
> And for those who don't expect dom0_options, I mean, for arm, kextra could be
> set to NULL, telling cmdline_parse() not to find any " -- " in the cmdline.

Sounds reasonable.

>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -237,4 +237,44 @@ config FAST_SYMBOL_LOOKUP
>>> The only user of this is Live patching.
>>>
>>> If unsure, say Y.
>>> +
>>> +config CMDLINE_BOOL
>>> + bool "Built-in hypervisor command line"
>>> + default n
>>
>> I don't think this line serves any purpose (also another time below).
> 
> But I do think this make the struture of the config set more clear.

Well, not sure. Let's see what others think (as said above).

>>> +config CMDLINE_OVERRIDE
>>> + bool "Built-in command line overrides bootloader arguments"
>>> + default n
>>> + depends on CMDLINE_BOOL
>>> + ---help---
>>> +   Set this option to 'Y' to have the hypervisor ignore the bootloader
>>> +   command line, and use ONLY the built-in command line.
>>> +
>>> +   This is used to work around broken bootloaders. This should
>>> +   be set to 'N' under normal conditions.
>>
>> I think this calls for an EXPERT dependency.
> 
> I think the last line of the help message can serve this purpose. But
> If you think adding an EXPERT option in the Kconfig file is necessary,
> I'll just do that.

I didn't ask for adding an EXPERT option (we already have one), but
for adding a dependency to it. I for one would find it quite surprising
if none of the options I pass the Xen would be honored.

Jan

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

Re: [Xen-devel] [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

[Igor Mammedov]

On Mon, 6 Mar 2017 15:54:17 +0100
Michal Hocko  wrote:

> On Fri 03-03-17 18:34:22, Igor Mammedov wrote:
> > On Fri, 3 Mar 2017 09:27:23 +0100
> > Michal Hocko  wrote:
> >   
> > > On Thu 02-03-17 18:03:15, Igor Mammedov wrote:  
> > > > On Thu, 2 Mar 2017 15:28:16 +0100
> > > > Michal Hocko  wrote:
> > > > 
> > > > > On Thu 02-03-17 14:53:48, Igor Mammedov wrote:
[...]

> > > > > memblocks. If that doesn't work I would call it a bug.
> > > > It's rather an implementation constrain than a bug
> > > > for details and workaround patch see
> > > >  [1] https://bugzilla.redhat.com/show_bug.cgi?id=1314306#c7
> > > 
> > > "You are not authorized to access bug #1314306"  
> > Sorry,
> > I've made it public, related comments and patch should be accessible now
> > (code snippets in BZ are based on older kernel but logic is still the same 
> > upstream)
> >
> > > could you paste the reasoning here please?  
> > sure here is reproducer:
> > start VM with CLI:
> >   qemu-system-x86_64  -enable-kvm -m size=1G,slots=2,maxmem=4G -numa node \
> >   -object memory-backend-ram,id=m1,size=1G -device pc-dimm,node=0,memdev=m1 
> > \
> >   /path/to/guest_image
> > 
> > then in guest dimm1 blocks are from 32-39
> > 
> >   echo online_movable > /sys/devices/system/memory/memory32/state
> > -bash: echo: write error: Invalid argument
> > 
> > in current mainline kernel it triggers following code path:
> > 
> > online_pages()
> >   ...
> >if (online_type == MMOP_ONLINE_KERNEL) { 
> > 
> > if (!zone_can_shift(pfn, nr_pages, ZONE_NORMAL, 
> > _shift))
> > return -EINVAL;  
> 
> Are you sure? I would expect MMOP_ONLINE_MOVABLE here
pretty much, reproducer is above so try and see for yourself

[...]
> [...]
> > > > > > Which means simple udev rule isn't usable since it gets event from
> > > > > > the first to the last hotplugged block order. So now we would have
> > > > > > to write a daemon that would
> > > > > >  - watch for all blocks in hotplugged memory appear (how would it 
> > > > > > know)
> > > > > >  - online them in right order (order might also be different 
> > > > > > depending
> > > > > >on kernel version)
> > > > > >-- it becomes even more complicated in NUMA case when there are
> > > > > >   multiple zones and kernel would have to provide user-space
> > > > > >   with information about zone maps
> > > > > > 
> > > > > > In short current experience shows that userspace approach
> > > > > >  - doesn't solve issues that Vitaly has been fixing (i.e. onlining
> > > > > >fast and/or under memory pressure) when udev (or something else
> > > > > >might be killed)  
> > > > > 
> > > > > yeah and that is why the patch does the onlining from the kernel.
> > > > onlining in this patch is limited to hyperv and patch breaks
> > > > auto-online on x86 kvm/vmware/baremetal as they reuse the same
> > > > hotplug path.
> > > 
> > > Those can use the udev or do you see any reason why they couldn't?  
> >
> > Reasons are above, under  and >> quotations, patch breaks
> > what Vitaly's fixed (including kvm/vmware usecases) i.e. udev/some
> > user-space process could be killed if hotplugged memory isn't onlined
> > fast enough leading to service termination and/or memory not
> > being onlined at all (if udev is killed)  
> 
> OK, so from the discussion so far I have learned that this would be
> problem _only_ if we are trying to hotplug a _lot_ of memory at once
> (~1.5% of the online memory is needed).  I am kind of skeptical this is
> a reasonable usecase. Who is going to hotadd 8G to 256M machine (which
> would eat half of the available memory which is still quite far from
> OOM)? Even if the memory balloning uses hotplug then such a grow sounds
> a bit excessive.
Slow and killable udev issue doesn't really depends on
amount of hotplugged memory since it's onlined in blocks
(128M for x64). Considering that it's currently onlined
as zone normal, kernel doesn't have any issues adding more
follow up blocks of memory.

> > Currently udev rule is not usable and one needs a daemon
> > which would correctly do onlining and keep zone balance
> > even for simple case usecase of 1 normal and 1 movable zone.
> > And it gets more complicated in case of multiple numa nodes
> > with multiple zones.  
> 
> That sounds to be more related to the current implementation than
> anything else and as such is not a reason to invent specific user
> visible api. Btw. you are talking about movable zones byt the auto
> onlining doesn't allow to auto online movable memory. So either I miss
> your point or I am utterly confused.
in current state neither does udev rule as memory is onlined
as NORMAL (x64 variant at least), which is the same as auto online
does now.

We are discussing 2 different issues here and thread got pretty
hard to follow. I'll try to sum up at results 

[Xen-devel] [ovmf test] 106511: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 105963
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 105963

version targeted for testing:
 ovmf 8994d2f95cc77a09a37e87ad6e4e4858615c3b9e
baseline version:
 ovmf e0307a7dad02aa8c0cd8b3b0b9edce8ddb3fef2e

Last test of basis   105963  2017-02-21 21:43:31 Z   13 days
Failing since105980  2017-02-22 10:03:53 Z   13 days   36 attempts
Testing same since   106511  2017-03-07 05:16:04 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Ard Biesheuvel 
  Brijesh Singh 
  Chao Zhang 
  Chen A Chen 
  Dandan Bi 
  edk2-devel On Behalf Of rthomaiy <[mailto:edk2-devel-boun...@lists.01.org]>
  Fu Siyuan 
  Hao Wu 
  Hegde Nagaraj P 
  Jeff Fan 
  Jiaxin Wu 
  Jiewen Yao 
  Laszlo Ersek 
  Leo Duran 
  Paolo Bonzini 
  Qin Long 
  Richard Thomaiyar 
  Ruiyu Ni 
  Star Zeng 
  Wu Jiaxin 
  Yonghong Zhu 
  Zhang Lubo 
  Zhang, Chao B 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] [PATCH 2/7] x86/shadow: Try to correctly identify implicit supervisor accesses

[Andrew Cooper]

On 07/03/17 11:26, George Dunlap wrote:
> On 27/02/17 14:03, Andrew Cooper wrote:
>> Signed-off-by: Andrew Cooper 
>> ---
>> CC: Jan Beulich 
>> CC: Tim Deegan 
>> CC: George Dunlap 
>> ---
>>  xen/arch/x86/mm/shadow/multi.c | 60 
>> --
>>  1 file changed, 58 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
>> index 128809d..7c6b017 100644
>> --- a/xen/arch/x86/mm/shadow/multi.c
>> +++ b/xen/arch/x86/mm/shadow/multi.c
>> @@ -2857,7 +2857,7 @@ static int sh_page_fault(struct vcpu *v,
>>  const struct x86_emulate_ops *emul_ops;
>>  int r;
>>  p2m_type_t p2mt;
>> -uint32_t rc;
>> +uint32_t rc, error_code;
>>  int version;
>>  const struct npfec access = {
>>   .read_access = 1,
>> @@ -3011,13 +3011,69 @@ static int sh_page_fault(struct vcpu *v,
>>  
>>   rewalk:
>>  
>> +error_code = regs->error_code;
>> +
>> +/*
>> + * When CR4.SMAP is enabled, instructions which have a side effect of
>> + * accessing the system data structures (e.g. mov to %ds accessing the
>> + * LDT/GDT, or int $n accessing the IDT) are known as implicit 
>> supervisor
>> + * accesses.
>> + *
>> + * The distinction between implicit and explicit accesses form part of 
>> the
>> + * determination of access rights, controlling whether the access is
>> + * successful, or raises a #PF.
>> + *
>> + * Unfortunately, the processor throws away the implicit/explicit
>> + * distinction and does not provide it to the pagefault handler
>> + * (i.e. here.) in the #PF error code.  Therefore, we must try to
>> + * reconstruct the lost state so it can be fed back into our pagewalk
>> + * through the guest tables.
>> + *
>> + * User mode accesses are easy to reconstruct:
>> + *
>> + *   If we observe a cpl3 data fetch which was a supervisor walk, this
>> + *   must have been an implicit access to a system table.
>> + *
>> + * Supervisor mode accesses are not easy:
>> + *
>> + *   In principle, we could decode the instruction under %rip and have 
>> the
>> + *   instruction emulator tell us if there is an implicit access.
>> + *   However, this is racy with other vcpus updating the pagetable or
>> + *   rewriting the instruction stream under our feet.
>> + *
>> + *   Therefore, we do nothing.  (If anyone has a sensible suggestion for
>> + *   how to distinguish these cases, xen-devel@ is all ears...)
>> + *
>> + * As a result, one specific corner case will fail.  If a guest OS with
>> + * SMAP enabled ends up mapping a system table with user mappings, sets
>> + * EFLAGS.AC to allow explicit accesses to user mappings, and implicitly
>> + * accesses the user mapping, hardware and the shadow code will disagree
>> + * on whether a #PF should be raised.
>> + *
>> + * Hardware raises #PF because implicit supervisor accesses to user
>> + * mappings are strictly disallowed.  As we can't reconstruct the 
>> correct
>> + * input, the pagewalk is performed as if it were an explicit access,
>> + * which concludes that the access should have succeeded and the shadow
>> + * pagetables need modifying.  The shadow pagetables are modified (to 
>> the
>> + * same value), and we re-enter the guest to re-execute the instruction,
>> + * which causes another #PF, and the vcpu livelocks, unable to make
>> + * forward progress.
> What you're saying is that if an attacker manages to trigger this
> behavior, then it's probably a mistake on her part; she was trying to do
> a full privilege escalation and accidentally screwed something up and
> turned it into a DoS?

This livelock can only occur if a system table is mapped with user
mappings.  This is not a situation which an OS would ever set up (other
than XTF for testing), as it means userspace can write to the GDT and
trivially root the OS.

It is certainly possible that userspace could use a vulnerability in the
OS to make such a change.  (Chances are that, if it could do that, there
are more interesting things it could do.)

Even if such a situation was set up, the livelock can only be triggered
in supervisor mode, via an implicit access, while userspace accesses are
whitelisted, which isn't a situation which will occur accidentally.

If an attacker had engineered this situation, it would be easy to
sidestep around the livelock.

>
>> + * In practice, this is tolerable because no OS would deliberately
>> + * construct such a corner case, as doing so would mean it is trivially
>> + * root-able by its own userspace.
> Just to point out, the problem with 'deliberately' is that the whole
> point of SMAP is to protect an OS from its own errors.

I don't understand your point here.  The point of 'deliberately' is to

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

[osstest service owner]

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

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. 59254
 test-armhf-armhf-xl  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck 11 guest-start fail REGR. vs. 59254
 test-armhf-armhf-libvirt 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu 11 guest-start  fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-armhf-armhf-xl-vhd   9 debian-di-install   fail baseline untested
 test-armhf-armhf-libvirt-raw  9 debian-di-install   fail baseline untested
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254

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

version targeted for testing:
 linuxc1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  607 days
Failing since 59348  2015-07-10 04:24:05 Z  606 days  318 attempts
Testing same since   106480  2017-03-05 23:48:45 Z1 days4 attempts


8045 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  fail
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  blocked 
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  pass
 

Re: [Xen-devel] [PATCH 2/7] x86/shadow: Try to correctly identify implicit supervisor accesses

[George Dunlap]

On 27/02/17 14:03, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Tim Deegan 
> CC: George Dunlap 
> ---
>  xen/arch/x86/mm/shadow/multi.c | 60 
> --
>  1 file changed, 58 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
> index 128809d..7c6b017 100644
> --- a/xen/arch/x86/mm/shadow/multi.c
> +++ b/xen/arch/x86/mm/shadow/multi.c
> @@ -2857,7 +2857,7 @@ static int sh_page_fault(struct vcpu *v,
>  const struct x86_emulate_ops *emul_ops;
>  int r;
>  p2m_type_t p2mt;
> -uint32_t rc;
> +uint32_t rc, error_code;
>  int version;
>  const struct npfec access = {
>   .read_access = 1,
> @@ -3011,13 +3011,69 @@ static int sh_page_fault(struct vcpu *v,
>  
>   rewalk:
>  
> +error_code = regs->error_code;
> +
> +/*
> + * When CR4.SMAP is enabled, instructions which have a side effect of
> + * accessing the system data structures (e.g. mov to %ds accessing the
> + * LDT/GDT, or int $n accessing the IDT) are known as implicit supervisor
> + * accesses.
> + *
> + * The distinction between implicit and explicit accesses form part of 
> the
> + * determination of access rights, controlling whether the access is
> + * successful, or raises a #PF.
> + *
> + * Unfortunately, the processor throws away the implicit/explicit
> + * distinction and does not provide it to the pagefault handler
> + * (i.e. here.) in the #PF error code.  Therefore, we must try to
> + * reconstruct the lost state so it can be fed back into our pagewalk
> + * through the guest tables.
> + *
> + * User mode accesses are easy to reconstruct:
> + *
> + *   If we observe a cpl3 data fetch which was a supervisor walk, this
> + *   must have been an implicit access to a system table.
> + *
> + * Supervisor mode accesses are not easy:
> + *
> + *   In principle, we could decode the instruction under %rip and have 
> the
> + *   instruction emulator tell us if there is an implicit access.
> + *   However, this is racy with other vcpus updating the pagetable or
> + *   rewriting the instruction stream under our feet.
> + *
> + *   Therefore, we do nothing.  (If anyone has a sensible suggestion for
> + *   how to distinguish these cases, xen-devel@ is all ears...)
> + *
> + * As a result, one specific corner case will fail.  If a guest OS with
> + * SMAP enabled ends up mapping a system table with user mappings, sets
> + * EFLAGS.AC to allow explicit accesses to user mappings, and implicitly
> + * accesses the user mapping, hardware and the shadow code will disagree
> + * on whether a #PF should be raised.
> + *
> + * Hardware raises #PF because implicit supervisor accesses to user
> + * mappings are strictly disallowed.  As we can't reconstruct the correct
> + * input, the pagewalk is performed as if it were an explicit access,
> + * which concludes that the access should have succeeded and the shadow
> + * pagetables need modifying.  The shadow pagetables are modified (to the
> + * same value), and we re-enter the guest to re-execute the instruction,
> + * which causes another #PF, and the vcpu livelocks, unable to make
> + * forward progress.

What you're saying is that if an attacker manages to trigger this
behavior, then it's probably a mistake on her part; she was trying to do
a full privilege escalation and accidentally screwed something up and
turned it into a DoS?

> + * In practice, this is tolerable because no OS would deliberately
> + * construct such a corner case, as doing so would mean it is trivially
> + * root-able by its own userspace.

Just to point out, the problem with 'deliberately' is that the whole
point of SMAP is to protect an OS from its own errors. :-)  But I agree
that at first blush, the scenario above would be pretty difficult to do
accidentally.  (And I certainly don't have any better ideas.)

Would this perhaps be better as:

"In practice, this is tolerable because it is difficult to imagine a
scenario in which an OS would accidentally construct such a corner case;
and if it did, SMAP would not actually protect it from being trivially
rooted by userspace unless the attacker made a mistake and accidentally
triggered the path described here."

But that's just a suggestion.  Either way:

Reviewed-by: George Dunlap 


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

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

[Chao Gao]

On Tue, Mar 07, 2017 at 02:16:50AM -0700, Jan Beulich wrote:
 On 07.03.17 at 06:52,  wrote:
>> flight 106504 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/106504/ 
>> 
>> Regressions :-(
>> 
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  [...]
>>  test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 16 guest-stop fail REGR. vs. 
>> 106482
>
>Here we go:
>
>(XEN) d15v0: intack: 02:48 pt: 38
>(XEN) vIRR:       0001 
>
>(XEN)  PIR:        
>
>(XEN) Assertion 'intack.vector >= pt_vector' failed at intr.c:360
>(XEN) [ Xen-4.9-unstable  x86_64  debug=y   Not tainted ]
>(XEN) CPU:0
>(XEN) RIP:e008:[] vmx_intr_assist+0x5fa/0x61a
>(XEN) RFLAGS: 00010292   CONTEXT: hypervisor (d15v0)
>(XEN) rax: 82d0804754a8   rbx: 83007f375680   rcx: 
>(XEN) rdx: 83007cd3   rsi: 000a   rdi: 82d0803316d8
>(XEN) rbp: 83007cd3ff08   rsp: 83007cd3fea8   r8:  830277db8000
>(XEN) r9:  0001   r10:    r11: 0001
>(XEN) r12:    r13: 82d0802b5b02   r14: 82d0802b5b02
>(XEN) r15: 83027d82e000   cr0: 80050033   cr4: 001526e0
>(XEN) cr3: 000259135000   cr2: 0164f034
>(XEN) ds:    es:    fs:    gs:    ss:    cs: e008
>(XEN) Xen code around  (vmx_intr_assist+0x5fa/0x61a):
>(XEN)  fb ff ff e9 49 fc ff ff <0f> 0b 89 ce 48 89 df e8 2a 21 00 00 e9 49 fe 
>ff
>(XEN) Xen stack trace from rsp=83007cd3fea8:
>(XEN)82d08044ab00 0038 83007cd3 83027d82e000
>(XEN)83007cd3fef8 82d080133a3d 83007f375000 83007f375000
>(XEN)83007f7fc000 83026df78000  83027d82e000
>(XEN)83007cd3fdb0 82d080213191 0004 00c2
>(XEN)0020 0002 880029994000 81ade0a0
>(XEN)0246  88002d08 0004
>(XEN)006c  03f8 03f8
>(XEN)81ade0a0 beefbeef 81389ac4 00bfbeef
>(XEN)0002 88002f403e08 beef beef
>(XEN)beef beef beef 
>(XEN)83007f375000  001526e0
>(XEN) Xen call trace:
>(XEN)[] vmx_intr_assist+0x5fa/0x61a
>(XEN)[] vmx_asm_vmexit_handler+0x41/0x120
>(XEN) 
>(XEN) 
>(XEN) 
>(XEN) Panic on CPU 0:
>(XEN) Assertion 'intack.vector >= pt_vector' failed at intr.c:360
>(XEN) 
>
>I didn't make an attempt at interpreting this yet, but I wonder if it
>is more than coincidence that - just like the first time the ASSERT()
>triggered - this is again a guest-stop of a qemuu-debianhvm.
>

Cc: xuquan.

Exciting! I have been monitoring osstest for about one months through
a python script. But I always crawl the flights one time a day.

From the output, the pt_vector is 0x38 and the intack.vector is
0x30. these two values are same with they were in the first time.
And only one bit 0x30 is set in vIRR. PIR is NULL. So maybe
our suspicion that PIR is not synced to vIRR is wrong. The 0x38 bit
is not present in vIRR is strange. Is it possible that we clear the 0x38 bit
just after we return from pt_update_irq()? Or, just like I suspected that
it is caused by pt_update_irq() sets 0x30 but wrongly returns 0x38.
Do you think it worths a try to disable guest's LAPIC timer and
force it use IRQ0 along with changing RTE very frequently?
If yes, I am glad to do it.

Thanks,
Chao

>Jan
>

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

Re: [Xen-devel] [PATCH v3] xen: Allow a default compiled-in command line using Kconfig

[Zhongze Liu]

Thanks for your time reviewing my code.

2017-03-07 17:36 GMT+08:00 Jan Beulich :
 On 07.03.17 at 09:34,  wrote:
>
> As an initial remark: Am I right in guessing that you manually prefix
> [Xen-devel] to your message subject? Please don't do so - receiving
> patches without that prefix serves as an indication to the receiver
> that (s)he is on the Cc list.
>

yes, you're right. I thought this should be done manually, but It
seems that I'm wrong.
I won't do that anymore.

>
>> --- a/xen/arch/arm/setup.c
>> +++ b/xen/arch/arm/setup.c
>> @@ -705,10 +705,16 @@ void __init start_xen(unsigned long boot_phys_offset,
>>  size_t fdt_size;
>>  int cpus, i;
>>  paddr_t xen_paddr;
>> -const char *cmdline;
>> +const char *cmdline, *boot_cmdline;
>>  struct bootmodule *xen_bootmodule;
>>  struct domain *dom0;
>>  struct xen_arch_domainconfig config;
>> +#ifdef CONFIG_CMDLINE_BOOL
>> +static xen_commandline_t __initdata builtin_cmdline = CONFIG_CMDLINE;
>> +#ifndef CONFIG_CMDLINE_OVERRIDE
>> +static xen_commandline_t __initdata complete_cmdline = "";
>
> Pointless initializer.
>

I'll remove this.

>
>> +#endif /* CONFIG_CMDLINE_OVERRIDE */
>> +#endif /* CONFIG_CMDLINE_BOOL */
>
> I think this #ifdef-ary can be reduced, along the lines of Andrew's
> earlier suggestion. But my main complaint remains that this
> continues to be duplicated between ARM and x86.
>

I think wrapping CMDLINE and CMDLINE_OVERRIDE in
a #ifdef CONFIG_CMDLINE_BOOL block makes the struture more clear,
and makes the code easier to read, because CMDLINE and CMDLINE_OVERRIDE
should be grouped together. BTW, this is exactly what linux did:

See https://github.com/torvalds/linux/blob/master/arch/x86/Kconfig#L2193 ,
https://github.com/torvalds/linux/blob/master/arch/x86/kernel/setup.c#L237,
https://github.com/torvalds/linux/blob/master/arch/x86/kernel/setup.c#L963,
https://github.com/torvalds/linux/blob/master/arch/mips/kernel/setup.c#L70
and https://github.com/torvalds/linux/blob/master/arch/mips/kernel/setup.c#L807.

However, I do agree with your suggestions on avoiding duplications of the same
pieces of code. I will address this problem later.

>
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -636,10 +636,41 @@ static char * __init cmdline_cook(char *p, const char 
>> *loader_name)
>>  return p;
>>  }
>>
>> +/*
>> + * Extracts dom0 options from the commandline.
>> + *
>> + * Options after ' -- ' separator belong to dom0.
>> + *  1. Orphan dom0's options from Xen's command line.
>> + *  2. Skip all but final leading space from dom0's options.
>> + */
>> +
>> +static inline char* __init extract_dom0_options(char *cmdline)
>> +{
>> +char *kextra;
>> +
>> +if ( (kextra = strstr(cmdline, " -- ")) != NULL )
>> +{
>> +*kextra = '\0';
>> +kextra += 3;
>> +while ( kextra[1] == ' ' ) kextra++;
>
> The body of the while() wants to go on its own line.
>
> And then - why is this Dom0 option handling done only on x86?
>

As you might have noticed, there isn't any code dealing with the dom0 options
in arch/arm/setup.c, and the arm version of construct_dom0() doesn't take any
command line options as its parameter,
so I have the reason to believe that this feature is not available
under the arm architecture.

As for the duplicated code. What do you say if I add a wrapper to
common/kernerl.c:cmdline_parse(). The wrapper automatically deals
with the CMDLINE_BOOL option, if toggled, and call the original cmdline_parser
on the concatenated line. The wrapper could be something like:
void cmdline_parse(char *cmdline, char *kextra);
where kextra will be filed with the concatenated dom0_options, if presented.
And for those who don't expect dom0_options, I mean, for arm, kextra could be
set to NULL, telling cmdline_parse() not to find any " -- " in the cmdline.

>
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -237,4 +237,44 @@ config FAST_SYMBOL_LOOKUP
>> The only user of this is Live patching.
>>
>> If unsure, say Y.
>> +
>> +config CMDLINE_BOOL
>> + bool "Built-in hypervisor command line"
>> + default n
>
> I don't think this line serves any purpose (also another time below).
>

But I do think this make the struture of the config set more clear.

>
>> + ---help---
>> +   Allow for specifying boot arguments to the hypervisor at
>> +   build time.  On some systems (e.g. embedded ones), it is
>> +   necessary or convenient to provide some or all of the
>> +   hypervisor boot arguments with the hypervisor itself (that is,
>> +   to not rely on the bootloader to provide them.)
>> +
>> +   To compile command line arguments into the hypervisor,
>> +   set this option to 'Y', then fill in the
>> +   boot arguments in CONFIG_CMDLINE.
>> +
>> +config CMDLINE
>> + string "Built-in hypervisor command string"
>> + depends on CMDLINE_BOOL
>
> Coming back to the 

Re: [Xen-devel] [PATCH v5 01/17] x86emul: MMX/SSEn support

[Andrew Cooper]

On 03/03/17 14:56, Jan Beulich wrote:
> This aims at covering most MMX/SSEn/AVX instructions in the 0x0f-escape
> space with memory operands. Not covered here are irregular moves,
> converts, and {,U}COMIS{S,D} (modifying EFLAGS).
>
> Note that the distinction between simd_*_fp isn't strictly needed, but
> I've kept them as separate entries since in an earlier version I needed
> them to be separate, and we may well find it useful down the road to
> have that distinction.
>
> Also take the opportunity and adjust the vmovdqu test case the new
> LDDQU one here has been cloned from: To zero a ymm register we don't
> need to go through hoops, as 128-bit AVX insns zero the upper portion
> of the destination register, and in the disabled AVX2 code there was a
> wrong YMM register used.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

[Xen-devel] [PATCH v4 3/5] xen: create wrappers for all other uses of xc_hvm_XXX() functions

[Paul Durrant]

This patch creates inline wrapper functions in xen_common.h for all open
coded calls to xc_hvm_XXX() functions outside of xen_common.h so that use
of xen_xc can be made implicit. This again is in preparation for the move
to using libxendevicemodel.

Signed-off-by: Paul Durrant 
Reviewed-by: Anthony Perard 
---
Cc: Stefano Stabellini 
Cc: Paolo Bonzini 
Cc: Richard Henderson 
Cc: Eduardo Habkost 
Cc: "Michael S. Tsirkin" 
---
 hw/i386/xen/xen_platform.c  |  2 +-
 include/hw/xen/xen_common.h | 44 
 xen-hvm.c   | 27 +--
 3 files changed, 58 insertions(+), 15 deletions(-)

diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c
index 6010f35..1419fc9 100644
--- a/hw/i386/xen/xen_platform.c
+++ b/hw/i386/xen/xen_platform.c
@@ -195,7 +195,7 @@ static void platform_fixed_ioport_writeb(void *opaque, 
uint32_t addr, uint32_t v
 case 0: /* Platform flags */ {
 hvmmem_type_t mem_type = (val & PFFLAG_ROM_LOCK) ?
 HVMMEM_ram_ro : HVMMEM_ram_rw;
-if (xc_hvm_set_mem_type(xen_xc, xen_domid, mem_type, 0xc0, 0x40)) {
+if (xen_set_mem_type(xen_domid, mem_type, 0xc0, 0x40)) {
 DPRINTF("unable to change ro/rw state of ROM memory area!\n");
 } else {
 s->flags = val & PFFLAG_ROM_LOCK;
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 1e08b98..31cf25f 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -26,6 +26,50 @@ extern xc_interface *xen_xc;
  * We don't support Xen prior to 4.2.0.
  */
 
+static inline int xen_set_mem_type(domid_t domid, hvmmem_type_t type,
+   uint64_t first_pfn, uint32_t nr)
+{
+return xc_hvm_set_mem_type(xen_xc, domid, type, first_pfn, nr);
+}
+
+static inline int xen_set_pci_intx_level(domid_t domid, uint16_t segment,
+ uint8_t bus, uint8_t device,
+ uint8_t intx, unsigned int level)
+{
+return xc_hvm_set_pci_intx_level(xen_xc, domid, segment, bus, device,
+ intx, level);
+}
+
+static inline int xen_set_pci_link_route(domid_t domid, uint8_t link,
+ uint8_t irq)
+{
+return xc_hvm_set_pci_link_route(xen_xc, domid, link, irq);
+}
+
+static inline int xen_inject_msi(domid_t domid, uint64_t msi_addr,
+ uint32_t msi_data)
+{
+return xc_hvm_inject_msi(xen_xc, domid, msi_addr, msi_data);
+}
+
+static inline int xen_set_isa_irq_level(domid_t domid, uint8_t irq,
+unsigned int level)
+{
+return xc_hvm_set_isa_irq_level(xen_xc, domid, irq, level);
+}
+
+static inline int xen_track_dirty_vram(domid_t domid, uint64_t first_pfn,
+   uint32_t nr, unsigned long *bitmap)
+{
+return xc_hvm_track_dirty_vram(xen_xc, domid, first_pfn, nr, bitmap);
+}
+
+static inline int xen_modified_memory(domid_t domid, uint64_t first_pfn,
+  uint32_t nr)
+{
+return xc_hvm_modified_memory(xen_xc, domid, first_pfn, nr);
+}
+
 /* Xen 4.2 through 4.6 */
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 471
 
diff --git a/xen-hvm.c b/xen-hvm.c
index edf4983..4b928cf 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -125,8 +125,8 @@ int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num)
 
 void xen_piix3_set_irq(void *opaque, int irq_num, int level)
 {
-xc_hvm_set_pci_intx_level(xen_xc, xen_domid, 0, 0, irq_num >> 2,
-  irq_num & 3, level);
+xen_set_pci_intx_level(xen_domid, 0, 0, irq_num >> 2,
+   irq_num & 3, level);
 }
 
 void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len)
@@ -141,7 +141,7 @@ void xen_piix_pci_write_config_client(uint32_t address, 
uint32_t val, int len)
 }
 v &= 0xf;
 if (((address + i) >= 0x60) && ((address + i) <= 0x63)) {
-xc_hvm_set_pci_link_route(xen_xc, xen_domid, address + i - 0x60, 
v);
+xen_set_pci_link_route(xen_domid, address + i - 0x60, v);
 }
 }
 }
@@ -156,7 +156,7 @@ int xen_is_pirq_msi(uint32_t msi_data)
 
 void xen_hvm_inject_msi(uint64_t addr, uint32_t data)
 {
-xc_hvm_inject_msi(xen_xc, xen_domid, addr, data);
+xen_inject_msi(xen_domid, addr, data);
 }
 
 static void xen_suspend_notifier(Notifier *notifier, void *data)
@@ -168,7 +168,7 @@ static void xen_suspend_notifier(Notifier *notifier, void 
*data)
 
 static void xen_set_irq(void *opaque, int irq, int level)
 {
-xc_hvm_set_isa_irq_level(xen_xc, xen_domid, irq, level);
+xen_set_isa_irq_level(xen_domid, irq, level);
 }
 
 qemu_irq *xen_interrupt_controller_init(void)
@@ -481,10 

[Xen-devel] [PATCH v4 5/5] xen: use libxendevicemodel when available

[Paul Durrant]

This patch modifies the wrapper functions in xen_common.h to use the
new xendevicemodel interface if it is available along with compatibility
code to use the old libxenctrl interface if it is not.

Signed-off-by: Paul Durrant 
Reviewed-by: Anthony Perard 
---
Cc: Stefano Stabellini 

v4:
- Fix typo causing build failures on < 490
- Fix building on < 450
- Build-tested against 4.2.5 and 4.8.0

v3:
- Switch from macros to static inlines.

v2:
- Add a compat define for xenforeignmemory_close() since this is now
  used.
---
 include/hw/xen/xen_common.h | 203 +---
 xen-common.c|   8 ++
 2 files changed, 178 insertions(+), 33 deletions(-)

diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 31cf25f..274accc 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -9,6 +9,7 @@
 #undef XC_WANT_COMPAT_EVTCHN_API
 #undef XC_WANT_COMPAT_GNTTAB_API
 #undef XC_WANT_COMPAT_MAP_FOREIGN_API
+#undef XC_WANT_COMPAT_DEVICEMODEL_API
 
 #include 
 #include 
@@ -26,48 +27,183 @@ extern xc_interface *xen_xc;
  * We don't support Xen prior to 4.2.0.
  */
 
+#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 490
+
+typedef xc_interface xendevicemodel_handle;
+
+static inline xendevicemodel_handle *xendevicemodel_open(
+struct xentoollog_logger *logger, unsigned int open_flags)
+{
+return xen_xc;
+}
+
+#if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 450
+
+static inline int xendevicemodel_create_ioreq_server(
+xendevicemodel_handle *dmod, domid_t domid, int handle_bufioreq,
+ioservid_t *id)
+{
+return xc_hvm_create_ioreq_server(dmod, domid, handle_bufioreq,
+  id);
+}
+
+static inline int xendevicemodel_get_ioreq_server_info(
+xendevicemodel_handle *dmod, domid_t domid, ioservid_t id,
+xen_pfn_t *ioreq_pfn, xen_pfn_t *bufioreq_pfn,
+evtchn_port_t *bufioreq_port)
+{
+return xc_hvm_get_ioreq_server_info(dmod, domid, id, ioreq_pfn,
+bufioreq_pfn, bufioreq_port);
+}
+
+static inline int xendevicemodel_map_io_range_to_ioreq_server(
+xendevicemodel_handle *dmod, domid_t domid, ioservid_t id, int is_mmio,
+uint64_t start, uint64_t end)
+{
+return xc_hvm_map_io_range_to_ioreq_server(dmod, domid, id, is_mmio,
+   start, end);
+}
+
+static inline int xendevicemodel_unmap_io_range_from_ioreq_server(
+xendevicemodel_handle *dmod, domid_t domid, ioservid_t id, int is_mmio,
+uint64_t start, uint64_t end)
+{
+return xc_hvm_unmap_io_range_from_ioreq_server(dmod, domid, id, is_mmio,
+   start, end);
+}
+
+static inline int xendevicemodel_map_pcidev_to_ioreq_server(
+xendevicemodel_handle *dmod, domid_t domid, ioservid_t id,
+uint16_t segment, uint8_t bus, uint8_t device, uint8_t function)
+{
+return xc_hvm_map_pcidev_to_ioreq_server(dmod, domid, id, segment,
+ bus, device, function);
+}
+
+static inline int xendevicemodel_unmap_pcidev_from_ioreq_server(
+xendevicemodel_handle *dmod, domid_t domid, ioservid_t id,
+uint16_t segment, uint8_t bus, uint8_t device, uint8_t function)
+{
+return xc_hvm_unmap_pcidev_from_ioreq_server(dmod, domid, id, segment,
+ bus, device, function);
+}
+
+static inline int xendevicemodel_destroy_ioreq_server(
+xendevicemodel_handle *dmod, domid_t domid, ioservid_t id)
+{
+return xc_hvm_destroy_ioreq_server(dmod, domid, id);
+}
+
+static inline int xendevicemodel_set_ioreq_server_state(
+xendevicemodel_handle *dmod, domid_t domid, ioservid_t id, int enabled)
+{
+return xc_hvm_set_ioreq_server_state(dmod, domid, id, enabled);
+}
+
+#endif /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 450 */
+
+static inline int xendevicemodel_set_pci_intx_level(
+xendevicemodel_handle *dmod, domid_t domid, uint16_t segment,
+uint8_t bus, uint8_t device, uint8_t intx, unsigned int level)
+{
+return xc_hvm_set_pci_intx_level(dmod, domid, segment, bus, device,
+ intx, level);
+}
+
+static inline int xendevicemodel_set_isa_irq_level(
+xendevicemodel_handle *dmod, domid_t domid, uint8_t irq,
+unsigned int level)
+{
+return xc_hvm_set_isa_irq_level(dmod, domid, irq, level);
+}
+
+static inline int xendevicemodel_set_pci_link_route(
+xendevicemodel_handle *dmod, domid_t domid, uint8_t link, uint8_t irq)
+{
+return xc_hvm_set_pci_link_route(dmod, domid, link, irq);
+}
+
+static inline int xendevicemodel_inject_msi(
+xendevicemodel_handle *dmod, domid_t domid, uint64_t msi_addr,
+uint32_t msi_data)
+{
+return xc_hvm_inject_msi(dmod, domid, msi_addr, msi_data);
+}
+
+static inline int xendevicemodel_track_dirty_vram(
+xendevicemodel_handle *dmod, domid_t domid, 

[Xen-devel] [PATCH v4 1/5] xen: make use of xen_xc implicit in xen_common.h inlines

[Paul Durrant]

Doing this will make the transition to using the new libxendevicemodel
interface less intrusive on the callers of these functions, since using
the new library will require a change of handle.

NOTE: The patch also moves the 'externs' for xen_xc and xen_fmem from
  xen_backend.h to xen_common.h, and the declarations from
  xen_backend.c to xen-common.c, which is where they belong.

Signed-off-by: Paul Durrant 
Reviewed-by: Anthony Perard 
---
Cc: Stefano Stabellini 
---
 hw/xen/xen_backend.c |  2 -
 include/hw/xen/xen_backend.h |  2 -
 include/hw/xen/xen_common.h  | 90 +++-
 xen-common.c |  3 ++
 xen-hvm.c| 20 +-
 5 files changed, 60 insertions(+), 57 deletions(-)

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index 6c21c37..d34c49e 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -43,8 +43,6 @@ BusState *xen_sysbus;
 /* - */
 
 /* public */
-xc_interface *xen_xc = NULL;
-xenforeignmemory_handle *xen_fmem = NULL;
 struct xs_handle *xenstore = NULL;
 const char *xen_protocol;
 
diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
index 4f4799a..30811a1 100644
--- a/include/hw/xen/xen_backend.h
+++ b/include/hw/xen/xen_backend.h
@@ -14,8 +14,6 @@
 OBJECT_CHECK(XenDevice, (obj), TYPE_XENBACKEND)
 
 /* variables */
-extern xc_interface *xen_xc;
-extern xenforeignmemory_handle *xen_fmem;
 extern struct xs_handle *xenstore;
 extern const char *xen_protocol;
 extern DeviceState *xen_sysdev;
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index dce76ee..1e08b98 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -20,6 +20,8 @@
 #include "qemu/queue.h"
 #include "hw/xen/trace.h"
 
+extern xc_interface *xen_xc;
+
 /*
  * We don't support Xen prior to 4.2.0.
  */
@@ -73,6 +75,8 @@ static inline void *xenforeignmemory_map(xc_interface *h, 
uint32_t dom,
 
 #endif
 
+extern xenforeignmemory_handle *xen_fmem;
+
 void destroy_hvm_domain(bool reboot);
 
 /* shutdown/destroy current domain because of an error */
@@ -107,8 +111,7 @@ static inline int xen_get_vmport_regs_pfn(xc_interface *xc, 
domid_t dom,
 
 #endif
 
-static inline int xen_get_default_ioreq_server_info(xc_interface *xc,
-domid_t dom,
+static inline int xen_get_default_ioreq_server_info(domid_t dom,
 xen_pfn_t *ioreq_pfn,
 xen_pfn_t *bufioreq_pfn,
 evtchn_port_t
@@ -117,7 +120,7 @@ static inline int 
xen_get_default_ioreq_server_info(xc_interface *xc,
 unsigned long param;
 int rc;
 
-rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, );
+rc = xc_get_hvm_param(xen_xc, dom, HVM_PARAM_IOREQ_PFN, );
 if (rc < 0) {
 fprintf(stderr, "failed to get HVM_PARAM_IOREQ_PFN\n");
 return -1;
@@ -125,7 +128,7 @@ static inline int 
xen_get_default_ioreq_server_info(xc_interface *xc,
 
 *ioreq_pfn = param;
 
-rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, );
+rc = xc_get_hvm_param(xen_xc, dom, HVM_PARAM_BUFIOREQ_PFN, );
 if (rc < 0) {
 fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_PFN\n");
 return -1;
@@ -133,7 +136,7 @@ static inline int 
xen_get_default_ioreq_server_info(xc_interface *xc,
 
 *bufioreq_pfn = param;
 
-rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_EVTCHN,
+rc = xc_get_hvm_param(xen_xc, dom, HVM_PARAM_BUFIOREQ_EVTCHN,
   );
 if (rc < 0) {
 fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_EVTCHN\n");
@@ -156,63 +159,64 @@ static inline int 
xen_get_default_ioreq_server_info(xc_interface *xc,
 
 typedef uint16_t ioservid_t;
 
-static inline void xen_map_memory_section(xc_interface *xc, domid_t dom,
+static inline void xen_map_memory_section(domid_t dom,
   ioservid_t ioservid,
   MemoryRegionSection *section)
 {
 }
 
-static inline void xen_unmap_memory_section(xc_interface *xc, domid_t dom,
+static inline void xen_unmap_memory_section(domid_t dom,
 ioservid_t ioservid,
 MemoryRegionSection *section)
 {
 }
 
-static inline void xen_map_io_section(xc_interface *xc, domid_t dom,
+static inline void xen_map_io_section(domid_t dom,
   ioservid_t ioservid,
   MemoryRegionSection *section)
 {
 }
 
-static inline void xen_unmap_io_section(xc_interface *xc, domid_t dom,
+static inline void xen_unmap_io_section(domid_t dom,
 

[Xen-devel] [PATCH v4 2/5] xen: rename xen_modified_memory() to xen_hvm_modified_memory()

[Paul Durrant]

This patch is a purely cosmetic change that avoids a name collision in
a subsequent patch.

Signed-off-by: Paul Durrant 
Reviewed-by: Anthony Perard 
---
Cc: Paolo Bonzini 
Cc: Stefano Stabellini 
---
 include/exec/ram_addr.h | 4 ++--
 include/hw/xen/xen.h| 2 +-
 xen-hvm-stub.c  | 2 +-
 xen-hvm.c   | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
index 3e79466..8715af6 100644
--- a/include/exec/ram_addr.h
+++ b/include/exec/ram_addr.h
@@ -259,7 +259,7 @@ static inline void 
cpu_physical_memory_set_dirty_range(ram_addr_t start,
 
 rcu_read_unlock();
 
-xen_modified_memory(start, length);
+xen_hvm_modified_memory(start, length);
 }
 
 #if !defined(_WIN32)
@@ -313,7 +313,7 @@ static inline void 
cpu_physical_memory_set_dirty_lebitmap(unsigned long *bitmap,
 
 rcu_read_unlock();
 
-xen_modified_memory(start, pages << TARGET_PAGE_BITS);
+xen_hvm_modified_memory(start, pages << TARGET_PAGE_BITS);
 } else {
 uint8_t clients = tcg_enabled() ? DIRTY_CLIENTS_ALL : 
DIRTY_CLIENTS_NOCODE;
 /*
diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
index 09c2ce5..2b1733b 100644
--- a/include/hw/xen/xen.h
+++ b/include/hw/xen/xen.h
@@ -43,7 +43,7 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
**ram_memory);
 
 void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
struct MemoryRegion *mr, Error **errp);
-void xen_modified_memory(ram_addr_t start, ram_addr_t length);
+void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t length);
 
 void xen_register_framebuffer(struct MemoryRegion *mr);
 
diff --git a/xen-hvm-stub.c b/xen-hvm-stub.c
index c500325..3ca6c51 100644
--- a/xen-hvm-stub.c
+++ b/xen-hvm-stub.c
@@ -50,7 +50,7 @@ void xen_register_framebuffer(MemoryRegion *mr)
 {
 }
 
-void xen_modified_memory(ram_addr_t start, ram_addr_t length)
+void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t length)
 {
 }
 
diff --git a/xen-hvm.c b/xen-hvm.c
index dbb8c66..edf4983 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -1391,7 +1391,7 @@ void xen_shutdown_fatal_error(const char *fmt, ...)
 qemu_system_shutdown_request();
 }
 
-void xen_modified_memory(ram_addr_t start, ram_addr_t length)
+void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t length)
 {
 if (unlikely(xen_in_migration)) {
 int rc;
-- 
2.1.4


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

[Xen-devel] [PATCH v4 4/5] configure: detect presence of libxendevicemodel

[Paul Durrant]

This patch adds code in configure to set CONFIG_XEN_CTRL_INTERFACE_VERSION
to a new value of 490 if libxendevicemodel is present in the build
environment.

Signed-off-by: Paul Durrant 
Reviewed-by: Anthony Perard 
---
Cc: Stefano Stabellini 
---
 configure | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/configure b/configure
index 8e8f18d..fc1e12b 100755
--- a/configure
+++ b/configure
@@ -1980,6 +1980,25 @@ EOF
   # Xen unstable
   elif
   cat > $TMPC <
+int main(void) {
+  xendevicemodel_handle *xd;
+
+  xd = xendevicemodel_open(0, 0);
+  xendevicemodel_close(xd);
+
+  return 0;
+}
+EOF
+  compile_prog "" "$xen_libs $xen_stable_libs -lxendevicemodel"
+then
+xen_stable_libs="$xen_stable_libs -lxendevicemodel"
+xen_ctrl_version=490
+xen=yes
+  elif
+  cat > $TMPC 

[Xen-devel] [PATCH v4 0/5] xen: use new xendevicemodel library

[Paul Durrant]

My recent patches to Xen [1] introduced a new library to support
running device models for HVM guests.
This series ports QEMU onto the new library if it is available in the
build environment.

[1] Patches starting with 
http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=b108240265deea37601f1a605910069a837da841

Paul Durrant (5):
  xen: make use of xen_xc implicit in xen_common.h inlines
  xen: rename xen_modified_memory() to xen_hvm_modified_memory()
  xen: create wrappers for all other uses of xc_hvm_XXX() functions
  configure: detect presence of libxendevicemodel
  xen: use libxendevicemodel when available

 configure|  19 +++
 hw/i386/xen/xen_platform.c   |   2 +-
 hw/xen/xen_backend.c |   2 -
 include/exec/ram_addr.h  |   4 +-
 include/hw/xen/xen.h |   2 +-
 include/hw/xen/xen_backend.h |   2 -
 include/hw/xen/xen_common.h  | 289 +++
 xen-common.c |  11 ++
 xen-hvm-stub.c   |   2 +-
 xen-hvm.c|  49 
 10 files changed, 296 insertions(+), 86 deletions(-)

-- 
2.1.4


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

Re: [Xen-devel] [PATCH 1/7] x86/hvm: Correctly identify implicit supervisor accesses

[Andrew Cooper]

On 27/02/17 14:03, Andrew Cooper wrote:
> All actions which refer to the active ldt/gdt/idt or task register
> (e.g. loading a new segment selector) are known as implicit supervisor
> accesses, even when the access originates from user code.

It turns out that this has a bugfix in it which I hadn't realised.

I have added:

"Right away, this fixes a bug during userspace emulation where a
pagewalk for a system table was (incorrectly) performed as a user
access, causing an access violation in the common case, as system tables
reside on supervisor mappings."

~Andrew

>
> The distinction is necessary in the pagewalk when SMAP is enabled.  Refer to
> Intel SDM Vol 3 "Access Rights" for the exact details.
>
> Introduce a new pagewalk input, and make use of the new system segment
> references in hvmemul_{read,write}().  While modifying those areas, move the
> calculation of the appropriate pagewalk input before its first use.
>
> Signed-off-by: Andrew Cooper 



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

Re: [Xen-devel] [PATCH 1/7] x86/hvm: Correctly identify implicit supervisor accesses

[George Dunlap]

On 27/02/17 14:03, Andrew Cooper wrote:
> All actions which refer to the active ldt/gdt/idt or task register
> (e.g. loading a new segment selector) are known as implicit supervisor
> accesses, even when the access originates from user code.
> 
> The distinction is necessary in the pagewalk when SMAP is enabled.  Refer to
> Intel SDM Vol 3 "Access Rights" for the exact details.
> 
> Introduce a new pagewalk input, and make use of the new system segment
> references in hvmemul_{read,write}().  While modifying those areas, move the
> calculation of the appropriate pagewalk input before its first use.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: George Dunlap 

> ---
> CC: Jan Beulich 
> CC: Paul Durrant 
> CC: George Dunlap 
> CC: Tim Deegan 
> ---
>  xen/arch/x86/hvm/emulate.c  | 18 ++
>  xen/arch/x86/mm/guest_walk.c|  4 
>  xen/include/asm-x86/processor.h |  1 +
>  3 files changed, 15 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> index f24d289..9b32bca 100644
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -783,6 +783,11 @@ static int __hvmemul_read(
>  struct hvm_vcpu_io *vio = >arch.hvm_vcpu.hvm_io;
>  int rc;
>  
> +if ( is_x86_system_segment(seg) )
> +pfec |= PFEC_implicit;
> +else if ( hvmemul_ctxt->seg_reg[x86_seg_ss].attr.fields.dpl == 3 )
> +pfec |= PFEC_user_mode;
> +
>  rc = hvmemul_virtual_to_linear(
>  seg, offset, bytes, , access_type, hvmemul_ctxt, );
>  if ( rc != X86EMUL_OKAY || !bytes )
> @@ -793,10 +798,6 @@ static int __hvmemul_read(
>   (vio->mmio_gla == (addr & PAGE_MASK)) )
>  return hvmemul_linear_mmio_read(addr, bytes, p_data, pfec, 
> hvmemul_ctxt, 1);
>  
> -if ( (seg != x86_seg_none) &&
> - (hvmemul_ctxt->seg_reg[x86_seg_ss].attr.fields.dpl == 3) )
> -pfec |= PFEC_user_mode;
> -
>  rc = ((access_type == hvm_access_insn_fetch) ?
>hvm_fetch_from_guest_linear(p_data, addr, bytes, pfec, ) :
>hvm_copy_from_guest_linear(p_data, addr, bytes, pfec, ));
> @@ -893,6 +894,11 @@ static int hvmemul_write(
>  struct hvm_vcpu_io *vio = >arch.hvm_vcpu.hvm_io;
>  int rc;
>  
> +if ( is_x86_system_segment(seg) )
> +pfec |= PFEC_implicit;
> +else if ( hvmemul_ctxt->seg_reg[x86_seg_ss].attr.fields.dpl == 3 )
> +pfec |= PFEC_user_mode;
> +
>  rc = hvmemul_virtual_to_linear(
>  seg, offset, bytes, , hvm_access_write, hvmemul_ctxt, );
>  if ( rc != X86EMUL_OKAY || !bytes )
> @@ -902,10 +908,6 @@ static int hvmemul_write(
>   (vio->mmio_gla == (addr & PAGE_MASK)) )
>  return hvmemul_linear_mmio_write(addr, bytes, p_data, pfec, 
> hvmemul_ctxt, 1);
>  
> -if ( (seg != x86_seg_none) &&
> - (hvmemul_ctxt->seg_reg[x86_seg_ss].attr.fields.dpl == 3) )
> -pfec |= PFEC_user_mode;
> -
>  rc = hvm_copy_to_guest_linear(addr, p_data, bytes, pfec, );
>  
>  switch ( rc )
> diff --git a/xen/arch/x86/mm/guest_walk.c b/xen/arch/x86/mm/guest_walk.c
> index faaf70c..4f8d0e3 100644
> --- a/xen/arch/x86/mm/guest_walk.c
> +++ b/xen/arch/x86/mm/guest_walk.c
> @@ -161,6 +161,10 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
>  bool_t pse1G = 0, pse2M = 0;
>  p2m_query_t qt = P2M_ALLOC | P2M_UNSHARE;
>  
> +/* Only implicit supervisor data accesses exist. */
> +ASSERT(!(pfec & PFEC_implicit) ||
> +   !(pfec & (PFEC_insn_fetch|PFEC_user_mode)));
> +
>  perfc_incr(guest_walk);
>  memset(gw, 0, sizeof(*gw));
>  gw->va = va;
> diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/processor.h
> index dda8b83..d3ba8ea 100644
> --- a/xen/include/asm-x86/processor.h
> +++ b/xen/include/asm-x86/processor.h
> @@ -76,6 +76,7 @@
>  /* Internally used only flags. */
>  #define PFEC_page_paged (1U<<16)
>  #define PFEC_page_shared(1U<<17)
> +#define PFEC_implicit   (1U<<18) /* Pagewalk input for ldt/gdt/idt/tr 
> accesses. */
>  
>  /* Other exception error code values. */
>  #define X86_XEC_EXT (_AC(1,U) << 0)
> 


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

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

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-i386-daily-netboot-pvgrub 10 guest-start fail blocked in 68619
 test-amd64-amd64-amd64-daily-netboot-pvgrub 10 guest-start fail blocked in 
68619
 test-armhf-armhf-armhf-daily-netboot-pygrub 9 debian-di-install fail like 68619
 test-amd64-i386-i386-weekly-netinst-pygrub 9 debian-di-install fail like 68619
 test-amd64-i386-amd64-weekly-netinst-pygrub 9 debian-di-install fail like 68619
 test-amd64-amd64-i386-weekly-netinst-pygrub 9 debian-di-install fail like 68619
 test-amd64-amd64-amd64-weekly-netinst-pygrub 9 debian-di-install fail like 
68619

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-armhf-daily-netboot-pygrub  1 build-check(1)  blocked n/a
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass

baseline version:
 flight   68619

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-daily-netboot-pvgrub  fail
 test-amd64-i386-i386-daily-netboot-pvgrubfail
 test-amd64-i386-amd64-daily-netboot-pygrub   pass
 test-arm64-arm64-armhf-daily-netboot-pygrub  blocked 
 test-armhf-armhf-armhf-daily-netboot-pygrub  fail
 test-amd64-amd64-i386-daily-netboot-pygrub   pass
 test-amd64-amd64-amd64-current-netinst-pygrubpass
 test-amd64-i386-amd64-current-netinst-pygrub pass
 test-amd64-amd64-i386-current-netinst-pygrub pass
 test-amd64-i386-i386-current-netinst-pygrub  pass
 test-amd64-amd64-amd64-weekly-netinst-pygrub fail
 test-amd64-i386-amd64-weekly-netinst-pygrub  fail
 test-amd64-amd64-i386-weekly-netinst-pygrub  fail
 test-amd64-i386-i386-weekly-netinst-pygrub   fail



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

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

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


Push not applicable.


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

Re: [Xen-devel] [PATCH 11/29] drivers, media: convert cx88_core.refcount from atomic_t to refcount_t

[Sergei Shtylyov]

On 3/7/2017 10:52 AM, Reshetova, Elena wrote:


refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.

Signed-off-by: Elena Reshetova 
Signed-off-by: Hans Liljestrand 
Signed-off-by: Kees Cook 
Signed-off-by: David Windsor 

[...]

diff --git a/drivers/media/pci/cx88/cx88.h b/drivers/media/pci/cx88/cx88.h
index 115414c..16c1313 100644
--- a/drivers/media/pci/cx88/cx88.h
+++ b/drivers/media/pci/cx88/cx88.h

[...]

@@ -339,7 +340,7 @@ struct cx8802_dev;

 struct cx88_core {
struct list_head   devlist;
-   atomic_t   refcount;
+   refcount_t   refcount;


Could you please keep the name aligned with above and below?


You mean "not aligned" to devlist, but with a shift like it was before?


   I mean aligned, like it was before. :-)


Sure, will fix. Is the patch ok otherwise?


   I haven't noticed anything else...


Best Regards,
Elena.

[...]

MBR, Sergei

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

Re: [Xen-devel] [PATCH v5 01/17] x86emul: support most memory accessing MMX/SSE{, 2, 3} insns

[Jan Beulich]

>>> On 03.03.17 at 15:58,  wrote:
> @@ -6183,6 +6579,76 @@ x86_emulate(
>  goto cannot_emulate;
>  }
>  
> +if ( state->simd_size )
> +{
> +#ifdef __XEN__
> +uint8_t *buf = stub.ptr;
> +#else
> +uint8_t *buf = get_stub(stub);
> +#endif
> +
> +generate_exception_if(!op_bytes, EXC_UD);
> +generate_exception_if(vex.opcx && (d & TwoOp) && vex.reg != 0xf,
> +  EXC_UD);
> +
> +if ( !buf )
> +BUG();
> +if ( vex.opcx == vex_none )
> +SET_SSE_PREFIX(buf[0], vex.pfx);
> +
> +buf[fic.insn_bytes] = 0xc3;
> +copy_REX_VEX(buf, rex_prefix, vex);
> +
> +if ( ea.type == OP_MEM )
> +{
> +uint32_t mxcsr = 0;
> +
> +if ( op_bytes < 16 ||
> + (vex.opcx
> +  ? /* vmov{a,nt}p{s,d} are exceptions. */
> +ext != ext_0f || ((b | 1) != 0x29 && b != 0x2b)
> +  : /* movup{s,d} and lddqu are exceptions. */
> +ext == ext_0f && ((b | 1) == 0x11 || b == 0xf0)) )
> +mxcsr = MXCSR_MM;
> +else if ( vcpu_has_misalignsse() )
> +asm ( "stmxcsr %0" : "=m" (mxcsr) );
> +generate_exception_if(!(mxcsr & MXCSR_MM) &&
> +  !is_aligned(ea.mem.seg, ea.mem.off, 
> op_bytes,
> +  ctxt, ops),
> +  EXC_GP, 0);
> +if ( (d & SrcMask) == SrcMem )
> +{
> +rc = ops->read(ea.mem.seg, ea.mem.off, mmvalp, op_bytes, 
> ctxt);
> +if ( rc != X86EMUL_OKAY )
> +goto done;
> +dst.type = OP_NONE;
> +}
> +else if ( (d & DstMask) == DstMem )
> +{
> +fail_if(!ops->write); /* Check before running the stub. */
> +ASSERT(d & Mov);
> +dst.type = OP_MEM;
> +dst.bytes = op_bytes;
> +dst.mem = ea.mem;
> +}
> +else if ( (d & SrcMask) == SrcMem16 )
> +dst.type = OP_NONE;
> +else
> +{
> +ASSERT_UNREACHABLE();
> +return X86EMUL_UNHANDLEABLE;

I've changed this to "goto cannot_emulate" to be on the safe side
on production builds (to avoid bypassing put_fpu() / put_stub()).

Jan


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

Re: [Xen-devel] [PATCH v2 5/5] xen: use libxendevicemodel when available

[Paul Durrant]

> -Original Message-
> From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> Sent: 06 March 2017 19:14
> To: Paul Durrant 
> Cc: 'Stefano Stabellini' ; Anthony Perard
> ; xen-de...@lists.xenproject.org; qemu-
> de...@nongnu.org
> Subject: RE: [PATCH v2 5/5] xen: use libxendevicemodel when available
> 
> On Mon, 6 Mar 2017, Paul Durrant wrote:
> > > -Original Message-
> > > From: Qemu-devel [mailto:qemu-devel-
> > > bounces+paul.durrant=citrix@nongnu.org] On Behalf Of Paul
> Durrant
> > > Sent: 06 March 2017 09:15
> > > To: 'Stefano Stabellini' 
> > > Cc: Anthony Perard ; xen-
> > > de...@lists.xenproject.org; qemu-de...@nongnu.org
> > > Subject: Re: [Qemu-devel] [PATCH v2 5/5] xen: use libxendevicemodel
> when
> > > available
> > >
> > > > -Original Message-
> > > > From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> > > > Sent: 03 March 2017 20:43
> > > > To: Stefano Stabellini 
> > > > Cc: Paul Durrant ; xen-
> > > de...@lists.xenproject.org;
> > > > qemu-de...@nongnu.org; Anthony Perard
> 
> > > > Subject: RE: [PATCH v2 5/5] xen: use libxendevicemodel when available
> > > >
> > > > On Fri, 3 Mar 2017, Stefano Stabellini wrote:
> > > > > On Fri, 3 Mar 2017, Paul Durrant wrote:
> > > > > > > -Original Message-
> > > > > > > From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> > > > > > > Sent: 02 March 2017 22:50
> > > > > > > To: Paul Durrant 
> > > > > > > Cc: xen-de...@lists.xenproject.org; qemu-de...@nongnu.org;
> > > Stefano
> > > > > > > Stabellini ; Anthony Perard
> > > > > > > 
> > > > > > > Subject: Re: [PATCH v2 5/5] xen: use libxendevicemodel when
> > > available
> > > > > > >
> > > > > > > On Thu, 2 Mar 2017, Paul Durrant wrote:
> > > > > > > > This patch modifies the wrapper functions in xen_common.h to
> use
> > > > the
> > > > > > > > new xendevicemodel interface if it is available along with
> > > > compatibility
> > > > > > > > code to use the old libxenctrl interface if it is not.
> > > > > > > >
> > > > > > > > Signed-off-by: Paul Durrant 
> > > > > > > > ---
> > > > > > > > Cc: Stefano Stabellini 
> > > > > > > > Cc: Anthony Perard 
> > > > > > > >
> > > > > > > > v2:
> > > > > > > > - Add a compat define for xenforeignmemory_close() since this
> is
> > > > now
> > > > > > > >   used.
> > > > > > > > ---
> > > > > > > >  include/hw/xen/xen_common.h | 115
> > > > > > > +++-
> > > > > > > >  xen-common.c|   8 +++
> > > > > > > >  2 files changed, 90 insertions(+), 33 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/include/hw/xen/xen_common.h
> > > > > > > b/include/hw/xen/xen_common.h
> > > > > > > > index 31cf25f..48444e5 100644
> > > > > > > > --- a/include/hw/xen/xen_common.h
> > > > > > > > +++ b/include/hw/xen/xen_common.h
> > > > > > > > @@ -9,6 +9,7 @@
> > > > > > > >  #undef XC_WANT_COMPAT_EVTCHN_API
> > > > > > > >  #undef XC_WANT_COMPAT_GNTTAB_API
> > > > > > > >  #undef XC_WANT_COMPAT_MAP_FOREIGN_API
> > > > > > > > +#undef XC_WANT_COMPAT_DEVICEMODEL_API
> > > > > > > >
> > > > > > > >  #include 
> > > > > > > >  #include 
> > > > > > > > @@ -26,48 +27,95 @@ extern xc_interface *xen_xc;
> > > > > > > >   * We don't support Xen prior to 4.2.0.
> > > > > > > >   */
> > > > > > > >
> > > > > > > > +#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 490
> > > > > > > > +
> > > > > > > > +typedef xc_interface xendevicemodel_handle;
> > > > > > > > +
> > > > > > > > +#define xendevicemodel_open(l, f) xen_xc
> > > > > > > > +
> > > > > > > > +#define xendevicemodel_map_io_range_to_ioreq_server \
> > > > > > > > +xc_hvm_map_io_range_to_ioreq_server
> > > > > > > > +#define
> xendevicemodel_unmap_io_range_from_ioreq_server \
> > > > > > > > +xc_hvm_unmap_io_range_from_ioreq_server
> > > > > > > > +#define xendevicemodel_map_pcidev_to_ioreq_server \
> > > > > > > > +xc_hvm_map_pcidev_to_ioreq_server
> > > > > > > > +#define xendevicemodel_unmap_pcidev_from_ioreq_server
> \
> > > > > > > > +xc_hvm_unmap_pcidev_from_ioreq_server
> > > > > > > > +#define xendevicemodel_create_ioreq_server \
> > > > > > > > +xc_hvm_create_ioreq_server
> > > > > > > > +#define xendevicemodel_destroy_ioreq_server \
> > > > > > > > +xc_hvm_destroy_ioreq_server
> > > > > > > > +#define xendevicemodel_get_ioreq_server_info \
> > > > > > > > +xc_hvm_get_ioreq_server_info
> > > > > > > > +#define xendevicemodel_set_ioreq_server_state \
> > > > > > > > +xc_hvm_set_ioreq_server_state
> > > > > > > > +#define xendevicemodel_set_pci_intx_level \
> > > > > > > > +xc_hvm_set_pci_intx_level
> > > > > > > > +#define 

Re: [Xen-devel] [PATCH v3] xen: Allow a default compiled-in command line using Kconfig

[Jan Beulich]

>>> On 07.03.17 at 09:34,  wrote:

As an initial remark: Am I right in guessing that you manually prefix
[Xen-devel] to your message subject? Please don't do so - receiving
patches without that prefix serves as an indication to the receiver
that (s)he is on the Cc list.

> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -705,10 +705,16 @@ void __init start_xen(unsigned long boot_phys_offset,
>  size_t fdt_size;
>  int cpus, i;
>  paddr_t xen_paddr;
> -const char *cmdline;
> +const char *cmdline, *boot_cmdline;
>  struct bootmodule *xen_bootmodule;
>  struct domain *dom0;
>  struct xen_arch_domainconfig config;
> +#ifdef CONFIG_CMDLINE_BOOL
> +static xen_commandline_t __initdata builtin_cmdline = CONFIG_CMDLINE;
> +#ifndef CONFIG_CMDLINE_OVERRIDE
> +static xen_commandline_t __initdata complete_cmdline = "";

Pointless initializer.

> +#endif /* CONFIG_CMDLINE_OVERRIDE */
> +#endif /* CONFIG_CMDLINE_BOOL */

I think this #ifdef-ary can be reduced, along the lines of Andrew's
earlier suggestion. But my main complaint remains that this
continues to be duplicated between ARM and x86.

> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -636,10 +636,41 @@ static char * __init cmdline_cook(char *p, const char 
> *loader_name)
>  return p;
>  }
>  
> +/*
> + * Extracts dom0 options from the commandline.
> + *
> + * Options after ' -- ' separator belong to dom0.
> + *  1. Orphan dom0's options from Xen's command line.
> + *  2. Skip all but final leading space from dom0's options.
> + */
> +
> +static inline char* __init extract_dom0_options(char *cmdline)
> +{
> +char *kextra;
> +
> +if ( (kextra = strstr(cmdline, " -- ")) != NULL )
> +{
> +*kextra = '\0';
> +kextra += 3;
> +while ( kextra[1] == ' ' ) kextra++;

The body of the while() wants to go on its own line.

And then - why is this Dom0 option handling done only on x86?

> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -237,4 +237,44 @@ config FAST_SYMBOL_LOOKUP
> The only user of this is Live patching.
>  
> If unsure, say Y.
> +
> +config CMDLINE_BOOL
> + bool "Built-in hypervisor command line"
> + default n

I don't think this line serves any purpose (also another time below).

> + ---help---
> +   Allow for specifying boot arguments to the hypervisor at
> +   build time.  On some systems (e.g. embedded ones), it is
> +   necessary or convenient to provide some or all of the
> +   hypervisor boot arguments with the hypervisor itself (that is,
> +   to not rely on the bootloader to provide them.)
> +
> +   To compile command line arguments into the hypervisor,
> +   set this option to 'Y', then fill in the
> +   boot arguments in CONFIG_CMDLINE.
> +
> +config CMDLINE
> + string "Built-in hypervisor command string"
> + depends on CMDLINE_BOOL

Coming back to the #ifdef-ary remark earlier on - if instead of
"depends on" you made the prompt conditional, CMDLINE would
always be defined, i.e. you could use without #ifdef guards. Of
course with that the question of the usefulness of
CMDLINE_BOOL arises: Does this really serve a purpose?

> + default ""
> + ---help---
> +   Enter arguments here that should be compiled into the hypervisor
> +   image and used at boot time.  If the bootloader provides a
> +   command line at boot time, it is appended to this string to
> +   form the full hypervisor command line, when the system boots.
> +   So if the same command line option was set twice, only the latter
> +   (i.e. the one in the bootloader command line), will take effect.

... unless an option is cumulative (I don't think we have any such
right now, but iirc Linux does, and so we should not exclude that we
may gain such).

> +   However, you can use the CONFIG_CMDLINE_OVERRIDE option to
> +   change this behavior.
> +
> +config CMDLINE_OVERRIDE
> + bool "Built-in command line overrides bootloader arguments"
> + default n
> + depends on CMDLINE_BOOL
> + ---help---
> +   Set this option to 'Y' to have the hypervisor ignore the bootloader
> +   command line, and use ONLY the built-in command line.
> +
> +   This is used to work around broken bootloaders. This should
> +   be set to 'N' under normal conditions.

I think this calls for an EXPERT dependency.

Jan

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

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

[Jan Beulich]

>>> On 07.03.17 at 06:52,  wrote:
> flight 106504 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/106504/ 
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  [...]
>  test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 16 guest-stop fail REGR. vs. 
> 106482

Here we go:

(XEN) d15v0: intack: 02:48 pt: 38
(XEN) vIRR:       0001 

(XEN)  PIR:        

(XEN) Assertion 'intack.vector >= pt_vector' failed at intr.c:360
(XEN) [ Xen-4.9-unstable  x86_64  debug=y   Not tainted ]
(XEN) CPU:0
(XEN) RIP:e008:[] vmx_intr_assist+0x5fa/0x61a
(XEN) RFLAGS: 00010292   CONTEXT: hypervisor (d15v0)
(XEN) rax: 82d0804754a8   rbx: 83007f375680   rcx: 
(XEN) rdx: 83007cd3   rsi: 000a   rdi: 82d0803316d8
(XEN) rbp: 83007cd3ff08   rsp: 83007cd3fea8   r8:  830277db8000
(XEN) r9:  0001   r10:    r11: 0001
(XEN) r12:    r13: 82d0802b5b02   r14: 82d0802b5b02
(XEN) r15: 83027d82e000   cr0: 80050033   cr4: 001526e0
(XEN) cr3: 000259135000   cr2: 0164f034
(XEN) ds:    es:    fs:    gs:    ss:    cs: e008
(XEN) Xen code around  (vmx_intr_assist+0x5fa/0x61a):
(XEN)  fb ff ff e9 49 fc ff ff <0f> 0b 89 ce 48 89 df e8 2a 21 00 00 e9 49 fe ff
(XEN) Xen stack trace from rsp=83007cd3fea8:
(XEN)82d08044ab00 0038 83007cd3 83027d82e000
(XEN)83007cd3fef8 82d080133a3d 83007f375000 83007f375000
(XEN)83007f7fc000 83026df78000  83027d82e000
(XEN)83007cd3fdb0 82d080213191 0004 00c2
(XEN)0020 0002 880029994000 81ade0a0
(XEN)0246  88002d08 0004
(XEN)006c  03f8 03f8
(XEN)81ade0a0 beefbeef 81389ac4 00bfbeef
(XEN)0002 88002f403e08 beef beef
(XEN)beef beef beef 
(XEN)83007f375000  001526e0
(XEN) Xen call trace:
(XEN)[] vmx_intr_assist+0x5fa/0x61a
(XEN)[] vmx_asm_vmexit_handler+0x41/0x120
(XEN) 
(XEN) 
(XEN) 
(XEN) Panic on CPU 0:
(XEN) Assertion 'intack.vector >= pt_vector' failed at intr.c:360
(XEN) 

I didn't make an attempt at interpreting this yet, but I wonder if it
is more than coincidence that - just like the first time the ASSERT()
triggered - this is again a guest-stop of a qemuu-debianhvm.

Jan


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

Re: [Xen-devel] [PATCH 12/29] drivers, media: convert s2255_dev.num_channels from atomic_t to refcount_t

[Sakari Ailus]

Hi Elena,

On Mon, Mar 06, 2017 at 04:20:59PM +0200, Elena Reshetova wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
> 
> Signed-off-by: Elena Reshetova 
> Signed-off-by: Hans Liljestrand 
> Signed-off-by: Kees Cook 
> Signed-off-by: David Windsor 
> ---
...
> @@ -1688,7 +1689,7 @@ static int s2255_probe_v4l(struct s2255_dev *dev)
>   "failed to register video device!\n");
>   break;
>   }
> - atomic_inc(>num_channels);
> + refcount_set(>num_channels, 1);

That's not right. The loop runs four iterations and the value after the
loop should be indeed the number of channels.

atomic_t isn't really used for reference counting here, but storing out how
many "channels" there are per hardware device, with maximum number of four
(4). I'd leave this driver using atomic_t.

>   v4l2_info(>v4l2_dev, "V4L2 device registered as %s\n",
> video_device_node_name(>vdev));
>  

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

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

Re: [Xen-devel] [PATCH 11/29] drivers, media: convert cx88_core.refcount from atomic_t to refcount_t

[Sakari Ailus]

On Mon, Mar 06, 2017 at 04:20:58PM +0200, Elena Reshetova wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
> 
> Signed-off-by: Elena Reshetova 
> Signed-off-by: Hans Liljestrand 
> Signed-off-by: Kees Cook 
> Signed-off-by: David Windsor 

Acked-by: Sakari Ailus 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

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

Re: [Xen-devel] [PATCH 13/29] drivers, media: convert vb2_vmarea_handler.refcount from atomic_t to refcount_t

[Sakari Ailus]

Hi Elena,

On Mon, Mar 06, 2017 at 04:21:00PM +0200, Elena Reshetova wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
> 
> Signed-off-by: Elena Reshetova 
> Signed-off-by: Hans Liljestrand 
> Signed-off-by: Kees Cook 
> Signed-off-by: David Windsor 
> ---
>  drivers/media/v4l2-core/videobuf2-memops.c | 6 +++---
>  include/media/videobuf2-memops.h   | 3 ++-
>  2 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/videobuf2-memops.c 
> b/drivers/media/v4l2-core/videobuf2-memops.c
> index 1cd322e..4bb8424 100644
> --- a/drivers/media/v4l2-core/videobuf2-memops.c
> +++ b/drivers/media/v4l2-core/videobuf2-memops.c
> @@ -96,10 +96,10 @@ static void vb2_common_vm_open(struct vm_area_struct *vma)
>   struct vb2_vmarea_handler *h = vma->vm_private_data;
>  
>   pr_debug("%s: %p, refcount: %d, vma: %08lx-%08lx\n",
> -__func__, h, atomic_read(h->refcount), vma->vm_start,
> +__func__, h, refcount_read(h->refcount), vma->vm_start,
>  vma->vm_end);
>  
> - atomic_inc(h->refcount);
> + refcount_inc(h->refcount);
>  }
>  
>  /**
> @@ -114,7 +114,7 @@ static void vb2_common_vm_close(struct vm_area_struct 
> *vma)
>   struct vb2_vmarea_handler *h = vma->vm_private_data;
>  
>   pr_debug("%s: %p, refcount: %d, vma: %08lx-%08lx\n",
> -__func__, h, atomic_read(h->refcount), vma->vm_start,
> +__func__, h, refcount_read(h->refcount), vma->vm_start,
>  vma->vm_end);
>  
>   h->put(h->arg);
> diff --git a/include/media/videobuf2-memops.h 
> b/include/media/videobuf2-memops.h
> index 36565c7a..a6ed091 100644
> --- a/include/media/videobuf2-memops.h
> +++ b/include/media/videobuf2-memops.h
> @@ -16,6 +16,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  /**
>   * struct vb2_vmarea_handler - common vma refcount tracking handler
> @@ -25,7 +26,7 @@
>   * @arg: argument for @put callback
>   */
>  struct vb2_vmarea_handler {
> - atomic_t*refcount;
> + refcount_t  *refcount;

This is a pointer to refcount, not refcount itself. The refcount is part of
a memory type specific struct, the types that you change in the following
three patches. I guess it would still compile and work as separate patches
but you'd sure get warnings at least.

How about merging this and the three following patches that change the memop
refcount types?

>   void(*put)(void *arg);
>   void*arg;
>  };

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

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