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

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl  15 guest-start/debian.repeat   fail pass in 99732

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

version targeted for testing:
 xen  c5eae7332909e3ef1a18e0164e9e4e512edf9ef3
baseline version:
 xen  d5438accceecc8172db2d37d98b695eb8bc43afc

Last test of basis99707  2016-07-26 10:01:43 Z1 days
Failing since 99722  2016-07-27 18:01:50 Z0 days4 attempts
Testing same since99729  2016-07-27 20:41:23 Z0 days3 attempts


People who touched revisions under test:
  Andrew Cooper 
  Juergen Gross 
  Julien Grall 
  Shanker Donthineni 
  Stefano Stabellini 
  Tamas K Lengyel 
  Wei Liu 

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



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

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

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

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


Not pushing.

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

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

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

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 xen  c5eae7332909e3ef1a18e0164e9e4e512edf9ef3
baseline version:
 xen  d5438accceecc8172db2d37d98b695eb8bc43afc

Last test of basis99707  2016-07-26 10:01:43 Z1 days
Failing since 99722  2016-07-27 18:01:50 Z0 days3 attempts
Testing same since99729  2016-07-27 20:41:23 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Juergen Gross 
  Julien Grall 
  Shanker Donthineni 
  Stefano Stabellini 
  Tamas K Lengyel 
  Wei Liu 

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



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] [PATCH 1/3] xen-blkfront: fix places not updated after introducing 64KB page granularity

[Konrad Rzeszutek Wilk]

On Tue, Jul 26, 2016 at 01:19:35PM +0800, Bob Liu wrote:
> Two places didn't get updated when 64KB page granularity was introduced, this
> patch fix them.
> 
> Signed-off-by: Bob Liu 
> Acked-by: Roger Pau Monné 

Could you rebase this on xen-tip/for-linus-4.8 pls?

> ---
>  drivers/block/xen-blkfront.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index fcc5b4e..032fc94 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -1321,7 +1321,7 @@ free_shadow:
>   rinfo->ring_ref[i] = GRANT_INVALID_REF;
>   }
>   }
> - free_pages((unsigned long)rinfo->ring.sring, 
> get_order(info->nr_ring_pages * PAGE_SIZE));
> + free_pages((unsigned long)rinfo->ring.sring, 
> get_order(info->nr_ring_pages * XEN_PAGE_SIZE));
>   rinfo->ring.sring = NULL;
>  
>   if (rinfo->irq)
> @@ -2013,7 +2013,7 @@ static int blkif_recover(struct blkfront_info *info)
>  
>   blkfront_gather_backend_features(info);
>   segs = info->max_indirect_segments ? : BLKIF_MAX_SEGMENTS_PER_REQUEST;
> - blk_queue_max_segments(info->rq, segs);
> + blk_queue_max_segments(info->rq, segs / GRANTS_PER_PSEG);
>  
>   for (r_index = 0; r_index < info->nr_rings; r_index++) {
>   struct blkfront_ring_info *rinfo = >rinfo[r_index];
> -- 
> 1.7.10.4
> 

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

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[Konrad Rzeszutek Wilk]

> > > Sadly not.  The debug symbols need to be specific to the exact binary
> > > you booted.
> > > 
> > > Any change in the compilation will result in the translation being
> > > useless.  What addr2line is doing is saying "which specific bit of
> > > source code did the compiler/linker end up putting at $X".
> > 
> > Got it.  Weird that they don't put the .debuginfo rpms in there.  While I 
> > was searching around kernel bug reports over at the distro there's lots of 
> > posts telling people to debug.  Not sure then how you do it without the 
> > debug symbols.
> > 
> > Guess you have to build your own kernel.
> 
> I got my hands on a 'matched set'
> 
>   rpm -qa kernel-default\*
>   kernel-default-4.7.0-5.1.x86_64
>   kernel-default-devel-4.7.0-5.1.x86_64
>   kernel-default-debuginfo-4.7.0-5.1.x86_64
> 
> reboot to Xen, still crashes
> 
>   (XEN) [2016-07-28 00:13:18] [ Xen-4.7.0_08-452  x86_64  
> debug=n  Tainted:C ]
>   (XEN) [2016-07-28 00:13:18] CPU:0
> >>>   (XEN) [2016-07-28 00:13:18] RIP:e033:[]
>   (XEN) [2016-07-28 00:13:18] RFLAGS: 0246   EM: 1   
> CONTEXT: pv guest (d0v0)
>   (XEN) [2016-07-28 00:13:18] rax:    rbx: 
>    rcx: 00016f144000
>   (XEN) [2016-07-28 00:13:18] rdx: 0001   rsi: 
> 00016f144000   rdi: f000
>   (XEN) [2016-07-28 00:13:18] rbp: 0100   rsp: 
> 81e03e50   r8:  81efb0c0
>   (XEN) [2016-07-28 00:13:18] r9:     r10: 
>    r11: 0001
>   (XEN) [2016-07-28 00:13:18] r12:    r13: 
>    r14: 81e03f28
>   (XEN) [2016-07-28 00:13:18] r15:    cr0: 
> 80050033   cr4: 001526e0
>   (XEN) [2016-07-28 00:13:18] cr3: 000841e06000   cr2: 
> 0018
>   (XEN) [2016-07-28 00:13:18] ds:    es:    fs:    
> gs:    ss: e02b   cs: e033
>   (XEN) [2016-07-28 00:13:18] Guest stack trace from 
> rsp=81e03e50:
> 
> check ar the RIP addr
> 
>   addr2line -e /usr/lib/debug/boot/vmlinux-4.7.0-5-default.debug 
> 81f63eb0
>   
> /usr/src/debug/kernel-default-4.7.0/linux-4.7/linux-obj/../arch/x86/platform/efi/efi.c:123
> 
> in source
> 
>   @ 
> https://github.com/torvalds/linux/blob/v4.7/arch/x86/platform/efi/efi.c
> 
>   ...
>   void __init efi_find_mirror(void)
>   {
>   efi_memory_desc_t *md;
>   u64 mirror_size = 0, total_size = 0;
> 
>   for_each_efi_memory_desc(md) {
>   unsigned long long start = md->phys_addr;
> 123   unsigned long long size = md->num_pages << 
> EFI_PAGE_SHIFT;
> 
>   total_size += size;
>   if (md->attribute & EFI_MEMORY_MORE_RELIABLE) {
>   memblock_mark_mirror(start, size);
>   mirror_size += size;
>   }
>   }
>   if (mirror_size)
>   pr_info("Memory: %lldM/%lldM mirrored memory\n",
>   mirror_size>>20, total_size>>20);
>   }
>   ...
> 

+CC-ing Daniel.


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

Re: [Xen-devel] pci passthrough kills qemu-xen

[Konrad Rzeszutek Wilk]

On Mon, Jul 25, 2016 at 11:56:40AM +0200, Olaf Hering wrote:
> I'm trying to assing a PCIe network card to a HVM guest on an Dell
> Optiplex 980. This works with qemu-xen-traditional, but fails with
> qemu-xen. I tried staging-4.4 and staging-4.7, both with xenlinux based
> SLE12 dom0 kernel and with plain pvops 4.6.4 dom0 kernel.
> 
> First I ran "xl pci-assignable-add 02:00.0", then xl create.
> 
> Any idea whats wrong on this host?
..snip..
> name='fv-x64-tw-clean'
> uuid='37c8ce56-7ad3-41ea-bff1-a3df282bde0a'
> memory=1024
> vcpus=2
> disk=[
> 'file:/vm_images/xen_images/fv-x64-tw-clean/vdisk-fv-x64-tw-clean-disk0.raw,hda,w',
> ]
> vif=[ 'mac=00:08:15:41:00:00,bridge=br0', ]
> vfb=[ 'type=vnc,vncunused=1,keymap=de', ]
> keymap="de"
> serial="pty"
> builder="hvm"
> pci=[ '02:00.0', ]
> device_model_override="/vm_images/xen_images/bug989250/dm.sh"

Why that over-write? Does it call the right qemu-binary? Does that binary
construct an /var/log/xen/qemu.. something?

Why not just:
bios="seabios"

Anhyow I also see:

>  Xen 4.7.20160704T103633.a492556-1.xen47
> (XEN) Xen version 4.7.20160704T103633.a492556-1.xen47 (abuild@) (gcc (SUSE 
> Linux) 4.8.5) debug=n Mon Jul  4 12:36:33 UTC 2016

Could you recompile it with debug=y?
.. snip..
> (XEN) HVM1 save: CPU
> (XEN) HVM1 save: PIC
> (XEN) HVM1 save: IOAPIC
> (XEN) HVM1 save: LAPIC
> (XEN) HVM1 save: LAPIC_REGS
> (XEN) HVM1 save: PCI_IRQ
> (XEN) HVM1 save: ISA_IRQ
> (XEN) HVM1 save: PCI_LINK
> (XEN) HVM1 save: PIT
> (XEN) HVM1 save: RTC
> (XEN) HVM1 save: HPET
> (XEN) HVM1 save: PMTIMER
> (XEN) HVM1 save: MTRR
> (XEN) HVM1 save: VIRIDIAN_DOMAIN
> (XEN) HVM1 save: CPU_XSAVE
> (XEN) HVM1 save: VIRIDIAN_VCPU
> (XEN) HVM1 save: VMCE_VCPU
> (XEN) HVM1 save: TSC_ADJUST
> (XEN) HVM1 restore: CPU 0
> (XEN) HVM2 save: CPU
> (XEN) HVM2 save: PIC
> (XEN) HVM2 save: IOAPIC
> (XEN) HVM2 save: LAPIC
> (XEN) HVM2 save: LAPIC_REGS
> (XEN) HVM2 save: PCI_IRQ
> (XEN) HVM2 save: ISA_IRQ
> (XEN) HVM2 save: PCI_LINK
> (XEN) HVM2 save: PIT
> (XEN) HVM2 save: RTC
> (XEN) HVM2 save: HPET
> (XEN) HVM2 save: PMTIMER
> (XEN) HVM2 save: MTRR
> (XEN) HVM2 save: VIRIDIAN_DOMAIN
> (XEN) HVM2 save: CPU_XSAVE
> (XEN) HVM2 save: VIRIDIAN_VCPU
> (XEN) HVM2 save: VMCE_VCPU
> (XEN) HVM2 save: TSC_ADJUST
> (XEN) HVM2 restore: CPU 0

.. Huh? Where is hvmloader?

Is it even being loaded? 

May have a bit more help if you compile it with debug=y and we can
see where hvmloader gets stuck.

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

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

On Wed, Jul 27, 2016, at 05:28 PM, li...@ssl-mail.com wrote:
> 123   unsigned long long size = md->num_pages << 
> EFI_PAGE_SHIFT;

If I'm reading it right, that originated in this pull

DateMon, 16 May 2016 16:43:11 +0200
FromIngo Molnar <>
Subject [GIT PULL] EFI changes for v4.7
https://lkml.org/lkml/2016/5/16/244

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

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

On Wed, Jul 27, 2016, at 11:36 AM, li...@ssl-mail.com wrote:
> On Wed, Jul 27, 2016, at 11:28 AM, Andrew Cooper wrote:
> > > I'm not sure if that's good enough.
> > 
> > Sadly not.  The debug symbols need to be specific to the exact binary
> > you booted.
> > 
> > Any change in the compilation will result in the translation being
> > useless.  What addr2line is doing is saying "which specific bit of
> > source code did the compiler/linker end up putting at $X".
> 
> Got it.  Weird that they don't put the .debuginfo rpms in there.  While I was 
> searching around kernel bug reports over at the distro there's lots of posts 
> telling people to debug.  Not sure then how you do it without the debug 
> symbols.
> 
> Guess you have to build your own kernel.

I got my hands on a 'matched set'

rpm -qa kernel-default\*
kernel-default-4.7.0-5.1.x86_64
kernel-default-devel-4.7.0-5.1.x86_64
kernel-default-debuginfo-4.7.0-5.1.x86_64

reboot to Xen, still crashes

(XEN) [2016-07-28 00:13:18] [ Xen-4.7.0_08-452  x86_64  
debug=n  Tainted:C ]
(XEN) [2016-07-28 00:13:18] CPU:0
>>> (XEN) [2016-07-28 00:13:18] RIP:e033:[]
(XEN) [2016-07-28 00:13:18] RFLAGS: 0246   EM: 1   
CONTEXT: pv guest (d0v0)
(XEN) [2016-07-28 00:13:18] rax:    rbx: 
   rcx: 00016f144000
(XEN) [2016-07-28 00:13:18] rdx: 0001   rsi: 
00016f144000   rdi: f000
(XEN) [2016-07-28 00:13:18] rbp: 0100   rsp: 
81e03e50   r8:  81efb0c0
(XEN) [2016-07-28 00:13:18] r9:     r10: 
   r11: 0001
(XEN) [2016-07-28 00:13:18] r12:    r13: 
   r14: 81e03f28
(XEN) [2016-07-28 00:13:18] r15:    cr0: 
80050033   cr4: 001526e0
(XEN) [2016-07-28 00:13:18] cr3: 000841e06000   cr2: 
0018
(XEN) [2016-07-28 00:13:18] ds:    es:    fs:    
gs:    ss: e02b   cs: e033
(XEN) [2016-07-28 00:13:18] Guest stack trace from 
rsp=81e03e50:

check ar the RIP addr

addr2line -e /usr/lib/debug/boot/vmlinux-4.7.0-5-default.debug 
81f63eb0

/usr/src/debug/kernel-default-4.7.0/linux-4.7/linux-obj/../arch/x86/platform/efi/efi.c:123

in source

@ 
https://github.com/torvalds/linux/blob/v4.7/arch/x86/platform/efi/efi.c

...
void __init efi_find_mirror(void)
{
efi_memory_desc_t *md;
u64 mirror_size = 0, total_size = 0;

for_each_efi_memory_desc(md) {
unsigned long long start = md->phys_addr;
123 unsigned long long size = md->num_pages << 
EFI_PAGE_SHIFT;

total_size += size;
if (md->attribute & EFI_MEMORY_MORE_RELIABLE) {
memblock_mark_mirror(start, size);
mirror_size += size;
}
}
if (mirror_size)
pr_info("Memory: %lldM/%lldM mirrored memory\n",
mirror_size>>20, total_size>>20);
}
...

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

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

[Andrew Cooper]

On 28/07/2016 00:46, Rafael J. Wysocki wrote:
> On Wednesday, July 27, 2016 04:18:32 PM Linus Torvalds wrote:
>> On Wed, Jul 27, 2016 at 4:09 PM, Rafael J. Wysocki  
>> wrote:
>>> The STAO definition document:
>>>
>>> http://wiki.xenproject.org/mediawiki/images/0/02/Status-override-table.pdf
>>>
>>> requires as to "operate as if that device does not exist", quite literally.
>> Well, first off, documentation is one thing, actually changing
>> behavior is something entirely different.
>>
>> Theory and practice are *not* the same.
> Well, the STAO thing is totally new, so we have the documentation only ATM.
>
>> The other worry I have is that I'd be happier if it's still visible in
>> /sys/bus/acpi/ etc. Again, it's one thing to not react to it
>> programmatically, and another thing entirely to actually hide the
>> information from the rest of the system.
>>
>> If I read that patch right, it will be hidden from sysfs too. But
>> Maybe I'm mistaken.
> You're right.
>
> Avoiding to enumerate it entirely is somewhat simpler, because it allows
> us to avoid some special casing in a few places IIRC.
>
> I guess we can ask the author of the commit in question to come up with a
> patch to unhide that device and we'll see how that looks like.

Well - the entire purpose of STAO is to list system resources which are
genuinely in use by the hypervisor, and genuinely can't be mapped or
used by the kernel (these latter two frequently resulting in crashes or
hangs at early boot).

Identifying that such devices exist is reasonable (it is certainly
possibly by dumping the raw acpi tables), but any sysfs tweakable is
going to end in misery.

~Andrew

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

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

[Rafael J. Wysocki]

On Wednesday, July 27, 2016 04:18:32 PM Linus Torvalds wrote:
> On Wed, Jul 27, 2016 at 4:09 PM, Rafael J. Wysocki  wrote:
> >
> > The STAO definition document:
> >
> > http://wiki.xenproject.org/mediawiki/images/0/02/Status-override-table.pdf
> >
> > requires as to "operate as if that device does not exist", quite literally.
> 
> Well, first off, documentation is one thing, actually changing
> behavior is something entirely different.
> 
> Theory and practice are *not* the same.

Well, the STAO thing is totally new, so we have the documentation only ATM.

> The other worry I have is that I'd be happier if it's still visible in
> /sys/bus/acpi/ etc. Again, it's one thing to not react to it
> programmatically, and another thing entirely to actually hide the
> information from the rest of the system.
> 
> If I read that patch right, it will be hidden from sysfs too. But
> Maybe I'm mistaken.

You're right.

Avoiding to enumerate it entirely is somewhat simpler, because it allows
us to avoid some special casing in a few places IIRC.

I guess we can ask the author of the commit in question to come up with a
patch to unhide that device and we'll see how that looks like.

Thanks,
Rafael


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

[Xen-devel] Integration of xen vTPM in Openstack cloud

[Arun Raghuramu]

Hello,

I saw in an earlier xen-devel conversation

that
there were some efforts going on to integrate xen vTPM in to the Openstack
cloud so that Openstack managed VM's can work with Xen vTPM. I'd like to
know if this was ever completed / what sort of changes would be necessary
to make this possible.
Any help would be appreciated.

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

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

[Linus Torvalds]

On Wed, Jul 27, 2016 at 4:09 PM, Rafael J. Wysocki  wrote:
>
> The STAO definition document:
>
> http://wiki.xenproject.org/mediawiki/images/0/02/Status-override-table.pdf
>
> requires as to "operate as if that device does not exist", quite literally.

Well, first off, documentation is one thing, actually changing
behavior is something entirely different.

Theory and practice are *not* the same.

The other worry I have is that I'd be happier if it's still visible in
/sys/bus/acpi/ etc. Again, it's one thing to not react to it
programmatically, and another thing entirely to actually hide the
information from the rest of the system.

If I read that patch right, it will be hidden from sysfs too. But
Maybe I'm mistaken.

 Linus

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

Re: [Xen-devel] [PATCH 04/19] xen: Move evtchn functions to xen_pvdev.c

[Eric Blake]

On 07/25/2016 07:53 AM, Anthony PERARD wrote:
> On Sun, Jul 10, 2016 at 02:47:35PM +0300, Emil Condrea wrote:
>> The name of the functions moved:
>>  * xen_be_evtchn_event
>>  * xen_be_unbind_evtchn
>>  * xen_be_send_notify
>>
>> Signed-off-by: Emil Condrea 
>> ---
>>  hw/xen/xen_backend.c | 37 +
>>  hw/xen/xen_pvdev.c   | 35 +++
>>  include/hw/xen/xen_backend.h |  2 --
>>  include/hw/xen/xen_pvdev.h   |  4 
>>  4 files changed, 40 insertions(+), 38 deletions(-)
>>
>> diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
>> index 0a9f9bb..5f2821a 100644
>> --- a/hw/xen/xen_backend.c
>> +++ b/hw/xen/xen_backend.c
>> @@ -693,4 +658,4 @@ static void xenbe_register_types(void)
>>  type_register_static(_info);
>>  }
>>  
>> -type_init(xenbe_register_types);
>> +type_init(xenbe_register_types);
>> \ No newline at end of file
> 
> Looks like this change does not belong to this patch.

For that matter, we prefer that all text files in qemu.git end in a
newline (since according to POSIX, a non-empty file that does not end in
newline is not a text file).

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



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

Re: [Xen-devel] [PATCH v3] xen-blkfront: dynamic configuration of per-vbd resources

[Bob Liu]

On 07/27/2016 10:24 PM, Roger Pau Monné wrote:
> On Wed, Jul 27, 2016 at 07:21:05PM +0800, Bob Liu wrote:
>>
>> On 07/27/2016 06:59 PM, Roger Pau Monné wrote:
>>> On Wed, Jul 27, 2016 at 11:21:25AM +0800, Bob Liu wrote:
>>> [...]
 +static ssize_t dynamic_reconfig_device(struct blkfront_info *info, 
 ssize_t count)
 +{
 +  /*
 +   * Prevent new requests even to software request queue.
 +   */
 +  blk_mq_freeze_queue(info->rq);
 +
 +  /*
 +   * Guarantee no uncompleted reqs.
 +   */
>>>
>>> I'm also wondering, why do you need to guarantee that there are no 
>>> uncompleted requests? The resume procedure is going to call blkif_recover 
>>> that will take care of requeuing any unfinished requests that are on the 
>>> ring.
>>>
>>
>> Because there may have requests in the software request queue with more 
>> segments than
>> we can handle(if info->max_indirect_segments is reduced).
>>
>> The blkif_recover() can't handle this since blk-mq was introduced,
>> because there is no way to iterate the sw-request queues(blk_fetch_request() 
>> can't be used by blk-mq).
>>
>> So there is a bug in blkif_recover(), I was thinking implement the suspend 
>> function of blkfront_driver like:
> 
> Hm, this is a regression and should be fixed ASAP. I'm still not sure I 
> follow, don't blk_queue_max_segments change the number of segments the 
> requests on the queue are going to have? So that you will only have to 
> re-queue the requests already on the ring?
> 

That's not enough, request queues were split to software queues and hardware 
queues since blk-mq was introduced.
We need to consider two more things:
 * Stop new requests be added to software queues before 
blk_queue_max_segments() is called(still using old 'max-indirect-segments').
   I didn't see other way except call blk_mq_freeze_queue().

 * Requests already in software queues but with old 'max-indirect-segments' 
also have to be re-queued based on new 'max-indirect-segments'.
   Neither blk-mq API can do this.

> Waiting for the whole queue to be flushed before suspending is IMHO not 
> acceptable, it introduces an unbounded delay during migration if the backend 
> is slow for some reason.
> 

Right, I also hope there is better solution.

-- 
Regards,
-Bob

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

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

[Rafael J. Wysocki]

On Wednesday, July 27, 2016 07:57:34 PM Andrew Cooper wrote:
> On 27/07/16 19:42, Linus Torvalds wrote:
> > On Wed, Jul 27, 2016 at 6:45 AM, David Vrabel  wrote:
> >> Shannon Zhao (16):
> >>   Xen: ACPI: Hide UART used by Xen
> > So this caused a trivial conflict. No biggie, it wasn't bad and the
> > patch was acked by Rafael. However, looking at it made me somewhat
> > unhappy.
> >
> > Should the device entry in ACPI really be hidden unconditionally? In
> > particular, if we are *not* running under virtualization, it sounds
> > wrong to hide it.
> >
> > Comments? Am I missing something?
> 
> The purpose of the ACPI STAO table (Status Override table, ratified in
> ACPI 6.0) is to list items elsewhere in the ACPI namespace which should
> be completely ignored.  It is used in cases where it is impossible or
> prohibitive to edit the system AML.
> 
> The patch itself only hides the UART if instructed to do so by the STAO
> table (last hunk).

Right.

The STAO definition document:

http://wiki.xenproject.org/mediawiki/images/0/02/Status-override-table.pdf

requires as to "operate as if that device does not exist", quite literally.

Thanks,
Rafael


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

Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support

[Luis R. Rodriguez]

On Tue, Jul 26, 2016 at 12:30:14AM +0900, Masami Hiramatsu wrote:
> On Fri, 22 Jul 2016 14:24:41 -0700
> "Luis R. Rodriguez"  wrote:
> 
> > +/**
> > + * LINKTABLE_RUN_ALL - iterate and run through all entries on a linker 
> > table
> > + *
> > + * @tbl: linker table
> > + * @func: structure name for the function name we want to call.
> > + * @args...: arguments to pass to func
> > + *
> > + * Example usage:
> > + *
> > + *   LINKTABLE_RUN_ALL(frobnicator_fns, some_run,);
> > + */
> > +#define LINKTABLE_RUN_ALL(tbl, func, args...)  
> > \
> > +do {   
> > \
> > +   size_t i;   \
> > +   for (i = 0; i < LINUX_SECTION_SIZE(tbl); i++)   \
> > +   (tbl[i]).func (args);   \
> > +} while (0);
> > +
> > +/**
> > + * LINKTABLE_RUN_ERR - run each linker table entry func and return error 
> > if any
> > + *
> > + * @tbl: linker table
> > + * @func: structure name for the function name we want to call.
> > + * @args...: arguments to pass to func
> > + *
> > + * Example usage:
> > + *
> > + *   unsigned int err = LINKTABLE_RUN_ERR(frobnicator_fns, some_run,);
> > + */
> > +#define LINKTABLE_RUN_ERR(tbl, func, args...)  
> > \
> > +({ \
> > +   size_t i;   \
> > +   int err = 0;\
> > +   for (i = 0; !err && i < LINUX_SECTION_SIZE(tbl); i++)   \
> > +   err = (tbl[i]).func (args); \
> > +   err; \
> > +})
> 
> These iteration APIs are a bit dangerous, at least for these APIs we'd better 
> change
> name like as FUNCTABLE_RUN etc. because LINKTABLE can contain not only 
> function address
> but also some data (or address of data).

Sure will do, thanks for the review.

  Luis

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

Re: [Xen-devel] [RFC v3 13/13] kprobes: port blacklist kprobes to linker table

[Luis R. Rodriguez]

On Tue, Jul 26, 2016 at 12:27:22AM +0900, Masami Hiramatsu wrote:
> On Fri, 22 Jul 2016 14:24:47 -0700
> "Luis R. Rodriguez"  wrote:
> 
> > kprobe makes use of two sections, the one dealing with the actual
> > kprobes was recently ported using the standard section range API.
> > The blacklist functionality of kprobes is still using a custom
> > section and declaring its custom section using the linker script
> > as follows:
> > 
> > type  Linux-section custom section name  beginend
> > table .init.data_kprobe_blacklist__start_kprobe_blacklist 
> > __stop_kprobe_blacklist
> > 
> > This ports the _kprobe_blacklist custom section to the standard
> > Linux linker table API allowing us remove all the custom blacklist
> > kprobe section declarations from the linker script.
> > 
> > This has been tested by trying to register a kprobe on a blacklisted
> > symbol (these are declared with NOKPROBE_SYMBOL()), and confirms that
> > this fails to work as expected. This was tested with:
> 
> This is OK for me, and if you would like to make sure, please use ftrace to 
> probe
>  (easier  than making new module) and compare debugfs/blacklist which shows
> all blacklisted functions, so if all the function names are same it
> must be OK :).

Ah I see, sure thanks for the tip! I was actually hoping to write a unit
test that automates this testing, but that can be done and submitted later,
the approach you suggest should make writing a unit easier as well.

> Acked-by: Masami Hiramatsu 

Great, thanks,

  Luis

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

Re: [Xen-devel] [RFC v3 10/13] jump_label: port __jump_table to linker tables

[Luis R. Rodriguez]

On Fri, Jul 22, 2016 at 05:55:35PM -0500, Josh Poimboeuf wrote:
> On Sat, Jul 23, 2016 at 12:26:54AM +0200, Luis R. Rodriguez wrote:
> > On Fri, Jul 22, 2016 at 04:49:45PM -0500, Josh Poimboeuf wrote:
> > > On Fri, Jul 22, 2016 at 02:24:44PM -0700, Luis R. Rodriguez wrote:
> > > > diff --git a/tools/objtool/special.c b/tools/objtool/special.c
> > > > index bff8abb3a4aa..f0ad369f994b 100644
> > > > --- a/tools/objtool/special.c
> > > > +++ b/tools/objtool/special.c
> > > > @@ -26,6 +26,10 @@
> > > >  #include "special.h"
> > > >  #include "warn.h"
> > > >  
> > > > +#include "../../include/asm-generic/sections.h"
> > > > +#include "../../include/asm-generic/tables.h"
> > > > +#include "../../include/linux/stringify.h"
> > > > +
> > > >  #define EX_ENTRY_SIZE  12
> > > >  #define EX_ORIG_OFFSET 0
> > > >  #define EX_NEW_OFFSET  4
> > > > @@ -63,7 +67,9 @@ struct special_entry entries[] = {
> > > > .feature = ALT_FEATURE_OFFSET,
> > > > },
> > > > {
> > > > -   .sec = "__jump_table",
> > > > +   .sec = __stringify(SECTION_TBL(SECTION_DATA,
> > > > +  __jump_table,
> > > > +  SECTION_ORDER_ANY)),
> > > > .jump_or_nop = true,
> > > > .size = JUMP_ENTRY_SIZE,
> > > > .orig = JUMP_ORIG_OFFSET,
> > > 
> > > (continuing our discussion from another thread...)
> > > 
> > > I think tools code isn't allowed to include kernel files because the
> > > tools subdirectory is supposed to be completely independent.
> > 
> > That was also the case for userpsace tools in scripts/ -- for instance
> > scripts/mod/modpost.c made an exception. What I've proposed here to
> > keep things simple was to ensure -UKERNEL is passed and then only
> > include files we know will work.
> > 
> > Refer to the patch "kprobes: port .kprobes.text to section range"
> > in this series for an extension of the scripts/mod/modpost.c kernel
> > headers use.
> 
> I think the rule of separating code is stricter for tools/ than it is
> for scripts/.  The scripts are generally kernel-specific whereas the
> tools are independent.  I believe the goal is to be able to copy them
> out of the kernel tree and still be able to compile them.

I see.

> > > As far as I can tell, the section name will always be
> > > ".data.tbl.__jump_table.any".  Is that true?  If so, any reason why we
> > > can't just hard-code the string here?
> > 
> > Its a fair strategy, however if upstream changes the order name we'd
> > have to hand code this as well, by using a macro we keep it all in one
> > place.
> 
> Hm, do you expect the section name to change often?

Nope, if anything only upon deployment on major distributions due to
some perhaps compatibility thing with custom hacks folks may have carried
and this just ended up clashing with. The only other case I can think
of a need for a change would be if upstream linkers supported something
similar for another brand of section names, with the added gain that
we would then not even need the 2 new lines on the kernel linker script
for section ranges and tables per section.

> > > As you saw, if the string
> > > changes, objtool will complain and 0-day will report it.
> > 
> > Indeed, which is why I was hoping to instead stick to a standard
> > sections set of header files that lets us get these in on place.
> 
> Actually, I meant that obtool reporting the change would be a good
> thing, in favor of just hard-coding the string.  It lets objtool do its
> job of letting us know when something changes, like it did today.

Getting a report so you can fix something is one reason to have a tool,
having it so you can inspect changes is another. So it depends what uses
there are for objtool. I take it that for this case we do want upstream
objtool to embrace the new section name to avoid further reports as
issues ?

> > The only place I hand coded in this series was in the perl
> > file scripts/recordmcount.pl but I suppose if we wanted to get
> > creative we could even generate a header for it too.
> > 
> > If we want to avoid all this hacker include stuff another option
> > is to *generate* each respective sections.h for the kernel, and
> > also, one for tools, and one for perl. What do you think?
> 
> If the generated files aren't checked into git, tools/ will rely on
> kernel files and will no longer be independent.  If they *are* checked
> in, then we have to keep the files in sync.  Either way it sounds like
> overkill, just to avoid hard-coding a string for which objtool will
> already warn if it changes.

We can open code the string, that's fine. In retrospect since things
won't change often that keeps things simple.

  Luis

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

Re: [Xen-devel] [RFC v3 00/13] linux: generalize sections, ranges and linker tables

[Luis R. Rodriguez]

On Mon, Jul 25, 2016 at 10:32:29PM +0900, Masami Hiramatsu wrote:
> Hi Luis,
> 
> On Fri, 22 Jul 2016 14:24:34 -0700
> "Luis R. Rodriguez"  wrote:
> 
> > This RFC v3 builds off the last RFC v2 series [0] for adding linker tables.
> > The largest amount of work here was to take Russell King's feedback on
> > using linker table for kprobes text not being appropriate -- and providing
> > another lightweight API for simple section ranges: read-only stitched pieces
> > of executable code. This required also generalizing common building blocks
> > for both linker tables and section ranges, these building blocks are defined
> > now in include/linux/sections.h and asm-generic/section.h. The other last 
> > thing
> > decided was to not support sub-sections. In the hunt for this I could think 
> > of
> > anything that really required this, and if it was needed it did not seem
> > impossible to port over to avoid its use. Please let me know if there are 
> > valid
> > uses cases for sub-sections.
> > 
> > Other significant effort here was to provide a set of common assembly 
> > helpers
> > which could be used across architectures, this starts off some of this work
> > for generic helpers which carve out and define custom Linux sections.
> > 
> > Lastly, this now also goes with two ports which required module support when
> > using linker tables: jump labels, and dynamic debug support. A few
> > extensions have been made to the original series in order to provide
> > support for that.
> > 
> > Since kprobes actually had both a linker table and a section range the
> > patch that dealt with kprobes is now split off in two patches, one
> > that deals with its linker table and another for its section ranges.
> > 
> > More elaborate uses for linker tables are possible, I'll hold off on any
> > of this type of work until at least the basic building blocks are fleshed
> > out. To review how this work came about, and more elaborate uses being
> > evaluated check out the userspace linker-tables mockup solution [1].
> > Hopefully most of the possible bikeshedding was already dealt with through
> > that tree. Thanks to hpa for tons of feedback.
> 
> Great! so table and ranges completely replace the old-style(add-hoc)
> _kprobe and NOKPROBE_SYMBOL() implementation, good job! :)

Indeed, thanks! In reality this is generalizing custom section hacks, but also
making them much more powerful due to the fact that we sort now at link time,
this buys us better than O(1) sort for code where dependencies can be spelled
out in code, it also expands on the semantics available to us for order
levels -- so we're no longer restricted to 7 levels for built-in code -- and
order levels can be subject/subsystem specific.

  Luis

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

Re: [Xen-devel] [RFC v3 12/13] kprobes: port .kprobes.text to section range

[Luis R. Rodriguez]

On Tue, Jul 26, 2016 at 12:19:58AM +0900, Masami Hiramatsu wrote:
> On Fri, 22 Jul 2016 14:24:46 -0700
> "Luis R. Rodriguez"  wrote:
> 
> > kprobe makes use of two custom sections, each custom section
> > is folded into one of the standard Linux sections types as follows,
> > it currently relies on the linker script to fold the custom section
> > onto the respective Linux section:
> > 
> > type  Linux-section custom section name  beginend
> > table .init.data_kprobe_blacklist__start_kprobe_blacklist 
> > __stop_kprobe_blacklist
> > range .text .kprobes.text__kprobes_text_start 
> > __kprobes_text_end
> > 
> > This ports the .kprobes.text custom section to the standard
> > Linux ranges API allowing us remove all the custom kprobe section
> > declarations from the linker script.
> > 
> > Tested with CONFIG_KPROBES_SANITY_TEST, it passes with:
> > 
> > Kprobe smoke test: started
> > Kprobe smoke test: passed successfully
> > 
> > Then tested CONFIG_SAMPLE_KPROBES on do_fork, and the kprobe bites
> > and kicks as expected.
> > 
> > Also ran ./ftracetest with no issues:
> > 
> > $ sudo ./ftracetest
> > === Ftrace unit tests ===
> > [1] Basic trace file check  [PASS]
> > [2] Basic test for tracers  [PASS]
> > [3] Basic trace clock test  [PASS]
> > [4] Basic event tracing check   [PASS]
> > [5] event tracing - enable/disable with event level files   [PASS]
> > [6] event tracing - restricts events based on pid   [PASS]
> > [7] event tracing - enable/disable with subsystem level files   [PASS]
> > [8] event tracing - enable/disable with top level files [PASS]
> > [9] ftrace - function graph filters with stack tracer   [PASS]
> > [10] ftrace - function graph filters[PASS]
> > [11] ftrace - function profiler with function tracing   [PASS]
> > [12] Test creation and deletion of trace instances while setting an 
> > event[PASS]
> > [13] Test creation and deletion of trace instances  [PASS]
> > [14] Kprobe dynamic event - adding and removing [PASS]
> > [15] Kprobe dynamic event - busy event check[PASS]
> > [16] Kprobe dynamic event with arguments[PASS]
> > [17] Kprobe dynamic event with function tracer  [PASS]
> > [18] Kretprobe dynamic event with arguments [PASS]
> > [19] event trigger - test event enable/disable trigger  [PASS]
> > [20] event trigger - test trigger filter[PASS]
> > [21] event trigger - test histogram modifiers   [PASS]
> > [22] event trigger - test histogram trigger [PASS]
> > [23] event trigger - test multiple histogram triggers   [PASS]
> > [24] event trigger - test snapshot-trigger  [PASS]
> > [25] event trigger - test stacktrace-trigger[PASS]
> > [26] event trigger - test traceon/off trigger   [PASS]
> > 
> >  # of passed:  26
> >  # of failed:  0
> >  # of unresolved:  0
> >  # of untested:  0
> >  # of unsupported:  0
> >  # of xfailed:  0
> >  # of undefined(test bug):  0
> 
> Looks good to me except for the modpost part.

OK thanks!

> > diff --git a/scripts/Makefile b/scripts/Makefile
> > index 1d80897a9644..77a0cc91628c 100644
> > --- a/scripts/Makefile
> > +++ b/scripts/Makefile
> > @@ -10,6 +10,7 @@
> >  # check-lc_ctype: Used in Documentation/DocBook
> >  
> >  HOST_EXTRACFLAGS += -I$(srctree)/tools/include
> > +HOST_EXTRACFLAGS += -U__KERNEL__
> 
> This looks a add-hoc hack. If we just need SECTION_RNG(SECTION_TEXT, kprobes)
> to convert to section name, can we export the definitions outside of _KERNEL_ 
> ?

We can, it was just a matter of deciding if we were OK with open coding the
section, copying over some defines, or sharing somehow (this was one way) the
header files.

Josh seems to prefer to open coding out the names on the tools we can certanly
do that here as well, I think his point that the names should/will likely
never change is sufficient motivation to avoid all this and prefer open coding
this.

Will do that in the next spin unless I hear otherwise.

  Luis

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

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

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 xen  c5eae7332909e3ef1a18e0164e9e4e512edf9ef3
baseline version:
 xen  d5438accceecc8172db2d37d98b695eb8bc43afc

Last test of basis99707  2016-07-26 10:01:43 Z1 days
Failing since 99722  2016-07-27 18:01:50 Z0 days2 attempts
Testing same since99729  2016-07-27 20:41:23 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Juergen Gross 
  Julien Grall 
  Shanker Donthineni 
  Stefano Stabellini 
  Tamas K Lengyel 
  Wei Liu 

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



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] [PATCH 11/22] xen/arm: p2m: Find the memory attributes based on the p2m type

[Julien Grall]

On 27/07/2016 18:55, Stefano Stabellini wrote:

On Wed, 27 Jul 2016, Julien Grall wrote:

Hi,

On 20/07/16 17:10, Julien Grall wrote:

Currently, mfn_to_p2m_entry is relying on the caller to provide the
correct memory attribute and will deduce the sharability based on it.

Some of the callers, such as p2m_create_table, are using same memory
attribute regardless the underlying p2m type. For instance, this will
lead to use change the memory attribute from MATTR_DEV to MATTR_MEM when
a MMIO superpage is shattered.

Furthermore, it makes more difficult to support different shareability
with the same memory attribute.

All the memory attributes could be deduced via the p2m type. This will
simplify the code by dropping one parameter.


I just noticed that I forgot to add my Signed-off-by. Stefano, can you add my
Signed-off-by while committing?


I could, but given that you need to resend some of the patches anyway,
it might be easier for me to wait for the next version.


I will resend the series tomorrow morning. Thank you for the review!

Cheers,





---
I am not sure whether p2m_direct_mmio_c (cacheable MMIO) should use
the outer-shareability or inner-shareability. Any opinions?
---
 xen/arch/arm/p2m.c | 55
--
 1 file changed, 24 insertions(+), 31 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 999de2b..2f50b4f 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -325,8 +325,7 @@ static void p2m_set_permission(lpae_t *e, p2m_type_t t,
p2m_access_t a)
 }
 }

-static lpae_t mfn_to_p2m_entry(mfn_t mfn, unsigned int mattr,
-   p2m_type_t t, p2m_access_t a)
+static lpae_t mfn_to_p2m_entry(mfn_t mfn, p2m_type_t t, p2m_access_t a)
 {
 /*
  * sh, xn and write bit will be defined in the following switches
@@ -335,7 +334,6 @@ static lpae_t mfn_to_p2m_entry(mfn_t mfn, unsigned int
mattr,
 lpae_t e = (lpae_t) {
 .p2m.af = 1,
 .p2m.read = 1,
-.p2m.mattr = mattr,
 .p2m.table = 1,
 .p2m.valid = 1,
 .p2m.type = t,
@@ -343,18 +341,21 @@ static lpae_t mfn_to_p2m_entry(mfn_t mfn, unsigned int
mattr,

 BUILD_BUG_ON(p2m_max_real_type > (1 << 4));

-switch (mattr)
+switch ( t )
 {
-case MATTR_MEM:
-e.p2m.sh = LPAE_SH_INNER;
+case p2m_mmio_direct_nc:
+e.p2m.mattr = MATTR_DEV;
+e.p2m.sh = LPAE_SH_OUTER;
 break;

-case MATTR_DEV:
+case p2m_mmio_direct_c:
+e.p2m.mattr = MATTR_MEM;
 e.p2m.sh = LPAE_SH_OUTER;
 break;
+
 default:
-BUG();
-break;
+e.p2m.mattr = MATTR_MEM;
+e.p2m.sh = LPAE_SH_INNER;
 }

 p2m_set_permission(, t, a);
@@ -421,7 +422,7 @@ static int p2m_create_table(struct domain *d, lpae_t
*entry,
  */
  for ( i=0 ; i < LPAE_ENTRIES; i++ )
  {
- pte = mfn_to_p2m_entry(mfn, MATTR_MEM, t,
p2m->default_access);
+ pte = mfn_to_p2m_entry(mfn, t, p2m->default_access);

  mfn = mfn_add(mfn, 1UL << (level_shift - LPAE_SHIFT));

@@ -445,7 +446,7 @@ static int p2m_create_table(struct domain *d, lpae_t
*entry,

 unmap_domain_page(p);

-pte = mfn_to_p2m_entry(_mfn(page_to_mfn(page)), MATTR_MEM, p2m_invalid,
+pte = mfn_to_p2m_entry(_mfn(page_to_mfn(page)), p2m_invalid,
p2m->default_access);

 p2m_write_pte(entry, pte, flush_cache);
@@ -666,7 +667,6 @@ static int apply_one_level(struct domain *d,
paddr_t *addr,
paddr_t *maddr,
bool_t *flush,
-   int mattr,
p2m_type_t t,
p2m_access_t a)
 {
@@ -695,7 +695,7 @@ static int apply_one_level(struct domain *d,
 return rc;

 /* New mapping is superpage aligned, make it */
-pte = mfn_to_p2m_entry(_mfn(*maddr >> PAGE_SHIFT), mattr, t,
a);
+pte = mfn_to_p2m_entry(_mfn(*maddr >> PAGE_SHIFT), t, a);
 if ( level < 3 )
 pte.p2m.table = 0; /* Superpage entry */

@@ -915,7 +915,6 @@ static int apply_p2m_changes(struct domain *d,
  gfn_t sgfn,
  unsigned long nr,
  mfn_t smfn,
- int mattr,
  uint32_t mask,
  p2m_type_t t,
  p2m_access_t a)
@@ -1054,7 +1053,7 @@ static int apply_p2m_changes(struct domain *d,
   level, flush_pt, op,
   start_gpaddr, end_gpaddr,
   , , ,
-  mattr, t, a);
+  t, a);
 if ( ret < 0 ) { rc = ret ; goto out; }
 count += ret;

@@ -1163,7 +1162,7 @@ out:
  * mapping.
  */
 

Re: [Xen-devel] [PATCH 06/22] xen/arm: p2m: Use the typesafe MFN in mfn_to_p2m_entry

[Julien Grall]

Hi Stefano,

On 27/07/2016 19:25, Stefano Stabellini wrote:

On Wed, 27 Jul 2016, Julien Grall wrote:

Hi Stefano,

On 26/07/16 23:28, Stefano Stabellini wrote:

On Wed, 20 Jul 2016, Julien Grall wrote:

@@ -411,7 +411,7 @@ static int p2m_create_table(struct domain *d, lpae_t
*entry,
 if ( splitting )
 {
 p2m_type_t t = entry->p2m.type;
-unsigned long base_pfn = entry->p2m.base;
+mfn_t mfn = _mfn(entry->p2m.base);
 int i;

 /*
@@ -420,8 +420,9 @@ static int p2m_create_table(struct domain *d, lpae_t
*entry,
  */
  for ( i=0 ; i < LPAE_ENTRIES; i++ )
  {
- pte = mfn_to_p2m_entry(base_pfn +
(i<<(level_shift-LPAE_SHIFT)),
-MATTR_MEM, t, p2m->default_access);
+ pte = mfn_to_p2m_entry(mfn, MATTR_MEM, t,
p2m->default_access);
+
+ mfn = mfn_add(mfn, 1UL << (level_shift - LPAE_SHIFT));


Should we be incrementing mfn before calling mfn_to_p2m_entry?


No. The base of the superpage is mfn, after splitting the first entry will be
equal to the base, the second entry base + level_size...


I understand what the patch is doing now, I confused "1" with "i" :-)
The patch is OK. It might be more obvious as the following:


  for ( i=0 ; i < LPAE_ENTRIES; i++ )
  {
 pte = mfn_to_p2m_entry(mfn_add(mfn, (i<<(level_shift-LPAE_SHIFT))),
MATTR_MEM, t, p2m->default_access);


However it's just a matter of taste, so I'll let you choose the way you
prefer.


I wanted to avoid shifting "i" at each loop (which should save an 
instruction). However, as it seems to be confusing, I will use your 
suggestion.




Reviewed-by: Stefano Stabellini 


Thank you!

Cheers,

--
Julien Grall

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

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

[Andrew Cooper]

On 27/07/2016 20:51, osstest service owner wrote:
> flight 99722 xen-unstable-smoke real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/99722/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-qemuu-debianhvm-i386 12 guest-saverestore fail REGR. vs. 
> 99707

This is :

*** Error in `xl': double free or corruption (fasttop): 0x0108e560 ***

from the commit range:

* 7179cd3 - xen/domctl: Add DOMINFO_hap to xen_domctl_getdomaininfo (5
hours ago) 
* d2412fd - libxl: move common nic stuff into one source (8 hours ago)

* 9f3fbaf - libxl: add config update callback to device type framework
(8 hours ago) 
* 20609ad - libxl: split libxl vtpm code into one source (8 hours ago)

* 803d4d3 - libxl: move library pvusb specific code into libxl_pvusb.c
(8 hours ago) 
* e320815 - libxl: add "pv device mode needed" support to device type
framework (8 hours ago) 
* de0b58c - libxl: add "merge" function to generic device type support
(8 hours ago) 
* 6539480 - altp2m: Allow shared entries to be copied to altp2m views
during lazycopy (10 hours ago) 
* a97bedb - xen/arm: p2m: Simplify p2m type check by using bitmask (21
hours ago) 
* 8cfe8bc - xen/arm: p2m: Use p2m_is_foreign in get_page_from_gfn to
avoid open coding (21 hours ago) 
* 4b11387 - xen/arm: p2m: Clean-up mfn_to_p2m_entry (21 hours ago)

* 96d1be3 - arm/vgic: Change fixed number of mmio handlers to variable
number (22 hours ago) 
* 8047e09 - xen/arm: io: Use binary search for mmio handler lookup (22
hours ago) 
* e3eb84e - xen: Add generic implementation of binary search (22 hours
ago) 
* 96a1eee - arm/io: Use separate memory allocation for mmio handlers (22
hours ago) 
* 9f14414 - x86/entry: Avoid SMAP violation in
compat_create_bounce_frame() (31 hours ago) 
* e1bff4c - x86/pv: Remove unsafe bits from the mod_l?_entry() fastpath
(31 hours ago) 

Sorry Juergen, but your libxl series looks like the only plausible
candidate.

The XenServer Coverity instance will get around to looking at this code
presently, and might spot something, but I don't have any results yet.

~Andrew

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

[Xen-devel] [PATCH] libxl: compilation warning fix for arm & aarch64

[Chris Patterson]

From: Chris Patterson 

GCC 6 will warn on unused static const variables in c modules:
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00847.html

When compiling with LIBXL_HAVE_NO_SUSPEND_RESUME set (arm & aarch64),
the compiler emits the following errors:
  xl_cmdimpl.c:101:19: error: 'migrate_report'
  defined but not used [-Werror=unused-const-variable=]
  xl_cmdimpl.c:99:19: error: 'migrate_permission_to_go'
  defined but not used [-Werror=unused-const-variable=]
  xl_cmdimpl.c:97:19: error: 'migrate_receiver_ready'
  defined but not used [-Werror=unused-const-variable=]
  xl_cmdimpl.c:95:19: error: 'migrate_receiver_banner'
  defined but not used [-Werror=unused-const-variable=]

These unused const variables are only used in functions which exist between
the ifndef block:
   #ifndef LIBXL_HAVE_NO_SUSPEND_RESUME
   ...
   #endif

Wrap the same ifndef around these variables.

Signed-off-by: Chris Patterson 
---
 tools/libxl/xl_cmdimpl.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index d1fcfa4..ada8178 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -92,6 +92,7 @@ static int fd_lock = -1;
 static const char savefileheader_magic[32]=
 "Xen saved domain, xl format\n \0 \r";
 
+#ifndef LIBXL_HAVE_NO_SUSPEND_RESUME
 static const char migrate_receiver_banner[]=
 "xl migration receiver ready, send binary domain data.\n";
 static const char migrate_receiver_ready[]=
@@ -100,6 +101,8 @@ static const char migrate_permission_to_go[]=
 "domain is yours, you are cleared to unpause";
 static const char migrate_report[]=
 "my copy unpause results are as follows";
+#endif
+
   /* followed by one byte:
* 0: everything went well, domain is running
*next thing is we all exit
-- 
2.1.4


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

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

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 xen  7179cd39efdb22ac847ae465d1aa11cd6263f19b
baseline version:
 xen  d5438accceecc8172db2d37d98b695eb8bc43afc

Last test of basis99707  2016-07-26 10:01:43 Z1 days
Testing same since99722  2016-07-27 18:01:50 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Juergen Gross 
  Julien Grall 
  Shanker Donthineni 
  Stefano Stabellini 
  Tamas K Lengyel 
  Wei Liu 

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



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

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

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

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


Not pushing.


commit 7179cd39efdb22ac847ae465d1aa11cd6263f19b
Author: Andrew Cooper 
Date:   Fri Jul 15 16:43:48 2016 +0100

xen/domctl: Add DOMINFO_hap to xen_domctl_getdomaininfo

This allows a toolstack to identify whether a running domain is using 
hardware
assisted paging or not.

The appropriate tests differ by architecture, so introduce
arch_get_domain_info().  ARM unconditionally sets the new flag, while x86
checks with the paging subsystem first.

Signed-off-by: Andrew Cooper 
Acked-by: Wei Liu 
Reviewed-by: Julien Grall 
Reviewed-by: George Dunlap 

commit d2412fd63b14c6c21d0a3d4367afa448425dfb8a
Author: Juergen Gross 
Date:   Tue Jul 12 17:30:44 2016 +0200

libxl: move common nic stuff into one source

Put all nic related stuff of libxl form common files into a dedicated
source file.

Signed-off-by: Juergen Gross 
Acked-by: Wei Liu 

commit 9f3fbaff6cccdab9122e8c987fa5694f0930d7f4
Author: Juergen Gross 
Date:   Tue Jul 12 17:30:43 2016 +0200

libxl: add config update callback to device type framework

Some device types require a configuration update after resume of
domain. Add a callback for this purpose.

Signed-off-by: Juergen Gross 
Acked-by: Wei Liu 

commit 20609ad8ee914c6e040bd64dac11e61aa5186ceb
Author: Juergen Gross 
Date:   Tue Jul 12 17:30:42 2016 +0200

libxl: split libxl vtpm code into one source

Put all vtpm related stuff of libxl into a dedicated source file.

Signed-off-by: Juergen Gross 
Acked-by: Wei Liu 

commit 803d4d332243fc2aa87c63a0ed871197252d23d1
Author: Juergen Gross 
Date:   Tue Jul 12 17:30:41 2016 +0200

libxl: move library pvusb specific code into libxl_pvusb.c

Outside libxl_pvusb.c only libxl_util.c still contains some pvusb code.

Move it to libxl_pvusb.c.

Signed-off-by: Juergen Gross 
Acked-by: Wei Liu 

commit e320815ea5a4ba538210d91c8527b9eabeb15333
Author: Juergen Gross 
Date:   Tue Jul 12 17:30:40 2016 +0200

libxl: add "pv device mode needed" support to device type framework

Add another callback to the device type framework in order to aid
decision whether a pv domain needs a device model.

Signed-off-by: 

Re: [Xen-devel] OVMF very slow on AMD

[Boris Ostrovsky]

On 07/27/2016 07:35 AM, Anthony PERARD wrote:
> On Wed, Jul 27, 2016 at 12:08:04PM +0100, Anthony PERARD wrote:
>> I can try to describe how OVMF is setting up the memory.
> From the start of the day:
> setup gdt
> cr0 = 0x4023

I think this is slightly odd, with bit 30 (cache disable) set. I'd
suspect that this would affect both Intel and AMD though.

Can you try clearing this bit?

-boris

>
> jump to 32bit
> cr4 = 0x640
>
> setup page tables:
> page directory attributes: (PAGE_ACCESSED + PAGE_READ_WRITE + PAGE_PRESENT)
> page tables attributes: (PAGE_2M_MBO + PAGE_ACCESSED + PAGE_DIRTY + 
> PAGE_READ_WRITE + PAGE_PRESENT)
> I think they map the all 4GB with 2MB pages.
> set cr3.
>
> enable PAE
> set LME
> set PG
>
> jump to 64bit
>
> I think that's it, before running this painfully slow decompression
> function.
>
> Is there something wrong, or maybe missing? Is the hypervisor or maybe
> the hardware does not do the right thing?
>
> Thanks,
>



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

Re: [Xen-devel] [PATCH v3 0/9] xen/arm: Support SPIs routing

[Stefano Stabellini]

Committed, thank you.

On Wed, 27 Jul 2016, Julien Grall wrote:
> Hello all,
> 
> Currently, Xen does not route SPIs to DOM0 when ACPI is inuse after
> the functionality has been reverted in Xen 4.7 by commit 909bd14.
> 
> In the previous approach, the SPIs was routed when DOM0 was writing into
> ISENABLER. However, this has resulted to deadlock (see more details in [1])
> as soon as the IRQ was enabled by DOM0.
> 
> We have multiple solutions to route the IRQ:
> 1) Rework route_irq_to_guest to avoid the deadlock
> 2) Route and enable the IRQ outside of the emulation of ISENABLER
> 3) Remove the dependency on the IRQ type in the routing function
> and route all the unused IRQs during domain building
> 4) Add a new hypercall to let DOM0 routing the IRQ
> 
> I think that 1) and 2) are not resilient because route_irq_to_guest may fail
> and there is no way to report this error to the guest (except by killing it).
> 
> Furthermore, in solution 2) enabling the interrupt would need to be defer
> until the routing has been done. This would require a lot of code duplication.
> 
> Which leave solution 3) and 4). The solution 4) requires to introduce a new
> (or re-use one) stable hypercall. I am not sure why we ruled out this
> solution when we reviewed the ACPI design document.
> 
> This patch series is implementing the 3rd solution which defer the IRQ
> type configuration for DOM0 IRQ when ACPI is inuse. However, this will
> slightly increase the memory usage of Xen (54KB).
> 
> I am happy to consider any other solutions.
> 
> This series has been tested with ACPI by Shanker on QDF2 server and
> I tested it on Juno r2 with DT.
> 
> A branch with all the patches can be found here:
> 
> git://xenbits.xen.org/people/julieng/xen-unstable.git branch 
> irq-routing-acpi-v3
> 
> All the patches but #7 have been reviewed/acked by Stefano.
> 
> Yours sincerely,
> 
> [1] http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg02633.html
> 
> Julien Grall (9):
>   xen/arm: gic: Consolidate the IRQ affinity set in a single place
>   xen/arm: gic: Do not configure affinity during routing
>   xen/arm: gic: split set_irq_properties
>   xen/arm: gic: set_type: Pass the type in parameter rather than in
> desc->arch.type
>   xen/arm: gic: Document how gic_set_irq_type should be called
>   Revert "xen/arm: warn the user that we cannot route SPIs to Dom0 on
> ACPI"
>   xen/arm: Allow DOM0 to set the IRQ type
>   xen/arm: acpi: route all unused IRQs to DOM0
>   xen/arm: Fix coding style and update comment in acpi_route_spis
> 
>  xen/arch/arm/domain_build.c | 33 +++--
>  xen/arch/arm/gic-v2.c   | 28 +---
>  xen/arch/arm/gic-v3.c   | 22 ++
>  xen/arch/arm/gic.c  | 36 ++--
>  xen/arch/arm/irq.c  | 17 ++---
>  xen/arch/arm/vgic.c | 37 +++--
>  xen/include/asm-arm/gic.h   | 14 --
>  xen/include/asm-arm/irq.h   |  6 ++
>  8 files changed, 111 insertions(+), 82 deletions(-)
> 
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH v3 7/9] xen/arm: Allow DOM0 to set the IRQ type

[Stefano Stabellini]

On Wed, 27 Jul 2016, Julien Grall wrote:
> The function route_irq_to_guest mandates the IRQ type, stored in
> desc->arch.type, to be valid. However, in case of ACPI, these
> information is not part of the static tables. Therefore Xen needs to
> rely on DOM0 to provide a valid type based on the firmware tables.
> 
> A new helper, irq_type_set_by_domain is provided to check whether a
> domain is allowed to set the IRQ type. For now, only DOM0 is allowed to
> configure.
> 
> When the helper returns 1, the routing function will not check whether
> the IRQ type is correctly set and configure the GIC. Instead, this will
> be done when the domain will enable the interrupt.
> 
> Note that irq_set_spi_type is not called because it validates the type
> and does not allow it the domain to change the type after the first
> write. It means that desc->arch.type may never be set, which is fine
> because the field is only used to configure the type during the routing.
> 
> Based on 4.3.13 in ARM IHI 0048B.b, changing the value of Int_config is
> UNPREDICTABLE when the corresponding interrupt is not disabled.
> 
> Therefore, setting the IRQ type when the guest is writing into ICFGR
> would require more work to make sure the IRQ has been disabled before
> writing into the host ICFGR. As the behavior is UNPREDICTABLE, the type
> will be set before enabling the physical IRQ associated to the virtual IRQ.
> 
> Signed-off-by: Julien Grall 
> Tested-by: Shanker Donthineni 

Reviewed-by: Stefano Stabellini 


> ---
> 
> It might be possible to let any domain configure the IRQ
> type (could be useful when passthrough an IRQ with ACPI). However, we would
> need to consider any potential security impact beforehand.
> 
> Changes in v3:
> - The current code only handle SPIs, add an assert to catch any
> support PPIs without modifying this code.
> - Tested by Shanker on QDF2XXX server
> 
> Changes in v2:
> - Rename the patch
> - Allow any DOM0 to set the IRQ type
> - Re-use in part of vgic_get_virq_type from
> "Configure SPI interrupt type and route to Dom0 dynamically".
> - Add rationale why the IRQ type is set in enable
> ---
>  xen/arch/arm/gic.c|  5 +++--
>  xen/arch/arm/irq.c| 13 -
>  xen/arch/arm/vgic.c   | 24 
>  xen/include/asm-arm/gic.h |  3 +++
>  xen/include/asm-arm/irq.h |  6 ++
>  5 files changed, 48 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 72bb885..63c744a 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -97,7 +97,7 @@ void gic_restore_state(struct vcpu *v)
>  }
>  
>  /* desc->irq needs to be disabled before calling this function */
> -static void gic_set_irq_type(struct irq_desc *desc, unsigned int type)
> +void gic_set_irq_type(struct irq_desc *desc, unsigned int type)
>  {
>  /*
>   * IRQ must be disabled before configuring it (see 4.3.13 in ARM IHI
> @@ -160,7 +160,8 @@ int gic_route_irq_to_guest(struct domain *d, unsigned int 
> virq,
>  desc->handler = gic_hw_ops->gic_guest_irq_type;
>  set_bit(_IRQ_GUEST, >status);
>  
> -gic_set_irq_type(desc, desc->arch.type);
> +if ( !irq_type_set_by_domain(d) )
> +gic_set_irq_type(desc, desc->arch.type);
>  gic_set_irq_priority(desc, priority);
>  
>  p->desc = desc;
> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> index 3fc22f2..06d4843 100644
> --- a/xen/arch/arm/irq.c
> +++ b/xen/arch/arm/irq.c
> @@ -395,6 +395,17 @@ bool_t is_assignable_irq(unsigned int irq)
>  }
>  
>  /*
> + * Only the hardware domain is allowed to set the configure the
> + * interrupt type for now.
> + *
> + * XXX: See whether it is possible to let any domain configure the type.
> + */
> +bool_t irq_type_set_by_domain(const struct domain *d)
> +{
> +return (d == hardware_domain);
> +}
> +
> +/*
>   * Route an IRQ to a specific guest.
>   * For now only SPIs are assignable to the guest.
>   */
> @@ -449,7 +460,7 @@ int route_irq_to_guest(struct domain *d, unsigned int 
> virq,
>  
>  spin_lock_irqsave(>lock, flags);
>  
> -if ( desc->arch.type == IRQ_TYPE_INVALID )
> +if ( !irq_type_set_by_domain(d) && desc->arch.type == IRQ_TYPE_INVALID )
>  {
>  printk(XENLOG_G_ERR "IRQ %u has not been configured\n", irq);
>  retval = -EIO;
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 938bc7d..0965119 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -340,6 +340,22 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r, int n)
>  }
>  }
>  
> +#define VGIC_ICFG_MASK(intr) (1 << ((2 * ((intr) % 16)) + 1))
> +
> +/* The function should be called with the rank lock taken */
> +static inline unsigned int vgic_get_virq_type(struct vcpu *v, int n, int 
> index)
> +{
> +struct vgic_irq_rank *r = vgic_get_rank(v, n);
> +

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

[Andrew Cooper]

On 27/07/16 19:42, Linus Torvalds wrote:
> On Wed, Jul 27, 2016 at 6:45 AM, David Vrabel  wrote:
>> Shannon Zhao (16):
>>   Xen: ACPI: Hide UART used by Xen
> So this caused a trivial conflict. No biggie, it wasn't bad and the
> patch was acked by Rafael. However, looking at it made me somewhat
> unhappy.
>
> Should the device entry in ACPI really be hidden unconditionally? In
> particular, if we are *not* running under virtualization, it sounds
> wrong to hide it.
>
> Comments? Am I missing something?

The purpose of the ACPI STAO table (Status Override table, ratified in
ACPI 6.0) is to list items elsewhere in the ACPI namespace which should
be completely ignored.  It is used in cases where it is impossible or
prohibitive to edit the system AML.

The patch itself only hides the UART if instructed to do so by the STAO
table (last hunk).

~Andrew

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

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

[Linus Torvalds]

On Wed, Jul 27, 2016 at 6:45 AM, David Vrabel  wrote:
>
> Shannon Zhao (16):
>   Xen: ACPI: Hide UART used by Xen

So this caused a trivial conflict. No biggie, it wasn't bad and the
patch was acked by Rafael. However, looking at it made me somewhat
unhappy.

Should the device entry in ACPI really be hidden unconditionally? In
particular, if we are *not* running under virtualization, it sounds
wrong to hide it.

Comments? Am I missing something?

   Linus

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

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

On Wed, Jul 27, 2016, at 11:28 AM, Andrew Cooper wrote:
> > I'm not sure if that's good enough.
> 
> Sadly not.  The debug symbols need to be specific to the exact binary
> you booted.
> 
> Any change in the compilation will result in the translation being
> useless.  What addr2line is doing is saying "which specific bit of
> source code did the compiler/linker end up putting at $X".

Got it.  Weird that they don't put the .debuginfo rpms in there.  While I was 
searching around kernel bug reports over at the distro there's lots of posts 
telling people to debug.  Not sure then how you do it without the debug symbols.

Guess you have to build your own kernel.

That's one of the things I'm thinking of doing , along with Xen, eventually so 
I don't have to waste days hoping packages get fixed when someone helps out 
with a suggestion to try, like you did.  But I never got the "build it all 
yourself" working when I tried awhile ago.  

> I wouldn't worry too much - I expect (the lack of) the aforementioned
> changeset is the cause of your issues.

Ok we'll wait and see if there's an update to try, I guess.

Thanks.

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

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[Juergen Gross]

On 27/07/16 18:56, Andrew Cooper wrote:
> On 27/07/16 17:54, li...@ssl-mail.com wrote:
>>
>> On Wed, Jul 27, 2016, at 09:34 AM, Andrew Cooper wrote:
>>> This looks suspiciously like the issue which was fixed by c/s
>>> d6b186c1e2d852a92c43f090d0d8fad4704d51ef "x86/xen: avoid m2p lookup when
>>> setting early page table entries", but that fix is present in Linux 4.7.0
>>>
>>> Can you check to see whether the commit is included in your kernel?
>> This
>>
>>  
>> https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.git/+/d6b186c1e2d852a92c43f090d0d8fad4704d51ef
>>
>> looks like the Suse team was involved,
>>
>>   Reviewed-by: Juergen Gross 
>>
>> But checking this kernel
>>
>>  rpm -q kernel-source
>>   kernel-source-4.7.0-4.1.g89a2ada.noarch
>>  rpm -q --changelog kernel-source | egrep -i "m2p|d6b186c1"
>>   - guarantee M2P to be invisible to user mode.
>>
>> it doesn't look like it's in here.
> 
> Juergen: Any ideas?

I'm rather sure it is a different problem for the following reasons:

- The failed virtual address is wrong. It is for sure no address
  related to the m2p table.

- The kernel booted a little bit further up here. So we have already
  passed the critical section where the faulty m2p lookup occurred.


Juergen

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

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[Andrew Cooper]

On 27/07/16 19:22, li...@ssl-mail.com wrote:
>
> On Wed, Jul 27, 2016, at 09:56 AM, Andrew Cooper wrote:
 Failing that, can you find out exactly where the kernel crashed?  You
 need to manually decode 81f6374c with the debug symbols.
>>> Sure can try.  I'm gonna have to read-up on how .  Atm no clue.
>> addr2line -e /path/to/linux/debug/symbols 81f6374c
> Thanks.
>
> For whatever reason it the dev debug symbols aren't available for the 
> official Kernel:Stable branch,
>
>   
> http://software.opensuse.org/package/kernel-default-debuginfo?search_term=kernel-default-debuginfo
>
> unlike for the release 4.1.x kernel.
>
> But there is this from an unofficial repo
>
>   
> https://build.opensuse.org/package/binaries/hardware:nvdimm/kernel-default?repository=openSUSE_Leap_42.1
>
> I'm not sure if that's good enough.

Sadly not.  The debug symbols need to be specific to the exact binary
you booted.

Any change in the compilation will result in the translation being
useless.  What addr2line is doing is saying "which specific bit of
source code did the compiler/linker end up putting at $X".

I wouldn't worry too much - I expect (the lack of) the aforementioned
changeset is the cause of your issues.

~Andrew

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

Re: [Xen-devel] [PATCH 06/22] xen/arm: p2m: Use the typesafe MFN in mfn_to_p2m_entry

[Stefano Stabellini]

On Wed, 27 Jul 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 26/07/16 23:28, Stefano Stabellini wrote:
> > On Wed, 20 Jul 2016, Julien Grall wrote:
> > > @@ -411,7 +411,7 @@ static int p2m_create_table(struct domain *d, lpae_t
> > > *entry,
> > >  if ( splitting )
> > >  {
> > >  p2m_type_t t = entry->p2m.type;
> > > -unsigned long base_pfn = entry->p2m.base;
> > > +mfn_t mfn = _mfn(entry->p2m.base);
> > >  int i;
> > > 
> > >  /*
> > > @@ -420,8 +420,9 @@ static int p2m_create_table(struct domain *d, lpae_t
> > > *entry,
> > >   */
> > >   for ( i=0 ; i < LPAE_ENTRIES; i++ )
> > >   {
> > > - pte = mfn_to_p2m_entry(base_pfn +
> > > (i<<(level_shift-LPAE_SHIFT)),
> > > -MATTR_MEM, t, p2m->default_access);
> > > + pte = mfn_to_p2m_entry(mfn, MATTR_MEM, t,
> > > p2m->default_access);
> > > +
> > > + mfn = mfn_add(mfn, 1UL << (level_shift - LPAE_SHIFT));
> > 
> > Should we be incrementing mfn before calling mfn_to_p2m_entry?
> 
> No. The base of the superpage is mfn, after splitting the first entry will be
> equal to the base, the second entry base + level_size...

I understand what the patch is doing now, I confused "1" with "i" :-)
The patch is OK. It might be more obvious as the following:


  for ( i=0 ; i < LPAE_ENTRIES; i++ )
  {
 pte = mfn_to_p2m_entry(mfn_add(mfn, (i<<(level_shift-LPAE_SHIFT))),
MATTR_MEM, t, p2m->default_access);


However it's just a matter of taste, so I'll let you choose the way you
prefer.

Reviewed-by: Stefano Stabellini 

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

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

On Wed, Jul 27, 2016, at 09:56 AM, Andrew Cooper wrote:
> >> Failing that, can you find out exactly where the kernel crashed?  You
> >> need to manually decode 81f6374c with the debug symbols.
> > Sure can try.  I'm gonna have to read-up on how .  Atm no clue.
> 
> addr2line -e /path/to/linux/debug/symbols 81f6374c

Thanks.

For whatever reason it the dev debug symbols aren't available for the official 
Kernel:Stable branch,


http://software.opensuse.org/package/kernel-default-debuginfo?search_term=kernel-default-debuginfo

unlike for the release 4.1.x kernel.

But there is this from an unofficial repo


https://build.opensuse.org/package/binaries/hardware:nvdimm/kernel-default?repository=openSUSE_Leap_42.1

I'm not sure if that's good enough.  Anyway if I directly install that one


http://download.opensuse.org/repositories/hardware:/nvdimm/openSUSE_Leap_42.1/x86_64/kernel-default-debuginfo-4.7.0-5.1.x86_64.rpm

Then

rpm -ql kernel-default-debuginfo | grep linux
/usr/lib/debug/boot/vmlinux-4.7.0-5-default.debug

addr2line -e /usr/lib/debug/boot/vmlinux-4.7.0-5-default.debug 
81f6374c

/usr/src/debug/kernel-default-4.7.0/linux-4.7/linux-obj/../arch/x86/mm/numa_emulation.c:444

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

[Xen-devel] [PATCH 1/2] x86/mm: Avoid NULL dereference when checking altp2m's for shareability

[Andrew Cooper]

Coverity identifies that __get_gfn_type_access() unconditionally writes to its
type parameter under a number of circumstances.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Tim Deegan 
CC: George Dunlap 
CC: Tamas K Lengyel 

There is a second complaint that ap2ma and p2ma are used before initialisation
in the following line, although that is harder to reason about.  I think the
code is OK...
---
 xen/arch/x86/mm/mem_sharing.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 47e0820..14952ce 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -870,6 +870,7 @@ int mem_sharing_nominate_page(struct domain *d,
 unsigned int i;
 struct p2m_domain *ap2m;
 mfn_t amfn;
+p2m_type_t ap2mt;
 p2m_access_t ap2ma;
 
 altp2m_list_lock(d);
@@ -880,7 +881,7 @@ int mem_sharing_nominate_page(struct domain *d,
 if ( !ap2m )
 continue;
 
-amfn = get_gfn_type_access(ap2m, gfn, NULL, , 0, NULL);
+amfn = get_gfn_type_access(ap2m, gfn, , , 0, NULL);
 if ( mfn_valid(amfn) && (mfn_x(amfn) != mfn_x(mfn) || ap2ma != 
p2ma) )
 {
 altp2m_list_unlock(d);
-- 
2.1.4


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

[Xen-devel] [PATCH 2/2] x86/mm: Annotate gfn_get_* helpers as requiring non-NULL parameters

[Andrew Cooper]

Introduce and use the nonnull attribute to help the compiler catch NULL
parameters being passed to function which require their parameters not to be
NULL.  Experimentally, GCC 4.9 on Debian Jessie only warns of non-NULL-ness
from immediate callers, so propagate the attributes out to all helpers.

A sample error looks like:

mem_sharing.c: In function ‘mem_sharing_nominate_page’:
mem_sharing.c:884:13: error: null argument where non-null required (argument 3) 
[-Werror=nonnull]
 amfn = get_gfn_type_access(ap2m, gfn, NULL, , 0, NULL);
 ^

As part of this, replace the get_gfn_type_access() macro with an equivalent
static inline function for extra type safety, and the ability to be annotated.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Tim Deegan 
CC: George Dunlap 
CC: Tamas K Lengyel 
---
 xen/include/asm-x86/p2m.h  | 19 +++
 xen/include/xen/compiler.h |  2 ++
 2 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 194020e..e35d59c 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -380,9 +380,9 @@ void p2m_unlock_and_tlb_flush(struct p2m_domain *p2m);
  * After calling any of the variants below, caller needs to use
  * put_gfn. /
 
-mfn_t __get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn,
-p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
-unsigned int *page_order, bool_t locked);
+mfn_t __nonnull(1, 3, 4) __get_gfn_type_access(
+struct p2m_domain *p2m, unsigned long gfn, p2m_type_t *t,
+p2m_access_t *a, p2m_query_t q, unsigned int *page_order, bool_t locked);
 
 /* Read a particular P2M table, mapping pages as we go.  Most callers
  * should _not_ call this directly; use the other get_gfn* functions
@@ -391,13 +391,16 @@ mfn_t __get_gfn_type_access(struct p2m_domain *p2m, 
unsigned long gfn,
  * If the lookup succeeds, the return value is != INVALID_MFN and 
  * *page_order is filled in with the order of the superpage (if any) that
  * the entry was found in.  */
-#define get_gfn_type_access(p, g, t, a, q, o)   \
-__get_gfn_type_access((p), (g), (t), (a), (q), (o), 1)
+static inline mfn_t __nonnull(1, 3, 4) get_gfn_type_access(
+struct p2m_domain *p2m, unsigned long gfn, p2m_type_t *t,
+p2m_access_t *a, p2m_query_t q, unsigned int *page_order)
+{
+return __get_gfn_type_access(p2m, gfn, t, a, q, page_order, true);
+}
 
 /* General conversion function from gfn to mfn */
-static inline mfn_t get_gfn_type(struct domain *d,
-unsigned long gfn, p2m_type_t *t,
-p2m_query_t q)
+static inline mfn_t __nonnull(1, 3) get_gfn_type(
+struct domain *d, unsigned long gfn, p2m_type_t *t, p2m_query_t q)
 {
 p2m_access_t a;
 return get_gfn_type_access(p2m_get_hostp2m(d), gfn, t, , q, NULL);
diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
index 892455b..8fcb033 100644
--- a/xen/include/xen/compiler.h
+++ b/xen/include/xen/compiler.h
@@ -62,6 +62,8 @@
 
 #define __must_check __attribute__((__warn_unused_result__))
 
+#define __nonnull(...) __attribute__((nonnull (__VA_ARGS__)))
+
 #define offsetof(a,b) __builtin_offsetof(a,b)
 
 #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 201112L
-- 
2.1.4


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

Re: [Xen-devel] [PATCH 09/22] xen/arm: p2m: Use a whitelist rather than blacklist in get_page_from_gfn

[Julien Grall]

Hi Stefano,

On 27/07/16 18:56, Stefano Stabellini wrote:

On Wed, 27 Jul 2016, Julien Grall wrote:

On 26/07/16 23:44, Stefano Stabellini wrote:

On Wed, 20 Jul 2016, Julien Grall wrote:

Currently, the check in get_page_from_gfn is using a blacklist. This is
very fragile because we may forgot to update the check when a new p2m
type is added.

To avoid any possible issue, use a whitelist. All type backed by a RAM
page can could potential be valid. The check is borrowed from x86.

Signed-off-by: Julien Grall 
---
 xen/include/asm-arm/p2m.h | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 3091c04..78d37ab 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -104,9 +104,16 @@ typedef enum {
 #define P2M_RAM_TYPES (p2m_to_mask(p2m_ram_rw) |\
p2m_to_mask(p2m_ram_ro))

+/* Grant mapping types, which map to a real frame in another VM */
+#define P2M_GRANT_TYPES (p2m_to_mask(p2m_grant_map_rw) |  \
+ p2m_to_mask(p2m_grant_map_ro))
+
 /* Useful predicates */
 #define p2m_is_ram(_t) (p2m_to_mask(_t) & P2M_RAM_TYPES)
 #define p2m_is_foreign(_t) (p2m_to_mask(_t) &
p2m_to_mask(p2m_map_foreign))
+#define p2m_is_any_ram(_t) (p2m_to_mask(_t) &   \
+(P2M_RAM_TYPES | P2M_GRANT_TYPES |  \
+ p2m_to_mask(p2m_map_foreign)))

 static inline
 void p2m_mem_access_emulate_check(struct vcpu *v,
@@ -224,7 +231,7 @@ static inline struct page_info *get_page_from_gfn(
 if (t)
 *t = p2mt;

-if ( p2mt == p2m_invalid || p2mt == p2m_mmio_direct )
+if ( !p2m_is_any_ram(p2mt) )
 return NULL;


What about the iommu mappings?


iommu mappings (p2m_iommu_map_*) are special mappings for the direct mapping
workaround. They should not be used in get_page_from_gfn.


Make sense. I think they deserve to be mentioned in the commit message,
as this patch changes behavior for them.


Good point. I will update the commit message.

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 09/22] xen/arm: p2m: Use a whitelist rather than blacklist in get_page_from_gfn

[Stefano Stabellini]

On Wed, 27 Jul 2016, Julien Grall wrote:
> On 26/07/16 23:44, Stefano Stabellini wrote:
> > On Wed, 20 Jul 2016, Julien Grall wrote:
> > > Currently, the check in get_page_from_gfn is using a blacklist. This is
> > > very fragile because we may forgot to update the check when a new p2m
> > > type is added.
> > > 
> > > To avoid any possible issue, use a whitelist. All type backed by a RAM
> > > page can could potential be valid. The check is borrowed from x86.
> > > 
> > > Signed-off-by: Julien Grall 
> > > ---
> > >  xen/include/asm-arm/p2m.h | 9 -
> > >  1 file changed, 8 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> > > index 3091c04..78d37ab 100644
> > > --- a/xen/include/asm-arm/p2m.h
> > > +++ b/xen/include/asm-arm/p2m.h
> > > @@ -104,9 +104,16 @@ typedef enum {
> > >  #define P2M_RAM_TYPES (p2m_to_mask(p2m_ram_rw) |\
> > > p2m_to_mask(p2m_ram_ro))
> > > 
> > > +/* Grant mapping types, which map to a real frame in another VM */
> > > +#define P2M_GRANT_TYPES (p2m_to_mask(p2m_grant_map_rw) |  \
> > > + p2m_to_mask(p2m_grant_map_ro))
> > > +
> > >  /* Useful predicates */
> > >  #define p2m_is_ram(_t) (p2m_to_mask(_t) & P2M_RAM_TYPES)
> > >  #define p2m_is_foreign(_t) (p2m_to_mask(_t) &
> > > p2m_to_mask(p2m_map_foreign))
> > > +#define p2m_is_any_ram(_t) (p2m_to_mask(_t) &   \
> > > +(P2M_RAM_TYPES | P2M_GRANT_TYPES |  \
> > > + p2m_to_mask(p2m_map_foreign)))
> > > 
> > >  static inline
> > >  void p2m_mem_access_emulate_check(struct vcpu *v,
> > > @@ -224,7 +231,7 @@ static inline struct page_info *get_page_from_gfn(
> > >  if (t)
> > >  *t = p2mt;
> > > 
> > > -if ( p2mt == p2m_invalid || p2mt == p2m_mmio_direct )
> > > +if ( !p2m_is_any_ram(p2mt) )
> > >  return NULL;
> > 
> > What about the iommu mappings?
> 
> iommu mappings (p2m_iommu_map_*) are special mappings for the direct mapping
> workaround. They should not be used in get_page_from_gfn.

Make sense. I think they deserve to be mentioned in the commit message,
as this patch changes behavior for them.

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

Re: [Xen-devel] [PATCH 11/22] xen/arm: p2m: Find the memory attributes based on the p2m type

[Stefano Stabellini]

On Wed, 27 Jul 2016, Julien Grall wrote:
> Hi,
> 
> On 20/07/16 17:10, Julien Grall wrote:
> > Currently, mfn_to_p2m_entry is relying on the caller to provide the
> > correct memory attribute and will deduce the sharability based on it.
> > 
> > Some of the callers, such as p2m_create_table, are using same memory
> > attribute regardless the underlying p2m type. For instance, this will
> > lead to use change the memory attribute from MATTR_DEV to MATTR_MEM when
> > a MMIO superpage is shattered.
> > 
> > Furthermore, it makes more difficult to support different shareability
> > with the same memory attribute.
> > 
> > All the memory attributes could be deduced via the p2m type. This will
> > simplify the code by dropping one parameter.
> 
> I just noticed that I forgot to add my Signed-off-by. Stefano, can you add my
> Signed-off-by while committing?

I could, but given that you need to resend some of the patches anyway,
it might be easier for me to wait for the next version.

 
> > ---
> > I am not sure whether p2m_direct_mmio_c (cacheable MMIO) should use
> > the outer-shareability or inner-shareability. Any opinions?
> > ---
> >  xen/arch/arm/p2m.c | 55
> > --
> >  1 file changed, 24 insertions(+), 31 deletions(-)
> > 
> > diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> > index 999de2b..2f50b4f 100644
> > --- a/xen/arch/arm/p2m.c
> > +++ b/xen/arch/arm/p2m.c
> > @@ -325,8 +325,7 @@ static void p2m_set_permission(lpae_t *e, p2m_type_t t,
> > p2m_access_t a)
> >  }
> >  }
> > 
> > -static lpae_t mfn_to_p2m_entry(mfn_t mfn, unsigned int mattr,
> > -   p2m_type_t t, p2m_access_t a)
> > +static lpae_t mfn_to_p2m_entry(mfn_t mfn, p2m_type_t t, p2m_access_t a)
> >  {
> >  /*
> >   * sh, xn and write bit will be defined in the following switches
> > @@ -335,7 +334,6 @@ static lpae_t mfn_to_p2m_entry(mfn_t mfn, unsigned int
> > mattr,
> >  lpae_t e = (lpae_t) {
> >  .p2m.af = 1,
> >  .p2m.read = 1,
> > -.p2m.mattr = mattr,
> >  .p2m.table = 1,
> >  .p2m.valid = 1,
> >  .p2m.type = t,
> > @@ -343,18 +341,21 @@ static lpae_t mfn_to_p2m_entry(mfn_t mfn, unsigned int
> > mattr,
> > 
> >  BUILD_BUG_ON(p2m_max_real_type > (1 << 4));
> > 
> > -switch (mattr)
> > +switch ( t )
> >  {
> > -case MATTR_MEM:
> > -e.p2m.sh = LPAE_SH_INNER;
> > +case p2m_mmio_direct_nc:
> > +e.p2m.mattr = MATTR_DEV;
> > +e.p2m.sh = LPAE_SH_OUTER;
> >  break;
> > 
> > -case MATTR_DEV:
> > +case p2m_mmio_direct_c:
> > +e.p2m.mattr = MATTR_MEM;
> >  e.p2m.sh = LPAE_SH_OUTER;
> >  break;
> > +
> >  default:
> > -BUG();
> > -break;
> > +e.p2m.mattr = MATTR_MEM;
> > +e.p2m.sh = LPAE_SH_INNER;
> >  }
> > 
> >  p2m_set_permission(, t, a);
> > @@ -421,7 +422,7 @@ static int p2m_create_table(struct domain *d, lpae_t
> > *entry,
> >   */
> >   for ( i=0 ; i < LPAE_ENTRIES; i++ )
> >   {
> > - pte = mfn_to_p2m_entry(mfn, MATTR_MEM, t,
> > p2m->default_access);
> > + pte = mfn_to_p2m_entry(mfn, t, p2m->default_access);
> > 
> >   mfn = mfn_add(mfn, 1UL << (level_shift - LPAE_SHIFT));
> > 
> > @@ -445,7 +446,7 @@ static int p2m_create_table(struct domain *d, lpae_t
> > *entry,
> > 
> >  unmap_domain_page(p);
> > 
> > -pte = mfn_to_p2m_entry(_mfn(page_to_mfn(page)), MATTR_MEM, p2m_invalid,
> > +pte = mfn_to_p2m_entry(_mfn(page_to_mfn(page)), p2m_invalid,
> > p2m->default_access);
> > 
> >  p2m_write_pte(entry, pte, flush_cache);
> > @@ -666,7 +667,6 @@ static int apply_one_level(struct domain *d,
> > paddr_t *addr,
> > paddr_t *maddr,
> > bool_t *flush,
> > -   int mattr,
> > p2m_type_t t,
> > p2m_access_t a)
> >  {
> > @@ -695,7 +695,7 @@ static int apply_one_level(struct domain *d,
> >  return rc;
> > 
> >  /* New mapping is superpage aligned, make it */
> > -pte = mfn_to_p2m_entry(_mfn(*maddr >> PAGE_SHIFT), mattr, t,
> > a);
> > +pte = mfn_to_p2m_entry(_mfn(*maddr >> PAGE_SHIFT), t, a);
> >  if ( level < 3 )
> >  pte.p2m.table = 0; /* Superpage entry */
> > 
> > @@ -915,7 +915,6 @@ static int apply_p2m_changes(struct domain *d,
> >   gfn_t sgfn,
> >   unsigned long nr,
> >   mfn_t smfn,
> > - int mattr,
> >   uint32_t mask,
> >   p2m_type_t t,
> >   p2m_access_t a)
> > @@ -1054,7 +1053,7 @@ static int apply_p2m_changes(struct domain *d,
> >level, 

Re: [Xen-devel] [PATCH v2 5/6] xen/arm: traps: Avoid unnecessary VA -> IPA translation in abort handlers

[Julien Grall]

On 27/07/16 18:28, Sergej Proskurin wrote:

Hi Julien,


Hello Sergej,

Please reply to all (or at least CC me) when answering to xen-devel. 
Otherwise your mail may be missed or the answer may be delayed because I 
filter any mail where I am not the recipients (a lot of people do this 
on the ML).




On 07/27/2016 07:09 PM, Julien Grall wrote:

@@ -2442,7 +2458,7 @@ static void do_trap_data_abort_guest(struct cpu_user_regs 
*regs,
 info.gva = READ_SYSREG64(FAR_EL2);
 #endif

-if ( dabt.s1ptw )
+if ( hpfar_is_valid(hsr.iabt.s1ptw, fsc) )


I belive this should be:

hpfar_is_valid(hsr.*dabt*.s1ptw, fsc)


You are right, I did not spot it during my testing because the field is 
exactly the same bits in the HSR.





 info.gpa = get_faulting_ipa(info.gva);
 else
 {
@@ -2451,7 +2467,7 @@ static void do_trap_data_abort_guest(struct cpu_user_regs 
*regs,
 return; /* Try again */
 }

-switch ( dabt.dfsc & ~FSC_LL_MASK )
+switch ( fsc )
 {
 case FSC_FLT_PERM:
 {


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 5/6] xen/arm: traps: Avoid unnecessary VA -> IPA translation in abort handlers

[Sergej Proskurin]

Hi Julien,


On 07/27/2016 07:09 PM, Julien Grall wrote:
> Translating a VA to a IPA is expensive. Currently, Xen is assuming that
> HPFAR_EL2 is only valid when the stage-2 data/instruction abort happened
> during a translation table walk of a first stage translation (i.e S1PTW
> is set).
>
> However, based on the ARM ARM (D7.2.34 in DDI 0487A.j), the register is
> also valid when the data/instruction abort occured for a translation
> fault.
>
> With this change, the VA -> IPA translation will only happen for
> permission faults that are not related to a translation table of a
> first stage translation.
>
> Signed-off-by: Julien Grall 
>
> ---
> Changes in v2:
> - Use fsc in the switch in do_trap_data_abort_guest
> ---
>  xen/arch/arm/traps.c | 24 
>  1 file changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index ea105f2..83a30fa 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2382,13 +2382,28 @@ static inline paddr_t get_faulting_ipa(vaddr_t gva)
>  return ipa;
>  }
>  
> +static inline bool hpfar_is_valid(bool s1ptw, uint8_t fsc)
> +{
> +/*
> + * HPFAR is valid if one of the following cases are true:
> + *  1. the stage 2 fault happen during a stage 1 page table walk
> + *  (the bit ESR_EL2.S1PTW is set)
> + *  2. the fault was due to a translation fault
> + *
> + * Note that technically HPFAR is valid for other cases, but they
> + * are currently not supported by Xen.
> + */
> +return s1ptw || (fsc == FSC_FLT_TRANS);
> +}
> +
>  static void do_trap_instr_abort_guest(struct cpu_user_regs *regs,
>const union hsr hsr)
>  {
>  int rc;
>  register_t gva = READ_SYSREG(FAR_EL2);
> +uint8_t fsc = hsr.iabt.ifsc & ~FSC_LL_MASK;
>  
> -switch ( hsr.iabt.ifsc & ~FSC_LL_MASK )
> +switch ( fsc )
>  {
>  case FSC_FLT_PERM:
>  {
> @@ -2399,7 +2414,7 @@ static void do_trap_instr_abort_guest(struct 
> cpu_user_regs *regs,
>  .kind = hsr.iabt.s1ptw ? npfec_kind_in_gpt : npfec_kind_with_gla
>  };
>  
> -if ( hsr.iabt.s1ptw )
> +if ( hpfar_is_valid(hsr.iabt.s1ptw, fsc) )
>  gpa = get_faulting_ipa(gva);
>  else
>  {
> @@ -2434,6 +2449,7 @@ static void do_trap_data_abort_guest(struct 
> cpu_user_regs *regs,
>  const struct hsr_dabt dabt = hsr.dabt;
>  int rc;
>  mmio_info_t info;
> +uint8_t fsc = hsr.dabt.dfsc & ~FSC_LL_MASK;
>  
>  info.dabt = dabt;
>  #ifdef CONFIG_ARM_32
> @@ -2442,7 +2458,7 @@ static void do_trap_data_abort_guest(struct 
> cpu_user_regs *regs,
>  info.gva = READ_SYSREG64(FAR_EL2);
>  #endif
>  
> -if ( dabt.s1ptw )
> +if ( hpfar_is_valid(hsr.iabt.s1ptw, fsc) )

I belive this should be:

hpfar_is_valid(hsr.*dabt*.s1ptw, fsc)

>  info.gpa = get_faulting_ipa(info.gva);
>  else
>  {
> @@ -2451,7 +2467,7 @@ static void do_trap_data_abort_guest(struct 
> cpu_user_regs *regs,
>  return; /* Try again */
>  }
>  
> -switch ( dabt.dfsc & ~FSC_LL_MASK )
> +switch ( fsc )
>  {
>  case FSC_FLT_PERM:
>  {

Cheers,
~Sergej
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 16/22] xen/arm: p2m: Move the vttbr field from arch_domain to p2m_domain

[Julien Grall]

Hi,

On 20/07/16 17:10, Julien Grall wrote:

The field vttbr holds the base address of the translation table for
guest. Its value will depends on how the p2m has been initialized and
will only be used by the code code.

So move the field from arch_domain to p2m_domain. This will also ease
the implementation of altp2m.


I forgot to add my signed-off-by in this patch as well :/. I will add in 
the next version.


Regards,


---
 xen/arch/arm/p2m.c   | 11 +++
 xen/arch/arm/traps.c |  2 +-
 xen/include/asm-arm/domain.h |  1 -
 xen/include/asm-arm/p2m.h|  3 +++
 4 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index c407e6a..c52081a 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -107,10 +107,14 @@ void dump_p2m_lookup(struct domain *d, paddr_t addr)

 static void p2m_load_VTTBR(struct domain *d)
 {
+struct p2m_domain *p2m = >arch.p2m;
+
 if ( is_idle_domain(d) )
 return;
-BUG_ON(!d->arch.vttbr);
-WRITE_SYSREG64(d->arch.vttbr, VTTBR_EL2);
+
+ASSERT(p2m->vttbr);
+
+WRITE_SYSREG64(p2m->vttbr, VTTBR_EL2);
 isb(); /* Ensure update is visible */
 }

@@ -1298,8 +1302,7 @@ static int p2m_alloc_table(struct domain *d)

 p2m->root = page;

-d->arch.vttbr = page_to_maddr(p2m->root)
-| ((uint64_t)p2m->vmid&0xff)<<48;
+p2m->vttbr = page_to_maddr(p2m->root) | ((uint64_t)p2m->vmid & 0xff) << 48;

 /*
  * Make sure that all TLBs corresponding to the new VMID are flushed
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 06a8ee5..65c6fb4 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -880,7 +880,7 @@ void vcpu_show_registers(const struct vcpu *v)
 ctxt.ifsr32_el2 = v->arch.ifsr;
 #endif

-ctxt.vttbr_el2 = v->domain->arch.vttbr;
+ctxt.vttbr_el2 = v->domain->arch.p2m.vttbr;

 _show_registers(>arch.cpu_info->guest_cpu_user_regs, , 1, v);
 }
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 4e9d8bf..9452fcd 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -48,7 +48,6 @@ struct arch_domain

 /* Virtual MMU */
 struct p2m_domain p2m;
-uint64_t vttbr;

 struct hvm_domain hvm_domain;
 gfn_t *grant_table_gfn;
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index ce28e8a..53c4d78 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -32,6 +32,9 @@ struct p2m_domain {
 /* Current VMID in use */
 uint8_t vmid;

+/* Current Translation Table Base Register for the p2m */
+uint64_t vttbr;
+
 /*
  * Highest guest frame that's ever been mapped in the p2m
  * Only takes into account ram and foreign mapping



--
Julien Grall

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

Re: [Xen-devel] [PATCH 11/22] xen/arm: p2m: Find the memory attributes based on the p2m type

[Julien Grall]

Hi,

On 20/07/16 17:10, Julien Grall wrote:

Currently, mfn_to_p2m_entry is relying on the caller to provide the
correct memory attribute and will deduce the sharability based on it.

Some of the callers, such as p2m_create_table, are using same memory
attribute regardless the underlying p2m type. For instance, this will
lead to use change the memory attribute from MATTR_DEV to MATTR_MEM when
a MMIO superpage is shattered.

Furthermore, it makes more difficult to support different shareability
with the same memory attribute.

All the memory attributes could be deduced via the p2m type. This will
simplify the code by dropping one parameter.


I just noticed that I forgot to add my Signed-off-by. Stefano, can you 
add my Signed-off-by while committing?


Cheers,


---
I am not sure whether p2m_direct_mmio_c (cacheable MMIO) should use
the outer-shareability or inner-shareability. Any opinions?
---
 xen/arch/arm/p2m.c | 55 --
 1 file changed, 24 insertions(+), 31 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 999de2b..2f50b4f 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -325,8 +325,7 @@ static void p2m_set_permission(lpae_t *e, p2m_type_t t, 
p2m_access_t a)
 }
 }

-static lpae_t mfn_to_p2m_entry(mfn_t mfn, unsigned int mattr,
-   p2m_type_t t, p2m_access_t a)
+static lpae_t mfn_to_p2m_entry(mfn_t mfn, p2m_type_t t, p2m_access_t a)
 {
 /*
  * sh, xn and write bit will be defined in the following switches
@@ -335,7 +334,6 @@ static lpae_t mfn_to_p2m_entry(mfn_t mfn, unsigned int 
mattr,
 lpae_t e = (lpae_t) {
 .p2m.af = 1,
 .p2m.read = 1,
-.p2m.mattr = mattr,
 .p2m.table = 1,
 .p2m.valid = 1,
 .p2m.type = t,
@@ -343,18 +341,21 @@ static lpae_t mfn_to_p2m_entry(mfn_t mfn, unsigned int 
mattr,

 BUILD_BUG_ON(p2m_max_real_type > (1 << 4));

-switch (mattr)
+switch ( t )
 {
-case MATTR_MEM:
-e.p2m.sh = LPAE_SH_INNER;
+case p2m_mmio_direct_nc:
+e.p2m.mattr = MATTR_DEV;
+e.p2m.sh = LPAE_SH_OUTER;
 break;

-case MATTR_DEV:
+case p2m_mmio_direct_c:
+e.p2m.mattr = MATTR_MEM;
 e.p2m.sh = LPAE_SH_OUTER;
 break;
+
 default:
-BUG();
-break;
+e.p2m.mattr = MATTR_MEM;
+e.p2m.sh = LPAE_SH_INNER;
 }

 p2m_set_permission(, t, a);
@@ -421,7 +422,7 @@ static int p2m_create_table(struct domain *d, lpae_t *entry,
  */
  for ( i=0 ; i < LPAE_ENTRIES; i++ )
  {
- pte = mfn_to_p2m_entry(mfn, MATTR_MEM, t, p2m->default_access);
+ pte = mfn_to_p2m_entry(mfn, t, p2m->default_access);

  mfn = mfn_add(mfn, 1UL << (level_shift - LPAE_SHIFT));

@@ -445,7 +446,7 @@ static int p2m_create_table(struct domain *d, lpae_t *entry,

 unmap_domain_page(p);

-pte = mfn_to_p2m_entry(_mfn(page_to_mfn(page)), MATTR_MEM, p2m_invalid,
+pte = mfn_to_p2m_entry(_mfn(page_to_mfn(page)), p2m_invalid,
p2m->default_access);

 p2m_write_pte(entry, pte, flush_cache);
@@ -666,7 +667,6 @@ static int apply_one_level(struct domain *d,
paddr_t *addr,
paddr_t *maddr,
bool_t *flush,
-   int mattr,
p2m_type_t t,
p2m_access_t a)
 {
@@ -695,7 +695,7 @@ static int apply_one_level(struct domain *d,
 return rc;

 /* New mapping is superpage aligned, make it */
-pte = mfn_to_p2m_entry(_mfn(*maddr >> PAGE_SHIFT), mattr, t, a);
+pte = mfn_to_p2m_entry(_mfn(*maddr >> PAGE_SHIFT), t, a);
 if ( level < 3 )
 pte.p2m.table = 0; /* Superpage entry */

@@ -915,7 +915,6 @@ static int apply_p2m_changes(struct domain *d,
  gfn_t sgfn,
  unsigned long nr,
  mfn_t smfn,
- int mattr,
  uint32_t mask,
  p2m_type_t t,
  p2m_access_t a)
@@ -1054,7 +1053,7 @@ static int apply_p2m_changes(struct domain *d,
   level, flush_pt, op,
   start_gpaddr, end_gpaddr,
   , , ,
-  mattr, t, a);
+  t, a);
 if ( ret < 0 ) { rc = ret ; goto out; }
 count += ret;

@@ -1163,7 +1162,7 @@ out:
  * mapping.
  */
 apply_p2m_changes(d, REMOVE, sgfn, gfn - gfn_x(sgfn), smfn,
-  mattr, 0, p2m_invalid, d->arch.p2m.default_access);
+  0, p2m_invalid, d->arch.p2m.default_access);
 }

 return rc;
@@ -1173,10 +1172,10 @@ static inline int p2m_insert_mapping(struct 

[Xen-devel] [PATCH v2 0/6] xen/arm: Simplify do_trap_*_abort_guest

[Julien Grall]

Hello all,

The current data/instruction abort paths contain unnecessary code and
translate to often a VA to a IPA. This series aim to simplify this path.

Now that the register HPFAR_EL2 is read in some case that can be affected
by the erratum 834220 on Cortex-A57, we need to implement a workaround
for it (see patch #6).

This series depends on version 6 of "xen/arm: Introduce alternative runtime
patching for ARM64" [1]. A branch with the two series can be found on xenbits:

git://xenbits.xen.org/people/julieng/xen-unstable.git branch abort-handlers-v2

Yours sincerely,

[1] https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg02816.html

Julien Grall (6):
  xen/arm: traps: Simplify the switch in do_trap_*_abort_guest
  xen/arm: Provide macros to help creating workaround helpers
  xen/arm: Use check_workaround to handle the erratum 766422
  xen/arm: traps: MMIO should only be emulated for fault translation
  xen/arm: traps: Avoid unnecessary VA -> IPA translation in abort
handlers
  xen/arm: arm64: Add Cortex-A57 erratum 834220 workaround

 docs/misc/arm/silicon-errata.txt  |  1 +
 xen/arch/arm/Kconfig  | 21 +
 xen/arch/arm/cpuerrata.c  | 15 +++
 xen/arch/arm/traps.c  | 81 ++-
 xen/include/asm-arm/arm32/processor.h |  4 --
 xen/include/asm-arm/arm64/processor.h |  2 -
 xen/include/asm-arm/cpuerrata.h   | 42 ++
 xen/include/asm-arm/cpufeature.h  |  4 +-
 xen/include/asm-arm/processor.h   |  2 +
 9 files changed, 136 insertions(+), 36 deletions(-)

-- 
1.9.1


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

[Xen-devel] [PATCH v2 6/6] xen/arm: arm64: Add Cortex-A57 erratum 834220 workaround

[Julien Grall]

The ARM erratum applies to certain revisions of Cortex-A57. The
processor may report a Stage 2 translation fault as the result of
Stage 1 fault for load crossing a page boundary when there is a
permission fault or device memory fault at stage 1 and a translation
fault at Stage 2.

So Xen needs to check that Stage 1 translation does not generate a fault
before handling the Stage 2 fault. If it is a Stage 1 translation fault,
return to the guest to let the processor injecting the correct fault.

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

---
Changes in v2:
- Add Stefano's reviewed-by
---
 docs/misc/arm/silicon-errata.txt |  1 +
 xen/arch/arm/Kconfig | 21 +
 xen/arch/arm/cpuerrata.c |  9 +
 xen/arch/arm/traps.c |  5 +++--
 xen/include/asm-arm/cpuerrata.h  |  1 +
 xen/include/asm-arm/cpufeature.h |  3 ++-
 6 files changed, 37 insertions(+), 3 deletions(-)

diff --git a/docs/misc/arm/silicon-errata.txt b/docs/misc/arm/silicon-errata.txt
index 220f724..c9854c3 100644
--- a/docs/misc/arm/silicon-errata.txt
+++ b/docs/misc/arm/silicon-errata.txt
@@ -47,3 +47,4 @@ stable hypervisors.
 | ARM| Cortex-A53  | #819472 | ARM64_ERRATUM_819472
|
 | ARM| Cortex-A57  | #852523 | N/A 
|
 | ARM| Cortex-A57  | #832075 | ARM64_ERRATUM_832075
|
+| ARM| Cortex-A57  | #834220 | ARM64_ERRATUM_834220
|
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index e26c4c8..871c243 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -142,6 +142,27 @@ config ARM64_ERRATUM_832075
 
  If unsure, say Y.
 
+config ARM64_ERRATUM_834220
+   bool "Cortex-A57: 834220: Stage 2 translation fault might be 
incorrectly reported in presence of a Stage 1 fault"
+   default y
+   depends on ARM_64
+   help
+ This option adds an alternative code sequence to work around ARM
+ erratum 834220 on Cortex-A57 parts up to r1p2.
+
+ Affected Cortex-A57 parts might report a Stage 2 translation
+ fault as the result of a Stage 1 fault for load crossing a
+ page boundary when there is a permission or device memory
+ alignment fault at Stage 1 and a translation fault at Stage 2.
+
+ The workaround is to verify that the Stage 1 translation
+ doesn't generate a fault before handling the Stage 2 fault.
+ Please note that this does not necessarily enable the workaround,
+ as it depends on the alternative framework, which will only patch
+ the kernel if an affected CPU is detected.
+
+ If unsure, say Y.
+
 endmenu
 
 source "common/Kconfig"
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 748e02e..a3e8dda 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -49,6 +49,15 @@ static const struct arm_cpu_capabilities arm_errata[] = {
(1 << MIDR_VARIANT_SHIFT) | 2),
 },
 #endif
+#ifdef CONFIG_ARM64_ERRATUM_834220
+{
+/* Cortex-A57 r0p0 - r1p2 */
+.desc = "ARM erratum 834220",
+.capability = ARM64_WORKAROUND_834220,
+MIDR_RANGE(MIDR_CORTEX_A57, 0x00,
+   (1 << MIDR_VARIANT_SHIFT) | 2),
+},
+#endif
 {},
 };
 
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 83a30fa..13935e8 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2388,12 +2388,13 @@ static inline bool hpfar_is_valid(bool s1ptw, uint8_t 
fsc)
  * HPFAR is valid if one of the following cases are true:
  *  1. the stage 2 fault happen during a stage 1 page table walk
  *  (the bit ESR_EL2.S1PTW is set)
- *  2. the fault was due to a translation fault
+ *  2. the fault was due to a translation fault and the processor
+ *  does not carry erratum #8342220
  *
  * Note that technically HPFAR is valid for other cases, but they
  * are currently not supported by Xen.
  */
-return s1ptw || (fsc == FSC_FLT_TRANS);
+return s1ptw || (fsc == FSC_FLT_TRANS && !check_workaround_834220());
 }
 
 static void do_trap_instr_abort_guest(struct cpu_user_regs *regs,
diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
index 5880e77..5e35b4f 100644
--- a/xen/include/asm-arm/cpuerrata.h
+++ b/xen/include/asm-arm/cpuerrata.h
@@ -41,6 +41,7 @@ static inline bool_t check_workaround_##erratum(void) 
  \
 #endif
 
 CHECK_WORKAROUND_HELPER(766422, ARM32_WORKAROUND_766422, CONFIG_ARM_32)
+CHECK_WORKAROUND_HELPER(834220, ARM64_WORKAROUND_834220, CONFIG_ARM_64)
 
 #undef CHECK_WORKAROUND_HELPER
 
diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
index ac6eaf0..66e930f 100644
--- a/xen/include/asm-arm/cpufeature.h
+++ b/xen/include/asm-arm/cpufeature.h
@@ -38,8 +38,9 @@
 #define 

[Xen-devel] [PATCH v2 5/6] xen/arm: traps: Avoid unnecessary VA -> IPA translation in abort handlers

[Julien Grall]

Translating a VA to a IPA is expensive. Currently, Xen is assuming that
HPFAR_EL2 is only valid when the stage-2 data/instruction abort happened
during a translation table walk of a first stage translation (i.e S1PTW
is set).

However, based on the ARM ARM (D7.2.34 in DDI 0487A.j), the register is
also valid when the data/instruction abort occured for a translation
fault.

With this change, the VA -> IPA translation will only happen for
permission faults that are not related to a translation table of a
first stage translation.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Use fsc in the switch in do_trap_data_abort_guest
---
 xen/arch/arm/traps.c | 24 
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index ea105f2..83a30fa 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2382,13 +2382,28 @@ static inline paddr_t get_faulting_ipa(vaddr_t gva)
 return ipa;
 }
 
+static inline bool hpfar_is_valid(bool s1ptw, uint8_t fsc)
+{
+/*
+ * HPFAR is valid if one of the following cases are true:
+ *  1. the stage 2 fault happen during a stage 1 page table walk
+ *  (the bit ESR_EL2.S1PTW is set)
+ *  2. the fault was due to a translation fault
+ *
+ * Note that technically HPFAR is valid for other cases, but they
+ * are currently not supported by Xen.
+ */
+return s1ptw || (fsc == FSC_FLT_TRANS);
+}
+
 static void do_trap_instr_abort_guest(struct cpu_user_regs *regs,
   const union hsr hsr)
 {
 int rc;
 register_t gva = READ_SYSREG(FAR_EL2);
+uint8_t fsc = hsr.iabt.ifsc & ~FSC_LL_MASK;
 
-switch ( hsr.iabt.ifsc & ~FSC_LL_MASK )
+switch ( fsc )
 {
 case FSC_FLT_PERM:
 {
@@ -2399,7 +2414,7 @@ static void do_trap_instr_abort_guest(struct 
cpu_user_regs *regs,
 .kind = hsr.iabt.s1ptw ? npfec_kind_in_gpt : npfec_kind_with_gla
 };
 
-if ( hsr.iabt.s1ptw )
+if ( hpfar_is_valid(hsr.iabt.s1ptw, fsc) )
 gpa = get_faulting_ipa(gva);
 else
 {
@@ -2434,6 +2449,7 @@ static void do_trap_data_abort_guest(struct cpu_user_regs 
*regs,
 const struct hsr_dabt dabt = hsr.dabt;
 int rc;
 mmio_info_t info;
+uint8_t fsc = hsr.dabt.dfsc & ~FSC_LL_MASK;
 
 info.dabt = dabt;
 #ifdef CONFIG_ARM_32
@@ -2442,7 +2458,7 @@ static void do_trap_data_abort_guest(struct cpu_user_regs 
*regs,
 info.gva = READ_SYSREG64(FAR_EL2);
 #endif
 
-if ( dabt.s1ptw )
+if ( hpfar_is_valid(hsr.iabt.s1ptw, fsc) )
 info.gpa = get_faulting_ipa(info.gva);
 else
 {
@@ -2451,7 +2467,7 @@ static void do_trap_data_abort_guest(struct cpu_user_regs 
*regs,
 return; /* Try again */
 }
 
-switch ( dabt.dfsc & ~FSC_LL_MASK )
+switch ( fsc )
 {
 case FSC_FLT_PERM:
 {
-- 
1.9.1


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

[Xen-devel] [PATCH v2 3/6] xen/arm: Use check_workaround to handle the erratum 766422

[Julien Grall]

Currently, Xen is accessing the stored MIDR everytime it has to check
whether the processor is affected by the erratum 766422.

This could take advantage of the new capability bitfields to detect
whether the processor is affected at boot time.

With this patch, the number of instructions to check the erratum is
going down from ~13 (including 2 loads and a co-processor access) to
~6 instructions (include 1 load).

Signed-off-by: Julien Grall 

---
Changes in v2:
- Update the commit message
---
 xen/arch/arm/cpuerrata.c  | 6 ++
 xen/arch/arm/traps.c  | 3 ++-
 xen/include/asm-arm/arm32/processor.h | 4 
 xen/include/asm-arm/arm64/processor.h | 2 --
 xen/include/asm-arm/cpuerrata.h   | 2 ++
 xen/include/asm-arm/cpufeature.h  | 3 ++-
 xen/include/asm-arm/processor.h   | 2 ++
 7 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 3ac97b3..748e02e 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -17,6 +17,12 @@ is_affected_midr_range(const struct arm_cpu_capabilities 
*entry)
 }
 
 static const struct arm_cpu_capabilities arm_errata[] = {
+{
+/* Cortex-A15 r0p4 */
+.desc = "ARM erratum 766422",
+.capability = ARM32_WORKAROUND_766422,
+MIDR_RANGE(MIDR_CORTEX_A15, 0x04, 0x04),
+},
 #if defined(CONFIG_ARM64_ERRATUM_827319) || \
 defined(CONFIG_ARM64_ERRATUM_824069)
 {
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index b34c46f..28982a4 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -46,6 +46,7 @@
 #include "vtimer.h"
 #include 
 #include 
+#include 
 
 /* The base of the stack must always be double-word aligned, which means
  * that both the kernel half of struct cpu_user_regs (which is pushed in
@@ -2481,7 +2482,7 @@ static void do_trap_data_abort_guest(struct cpu_user_regs 
*regs,
  * Erratum 766422: Thumb store translation fault to Hypervisor may
  * not have correct HSR Rt value.
  */
-if ( cpu_has_erratum_766422() && (regs->cpsr & PSR_THUMB) && dabt.write )
+if ( check_workaround_766422() && (regs->cpsr & PSR_THUMB) && dabt.write )
 {
 rc = decode_instruction(regs, );
 if ( rc )
diff --git a/xen/include/asm-arm/arm32/processor.h 
b/xen/include/asm-arm/arm32/processor.h
index f41644d..11366bb 100644
--- a/xen/include/asm-arm/arm32/processor.h
+++ b/xen/include/asm-arm/arm32/processor.h
@@ -115,10 +115,6 @@ struct cpu_user_regs
 #define READ_SYSREG(R...)   READ_SYSREG32(R)
 #define WRITE_SYSREG(V, R...)   WRITE_SYSREG32(V, R)
 
-/* Erratum 766422: only Cortex A15 r0p4 is affected */
-#define cpu_has_erratum_766422() \
-(unlikely(current_cpu_data.midr.bits == 0x410fc0f4))
-
 #endif /* __ASSEMBLY__ */
 
 #endif /* __ASM_ARM_ARM32_PROCESSOR_H */
diff --git a/xen/include/asm-arm/arm64/processor.h 
b/xen/include/asm-arm/arm64/processor.h
index fef35a5..b0726ff 100644
--- a/xen/include/asm-arm/arm64/processor.h
+++ b/xen/include/asm-arm/arm64/processor.h
@@ -111,8 +111,6 @@ struct cpu_user_regs
 #define READ_SYSREG(name) READ_SYSREG64(name)
 #define WRITE_SYSREG(v, name) WRITE_SYSREG64(v, name)
 
-#define cpu_has_erratum_766422() 0
-
 #endif /* __ASSEMBLY__ */
 
 #endif /* __ASM_ARM_ARM64_PROCESSOR_H */
diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
index 2982a92..5880e77 100644
--- a/xen/include/asm-arm/cpuerrata.h
+++ b/xen/include/asm-arm/cpuerrata.h
@@ -40,6 +40,8 @@ static inline bool_t check_workaround_##erratum(void) 
  \
 
 #endif
 
+CHECK_WORKAROUND_HELPER(766422, ARM32_WORKAROUND_766422, CONFIG_ARM_32)
+
 #undef CHECK_WORKAROUND_HELPER
 
 #endif /* __ARM_CPUERRATA_H__ */
diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
index 78e2263..ac6eaf0 100644
--- a/xen/include/asm-arm/cpufeature.h
+++ b/xen/include/asm-arm/cpufeature.h
@@ -37,8 +37,9 @@
 
 #define ARM64_WORKAROUND_CLEAN_CACHE0
 #define ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE1
+#define ARM32_WORKAROUND_766422 2
 
-#define ARM_NCAPS   2
+#define ARM_NCAPS   3
 
 #ifndef __ASSEMBLY__
 
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 1708253..15bf890 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -46,9 +46,11 @@
 
 #define ARM_CPU_IMP_ARM 0x41
 
+#define ARM_CPU_PART_CORTEX_A15 0xC0F
 #define ARM_CPU_PART_CORTEX_A53 0xD03
 #define ARM_CPU_PART_CORTEX_A57 0xD07
 
+#define MIDR_CORTEX_A15 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A15)
 #define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A53)
 #define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A57)
 
-- 
1.9.1


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

[Xen-devel] [PATCH v2 2/6] xen/arm: Provide macros to help creating workaround helpers

[Julien Grall]

Workarounds may require to execute a different path when the platform
is affected by the associated erratum. Furthermore, this may need to
be called in the common code.

To avoid too much intrusion/overhead, the workaround helpers need to
be a nop on architecture which will never have the workaround and have
to be quick to check whether the platform requires it.

The alternative framework is used to transform the check in a single
instruction. When the framework is not available, the helper will have
~6 instructions including 1 instruction load.

The macro will create a handler called check_workaround_x with
 the erratum number.

For instance, the line bellow will create a workaround helper for
erratum #424242 which is enabled when the capability
ARM64_WORKAROUND_424242 is set and only available for ARM64:

CHECK_WORKAROUND_HELPER(424242, ARM64_WORKAROUND_42424242, CONFIG_ARM64)

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

---
Changes in v2:
- Add Konrad's reviewed-by
---
 xen/include/asm-arm/cpuerrata.h | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
index c495ee5..2982a92 100644
--- a/xen/include/asm-arm/cpuerrata.h
+++ b/xen/include/asm-arm/cpuerrata.h
@@ -1,8 +1,47 @@
 #ifndef __ARM_CPUERRATA_H__
 #define __ARM_CPUERRATA_H__
 
+#include 
+#include 
+#include 
+
 void check_local_cpu_errata(void);
 
+#ifdef CONFIG_ALTERNATIVE
+
+#define CHECK_WORKAROUND_HELPER(erratum, feature, arch) \
+static inline bool_t check_workaround_##erratum(void)   \
+{   \
+if ( !IS_ENABLED(arch) )\
+return 0;   \
+else\
+{   \
+bool_t ret; \
+\
+asm volatile (ALTERNATIVE("mov %0, #0", \
+  "mov %0, #1", \
+  feature)  \
+  : "=r" (ret));\
+\
+return unlikely(ret);   \
+}   \
+}
+
+#else /* CONFIG_ALTERNATIVE */
+
+#define CHECK_WORKAROUND_HELPER(erratum, feature, arch) \
+static inline bool_t check_workaround_##erratum(void)   \
+{   \
+if ( !IS_ENABLED(arch) )\
+return 0;   \
+else\
+return unlikely(cpus_have_cap(feature));\
+}
+
+#endif
+
+#undef CHECK_WORKAROUND_HELPER
+
 #endif /* __ARM_CPUERRATA_H__ */
 /*
  * Local variables:
-- 
1.9.1


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

[Xen-devel] [PATCH v2 4/6] xen/arm: traps: MMIO should only be emulated for fault translation

[Julien Grall]

The function do_trap_data_abort_guest assumes that a stage-2 data abort
can only be taken for a translation fault or permission fault today.

Whilst this is true today, it might not be in the future. Rather than
emulating the MMIO for any fault other than the permission one, print
a warning message when the fault is not handled by Xen.

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

---
Changes in v2:
- Add Stefano's reviewed-by
---
 xen/arch/arm/traps.c | 51 ---
 1 file changed, 28 insertions(+), 23 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 28982a4..ea105f2 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2467,35 +2467,40 @@ static void do_trap_data_abort_guest(struct 
cpu_user_regs *regs,
 /* Trap was triggered by mem_access, work here is done */
 if ( !rc )
 return;
+break;
 }
-break;
-}
-
-if ( dabt.s1ptw )
-goto bad_data_abort;
+case FSC_FLT_TRANS:
+if ( dabt.s1ptw )
+goto bad_data_abort;
 
-/* XXX: Decode the instruction if ISS is not valid */
-if ( !dabt.valid )
-goto bad_data_abort;
+/* XXX: Decode the instruction if ISS is not valid */
+if ( !dabt.valid )
+goto bad_data_abort;
 
-/*
- * Erratum 766422: Thumb store translation fault to Hypervisor may
- * not have correct HSR Rt value.
- */
-if ( check_workaround_766422() && (regs->cpsr & PSR_THUMB) && dabt.write )
-{
-rc = decode_instruction(regs, );
-if ( rc )
+/*
+ * Erratum 766422: Thumb store translation fault to Hypervisor may
+ * not have correct HSR Rt value.
+ */
+if ( check_workaround_766422() && (regs->cpsr & PSR_THUMB) &&
+ dabt.write )
 {
-gprintk(XENLOG_DEBUG, "Unable to decode instruction\n");
-goto bad_data_abort;
+rc = decode_instruction(regs, );
+if ( rc )
+{
+gprintk(XENLOG_DEBUG, "Unable to decode instruction\n");
+goto bad_data_abort;
+}
 }
-}
 
-if (handle_mmio())
-{
-advance_pc(regs, hsr);
-return;
+if ( handle_mmio() )
+{
+advance_pc(regs, hsr);
+return;
+}
+break;
+default:
+gprintk(XENLOG_WARNING, "Unsupported DFSC: HSR=%#x DFSC=%#x\n",
+hsr.bits, dabt.dfsc);
 }
 
 bad_data_abort:
-- 
1.9.1


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

[Xen-devel] [PATCH v2 1/6] xen/arm: traps: Simplify the switch in do_trap_*_abort_guest

[Julien Grall]

The fault status we care are in the form xx where xx is the lookup
level that gave the fault. We can simplify the code by masking the 2 least
significant bits.

Signed-off-by: Julien Grall 

---
The switch has not been replaced by a simple if because more case
will be added in follow-up patches.

Changes in v2:
- Fix typoes in the commit message
---
 xen/arch/arm/traps.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 2d05936..b34c46f 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2387,9 +2387,9 @@ static void do_trap_instr_abort_guest(struct 
cpu_user_regs *regs,
 int rc;
 register_t gva = READ_SYSREG(FAR_EL2);
 
-switch ( hsr.iabt.ifsc & 0x3f )
+switch ( hsr.iabt.ifsc & ~FSC_LL_MASK )
 {
-case FSC_FLT_PERM ... FSC_FLT_PERM + 3:
+case FSC_FLT_PERM:
 {
 paddr_t gpa;
 const struct npfec npfec = {
@@ -2450,9 +2450,9 @@ static void do_trap_data_abort_guest(struct cpu_user_regs 
*regs,
 return; /* Try again */
 }
 
-switch ( dabt.dfsc & 0x3f )
+switch ( dabt.dfsc & ~FSC_LL_MASK )
 {
-case FSC_FLT_PERM ... FSC_FLT_PERM + 3:
+case FSC_FLT_PERM:
 {
 const struct npfec npfec = {
 .read_access = !dabt.write,
-- 
1.9.1


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

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[Andrew Cooper]

On 27/07/16 17:54, li...@ssl-mail.com wrote:
>
> On Wed, Jul 27, 2016, at 09:34 AM, Andrew Cooper wrote:
>> This looks suspiciously like the issue which was fixed by c/s
>> d6b186c1e2d852a92c43f090d0d8fad4704d51ef "x86/xen: avoid m2p lookup when
>> setting early page table entries", but that fix is present in Linux 4.7.0
>>
>> Can you check to see whether the commit is included in your kernel?
> This
>
>  
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.git/+/d6b186c1e2d852a92c43f090d0d8fad4704d51ef
>
> looks like the Suse team was involved,
>
>   Reviewed-by: Juergen Gross 
>
> But checking this kernel
>
>  rpm -q kernel-source
>   kernel-source-4.7.0-4.1.g89a2ada.noarch
>  rpm -q --changelog kernel-source | egrep -i "m2p|d6b186c1"
>   - guarantee M2P to be invisible to user mode.
>
> it doesn't look like it's in here.

Juergen: Any ideas?

>
>> Failing that, can you find out exactly where the kernel crashed?  You
>> need to manually decode 81f6374c with the debug symbols.
> Sure can try.  I'm gonna have to read-up on how .  Atm no clue.

addr2line -e /path/to/linux/debug/symbols 81f6374c

~Andrew

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

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

On Wed, Jul 27, 2016, at 09:34 AM, Andrew Cooper wrote:
> This looks suspiciously like the issue which was fixed by c/s
> d6b186c1e2d852a92c43f090d0d8fad4704d51ef "x86/xen: avoid m2p lookup when
> setting early page table entries", but that fix is present in Linux 4.7.0
> 
> Can you check to see whether the commit is included in your kernel?

This

 
https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.git/+/d6b186c1e2d852a92c43f090d0d8fad4704d51ef

looks like the Suse team was involved,

  Reviewed-by: Juergen Gross 

But checking this kernel

 rpm -q kernel-source
  kernel-source-4.7.0-4.1.g89a2ada.noarch
 rpm -q --changelog kernel-source | egrep -i "m2p|d6b186c1"
  - guarantee M2P to be invisible to user mode.

it doesn't look like it's in here.

> Failing that, can you find out exactly where the kernel crashed?  You
> need to manually decode 81f6374c with the debug symbols.

Sure can try.  I'm gonna have to read-up on how .  Atm no clue.

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

[Xen-devel] [PATCH v6 3/7] xen/arm: Detect silicon revision and set cap bits accordingly

[Julien Grall]

After each CPU has been started, we iterate through a list of CPU
errata to detect CPUs which need from hypervisor code patches.

For each bug there is a function which checks if that a particular CPU is
affected. This needs to be done on every CPU to cover heterogenous
systems properly.

If a certain erratum has been detected, the capability bit will be set.
In the case the erratum requires code patching, this will be triggered
by the call to apply_alternatives.

The code is based on the file arch/arm64/kernel/cpu_errata.c in Linux
v4.6-rc3.

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

---
Changes in v6:
- Fix typoes in the commit message
- Add __ to the guard

Changes in v4:
- Add missing emacs magic blocks
- Add Stefano's acked-by

Changes in v3:
- Move update_cpu_capabilities in a separate patch
- Update the commit message to mention that workaround may
not require code patching.

Changes in v2:
- Use XENLOG_INFO for the loglevel of the message
---
 xen/arch/arm/Makefile|  1 +
 xen/arch/arm/cpuerrata.c | 34 ++
 xen/arch/arm/setup.c |  3 +++
 xen/arch/arm/smpboot.c   |  3 +++
 xen/include/asm-arm/cpuerrata.h  | 14 ++
 xen/include/asm-arm/cpufeature.h |  6 ++
 6 files changed, 61 insertions(+)
 create mode 100644 xen/arch/arm/cpuerrata.c
 create mode 100644 xen/include/asm-arm/cpuerrata.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 74bd7b8..23aaf52 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -7,6 +7,7 @@ subdir-$(CONFIG_ACPI) += acpi
 obj-$(CONFIG_ALTERNATIVE) += alternative.o
 obj-y += bootfdt.o
 obj-y += cpu.o
+obj-y += cpuerrata.o
 obj-y += cpufeature.o
 obj-y += decode.o
 obj-y += device.o
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
new file mode 100644
index 000..03ae7b4
--- /dev/null
+++ b/xen/arch/arm/cpuerrata.c
@@ -0,0 +1,34 @@
+#include 
+#include 
+#include 
+
+#define MIDR_RANGE(model, min, max) \
+.matches = is_affected_midr_range,  \
+.midr_model = model,\
+.midr_range_min = min,  \
+.midr_range_max = max
+
+static bool_t __maybe_unused
+is_affected_midr_range(const struct arm_cpu_capabilities *entry)
+{
+return MIDR_IS_CPU_MODEL_RANGE(boot_cpu_data.midr.bits, entry->midr_model,
+   entry->midr_range_min,
+   entry->midr_range_max);
+}
+
+static const struct arm_cpu_capabilities arm_errata[] = {
+{},
+};
+
+void check_local_cpu_errata(void)
+{
+update_cpu_capabilities(arm_errata, "enabled workaround for");
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 97b3214..38eb888 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -171,6 +172,8 @@ static void __init processor_id(void)
 }
 
 processor_setup();
+
+check_local_cpu_errata();
 }
 
 void dt_unreserved_regions(paddr_t s, paddr_t e,
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 3a962f7..d56b91d 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -316,6 +317,8 @@ void start_secondary(unsigned long boot_phys_offset,
 local_irq_enable();
 local_abort_enable();
 
+check_local_cpu_errata();
+
 printk(XENLOG_DEBUG "CPU %u booted.\n", smp_processor_id());
 
 startup_cpu_idle_loop();
diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
new file mode 100644
index 000..c495ee5
--- /dev/null
+++ b/xen/include/asm-arm/cpuerrata.h
@@ -0,0 +1,14 @@
+#ifndef __ARM_CPUERRATA_H__
+#define __ARM_CPUERRATA_H__
+
+void check_local_cpu_errata(void);
+
+#endif /* __ARM_CPUERRATA_H__ */
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
index be2414c..fb57295 100644
--- a/xen/include/asm-arm/cpufeature.h
+++ b/xen/include/asm-arm/cpufeature.h
@@ -66,6 +66,12 @@ struct arm_cpu_capabilities {
 const char *desc;
 u16 capability;
 bool_t (*matches)(const struct arm_cpu_capabilities *);
+union {
+struct {/* To be used for eratum handling only */
+u32 midr_model;
+u32 midr_range_min, midr_range_max;
+};
+};
 };
 
 void update_cpu_capabilities(const struct arm_cpu_capabilities *caps,
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org

[Xen-devel] [PATCH v6 1/7] xen/arm: Introduce alternative runtime patching

[Julien Grall]

Some of the processor erratum will require to modify code sequence.
As those modifications may impact the performance, they should only
be enabled on affected cores. Furthermore, Xen may also want to take
advantage of new hardware features coming up with v8.1 and v8.2.

This patch adds an infrastructure to patch Xen during boot time
depending on the "features" available on the platform.

This code is based on the file arch/arm64/kernel/alternative.c in
Linux 4.6-rc3. Any references to arm64 have been dropped to make the
code as generic as possible.

When Xen is creating the page tables, all the executable sections
(.text and .init.text) will be marked read-only and then enforced by
setting SCTLR.WNX.

Whilst it might be possible to mark those entries read-only after
Xen has been patched, we would need extra care to avoid possible
TLBs conflicts (see D4-1732 in ARM DDI 0487A.i) as all
physical CPUs will be running.

All the physical CPUs have to be brought up before patching Xen because
each cores may have different errata/features which require code
patching. The only way to find them is to probe system registers on
each CPU.

To avoid extra complexity, it is possible to create a temporary
writeable mapping with vmap. This mapping will be used to write the
new instructions.

Lastly, runtime patching is currently not necessary for ARM32. So the
code is only enabled for ARM64.

Note that the header asm-arm/alternative.h is a verbatim copy for the
Linux one (arch/arm64/include/asm/alternative.h). It may contain
innacurate comments, but I did not touch them for now.

Signed-off-by: Julien Grall 

---
Changes in v6:
- Update some messages
- Constify some structure
- Add an ASSERT in apply_alternatives
- Mention in the commit message that alternative is a verbatim
copy of the Linux headers.

Changes in v5:
- Rebase on the latest staging

Changes in v4:
- Fix build when ALTERNATIVE is not enabled
- Fix typo
- Move .altinstructions in init.data

Changes in v3:
- .altinstr_replacement should live in init.text
- Add a comment to explain when apply_alternatives_all should be
called.

Changes in v2:
- Use hard tabs in Kconfig
- Update the copyright year
- Update the commit message to explain the extra mapping
---
 xen/arch/arm/Kconfig  |   5 +
 xen/arch/arm/Makefile |   1 +
 xen/arch/arm/alternative.c| 224 ++
 xen/arch/arm/setup.c  |   7 ++
 xen/arch/arm/xen.lds.S|   9 ++
 xen/include/asm-arm/alternative.h | 165 
 xen/include/asm-arm/arm64/insn.h  |  16 +++
 7 files changed, 427 insertions(+)
 create mode 100644 xen/arch/arm/alternative.c
 create mode 100644 xen/include/asm-arm/alternative.h

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 6231cd5..0141bd9 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -14,6 +14,7 @@ config ARM_64
def_bool y
depends on 64BIT
select HAS_GICV3
+   select ALTERNATIVE
 
 config ARM
def_bool y
@@ -46,6 +47,10 @@ config ACPI
 config HAS_GICV3
bool
 
+# Select ALTERNATIVE if the architecture supports runtime patching
+config ALTERNATIVE
+   bool
+
 endmenu
 
 source "common/Kconfig"
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index b264ed4..74bd7b8 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -4,6 +4,7 @@ subdir-y += platforms
 subdir-$(CONFIG_ARM_64) += efi
 subdir-$(CONFIG_ACPI) += acpi
 
+obj-$(CONFIG_ALTERNATIVE) += alternative.o
 obj-y += bootfdt.o
 obj-y += cpu.o
 obj-y += cpufeature.o
diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
new file mode 100644
index 000..8ee5a11
--- /dev/null
+++ b/xen/arch/arm/alternative.c
@@ -0,0 +1,224 @@
+/*
+ * alternative runtime patching
+ * inspired by the x86 version
+ *
+ * Copyright (C) 2014-2016 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define __ALT_PTR(a,f)  (u32 *)((void *)&(a)->f + (a)->f)
+#define ALT_ORIG_PTR(a) __ALT_PTR(a, orig_offset)
+#define ALT_REPL_PTR(a) __ALT_PTR(a, alt_offset)
+
+extern 

[Xen-devel] [PATCH v6 6/7] xen/arm: arm64: Add cortex-A57 erratum 832075 workaround

[Julien Grall]

The ARM erratum 832075 applies to certain revisions of Cortex-A57, one
of the workarounds is to change device loads into using load-acquire
semantics.

Use the alternative framework to enable the workaround only on affected
cores.

Whilst a guest could trigger the deadlock, it can be broken when the
processor is receiving an interrupt. As the Xen scheduler will always setup
a timer (firing to every 1ms to 300ms depending on the running time
slice) on each processor, the deadlock would last only few milliseconds
and only affects the guest time slice.

Therefore a malicious guest could only hurt itself. Note that all the
guests should implement/enable the workaround for the affected cores.

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

---
Changes in v4:
- Add Stefano's acked-by

Changes in v2:
- Update the commit message to explain why it is not necessary
to take care of possible deadlock from the guest.
---
 docs/misc/arm/silicon-errata.txt |  1 +
 xen/arch/arm/Kconfig | 20 
 xen/arch/arm/cpuerrata.c |  9 +
 xen/include/asm-arm/arm64/io.h   | 21 +
 xen/include/asm-arm/cpufeature.h |  3 ++-
 xen/include/asm-arm/processor.h  |  2 ++
 6 files changed, 51 insertions(+), 5 deletions(-)

diff --git a/docs/misc/arm/silicon-errata.txt b/docs/misc/arm/silicon-errata.txt
index 546ccd7..220f724 100644
--- a/docs/misc/arm/silicon-errata.txt
+++ b/docs/misc/arm/silicon-errata.txt
@@ -46,3 +46,4 @@ stable hypervisors.
 | ARM| Cortex-A53  | #824069 | ARM64_ERRATUM_824069
|
 | ARM| Cortex-A53  | #819472 | ARM64_ERRATUM_819472
|
 | ARM| Cortex-A57  | #852523 | N/A 
|
+| ARM| Cortex-A57  | #832075 | ARM64_ERRATUM_832075
|
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index a473d9c..e26c4c8 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -122,6 +122,26 @@ config ARM64_ERRATUM_819472
  the kernel if an affected CPU is detected.
 
  If unsure, say Y.
+
+config ARM64_ERRATUM_832075
+   bool "Cortex-A57: 832075: possible deadlock on mixing exclusive memory 
accesses with device loads"
+   default y
+   depends on ARM_64
+   help
+ This option adds an alternative code sequence to work around ARM
+ erratum 832075 on Cortex-A57 parts up to r1p2.
+
+ Affected Cortex-A57 parts might deadlock when exclusive load/store
+ instructions to Write-Back memory are mixed with Device loads.
+
+ The workaround is to promote device loads to use Load-Acquire
+ semantics.
+ Please note that this does not necessarily enable the workaround,
+ as it depends on the alternative framework, which will only patch
+ the kernel if an affected CPU is detected.
+
+ If unsure, say Y.
+
 endmenu
 
 source "common/Kconfig"
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 121788d..3ac97b3 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -34,6 +34,15 @@ static const struct arm_cpu_capabilities arm_errata[] = {
 MIDR_RANGE(MIDR_CORTEX_A53, 0x00, 0x01),
 },
 #endif
+#ifdef CONFIG_ARM64_ERRATUM_832075
+{
+/* Cortex-A57 r0p0 - r1p2 */
+.desc = "ARM erratum 832075",
+.capability = ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE,
+MIDR_RANGE(MIDR_CORTEX_A57, 0x00,
+   (1 << MIDR_VARIANT_SHIFT) | 2),
+},
+#endif
 {},
 };
 
diff --git a/xen/include/asm-arm/arm64/io.h b/xen/include/asm-arm/arm64/io.h
index f80156f..30bfc78 100644
--- a/xen/include/asm-arm/arm64/io.h
+++ b/xen/include/asm-arm/arm64/io.h
@@ -22,6 +22,7 @@
 
 #include 
 #include 
+#include 
 
 /*
  * Generic IO read/write.  These perform native-endian accesses.
@@ -49,28 +50,40 @@ static inline void __raw_writeq(u64 val, volatile void 
__iomem *addr)
 static inline u8 __raw_readb(const volatile void __iomem *addr)
 {
 u8 val;
-asm volatile("ldrb %w0, [%1]" : "=r" (val) : "r" (addr));
+asm volatile(ALTERNATIVE("ldrb %w0, [%1]",
+ "ldarb %w0, [%1]",
+ ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE)
+ : "=r" (val) : "r" (addr));
 return val;
 }
 
 static inline u16 __raw_readw(const volatile void __iomem *addr)
 {
 u16 val;
-asm volatile("ldrh %w0, [%1]" : "=r" (val) : "r" (addr));
+asm volatile(ALTERNATIVE("ldrh %w0, [%1]",
+ "ldarh %w0, [%1]",
+ ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE)
+ : "=r" (val) : "r" (addr));
 return val;
 }
 
 static inline u32 __raw_readl(const volatile void __iomem *addr)
 {
 u32 val;
-asm volatile("ldr %w0, [%1]" : "=r" (val) : 

[Xen-devel] [PATCH v6 7/7] xen/arm: traps: Don't inject a fault if the translation VA -> IPA fails

[Julien Grall]

Based on ARM ARM (D4.5.3 in ARM DDI 0486A and B3.12.7 in ARM DDI 0406C.c),
a Stage 1 translation error has priority over a Stage 2 translation error.

Therefore gva_to_ipa can only fail if another vCPU is playing with the
page table.

Rather than injecting a custom fault, replay the instruction and let the
processor injecting the correct fault.

This is fine as Xen is handling all the pending softirqs
(see leave_hypervisor_tail) before returning to the guest. One of them
is the scheduler which could rescheduled the vCPU.

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

---
Changes in v4:
- s/reschuled/rescheduled/ in the commit message

Changes in v3:
- Add Stefano's acked-by

Changes in v2:
- Update commit message to explain why a guest cannot DoS the
hypervisor with it.
---
 xen/arch/arm/traps.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 2482a20..2d05936 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2412,7 +2412,7 @@ static void do_trap_instr_abort_guest(struct 
cpu_user_regs *regs,
 
 rc = gva_to_ipa(gva, , GV2M_READ);
 if ( rc == -EFAULT )
-goto bad_insn_abort;
+return; /* Try again */
 }
 
 rc = p2m_mem_access_check(gpa, gva, npfec);
@@ -2424,7 +2424,6 @@ static void do_trap_instr_abort_guest(struct 
cpu_user_regs *regs,
 break;
 }
 
-bad_insn_abort:
 inject_iabt_exception(regs, gva, hsr.len);
 }
 
@@ -2448,7 +2447,7 @@ static void do_trap_data_abort_guest(struct cpu_user_regs 
*regs,
 {
 rc = gva_to_ipa(info.gva, , GV2M_READ);
 if ( rc == -EFAULT )
-goto bad_data_abort;
+return; /* Try again */
 }
 
 switch ( dabt.dfsc & 0x3f )
-- 
1.9.1


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

[Xen-devel] [PATCH v6 5/7] xen/arm: arm64: Add Cortex-A53 cache errata workaround

[Julien Grall]

The ARM errata 819472, 827319 and 824069 define the same workaround for
these hardware issues in certain Cortex-A53 parts.

The cache instructions "dc cvac" and "dc cvau" need to be upgraded to
"dc civac".

Use the alternative framework to replace those instructions only on
affected cores.

Whilst the errata affect cache instructions issued at any exception
level, it is not necessary to trap EL1/EL0 data cache instructions
access in order to upgrade them. Indeed the data cache corruption would
always be at the address used by the data cache instructions. Note that
this address could point to a shared memory between guests and the
hypervisors, however all the information present in it are be validated
before any use.

Therefore a malicious guest could only hurt itself. Note that all the
guests should implement/enable the workaround for the affected cores.

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

---
Changes in v4:
- Add Stefano's acked-by

Changes in v3:
- Remove conflict introduced whilst rebasing this series
---
 docs/misc/arm/silicon-errata.txt |  3 ++
 xen/arch/arm/Kconfig | 71 
 xen/arch/arm/arm64/cache.S   |  2 ++
 xen/arch/arm/cpuerrata.c | 17 ++
 xen/include/asm-arm/arm64/page.h |  7 +++-
 xen/include/asm-arm/cpufeature.h |  4 ++-
 xen/include/asm-arm/processor.h  |  6 
 7 files changed, 108 insertions(+), 2 deletions(-)

diff --git a/docs/misc/arm/silicon-errata.txt b/docs/misc/arm/silicon-errata.txt
index 5d54694..546ccd7 100644
--- a/docs/misc/arm/silicon-errata.txt
+++ b/docs/misc/arm/silicon-errata.txt
@@ -42,4 +42,7 @@ stable hypervisors.
 | Implementor| Component   | Erratum ID  | Kconfig 
|
 
++-+-+-+
 | ARM| Cortex-A15  | #766422 | N/A 
|
+| ARM| Cortex-A53  | #827319 | ARM64_ERRATUM_827319
|
+| ARM| Cortex-A53  | #824069 | ARM64_ERRATUM_824069
|
+| ARM| Cortex-A53  | #819472 | ARM64_ERRATUM_819472
|
 | ARM| Cortex-A57  | #852523 | N/A 
|
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 0141bd9..a473d9c 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -53,6 +53,77 @@ config ALTERNATIVE
 
 endmenu
 
+menu "ARM errata workaround via the alternative framework"
+   depends on ALTERNATIVE
+
+config ARM64_ERRATUM_827319
+   bool "Cortex-A53: 827319: Data cache clean instructions might cause 
overlapping transactions to the interconnect"
+   default y
+   depends on ARM_64
+   help
+ This option adds an alternative code sequence to work around ARM
+ erratum 827319 on Cortex-A53 parts up to r0p2 with an AMBA 5 CHI
+ master interface and an L2 cache.
+
+ Under certain conditions this erratum can cause a clean line eviction
+ to occur at the same time as another transaction to the same address
+ on the AMBA 5 CHI interface, which can cause data corruption if the
+ interconnect reorders the two transactions.
+
+ The workaround promotes data cache clean instructions to
+ data cache clean-and-invalidate.
+ Please note that this does not necessarily enable the workaround,
+ as it depends on the alternative framework, which will only patch
+ the kernel if an affected CPU is detected.
+
+ If unsure, say Y.
+
+config ARM64_ERRATUM_824069
+   bool "Cortex-A53: 824069: Cache line might not be marked as clean after 
a CleanShared snoop"
+   default y
+   depends on ARM_64
+   help
+ This option adds an alternative code sequence to work around ARM
+ erratum 824069 on Cortex-A53 parts up to r0p2 when it is connected
+ to a coherent interconnect.
+
+ If a Cortex-A53 processor is executing a store or prefetch for
+ write instruction at the same time as a processor in another
+ cluster is executing a cache maintenance operation to the same
+ address, then this erratum might cause a clean cache line to be
+ incorrectly marked as dirty.
+
+ The workaround promotes data cache clean instructions to
+ data cache clean-and-invalidate.
+ Please note that this option does not necessarily enable the
+ workaround, as it depends on the alternative framework, which will
+ only patch the kernel if an affected CPU is detected.
+
+ If unsure, say Y.
+
+config ARM64_ERRATUM_819472
+   bool "Cortex-A53: 819472: Store exclusive instructions might cause data 
corruption"
+   default y
+   depends on ARM_64
+   help
+ This option adds an alternative code sequence to work around ARM
+ erratum 

[Xen-devel] [PATCH v6 0/7] xen/arm: Introduce alternative runtime patching on ARM64

[Julien Grall]

Hello,

Some of the processor errata will require to modify code sequence. As those
modifications may impact the performance, they should only be enabled on
affected cores. Furthermore, Xen may also want to take advantage of
new hardware features coming up with v8.1 and v8.2.

The first part of the series adds the alternative infrastructure, most of
the code is based on Linux v4.6-rc3. The rest of the series implements
errata for Cortex-A57 and Cortex-A53.

A branch with all the patches can be found here:

git://xenbits.xen.org/people/julieng/xen-unstable.git branch alternative-v6

For all the changes, see in each patch.

Yours sincerely,

Julien Grall (7):
  xen/arm: Introduce alternative runtime patching
  xen/arm: cpufeature: Provide an helper to check if a capability is
supported
  xen/arm: Detect silicon revision and set cap bits accordingly
  xen/arm: Document the errata implemented in Xen
  xen/arm: arm64: Add Cortex-A53 cache errata workaround
  xen/arm: arm64: Add cortex-A57 erratum 832075 workaround
  xen/arm: traps: Don't inject a fault if the translation VA -> IPA
fails

 docs/misc/arm/silicon-errata.txt  |  49 +
 xen/arch/arm/Kconfig  |  96 
 xen/arch/arm/Makefile |   2 +
 xen/arch/arm/alternative.c| 224 ++
 xen/arch/arm/arm64/cache.S|   2 +
 xen/arch/arm/cpuerrata.c  |  60 ++
 xen/arch/arm/cpufeature.c |  16 +++
 xen/arch/arm/setup.c  |  10 ++
 xen/arch/arm/smpboot.c|   3 +
 xen/arch/arm/traps.c  |   5 +-
 xen/arch/arm/xen.lds.S|   9 ++
 xen/include/asm-arm/alternative.h | 165 
 xen/include/asm-arm/arm64/insn.h  |  16 +++
 xen/include/asm-arm/arm64/io.h|  21 +++-
 xen/include/asm-arm/arm64/page.h  |   7 +-
 xen/include/asm-arm/cpuerrata.h   |  14 +++
 xen/include/asm-arm/cpufeature.h  |  20 +++-
 xen/include/asm-arm/processor.h   |   8 ++
 18 files changed, 718 insertions(+), 9 deletions(-)
 create mode 100644 docs/misc/arm/silicon-errata.txt
 create mode 100644 xen/arch/arm/alternative.c
 create mode 100644 xen/arch/arm/cpuerrata.c
 create mode 100644 xen/include/asm-arm/alternative.h
 create mode 100644 xen/include/asm-arm/cpuerrata.h

-- 
1.9.1


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

[Xen-devel] [PATCH v6 4/7] xen/arm: Document the errata implemented in Xen

[Julien Grall]

The new document will help to keep track of each erratum Xen is able to
handle.

The text is based on the Linux doc in Documents/arm64/silicon-errata.txt.

Also list the current errata that Xen is aware of.

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

---
Changes in v6:
- Add Konrad's reviewed-by

Changes in v4:
- Fix grammar in the document : s/by ARM64/on ARM64/
- Add Stefano's acked-by

Changes in v3:
- Fix grammar in the commit message
- s/Linux/Xen/
- Mention that runtime patching is only supported by ARM64
---
 docs/misc/arm/silicon-errata.txt | 45 
 1 file changed, 45 insertions(+)
 create mode 100644 docs/misc/arm/silicon-errata.txt

diff --git a/docs/misc/arm/silicon-errata.txt b/docs/misc/arm/silicon-errata.txt
new file mode 100644
index 000..5d54694
--- /dev/null
+++ b/docs/misc/arm/silicon-errata.txt
@@ -0,0 +1,45 @@
+Silicon Errata and Software Workarounds
+===
+
+It is an unfortunate fact of life that hardware is often produced with
+so-called "errata", which can cause it to deviate from the architecture
+under specific circumstances.  For hardware produced by ARM, these
+errata are broadly classified into the following categories:
+
+  Category A: A critical error without a viable workaround.
+  Category B: A significant or critical error with an acceptable
+  workaround.
+  Category C: A minor error that is not expected to occur under normal
+  operation.
+
+For more information, consult one of the "Software Developers Errata
+Notice" documents available on infocenter.arm.com (registration
+required).
+
+As far as Xen is concerned, Category B errata may require some special
+treatment in the hypervisor. For example, avoiding a particular sequence
+of code, or configuring the processor in a particular way. A less common
+situation may require similar actions in order to declassify a Category A
+erratum into a Category C erratum. These are collectively known as
+"software workarounds" and are only required in the minority of cases
+(e.g. those cases that both require a non-secure workaround *and* can
+be triggered by Xen).
+
+For software workarounds that may adversely impact systems unaffected by
+the erratum in question, a Kconfig entry is added under "ARM errata
+workarounds via the alternatives framework". These are enabled by default
+and patched in at runtime when an affected CPU is detected. Note that
+runtime patching is only supported on ARM64. For less-intrusive workarounds,
+a Kconfig option is not available and the code is structured (preferably
+with a comment) in such a way that the erratum will not be hit.
+
+This approach can make it slightly onerous to determine exactly which
+errata are worked around in an arbitrary hypervisor source tree, so this
+file acts as a registry of software workarounds in the Xen hypervisor and
+will be updated when new workarounds are committed and backported to
+stable hypervisors.
+
+| Implementor| Component   | Erratum ID  | Kconfig 
|
+++-+-+-+
+| ARM| Cortex-A15  | #766422 | N/A 
|
+| ARM| Cortex-A57  | #852523 | N/A 
|
-- 
1.9.1


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

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[Andrew Cooper]

On 27/07/16 17:21, li...@ssl-mail.com wrote:
> [0.00] DMI: Supermicro X10SAT/X10SAT, BIOS 3.0 05/26/2015
> [0.00] Hypervisor detected: Xen
> [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
> [0.00] e820: remove [mem 0x000a-0x000f] usable
> [0.00] e820: last_pfn = 0x16f144 max_arch_pfn = 0x4
> [0.00] MTRR: Disabled
> [0.00] x86/PAT: MTRRs disabled, skipping PAT initialization too.
> [0.00] x86/PAT: Configuration [0-7]: WB  WT  UC- UC  WC  WP  UC  UC  
> [0.00] e820: last_pfn = 0x9e891 max_arch_pfn = 0x4
> (XEN) [2016-07-27 16:08:38] d0v0: unhandled page fault (ec=)
> (XEN) [2016-07-27 16:08:38] Pagetable walk from 0018:
> (XEN) [2016-07-27 16:08:38]  L4[0x000] =  
> (XEN) [2016-07-27 16:08:38] domain_crash_sync called from entry.S: fault at 
> 82d08022ca4a entry.o#create_bounce_frame+0x137/0x146
> (XEN) [2016-07-27 16:08:38] Domain 0 (vcpu#0) crashed on cpu#0:
> (XEN) [2016-07-27 16:08:38] [ Xen-4.7.0_08-452  x86_64  debug=n  Tainted: 
>C ]
> (XEN) [2016-07-27 16:08:38] CPU:0
> (XEN) [2016-07-27 16:08:38] RIP:e033:[]
> (XEN) [2016-07-27 16:08:38] RFLAGS: 0246   EM: 1   CONTEXT: pv 
> guest (d0v0)
> (XEN) [2016-07-27 16:08:38] rax:    rbx:    
> rcx: 0001
> (XEN) [2016-07-27 16:08:38] rdx: 00016f144000   rsi: 81efb2c0   
> rdi: 00016f144000
> (XEN) [2016-07-27 16:08:38] rbp:    rsp: 81e03e50   
> r8:  0200
> (XEN) [2016-07-27 16:08:38] r9:     r10: 7ff0   
> r11: 0067
> (XEN) [2016-07-27 16:08:38] r12:    r13: 81e03f28   
> r14: 
> (XEN) [2016-07-27 16:08:38] r15:    cr0: 80050033   
> cr4: 001526e0
> (XEN) [2016-07-27 16:08:38] cr3: 000841e06000   cr2: 0018
> (XEN) [2016-07-27 16:08:38] ds:    es:    fs:    gs:    ss: 
> e02b   cs: e033
> (XEN) [2016-07-27 16:08:38] Guest stack trace from rsp=81e03e50:
> (XEN) [2016-07-27 16:08:38]0001 0067 
>  81f6374c
> (XEN) [2016-07-27 16:08:38]0001e030 00010046 
> 81e03e98 e02b
> (XEN) [2016-07-27 16:08:38]820e2ce0 0100 
> 0129 
> (XEN) [2016-07-27 16:08:38]81e03f28 81f4d940 
> 8118b419 0010
> (XEN) [2016-07-27 16:08:38]81e03f28 81e03ee0 
> 001a 
> (XEN) [2016-07-27 16:08:38]  
> 81fe9920 
> (XEN) [2016-07-27 16:08:38]  
> 81f42b92 81ff62e0
> (XEN) [2016-07-27 16:08:38]81e03f68 81e03f64 
>  
> (XEN) [2016-07-27 16:08:38]81f486b1 000306c3 
> 000100100800 03010032
> (XEN) [2016-07-27 16:08:38]0005  
>  
> (XEN) [2016-07-27 16:08:38]  
>  
> (XEN) [2016-07-27 16:08:38]  
>  
> (XEN) [2016-07-27 16:08:38]  
>  
> (XEN) [2016-07-27 16:08:38]  
> 0f0060c0c748 c305
> (XEN) [2016-07-27 16:08:38]  
>  
> (XEN) [2016-07-27 16:08:38]  
>  
> (XEN) [2016-07-27 16:08:38]  
>  
> (XEN) [2016-07-27 16:08:38]  
>  
> (XEN) [2016-07-27 16:08:38]  
>  
> (XEN) [2016-07-27 16:08:38]  
>  
> (XEN) [2016-07-27 16:08:38] Hardware Dom0 crashed: 'noreboot' set - not 
> rebooting.

This looks suspiciously like the issue which was fixed by c/s
d6b186c1e2d852a92c43f090d0d8fad4704d51ef "x86/xen: avoid m2p lookup when
setting early page table entries", but that fix is present in Linux 4.7.0

Can you check to see whether the commit is included in your kernel?

Failing that, can you find out exactly where the kernel crashed?  You
need to manually decode 81f6374c with the debug symbols.

~Andrew

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

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[lists]

On Wed, Jul 27, 2016, at 08:50 AM, Andrew Cooper wrote:
> This disassembles to
> 
> callq  *0x8(%rax)
> 
> and %rax looks like an implausible value for a function pointer.  This
> particular issue is definitely an EFI firmware issue.

With all the reference to & around EFI I kinda figured ...

> I presume you mean an upgrade of the dom0 Linux kernel from 4.6.3 to 4.7.0?

Yep.

> > What other debug info can help figure out this specific problem?
> 
> This is first a Linux crash, followed by bad knock-on behaviour.
> 
> For the knockon behaviour, does Linux 4.6.3 encounter the same reboot crash 
> with Xen 4.7.0?

It didn't ... a week or so ago.  I.e. it was working fine.  Or at least I can 
say it wasn't crashing and I could boot Dom0 & my DomUs.

At the moment, I'm stuck in "use what the distro packaging provides"-land.

Which mean that I don't have a drop-back to 4.6.3 available.

Couple of things I'm gonna do to make sure that doesn't happen again in the 
future.  But for today - I'm stuck with 4.7 kernel.

> For the Linux crash, can you boot Linux with "earlyprintk=xen" and see
> if that provides more help as to what went wrong?

Here's serial console output with grub2 log parameters included as

kernel: earlyprintk=xen,keep debug loglevel=8
hypervisor: loglvl=all guest_loglvl=all sync_console console_to_ring


Loading Xen 4.7.0_08-452 with Linux 4.7.0-4.g89a2ada-default ...Loading Xen 
4.7.0_08-452 with Linux 4.7.0-4.g89a2ada-default ...

/EndEntire
/EndEntire
file path: file path: 
/ACPI(a0341d0,0)/ACPI(a0341d0,0)/PCI(1,1c)/PCI(1,1c)/PCI(0,0)/PCI(0,0)/PCI(0,1)/PCI(0,1)/PCI(0,0)/PCI(0,0)/HardwareVendor
(cf31fac5-c24e-11d2-85f3-00a0c93ec93b)[1: 
/HardwareVendor(cf31fac5-c24e-11d2-85f3-00a0c93ec93b)[1: 88 88 
]]/HD(2,1000,96000,c5cc9661271ee648
,2,2)/HD(2,1000,96000,c5cc9661271ee648,2,2)/File(\EFI\OPENSUSE)
/File(\EFI\OPENSUSE)/File(xen-4.7.0_08-452.efi)/File(xen-4.7.0_08-452.efi)/EndEntire
/EndEntire
Xen 4.7.0_08-452 (c/s ) EFI loader
Using configuration file 'xen-4.7.0_08-452.cfg'
vmlinuz-4.7.0-4.g89a2ada-default: 0x8bef9000-0x8c5064c0
initrd-4.7.0-4.g89a2ada-default: 0x8af57000-0x8bef8b2c
0x:0x00:0x19.0x0: ROM: 0x1 bytes at 0x92a25018
0x:0x03:0x00.0x0: ROM: 0x8000 bytes at 0x92a1c018
0x:0x0f:0x00.0x0: ROM: 0x10800 bytes at 0x929fb018
 __  ___  _   _ ___ ___   ___ _  _     
 \ \/ /___ _ __   | || | |___  / _ \   / _ \ ( _ )   | || || ___|___ \ 
  \  // _ \ '_ \  | || |_   / / | | | | | | |/ _ \ __| || ||___ \ __) |
  /  \  __/ | | | |__   _| / /| |_| | | |_| | (_) |__|__   _|__) / __/ 
 /_/\_\___|_| |_||_|(_)_/(_)___/___\___/ \___/  |_||/_|
  |_|  
(XEN) Xen version 4.7.0_08-452 (abu...@suse.de) (gcc (SUSE Linux) 4.8.5) 
debug=n Thu Jun 23 15:45:38 UTC 2016
(XEN) Latest ChangeSet: 
(XEN) Console output is synchronous.
(XEN) Bootloader: EFI
(XEN) Command line: dom0_mem=4096M,max:4096M dom0_max_vcpus=1 
dom0_vcpus_pin=true cpuidle=1 cpufreq=xen com1=115200,8n1,pci console=com1,vga 
console_timestamps consol
e_to_ring conring_size=64  log_buf_len=16M sched_debug apic_verbosity=verbose 
loglvl=all guest_loglvl=all noreboot=true sync_console=true 
(XEN) Video information:
(XEN)  VGA is graphics mode 800x600, 32 bpp
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 6 EDD information structures
(XEN) EFI RAM map:
(XEN)   - 8000 (reserved)
(XEN)  8000 - 00048000 (usable)
(XEN)  00048000 - 00059000 (reserved)
(XEN)  00059000 - 0005f000 (usable)
(XEN)  0005f000 - 000a (reserved)
(XEN)  0010 - 8d93e000 (usable)
(XEN)  8d93e000 - 8d945000 (ACPI NVS)
(XEN)  8d945000 - 8e25a000 (reserved)
(XEN)  8e25a000 - 8e26 (usable)
(XEN)  8e26 - 8e6a1000 (reserved)
(XEN)  8e6a1000 - 91782000 (usable)
(XEN)  91782000 - 919ea000 (reserved)
(XEN)  919ea000 - 91a1d000 (usable)
(XEN)  91a1d000 - 91a7a000 (reserved)
(XEN)  91a7a000 - 91ae (usable)
(XEN)  91ae - 91b86000 (reserved)
(XEN)  91b86000 - 91bba000 (usable)
(XEN)  91bba000 - 91bbb000 (reserved)
(XEN)  91bbb000 - 91bbd000 (usable)
(XEN)  91bbd000 - 91bbe000 (reserved)
(XEN)  91bbe000 - 91bc6000 (usable)
(XEN)  91bc6000 - 91bc9000 (reserved)
(XEN)  91bc9000 - 91bdc000 (usable)
(XEN)  91bdc000 - 91be7000 (reserved)
(XEN)  91be7000 - 91c68000 (usable)
(XEN)  91c68000 - 91ce5000 (reserved)
(XEN)  91ce5000 - 91d2f000 (usable)
(XEN)  91d2f000 - 9208d000 (reserved)
(XEN)  9208d000 - 920d4000 

Re: [Xen-devel] [PATCH v5 3/7] xen/arm: Detect silicon revision and set cap bits accordingly

[Julien Grall]

Hi Konrad,

On 22/07/16 15:24, Konrad Rzeszutek Wilk wrote:

On Wed, Jul 20, 2016 at 04:25:56PM +0100, Julien Grall wrote:

diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
new file mode 100644
index 000..fe93beb
--- /dev/null
+++ b/xen/include/asm-arm/cpuerrata.h
@@ -0,0 +1,14 @@
+#ifndef __ARM_CPUERRATA_H


Sorry about having engaged the pedantic review mode, but this caught my
eye.

I thought the style was to prefix it with __ and also postfix it with __:

$ grep "__" *.h
decode.h:#ifndef __ARCH_ARM_DECODE_H_
decode.h:#define __ARCH_ARM_DECODE_H_
decode.h:#endif /* __ARCH_ARM_DECODE_H_ */
kernel.h:#ifndef __ARCH_ARM_KERNEL_H__
kernel.h:#define __ARCH_ARM_KERNEL_H__
kernel.h:#endif /* #ifdef __ARCH_ARM_KERNEL_H__ */
vtimer.h:#ifndef __ARCH_ARM_VTIMER_H__
vtimer.h:#define __ARCH_ARM_VTIMER_H__
vuart.h:#ifndef __ARCH_ARM_VUART_H__
vuart.h:#define __ARCH_ARM_VUART_H__
vuart.h:#endif /* __ARCH_ARM_VUART_H__ */

And the include/asm also has have this in in surplus.

It really is minor and I am sorry for even picking up on this, but
could you add the __ at the end?


I am not sure if there is a strict coding style here. A lot of ARM 
headers (and x86 too) does not have the trailing "__" or only one "_" as 
the first example you gave.


Anyway, I don't mind to add them here.

Regards,

--
Julien Grall

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

[Xen-devel] Xen Security Advisory 184 (CVE-2016-5403) - virtio: unbounded memory allocation issue

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Xen Security Advisory CVE-2016-5403 / XSA-184
  version 2

   virtio: unbounded memory allocation issue

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

A guest can submit virtio requests without bothering to wait for
completion and is therefore not bound by virtqueue size.  (This
requires reusing vring descriptors in more than one request, which is
incorrect but possible.)  Processing a request allocates a
VirtQueueElement and therefore causes unbounded memory allocation
controlled by the guest.

IMPACT
==

A malicious guest administrator can cause unbounded memory allocation
in QEMU, which can cause an Out-of-Memory condition in the domain
running qemu.

Thus, a malicious guest administrator can cause a denial of service
affecting the whole host.

VULNERABLE SYSTEMS
==

ARM systems are not vulnerable.

PV domains are not vulnerable.

Only HVM domains where virtio-net devices are provided to the guest
are vulnerable.  Note that NO such devices are provided by default,
so the default configuration is not vulnerable.

HVM domains run with QEMU stub domains are not vulnerable.

(Note that all virtio subsystems are affected; but only virtio-net is
a supported configuration.  See docs/misc/qemu-xen-security.)

MITIGATION
==

Running PV only will avoid the issue.

Running HVM domains with Xen PV drivers instead of virtio-net will
avoid the issue.

Running HVM domains with with stubdomains will mitigate the issue.

CREDITS
===

This issue was discovered by Zhenhao Hong of the 360 Marvel Team.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.

xsa184-qemuu-master.patch  qemu-upstream, Xen unstable, 4.7.x, 4.6.x, 4.5.x, 
4.4.x
xsa184-qemut-master.patch  qemu-traditional, Xen unstable, 4.7.x, 4.6.x, 4.5.x, 
4.4.x

$ sha256sum xsa184*
ea41a25dac82cc5c0ef8e599feb6ed400e99414110d4dba8017d6bd048bc3de4  
xsa184-qemut-master.patch
2d675e5e08d9443cf2e5f3aa37521241d6ed898a602b5111d6969023e67b9b6b  
xsa184-qemuu-master.patch
$

NOTES ON THE EMBARGO PERIOD
===

Note that the embargo period is shorter than normal as the Xen
Security team were only notified of the issue on 25 July.

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.

(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJXmNwVAAoJEIP+FMlX6CvZUUQIAMMpYEr4wyoPEWe1w/4TrtQt
eTaDbBFFblfuHOTQcXZephlWBtSZ1bHbdEiTsQnflBYWLLiZZP1tud0f3MvN03uN
M9kTv1LsAb29NC19Oy1w02AOVXm0XklA3JbFG5OoidWVYra0UQSFKeZvi8Tlqr5C
ry2+jdErRGHsQFkjecBU0zSqXmz0+rcTlpzHtfJw3We3J9J4A1WPfAjXN3dL81yx
Tdl3P2heokhR2jsZgi7ZgIBo/s4rD4wbRD5gL4pf6eokyJIib7NFhctMi8hLDkTL
RbJh7sb+U9G5B2arMhRE7e00v7PgSfh+ossBQljszWhbHHCctggmGGIqWF0AvuQ=
=+1d1
-END PGP SIGNATURE-


xsa184-qemut-master.patch
Description: Binary data


xsa184-qemuu-master.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[Andrew Cooper]

On 27/07/16 00:32, li...@ssl-mail.com wrote:
> I'm running Xen-4.7.0_08-452 + linux kernel 4.7.0-4.g89a2ada-default on 
> X86_64 UEFI hardware.
>
> If I boot without Xen hypervisor enabled it boots fine.
>
> If I boot with Xen enabled it PANICs:
>   
>   (XEN) [2016-07-26 22:05:33] Hardware Dom0 crashed: rebooting machine in 
> 5 seconds.

The Dom0 kernel crashed.  As a result, Xen tried to reboot.

>   (XEN) [2016-07-26 22:05:33] APIC error on CPU0: 40(00)
>   (XEN) [2016-07-26 22:05:38] [ Xen-4.7.0_08-452  x86_64  debug=n  
> Tainted:C ]
>   (XEN) [2016-07-26 22:05:38] CPU:0
>   (XEN) [2016-07-26 22:05:38] RIP:e008:[<9e7463c6>] 
> 9e7463c6
>   (XEN) [2016-07-26 22:05:38] RFLAGS: 00010202   CONTEXT: 
> hypervisor (d0v0)
>   (XEN) [2016-07-26 22:05:38] rax: 0003   rbx: 
>    rcx: 
>   (XEN) [2016-07-26 22:05:38] rdx: 9e7467a0   rsi: 
>    rdi: 
>   (XEN) [2016-07-26 22:05:38] rbp:    rsp: 
> 83008ce27d78   r8:  83008ce27db8
>   (XEN) [2016-07-26 22:05:38] r9:  83008ce27da8   r10: 
>    r11: 
>   (XEN) [2016-07-26 22:05:38] r12:    r13: 
> 0cf9   r14: 0065
>   (XEN) [2016-07-26 22:05:38] r15: 8300   cr0: 
> 80050033   cr4: 001526e0
>   (XEN) [2016-07-26 22:05:38] cr3: 00084b4f6000   cr2: 
> 0018
>   (XEN) [2016-07-26 22:05:38] ds:    es:    fs:    gs:    
> ss:    cs: e008
>   (XEN) [2016-07-26 22:05:38] Xen code around <9e7463c6> 
> (9e7463c6):
>   (XEN) [2016-07-26 22:05:38]  0f 48 8b 44 24 40 8b ce  50 08 3b d8 
> 0f 4c d8 48 ff c7 48 3b 7c 24 30

This disassembles to

callq  *0x8(%rax)

and %rax looks like an implausible value for a function pointer.  This
particular issue is definitely an EFI firmware issue.

>   (XEN) [2016-07-26 22:05:38] Xen stack trace from rsp=83008ce27d78:
>   (XEN) [2016-07-26 22:05:38]83084b4b51c0  
>  82d0801670f6
>   (XEN) [2016-07-26 22:05:38]83008ce27db0  
> 001526e0 0206
>   (XEN) [2016-07-26 22:05:38]0003 000841e06000 
>  9efe42f6
>   (XEN) [2016-07-26 22:05:38]  
> efff 82d0807fe000
>   (XEN) [2016-07-26 22:05:38]00084b4f6000 82d08022f94a 
> 000841e06000 
>   (XEN) [2016-07-26 22:05:38]0007 e008 
> 0296 
>   (XEN) [2016-07-26 22:05:38]fffe 82d08018bcc8 
>  13880008
>   (XEN) [2016-07-26 22:05:38]83008ce27ea8  
> 83008ce27eb8 0003
>   (XEN) [2016-07-26 22:05:38]0003 83084b4b5000 
> 83084b4b51c0 
>   (XEN) [2016-07-26 22:05:38] 82d08012bf0d 
> 0003 82d08012bfaf
>   (XEN) [2016-07-26 22:05:38]81e03f28 82d080105871 
>  83008ce27fff
>   (XEN) [2016-07-26 22:05:38]  
> 81e03f28 82d080105978
>   (XEN) [2016-07-26 22:05:38]830092826000 82d080197f8e 
> 0001 82d08022cc55
>   (XEN) [2016-07-26 22:05:38]  
> 81e03f28 
>   (XEN) [2016-07-26 22:05:38]  
> 0067 7ff0
>   (XEN) [2016-07-26 22:05:38] 0200 
>  0001
>   (XEN) [2016-07-26 22:05:38]00016f141000 81efb2c0 
> 00016f141000 010e0004
>   (XEN) [2016-07-26 22:05:38]81f6374c e033 
> 0246 81e03e50
>   (XEN) [2016-07-26 22:05:38]e02b  
>  
>   (XEN) [2016-07-26 22:05:38]  
> 830092826000 
>   (XEN) [2016-07-26 22:05:38] Xen call trace:
>   (XEN) [2016-07-26 22:05:38][<9e7463c6>] 9e7463c6
>   (XEN) [2016-07-26 22:05:38][] 
> i387.c#_vcpu_save_fpu+0x86/0x190
>   (XEN) [2016-07-26 22:05:38][] 
> efi_reset_system+0x3a/0x60
>   (XEN) [2016-07-26 22:05:38][] 
> machine_restart+0x208/0x2d0
>   (XEN) [2016-07-26 22:05:38][] 
> shutdown.c#maybe_reboot+0x3d/0x40
>   (XEN) [2016-07-26 22:05:38][] 
> hwdom_shutdown+0x9f/0xf0
>   (XEN) [2016-07-26 22:05:38][] 
> domain_shutdown+0xf1/0x100
>   (XEN) [2016-07-26 22:05:38][] 
> __domain_crash_synchronous+0x18/0x30
>   (XEN) [2016-07-26 22:05:38][] 
> 

Re: [Xen-devel] [PATCH] xsm: don't require configuring tools to build xen xsm blob

[Julien Grall]

Hi Wei,

On 25/07/16 16:22, Wei Liu wrote:

Starting from 08cffe66 ("xsm: add a default policy to .init.data") we
can attach a xsm policy blob to hypervisor. To build that policy blob
now hypervisor build system needs to enter tools directory.

The expectation for hypervisor and tools build systems is different. We
don't want xen build system to depend on configure but we want tools
build system to. That commit broke this expectation because it required
users to run configure before building hypervisor. This broke ARM build
because ARM developers normally build hypervisor and tools separately
(and possibly on different platforms). It can also break x86 if
developers don't run configure before building hypervisor with XSM on.

To fix it, move major part of tools/flask/policy/Makefile into
Makefile.common and create tools only Makefile to include that common
Makefile. Hypervisor Makefile will use Makefile.common to build xsm
policy.

Signed-off-by: Wei Liu 


Tested-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [oxenstored]Guest users could get the VM count and domids on the host

[George Dunlap]

On Tue, Jul 12, 2016 at 4:35 AM, Sunguodong  wrote:
> Hi all,
>
> I found a problem in oxenstored, which may be a security issue:
> Guest users could get the VM count and domids on the host by a sniffing 
> method.
>
> You can reproduce it like this:
> (1) Create a VM, e.g. CentOS 7.0 64bit
> (2) Install xen tools in VM, excute cmds:
> yum install centos-release-xen; yum install
> (3) Use xenstore-ls to sniff, excute cmds:
> for((i=1;i<=1000;i++));do `xenstore-ls /local/domain/$i 1>>1.txt 
> 2>>2.txt`; done
> then check 2.txt, speculate according the error message. example:
> xenstore-ls: xs_directory (/local/domain/17): No such file or 
> directory
> ---which means dom 17 does not exist
> xenstore-ls: xs_directory (/local/domain/19): Permission denied
> ---which means dom 19 exists
> Count the number of "Permission denied" and we get the VM count on the 
> host.
>
> I tried xen-4.2 and xen-4.6, same result with above.
>
> But when I use c-xenstored on xen-4.2, all error messages are "Permission 
> denied",
> so there is no way to get any info about other domains on the host.
>
> In func "get_node" of c-xenstored, it will clean up the errno before return:
> /* Clean up errno if they weren't supposed to know. */
> if (!node)
> errno = errno_from_parents(conn, name, errno, perm);
> return node;
> but in oxenstored, there is no such code like this. So, I think this part was 
> missed
> when we upgraded c-xenstored to oxenstored.
>
> Please confirm.
>
> Looking forward to your reply, thank you!

Sundong,

Thanks for your report.  At the moment there are actually a fairly large
number of ways to discover active domain IDs through hypercalls as well.
So we will not be treating this as a critical vulnerability.

However, it's always better to make life harder for attackers, so I'm
sure a patch to change oxenstored's behavior would be welcome.
Otherwise, we'll be putting this on a list of improvements to make at
some point.

Also, for future reference, if you find what you think may be a security
vulnerability, please report it directly to the XenProject Securty Team
at secur...@xenproject.org -- even if you're not sure that it is a
vulnerability yet.  Part of our job is to help figure out if there
really is a vulnerability or not.

Thanks,
 - The XenProject Security Team

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

Re: [Xen-devel] [PATCH v3] xen-blkfront: dynamic configuration of per-vbd resources

[Roger Pau Monné]

On Wed, Jul 27, 2016 at 07:21:05PM +0800, Bob Liu wrote:
> 
> On 07/27/2016 06:59 PM, Roger Pau Monné wrote:
> > On Wed, Jul 27, 2016 at 11:21:25AM +0800, Bob Liu wrote:
> > [...]
> >> +static ssize_t dynamic_reconfig_device(struct blkfront_info *info, 
> >> ssize_t count)
> >> +{
> >> +  /*
> >> +   * Prevent new requests even to software request queue.
> >> +   */
> >> +  blk_mq_freeze_queue(info->rq);
> >> +
> >> +  /*
> >> +   * Guarantee no uncompleted reqs.
> >> +   */
> > 
> > I'm also wondering, why do you need to guarantee that there are no 
> > uncompleted requests? The resume procedure is going to call blkif_recover 
> > that will take care of requeuing any unfinished requests that are on the 
> > ring.
> > 
> 
> Because there may have requests in the software request queue with more 
> segments than
> we can handle(if info->max_indirect_segments is reduced).
> 
> The blkif_recover() can't handle this since blk-mq was introduced,
> because there is no way to iterate the sw-request queues(blk_fetch_request() 
> can't be used by blk-mq).
> 
> So there is a bug in blkif_recover(), I was thinking implement the suspend 
> function of blkfront_driver like:

Hm, this is a regression and should be fixed ASAP. I'm still not sure I 
follow, don't blk_queue_max_segments change the number of segments the 
requests on the queue are going to have? So that you will only have to 
re-queue the requests already on the ring?

Waiting for the whole queue to be flushed before suspending is IMHO not 
acceptable, it introduces an unbounded delay during migration if the backend 
is slow for some reason.

Roger.

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

[Xen-devel] [PATCH v3 3/9] xen/arm: gic: split set_irq_properties

[Julien Grall]

The callback set_irq_properties will configure the GIC for a specific
IRQ with the type and the priority.

In a follow-up patch, Xen will configure the type and the priority at
different stage of the routing. So split it in 2 separate callbacks.

At the same time, move the ASSERT to check the validity of the type and
if the desc->lock is locked in the common code (gic.c). This is because
the constraint are the same between GICv2 and GICv3, however the driver
of the latter did not contain any sanity check.

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

---
Changes in v2:
- Add Stefano's reviewed-by
---
 xen/arch/arm/gic-v2.c | 19 +--
 xen/arch/arm/gic-v3.c | 15 ---
 xen/arch/arm/gic.c| 23 ++-
 xen/include/asm-arm/gic.h |  7 ---
 4 files changed, 43 insertions(+), 21 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 6c7dbfe..69ed72d 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -236,16 +236,12 @@ static unsigned int gicv2_read_irq(void)
 return (readl_gicc(GICC_IAR) & GICC_IA_IRQ);
 }
 
-static void gicv2_set_irq_properties(struct irq_desc *desc,
- unsigned int priority)
+static void gicv2_set_irq_type(struct irq_desc *desc)
 {
 uint32_t cfg, actual, edgebit;
 unsigned int irq = desc->irq;
 unsigned int type = desc->arch.type;
 
-ASSERT(type != IRQ_TYPE_INVALID);
-ASSERT(spin_is_locked(>lock));
-
 spin_lock();
 /* Set edge / level */
 cfg = readl_gicd(GICD_ICFGR + (irq / 16) * 4);
@@ -270,6 +266,16 @@ static void gicv2_set_irq_properties(struct irq_desc *desc,
 IRQ_TYPE_LEVEL_HIGH;
 }
 
+spin_unlock();
+}
+
+static void gicv2_set_irq_priority(struct irq_desc *desc,
+   unsigned int priority)
+{
+unsigned int irq = desc->irq;
+
+spin_lock();
+
 /* Set priority */
 writeb_gicd(priority, GICD_IPRIORITYR + irq);
 
@@ -1217,7 +1223,8 @@ const static struct gic_hw_operations gicv2_ops = {
 .eoi_irq = gicv2_eoi_irq,
 .deactivate_irq  = gicv2_dir_irq,
 .read_irq= gicv2_read_irq,
-.set_irq_properties  = gicv2_set_irq_properties,
+.set_irq_type= gicv2_set_irq_type,
+.set_irq_priority= gicv2_set_irq_priority,
 .send_SGI= gicv2_send_SGI,
 .disable_interface   = gicv2_disable_interface,
 .update_lr   = gicv2_update_lr,
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index d6ab0e9..781f25c 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -471,8 +471,7 @@ static inline uint64_t gicv3_mpidr_to_affinity(int cpu)
  MPIDR_AFFINITY_LEVEL(mpidr, 0));
 }
 
-static void gicv3_set_irq_properties(struct irq_desc *desc,
- unsigned int priority)
+static void gicv3_set_irq_type(struct irq_desc *desc)
 {
 uint32_t cfg, actual, edgebit;
 void __iomem *base;
@@ -512,6 +511,15 @@ static void gicv3_set_irq_properties(struct irq_desc *desc,
 IRQ_TYPE_EDGE_RISING :
 IRQ_TYPE_LEVEL_HIGH;
 }
+spin_unlock();
+}
+
+static void gicv3_set_irq_priority(struct irq_desc *desc,
+   unsigned int priority)
+{
+unsigned int irq = desc->irq;
+
+spin_lock();
 
 /* Set priority */
 if ( irq < NR_GIC_LOCAL_IRQS )
@@ -1579,7 +1587,8 @@ static const struct gic_hw_operations gicv3_ops = {
 .eoi_irq = gicv3_eoi_irq,
 .deactivate_irq  = gicv3_dir_irq,
 .read_irq= gicv3_read_irq,
-.set_irq_properties  = gicv3_set_irq_properties,
+.set_irq_type= gicv3_set_irq_type,
+.set_irq_priority= gicv3_set_irq_priority,
 .send_SGI= gicv3_send_sgi,
 .disable_interface   = gicv3_disable_interface,
 .update_lr   = gicv3_update_lr,
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index bc814a0..c63c862 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -96,14 +96,17 @@ void gic_restore_state(struct vcpu *v)
 gic_restore_pending_irqs(v);
 }
 
-/*
- * - desc.lock must be held
- * - arch.type must be valid (i.e != IRQ_TYPE_INVALID)
- */
-static void gic_set_irq_properties(struct irq_desc *desc,
-   unsigned int priority)
+static void gic_set_irq_type(struct irq_desc *desc)
+{
+ASSERT(spin_is_locked(>lock));
+ASSERT(desc->arch.type != IRQ_TYPE_INVALID);
+
+gic_hw_ops->set_irq_type(desc);
+}
+
+static void gic_set_irq_priority(struct irq_desc *desc, unsigned int priority)
 {
-gic_hw_ops->set_irq_properties(desc, priority);
+gic_hw_ops->set_irq_priority(desc, priority);
 }
 
 /* Program the GIC to route an interrupt to the host (i.e. Xen)
@@ -118,7 +121,8 @@ void gic_route_irq_to_xen(struct irq_desc *desc, unsigned 
int priority)
 
 

[Xen-devel] [PATCH v3 2/9] xen/arm: gic: Do not configure affinity during routing

[Julien Grall]

The affinity of a guest IRQ is set every time the guest enable it (see
vgic_enable_irqs).

It is not necessary to set the affinity when the IRQ is routed to the
guest because Xen will never receive the IRQ until it hass been enabled
by the guest.

To keep gic_route_irq_to_{xen,guest} behaving the same way (i.e just
setting up the routing), the affinity of IRQ routed to Xen is moved into
__setup_irq.

Signed-off-by: Julien grall 
Reviewed-by: Stefano Stabellini 

---
Changes in v3:
- Add Stefano's reviewed-by

Changes in v2:
- Patch renamed
- Set the affinity for IRQ routed to Xen in __setup_irq
---
 xen/arch/arm/gic.c| 11 +++
 xen/arch/arm/irq.c|  4 ++--
 xen/include/asm-arm/gic.h |  3 +--
 3 files changed, 6 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 5726a05..bc814a0 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -97,24 +97,19 @@ void gic_restore_state(struct vcpu *v)
 }
 
 /*
- * needs to be called with a valid cpu_mask, ie each cpu in the mask has
- * already called gic_cpu_init
  * - desc.lock must be held
  * - arch.type must be valid (i.e != IRQ_TYPE_INVALID)
  */
 static void gic_set_irq_properties(struct irq_desc *desc,
-   const cpumask_t *cpu_mask,
unsigned int priority)
 {
 gic_hw_ops->set_irq_properties(desc, priority);
-desc->handler->set_affinity(desc, cpu_mask);
 }
 
 /* Program the GIC to route an interrupt to the host (i.e. Xen)
  * - needs to be called with desc.lock held
  */
-void gic_route_irq_to_xen(struct irq_desc *desc, const cpumask_t *cpu_mask,
-  unsigned int priority)
+void gic_route_irq_to_xen(struct irq_desc *desc, unsigned int priority)
 {
 ASSERT(priority <= 0xff); /* Only 8 bits of priority */
 ASSERT(desc->irq < gic_number_lines());/* Can't route interrupts that 
don't exist */
@@ -123,7 +118,7 @@ void gic_route_irq_to_xen(struct irq_desc *desc, const 
cpumask_t *cpu_mask,
 
 desc->handler = gic_hw_ops->gic_host_irq_type;
 
-gic_set_irq_properties(desc, cpu_mask, priority);
+gic_set_irq_properties(desc, priority);
 }
 
 /* Program the GIC to route an interrupt to a guest
@@ -155,7 +150,7 @@ int gic_route_irq_to_guest(struct domain *d, unsigned int 
virq,
 desc->handler = gic_hw_ops->gic_guest_irq_type;
 set_bit(_IRQ_GUEST, >status);
 
-gic_set_irq_properties(desc, cpumask_of(v_target->processor), priority);
+gic_set_irq_properties(desc, priority);
 
 p->desc = desc;
 res = 0;
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 2f8af72..3fc22f2 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -370,6 +370,7 @@ int setup_irq(unsigned int irq, unsigned int irqflags, 
struct irqaction *new)
 /* First time the IRQ is setup */
 if ( disabled )
 {
+gic_route_irq_to_xen(desc, GIC_PRI_IRQ);
 /* It's fine to use smp_processor_id() because:
  * For PPI: irq_desc is banked
  * For SPI: we don't care for now which CPU will receive the
@@ -377,8 +378,7 @@ int setup_irq(unsigned int irq, unsigned int irqflags, 
struct irqaction *new)
  * TODO: Handle case where SPI is setup on different CPU than
  * the targeted CPU and the priority.
  */
-gic_route_irq_to_xen(desc, cpumask_of(smp_processor_id()),
- GIC_PRI_IRQ);
+irq_set_affinity(desc, cpumask_of(smp_processor_id()));
 desc->handler->startup(desc);
 }
 
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 2fc6126..7ba3846 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -223,8 +223,7 @@ enum gic_version {
 extern enum gic_version gic_hw_version(void);
 
 /* Program the GIC to route an interrupt */
-extern void gic_route_irq_to_xen(struct irq_desc *desc, const cpumask_t 
*cpu_mask,
- unsigned int priority);
+extern void gic_route_irq_to_xen(struct irq_desc *desc, unsigned int priority);
 extern int gic_route_irq_to_guest(struct domain *, unsigned int virq,
   struct irq_desc *desc,
   unsigned int priority);
-- 
1.9.1


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

[Xen-devel] [PATCH v3 8/9] xen/arm: acpi: route all unused IRQs to DOM0

[Julien Grall]

It is not possible to know which IRQs will be used by DOM0 when ACPI is
inuse. The approach implemented by this patch, will route all unused
IRQs to DOM0 before it has booted.

The number of IRQs routed is based on the maximum SPIs supported by the
hardware (up to ~1000). However, some of them might not be wired. So we
would allocate resource for nothing.

For each IRQ routed, Xen is allocating memory for irqaction (40 bytes)
and irq_guest (16 bytes). So in the worst case scenario ~54KB of memory
will be allocated. Given that ACPI will mostly be used by server, I
think it is a small drawback.

map_irq_to_domain is slightly reworked to remove the dependency on
device-tree. So the function can be also be used for ACPI and will
avoid code duplication.

Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 
Tested-by: Shanker Donthineni 

---
Changes in v3:
- Add Stefano's reviewed-by
- Tested by Shanker on QDF2XXX server

Changes in v2:
- Rename acpi_permit_spi_access to acpi_route_spis
- Update the comment in the function acpi_route_spis
---
 xen/arch/arm/domain_build.c | 28 
 1 file changed, 12 insertions(+), 16 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 60db9e4..5b2f8ad 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -903,11 +903,10 @@ static int make_timer_node(const struct domain *d, void 
*fdt,
 return res;
 }
 
-static int map_irq_to_domain(const struct dt_device_node *dev,
- struct domain *d, unsigned int irq)
+static int map_irq_to_domain(struct domain *d, unsigned int irq,
+ bool_t need_mapping, const char *devname)
 
 {
-bool_t need_mapping = !dt_device_for_passthrough(dev);
 int res;
 
 res = irq_permit_access(d, irq);
@@ -927,7 +926,7 @@ static int map_irq_to_domain(const struct dt_device_node 
*dev,
  */
 vgic_reserve_virq(d, irq);
 
-res = route_irq_to_guest(d, irq, irq, dt_node_name(dev));
+res = route_irq_to_guest(d, irq, irq, devname);
 if ( res < 0 )
 {
 printk(XENLOG_ERR "Unable to map IRQ%"PRId32" to dom%d\n",
@@ -947,6 +946,7 @@ static int map_dt_irq_to_domain(const struct dt_device_node 
*dev,
 struct domain *d = data;
 unsigned int irq = dt_irq->irq;
 int res;
+bool_t need_mapping = !dt_device_for_passthrough(dev);
 
 if ( irq < NR_LOCAL_IRQS )
 {
@@ -965,7 +965,7 @@ static int map_dt_irq_to_domain(const struct dt_device_node 
*dev,
 return res;
 }
 
-res = map_irq_to_domain(dev, d, irq);
+res = map_irq_to_domain(d, irq, need_mapping, dt_node_name(dev));
 
 return 0;
 }
@@ -1103,7 +1103,7 @@ static int handle_device(struct domain *d, struct 
dt_device_node *dev)
 return res;
 }
 
-res = map_irq_to_domain(dev, d, res);
+res = map_irq_to_domain(d, res, need_mapping, dt_node_name(dev));
 if ( res )
 return res;
 }
@@ -1343,15 +1343,14 @@ static int acpi_iomem_deny_access(struct domain *d)
 return gic_iomem_deny_access(d);
 }
 
-static int acpi_permit_spi_access(struct domain *d)
+static int acpi_route_spis(struct domain *d)
 {
 int i, res;
 struct irq_desc *desc;
 
 /*
- * Here just permit Dom0 to access the SPIs which Xen doesn't use. Then 
when
- * Dom0 configures the interrupt, set the interrupt type and route it to
- * Dom0.
+ * Route the IRQ to hardware domain and permit the access.
+ * The interrupt type will be set by set by the hardware domain.
  */
 for( i = NR_LOCAL_IRQS; i < vgic_num_irqs(d); i++ )
 {
@@ -1362,13 +1361,10 @@ static int acpi_permit_spi_access(struct domain *d)
 if ( desc->action != NULL)
 continue;
 
-res = irq_permit_access(d, i);
+/* XXX: Shall we use a proper devname? */
+res = map_irq_to_domain(d, i, true, "ACPI");
 if ( res )
-{
-printk(XENLOG_ERR "Unable to permit to dom%u access to IRQ %u\n",
-   d->domain_id, i);
 return res;
-}
 }
 
 return 0;
@@ -1902,7 +1898,7 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 if ( rc != 0 )
 return rc;
 
-rc = acpi_permit_spi_access(d);
+rc = acpi_route_spis(d);
 if ( rc != 0 )
 return rc;
 
-- 
1.9.1


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

[Xen-devel] [PATCH v3 5/9] xen/arm: gic: Document how gic_set_irq_type should be called

[Julien Grall]

Changing the value of Int_config is UNPREDICTABLE when the corresponding
interrupt is not disabled.

The driver is assuming the interrupt will be disabled by the caller of
gic_set_irq_type. Add an ASSERT to ensure it.

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

---
Changes in v2:
- Add Stefano's acked-by
---
 xen/arch/arm/gic.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index b9371a7..72bb885 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -96,8 +96,14 @@ void gic_restore_state(struct vcpu *v)
 gic_restore_pending_irqs(v);
 }
 
+/* desc->irq needs to be disabled before calling this function */
 static void gic_set_irq_type(struct irq_desc *desc, unsigned int type)
 {
+/*
+ * IRQ must be disabled before configuring it (see 4.3.13 in ARM IHI
+ * 0048B.b). We rely on the caller to do it.
+ */
+ASSERT(test_bit(_IRQ_DISABLED, >status));
 ASSERT(spin_is_locked(>lock));
 ASSERT(type != IRQ_TYPE_INVALID);
 
-- 
1.9.1


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

[Xen-devel] [PATCH v3 6/9] Revert "xen/arm: warn the user that we cannot route SPIs to Dom0 on ACPI"

[Julien Grall]

This reverts commit f91c84edebe67296e4051af055dbf0adafb13a37. SPI
routing for ACPI support will be added in a follow-up patch.

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

---
Changes in v3:
- Fix typo in Stefano's e-mail address

Changes in v2:
- Add Stefano's reviewed-by
---
 xen/arch/arm/vgic.c | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index e47daca..938bc7d 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -25,8 +25,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 
 #include 
 
@@ -350,22 +348,9 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
 unsigned long flags;
 int i = 0;
 struct vcpu *v_target;
-struct domain *d = v->domain;
 
 while ( (i = find_next_bit(, 32, i)) < 32 ) {
 irq = i + (32 * n);
-/* Set the irq type and route it to guest only for SPI and Dom0 */
-if( irq_access_permitted(d, irq) && is_hardware_domain(d) &&
-( irq >= 32 ) && ( !acpi_disabled ) )
-{
-static int log_once = 0;
-if ( !log_once )
-{
-gprintk(XENLOG_WARNING, "Routing SPIs to Dom0 on ACPI systems 
is unimplemented.\n");
-log_once++;
-}
-}
-
 v_target = __vgic_get_target_vcpu(v, irq);
 p = irq_to_pending(v_target, irq);
 set_bit(GIC_IRQ_GUEST_ENABLED, >status);
-- 
1.9.1


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

[Xen-devel] [PATCH v3 9/9] xen/arm: Fix coding style and update comment in acpi_route_spis

[Julien Grall]

The comment was not correctly indented. Also the preferred name for the
initial domain is "hardware domain" and not "dom0, so replace it.

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

---
Changes in v3:
- Add Stefano's acked-by

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

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 5b2f8ad..35ab08d 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1355,8 +1355,9 @@ static int acpi_route_spis(struct domain *d)
 for( i = NR_LOCAL_IRQS; i < vgic_num_irqs(d); i++ )
 {
 /*
-* TODO: Exclude the SPIs SMMU uses which should not be routed to Dom0.
-*/
+ * TODO: Exclude the SPIs SMMU uses which should not be routed to
+ * the hardware domain.
+ */
 desc = irq_to_desc(i);
 if ( desc->action != NULL)
 continue;
-- 
1.9.1


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

[Xen-devel] [PATCH v3 7/9] xen/arm: Allow DOM0 to set the IRQ type

[Julien Grall]

The function route_irq_to_guest mandates the IRQ type, stored in
desc->arch.type, to be valid. However, in case of ACPI, these
information is not part of the static tables. Therefore Xen needs to
rely on DOM0 to provide a valid type based on the firmware tables.

A new helper, irq_type_set_by_domain is provided to check whether a
domain is allowed to set the IRQ type. For now, only DOM0 is allowed to
configure.

When the helper returns 1, the routing function will not check whether
the IRQ type is correctly set and configure the GIC. Instead, this will
be done when the domain will enable the interrupt.

Note that irq_set_spi_type is not called because it validates the type
and does not allow it the domain to change the type after the first
write. It means that desc->arch.type may never be set, which is fine
because the field is only used to configure the type during the routing.

Based on 4.3.13 in ARM IHI 0048B.b, changing the value of Int_config is
UNPREDICTABLE when the corresponding interrupt is not disabled.

Therefore, setting the IRQ type when the guest is writing into ICFGR
would require more work to make sure the IRQ has been disabled before
writing into the host ICFGR. As the behavior is UNPREDICTABLE, the type
will be set before enabling the physical IRQ associated to the virtual IRQ.

Signed-off-by: Julien Grall 
Tested-by: Shanker Donthineni 

---

It might be possible to let any domain configure the IRQ
type (could be useful when passthrough an IRQ with ACPI). However, we would
need to consider any potential security impact beforehand.

Changes in v3:
- The current code only handle SPIs, add an assert to catch any
support PPIs without modifying this code.
- Tested by Shanker on QDF2XXX server

Changes in v2:
- Rename the patch
- Allow any DOM0 to set the IRQ type
- Re-use in part of vgic_get_virq_type from
"Configure SPI interrupt type and route to Dom0 dynamically".
- Add rationale why the IRQ type is set in enable
---
 xen/arch/arm/gic.c|  5 +++--
 xen/arch/arm/irq.c| 13 -
 xen/arch/arm/vgic.c   | 24 
 xen/include/asm-arm/gic.h |  3 +++
 xen/include/asm-arm/irq.h |  6 ++
 5 files changed, 48 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 72bb885..63c744a 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -97,7 +97,7 @@ void gic_restore_state(struct vcpu *v)
 }
 
 /* desc->irq needs to be disabled before calling this function */
-static void gic_set_irq_type(struct irq_desc *desc, unsigned int type)
+void gic_set_irq_type(struct irq_desc *desc, unsigned int type)
 {
 /*
  * IRQ must be disabled before configuring it (see 4.3.13 in ARM IHI
@@ -160,7 +160,8 @@ int gic_route_irq_to_guest(struct domain *d, unsigned int 
virq,
 desc->handler = gic_hw_ops->gic_guest_irq_type;
 set_bit(_IRQ_GUEST, >status);
 
-gic_set_irq_type(desc, desc->arch.type);
+if ( !irq_type_set_by_domain(d) )
+gic_set_irq_type(desc, desc->arch.type);
 gic_set_irq_priority(desc, priority);
 
 p->desc = desc;
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 3fc22f2..06d4843 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -395,6 +395,17 @@ bool_t is_assignable_irq(unsigned int irq)
 }
 
 /*
+ * Only the hardware domain is allowed to set the configure the
+ * interrupt type for now.
+ *
+ * XXX: See whether it is possible to let any domain configure the type.
+ */
+bool_t irq_type_set_by_domain(const struct domain *d)
+{
+return (d == hardware_domain);
+}
+
+/*
  * Route an IRQ to a specific guest.
  * For now only SPIs are assignable to the guest.
  */
@@ -449,7 +460,7 @@ int route_irq_to_guest(struct domain *d, unsigned int virq,
 
 spin_lock_irqsave(>lock, flags);
 
-if ( desc->arch.type == IRQ_TYPE_INVALID )
+if ( !irq_type_set_by_domain(d) && desc->arch.type == IRQ_TYPE_INVALID )
 {
 printk(XENLOG_G_ERR "IRQ %u has not been configured\n", irq);
 retval = -EIO;
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 938bc7d..0965119 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -340,6 +340,22 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r, int n)
 }
 }
 
+#define VGIC_ICFG_MASK(intr) (1 << ((2 * ((intr) % 16)) + 1))
+
+/* The function should be called with the rank lock taken */
+static inline unsigned int vgic_get_virq_type(struct vcpu *v, int n, int index)
+{
+struct vgic_irq_rank *r = vgic_get_rank(v, n);
+uint32_t tr = r->icfg[index >> 4];
+
+ASSERT(spin_is_locked(>lock));
+
+if ( tr & VGIC_ICFG_MASK(index) )
+return IRQ_TYPE_EDGE_RISING;
+else
+return IRQ_TYPE_LEVEL_HIGH;
+}
+
 void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
 {
 const unsigned long mask = r;
@@ -348,6 +364,7 @@ void vgic_enable_irqs(struct vcpu *v, 

[Xen-devel] [PATCH v3 4/9] xen/arm: gic: set_type: Pass the type in parameter rather than in desc->arch.type

[Julien Grall]

A follow-up patch will not store the type in desc->arch.type. Also, the
callback prototype is more logical.

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

---
Changes in v3:
- Add Stefano's reviewed-by

Changes in v2:
- gic_set_irq_type has been dropped by mistake in
gic_route_irq_to_xen. Re-add it!
---
 xen/arch/arm/gic-v2.c |  3 +--
 xen/arch/arm/gic-v3.c |  3 +--
 xen/arch/arm/gic.c| 10 +-
 xen/include/asm-arm/gic.h |  4 ++--
 4 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 69ed72d..9bd9d0b 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -236,11 +236,10 @@ static unsigned int gicv2_read_irq(void)
 return (readl_gicc(GICC_IAR) & GICC_IA_IRQ);
 }
 
-static void gicv2_set_irq_type(struct irq_desc *desc)
+static void gicv2_set_irq_type(struct irq_desc *desc, unsigned int type)
 {
 uint32_t cfg, actual, edgebit;
 unsigned int irq = desc->irq;
-unsigned int type = desc->arch.type;
 
 spin_lock();
 /* Set edge / level */
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 781f25c..b8be395 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -471,12 +471,11 @@ static inline uint64_t gicv3_mpidr_to_affinity(int cpu)
  MPIDR_AFFINITY_LEVEL(mpidr, 0));
 }
 
-static void gicv3_set_irq_type(struct irq_desc *desc)
+static void gicv3_set_irq_type(struct irq_desc *desc, unsigned int type)
 {
 uint32_t cfg, actual, edgebit;
 void __iomem *base;
 unsigned int irq = desc->irq;
-unsigned int type = desc->arch.type;
 
 /* SGI's are always edge-triggered not need to call GICD_ICFGR0 */
 ASSERT(irq >= NR_GIC_SGI);
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index c63c862..b9371a7 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -96,12 +96,12 @@ void gic_restore_state(struct vcpu *v)
 gic_restore_pending_irqs(v);
 }
 
-static void gic_set_irq_type(struct irq_desc *desc)
+static void gic_set_irq_type(struct irq_desc *desc, unsigned int type)
 {
 ASSERT(spin_is_locked(>lock));
-ASSERT(desc->arch.type != IRQ_TYPE_INVALID);
+ASSERT(type != IRQ_TYPE_INVALID);
 
-gic_hw_ops->set_irq_type(desc);
+gic_hw_ops->set_irq_type(desc, type);
 }
 
 static void gic_set_irq_priority(struct irq_desc *desc, unsigned int priority)
@@ -121,7 +121,7 @@ void gic_route_irq_to_xen(struct irq_desc *desc, unsigned 
int priority)
 
 desc->handler = gic_hw_ops->gic_host_irq_type;
 
-gic_set_irq_type(desc);
+gic_set_irq_type(desc, desc->arch.type);
 gic_set_irq_priority(desc, priority);
 }
 
@@ -154,7 +154,7 @@ int gic_route_irq_to_guest(struct domain *d, unsigned int 
virq,
 desc->handler = gic_hw_ops->gic_guest_irq_type;
 set_bit(_IRQ_GUEST, >status);
 
-gic_set_irq_type(desc);
+gic_set_irq_type(desc, desc->arch.type);
 gic_set_irq_priority(desc, priority);
 
 p->desc = desc;
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 3f39f79..2214e87 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -328,8 +328,8 @@ struct gic_hw_operations {
 void (*deactivate_irq)(struct irq_desc *irqd);
 /* Read IRQ id and Ack */
 unsigned int (*read_irq)(void);
-/* Set IRQ type - type is taken from desc->arch.type */
-void (*set_irq_type)(struct irq_desc *desc);
+/* Set IRQ type */
+void (*set_irq_type)(struct irq_desc *desc, unsigned int type);
 /* Set IRQ priority */
 void (*set_irq_priority)(struct irq_desc *desc, unsigned int priority);
 /* Send SGI */
-- 
1.9.1


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

[Xen-devel] [PATCH v3 0/9] xen/arm: Support SPIs routing

[Julien Grall]

Hello all,

Currently, Xen does not route SPIs to DOM0 when ACPI is inuse after
the functionality has been reverted in Xen 4.7 by commit 909bd14.

In the previous approach, the SPIs was routed when DOM0 was writing into
ISENABLER. However, this has resulted to deadlock (see more details in [1])
as soon as the IRQ was enabled by DOM0.

We have multiple solutions to route the IRQ:
1) Rework route_irq_to_guest to avoid the deadlock
2) Route and enable the IRQ outside of the emulation of ISENABLER
3) Remove the dependency on the IRQ type in the routing function
and route all the unused IRQs during domain building
4) Add a new hypercall to let DOM0 routing the IRQ

I think that 1) and 2) are not resilient because route_irq_to_guest may fail
and there is no way to report this error to the guest (except by killing it).

Furthermore, in solution 2) enabling the interrupt would need to be defer
until the routing has been done. This would require a lot of code duplication.

Which leave solution 3) and 4). The solution 4) requires to introduce a new
(or re-use one) stable hypercall. I am not sure why we ruled out this
solution when we reviewed the ACPI design document.

This patch series is implementing the 3rd solution which defer the IRQ
type configuration for DOM0 IRQ when ACPI is inuse. However, this will
slightly increase the memory usage of Xen (54KB).

I am happy to consider any other solutions.

This series has been tested with ACPI by Shanker on QDF2 server and
I tested it on Juno r2 with DT.

A branch with all the patches can be found here:

git://xenbits.xen.org/people/julieng/xen-unstable.git branch irq-routing-acpi-v3

All the patches but #7 have been reviewed/acked by Stefano.

Yours sincerely,

[1] http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg02633.html

Julien Grall (9):
  xen/arm: gic: Consolidate the IRQ affinity set in a single place
  xen/arm: gic: Do not configure affinity during routing
  xen/arm: gic: split set_irq_properties
  xen/arm: gic: set_type: Pass the type in parameter rather than in
desc->arch.type
  xen/arm: gic: Document how gic_set_irq_type should be called
  Revert "xen/arm: warn the user that we cannot route SPIs to Dom0 on
ACPI"
  xen/arm: Allow DOM0 to set the IRQ type
  xen/arm: acpi: route all unused IRQs to DOM0
  xen/arm: Fix coding style and update comment in acpi_route_spis

 xen/arch/arm/domain_build.c | 33 +++--
 xen/arch/arm/gic-v2.c   | 28 +---
 xen/arch/arm/gic-v3.c   | 22 ++
 xen/arch/arm/gic.c  | 36 ++--
 xen/arch/arm/irq.c  | 17 ++---
 xen/arch/arm/vgic.c | 37 +++--
 xen/include/asm-arm/gic.h   | 14 --
 xen/include/asm-arm/irq.h   |  6 ++
 8 files changed, 111 insertions(+), 82 deletions(-)

-- 
1.9.1


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

[Xen-devel] [PATCH v3 1/9] xen/arm: gic: Consolidate the IRQ affinity set in a single place

[Julien Grall]

The code to set the IRQ affinity is duplicated: once in
gicv{2,3}_set_properties and the other is gicv{2,3}_irq_set_affinity.

Remove the code from gicv{2,3}_set_properties and call directly the
affinity set helper from the common code.

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

---
Changes in v2:
- Add Stefano's reviewed-by
---
 xen/arch/arm/gic-v2.c | 10 +-
 xen/arch/arm/gic-v3.c | 10 --
 xen/arch/arm/gic.c|  3 ++-
 xen/include/asm-arm/gic.h |  1 -
 4 files changed, 3 insertions(+), 21 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 3893ece..6c7dbfe 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -236,16 +236,10 @@ static unsigned int gicv2_read_irq(void)
 return (readl_gicc(GICC_IAR) & GICC_IA_IRQ);
 }
 
-/*
- * needs to be called with a valid cpu_mask, ie each cpu in the mask has
- * already called gic_cpu_init
- */
 static void gicv2_set_irq_properties(struct irq_desc *desc,
-   const cpumask_t *cpu_mask,
-   unsigned int priority)
+ unsigned int priority)
 {
 uint32_t cfg, actual, edgebit;
-unsigned int mask = gicv2_cpu_mask(cpu_mask);
 unsigned int irq = desc->irq;
 unsigned int type = desc->arch.type;
 
@@ -276,8 +270,6 @@ static void gicv2_set_irq_properties(struct irq_desc *desc,
 IRQ_TYPE_LEVEL_HIGH;
 }
 
-/* Set target CPU mask (RAZ/WI on uniprocessor) */
-writeb_gicd(mask, GICD_ITARGETSR + irq);
 /* Set priority */
 writeb_gicd(priority, GICD_IPRIORITYR + irq);
 
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index cbda066..d6ab0e9 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -472,13 +472,10 @@ static inline uint64_t gicv3_mpidr_to_affinity(int cpu)
 }
 
 static void gicv3_set_irq_properties(struct irq_desc *desc,
- const cpumask_t *cpu_mask,
  unsigned int priority)
 {
 uint32_t cfg, actual, edgebit;
-uint64_t affinity;
 void __iomem *base;
-unsigned int cpu = gicv3_get_cpu_from_mask(cpu_mask);
 unsigned int irq = desc->irq;
 unsigned int type = desc->arch.type;
 
@@ -516,13 +513,6 @@ static void gicv3_set_irq_properties(struct irq_desc *desc,
 IRQ_TYPE_LEVEL_HIGH;
 }
 
-affinity = gicv3_mpidr_to_affinity(cpu);
-/* Make sure we don't broadcast the interrupt */
-affinity &= ~GICD_IROUTER_SPI_MODE_ANY;
-
-if ( irq >= NR_GIC_LOCAL_IRQS )
-writeq_relaxed(affinity, (GICD + GICD_IROUTER + irq * 8));
-
 /* Set priority */
 if ( irq < NR_GIC_LOCAL_IRQS )
 writeb_relaxed(priority, GICD_RDIST_SGI_BASE + GICR_IPRIORITYR0 + irq);
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 12bb0ab..5726a05 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -106,7 +106,8 @@ static void gic_set_irq_properties(struct irq_desc *desc,
const cpumask_t *cpu_mask,
unsigned int priority)
 {
-   gic_hw_ops->set_irq_properties(desc, cpu_mask, priority);
+gic_hw_ops->set_irq_properties(desc, priority);
+desc->handler->set_affinity(desc, cpu_mask);
 }
 
 /* Program the GIC to route an interrupt to the host (i.e. Xen)
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index b073c53..2fc6126 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -331,7 +331,6 @@ struct gic_hw_operations {
 unsigned int (*read_irq)(void);
 /* Set IRQ property */
 void (*set_irq_properties)(struct irq_desc *desc,
-   const cpumask_t *cpu_mask,
unsigned int priority);
 /* Send SGI */
 void (*send_SGI)(enum gic_sgi sgi, enum gic_sgi_mode irqmode,
-- 
1.9.1


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

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

[David Vrabel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Linus,

Please git pull the following tag:

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

xen: features and fixes for 4.8-rc0

- - ACPI support for guests on ARM platforms.
- - Generic steal time support for arm and x86.
- - Support cases where kernel cpu is not Xen VCPU number (e.g., if
  in-guest kexec is used).
- - Use the system workqueue instead of a custom workqueue in various
  places.

Thanks.

David

 Documentation/devicetree/bindings/arm/xen.txt |  35 +
 arch/arm/include/asm/xen/hypercall.h  |   1 +
 arch/arm/include/asm/xen/xen-ops.h|   6 +
 arch/arm/kernel/setup.c   |   2 +-
 arch/arm/xen/Makefile |   1 +
 arch/arm/xen/efi.c|  40 ++
 arch/arm/xen/enlighten.c  | 157 +++--
 arch/arm/xen/hypercall.S  |   1 +
 arch/arm64/include/asm/xen/xen-ops.h  |   6 +
 arch/arm64/kernel/setup.c |   3 +-
 arch/arm64/xen/Makefile   |   1 +
 arch/arm64/xen/hypercall.S|   1 +
 arch/x86/include/asm/cpu.h|   1 +
 arch/x86/include/asm/smp.h|   2 +
 arch/x86/include/asm/xen/cpuid.h  |   5 +-
 arch/x86/kernel/acpi/boot.c   |  16 ++-
 arch/x86/kernel/apic/apic.c   |   2 +
 arch/x86/kernel/setup_percpu.c|   3 +
 arch/x86/xen/efi.c| 111 +++
 arch/x86/xen/enlighten.c  |  49 +--
 arch/x86/xen/grant-table.c|  57 +---
 arch/x86/xen/irq.c|   3 +-
 arch/x86/xen/pmu.c|   2 +-
 arch/x86/xen/smp.c|  18 ++-
 arch/x86/xen/time.c   |  63 ++---
 arch/x86/xen/xen-ops.h|   1 +
 drivers/acpi/scan.c   |  74 ++
 drivers/block/xen-blkback/xenbus.c|  20 +--
 drivers/block/xen-blkfront.c  |  43 +++---
 drivers/firmware/efi/arm-runtime.c|   5 +
 drivers/firmware/efi/efi.c|  81 ---
 drivers/of/fdt.c  |  13 ++
 drivers/xen/Kconfig   |   2 +-
 drivers/xen/Makefile  |   1 +
 drivers/xen/arm-device.c  | 196 ++
 drivers/xen/efi.c | 173 +--
 drivers/xen/events/events_base.c  |  13 +-
 drivers/xen/events/events_fifo.c  |   2 +-
 drivers/xen/evtchn.c  |  43 +-
 drivers/xen/gntalloc.c|   2 +-
 drivers/xen/gntdev.c  |   2 +-
 drivers/xen/privcmd.c |   2 +-
 drivers/xen/time.c|  50 +--
 drivers/xen/xen-pciback/conf_space.c  |  22 ++-
 drivers/xen/xen-pciback/conf_space_header.c   |  57 +++-
 drivers/xen/xen-pciback/pciback.h |   1 -
 drivers/xen/xen-pciback/pciback_ops.c |   2 +-
 drivers/xen/xen-pciback/xenbus.c  |  10 +-
 drivers/xen/xenbus/xenbus_probe_frontend.c|  15 +-
 drivers/xen/xlate_mmu.c   |  77 ++
 include/linux/kernel_stat.h   |   1 -
 include/linux/of_fdt.h|   2 +
 include/uapi/xen/evtchn.h |  15 ++
 include/xen/interface/hvm/params.h|  40 +-
 include/xen/interface/memory.h|   1 +
 include/xen/interface/vcpu.h  |  24 ++--
 include/xen/interface/xen.h   |  17 ++-
 include/xen/xen-ops.h |  40 --
 kernel/sched/cputime.c|  10 --
 59 files changed, 1150 insertions(+), 493 deletions(-)

Amitoj Kaur Chawla (1):
  x86/xen: Use DIV_ROUND_UP

Bhaktipriya Shridhar (2):
  xen: xen-pciback: Remove create_workqueue
  xen: xenbus: Remove create_workqueue

Boris Ostrovsky (1):
  xen/PMU: Log VPMU initialization error at lower level

David Vrabel (1):
  xen/evtchn: add IOCTL_EVTCHN_RESTRICT

Jan Beulich (11):
  xen-pciback: drop unused function parameter of read_dev_bar()
  xen-pciback: drop rom_init()
  xen-pciback: fold read_dev_bar() into its now single caller
  xen-pciback: simplify determination of 64-bit memory resource
  xen-pciback: use const and unsigned in bar_init()
  xen-pciback: short-circuit read path used for merging write values
  xen-pciback: drop superfluous variables
  xen-blkback: prefer xenbus_scanf() over xenbus_gather()
  xen-blkfront: prefer xenbus_scanf() over xenbus_gather()
  xen-blkback: constify instance of "struct attribute_group"
  xen-blkback: really don't leak mode property

Re: [Xen-devel] [PATCH v2 0/9] xen/arm: Support SPIs routing

[Julien Grall]

On 14/07/16 19:17, Shanker Donthineni wrote:

Hi Julien,


Hello Shanker,


Tested-by: Shanker Donthineni

I have tested this patchset on Qualcomm Technologies QDF2XXX server
platform without any issue.


Thank you for testing this series on your platform. I have added your 
tested-by on patch #7 and #8 which contain meat of this series.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 0/6] libxl: extend device type framework

[Wei Liu]

Series pushed to staging.

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

Re: [Xen-devel] OVMF very slow on AMD

[Anthony PERARD]

On Wed, Jul 27, 2016 at 12:08:04PM +0100, Anthony PERARD wrote:
> I can try to describe how OVMF is setting up the memory.

From the start of the day:
setup gdt
cr0 = 0x4023

jump to 32bit
cr4 = 0x640

setup page tables:
page directory attributes: (PAGE_ACCESSED + PAGE_READ_WRITE + PAGE_PRESENT)
page tables attributes: (PAGE_2M_MBO + PAGE_ACCESSED + PAGE_DIRTY + 
PAGE_READ_WRITE + PAGE_PRESENT)
I think they map the all 4GB with 2MB pages.
set cr3.

enable PAE
set LME
set PG

jump to 64bit

I think that's it, before running this painfully slow decompression
function.

Is there something wrong, or maybe missing? Is the hypervisor or maybe
the hardware does not do the right thing?

Thanks,

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH v3] xen-blkfront: dynamic configuration of per-vbd resources

[Bob Liu]

On 07/27/2016 06:59 PM, Roger Pau Monné wrote:
> On Wed, Jul 27, 2016 at 11:21:25AM +0800, Bob Liu wrote:
> [...]
>> +static ssize_t dynamic_reconfig_device(struct blkfront_info *info, ssize_t 
>> count)
>> +{
>> +/*
>> + * Prevent new requests even to software request queue.
>> + */
>> +blk_mq_freeze_queue(info->rq);
>> +
>> +/*
>> + * Guarantee no uncompleted reqs.
>> + */
> 
> I'm also wondering, why do you need to guarantee that there are no 
> uncompleted requests? The resume procedure is going to call blkif_recover 
> that will take care of requeuing any unfinished requests that are on the 
> ring.
> 

Because there may have requests in the software request queue with more 
segments than
we can handle(if info->max_indirect_segments is reduced).

The blkif_recover() can't handle this since blk-mq was introduced,
because there is no way to iterate the sw-request queues(blk_fetch_request() 
can't be used by blk-mq).

So there is a bug in blkif_recover(), I was thinking implement the suspend 
function of blkfront_driver like:

+static int blkfront_suspend(struct xenbus_device *dev)
+{
+   blk_mq_freeze_queue(info->rq);
+   ..
+}
 static struct xenbus_driver blkfront_driver = {
.ids  = blkfront_ids,
.probe = blkfront_probe,
.remove = blkfront_remove,
+   .suspend = blkfront_suspend,
.resume = blkfront_resume,

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

Re: [Xen-devel] OVMF very slow on AMD

[Anthony PERARD]

On Fri, Jul 15, 2016 at 11:22:45AM -0400, Boris Ostrovsky wrote:
> On 07/15/2016 09:48 AM, Konrad Rzeszutek Wilk wrote:
> > On Thu, Jul 14, 2016 at 04:53:07PM +0100, Anthony PERARD wrote:
> >> Hi,
> >>
> >> I've been investigating why OVMF is very slow  in a Xen guest on an AMD
> >> host. This, I think, is the current failure that osstest is having.
> >>
> >> I've only look at a specific part of OVMF where the slowdown is very
> >> obvious on AMD vs Intel, the decompression.
> >>
> >> This is what I get on AMD, via the Xen serial console port:
> >>   Invoking OVMF ...
> >>   SecCoreStartupWithStack(0xFFFCC000, 0x818000)
> >> then, nothing for almost 1 minute, then the rest of the boot process.
> >> The same binary on Intel, the output does not stay "stuck" here.
> >>
> >> I could pin-point which part of the boot process takes a long time, but
> >> there is not anything obvious in there, just a loop that decompress the
> >> ovmf binary, with plenty of iteration.
> >> I tried `xentrace', but the trace does not show anything wrong, there is
> >> just an interrupt from time to time. I've tried to had some tracepoint
> >> inside this decompresion function in OVMF, but that did not reveal
> >> anything either, maybe there where not at the right place.
> >>
> >> Anyway, the function is: LzmaDec_DecodeReal() from the file
> >> IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/Sdk/C/LzmaDec.c
> >> you can get the assembly from this object:
> >> Build/OvmfX64/DEBUG_GCC49/X64/IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib/OUTPUT/Sdk/C/LzmaDec.obj
> >> This is with OVMF upstream (https://github.com/tianocore/edk2).
> 
> I don't know whether it's possible but can you extract this loop somehow
> and run it on baremetal? Or run the whole thing on baremetal.

I think I've managed to run the same function, with the same input, as a
linux process.

And, even within the guest, it takes about 0.3s to run, versus about 60s
when OVMF boot.

Could it be that, for some reason, access to the memory is uncached?
Only on AMD? And later, Linux is doing the right things?

I can try to describe how OVMF is setting up the memory.


> Also a newer compiler might potentially make a difference (if you are
> running on something older).

I have gcc (GCC) 6.1.1 20160707. I think that new enough, or too new
maybe.

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH] xen/domctl: Add DOMINFO_hap to xen_domctl_getdomaininfo

[George Dunlap]

On Fri, Jul 15, 2016 at 5:57 PM, Andrew Cooper
 wrote:
> This allows a toolstack to identify whether a running domain is using hardware
> assisted paging or not.
>
> The appropriate tests differ by architecture, so introduce
> arch_get_domain_info().  ARM unconditionally sets the new flag, while x86
> checks with the paging subsystem first.
>
> Signed-off-by: Andrew Cooper 

For THE REST:

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-blkfront: dynamic configuration of per-vbd resources

[Roger Pau Monné]

On Wed, Jul 27, 2016 at 11:21:25AM +0800, Bob Liu wrote:
[...]
> +static ssize_t dynamic_reconfig_device(struct blkfront_info *info, ssize_t 
> count)
> +{
> + /*
> +  * Prevent new requests even to software request queue.
> +  */
> + blk_mq_freeze_queue(info->rq);
> +
> + /*
> +  * Guarantee no uncompleted reqs.
> +  */

I'm also wondering, why do you need to guarantee that there are no 
uncompleted requests? The resume procedure is going to call blkif_recover 
that will take care of requeuing any unfinished requests that are on the 
ring.

> + if (part_in_flight(>gd->part0) || info->reconfiguring) {
> + blk_mq_unfreeze_queue(info->rq);
> + pr_err("Dev:%s busy, please retry later.\n", 
> dev_name(>xbdev->dev));
> + return -EBUSY;
> + }

Roger.

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

Re: [Xen-devel] [PATCH v2 2/3] xen-blkfront: introduce blkif_set_queue_limits()

[Roger Pau Monné]

On Tue, Jul 26, 2016 at 01:19:36PM +0800, Bob Liu wrote:
> blk_mq_update_nr_hw_queues() reset all queue limits to default which it's not
> as xen-blkfront expected, introducing blkif_set_queue_limits() to reset limits
> with initial correct values.
> 
> Signed-off-by: Bob Liu 

Acked-by: Roger Pau Monné 

Roger.

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

[Xen-devel] VM save/restore on Xen ARM

[Julien Grall]

Hello Chenxiao,

You mentioned that you were working on save/restore for Xen ARM on the 
hikey board a couple of months [1].


I am wondering if you are still working on? If so, do you have any plan 
to upstream it?


Regards,

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2016-05/msg02681.html


--
Julien Grall

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

Re: [Xen-devel] [PATCH 18/22] xen/arm: p2m: Rework the context switch to another VTTBR in flush_tlb_domain

[Julien Grall]

Hi Stefano,

On 27/07/16 02:12, Stefano Stabellini wrote:

On Wed, 20 Jul 2016, Julien Grall wrote:

The current implementation of flush_tlb_domain is relying on the domain
to have a single p2m. With the upcoming feature altp2m, a single domain
may have different p2m. So we would need to switch to the correct p2m in
order to flush the TLBs.

Rather than checking whether the domain is not the current domain, check
whether the VTTBR is different. The resulting assembly code is much
smaller: from 38 instructions (+ 2 functions call) to 22 instructions.


That's true but SYSREG reads are more expensive than regular
instructions.


This argument is not really true. The ARM ARM (D7-1879 in ARM DDI 
0487A.j) says: "Reads of the System registers can occur out of order 
with respect to earlier instructions executed on the same PE, provided 
that any data dependencies between the instructions are respected". So 
It will depend on how the micro-architecture implemented access to SYSREG.


However, the current code already contains plenty of SYSREG read access 
(via the macro current using TPIDR_EL2). So the number of SYSREG 
accesses stay exactly the same.


I also forgot to mention that the number of instructions in the function 
call (10 instructions). So we are down from 58 instructions to 22 
instructions.


Therefore, smaller code and likely better performance.





Signed-off-by: Julien Grall 
---
 xen/arch/arm/p2m.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index d1b6009..015c1e8 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -151,24 +151,28 @@ void p2m_restore_state(struct vcpu *n)

 void flush_tlb_domain(struct domain *d)
 {
+struct p2m_domain *p2m = >arch.p2m;
 unsigned long flags = 0;
+uint64_t ovttbr;

 /*
- * Update the VTTBR if necessary with the domain d. In this case,
- * it's only necessary to flush TLBs on every CPUs with the current VMID
- * (our domain).
+ * ARM only provides an instruction to flush TLBs for the current
+ * VMID. So switch to the VTTBR of a given P2M if different.
  */
-if ( d != current->domain )
+ovttbr = READ_SYSREG64(VTTBR_EL2);
+if ( ovttbr != p2m->vttbr )
 {
 local_irq_save(flags);
-p2m_load_VTTBR(d);
+WRITE_SYSREG64(p2m->vttbr, VTTBR_EL2);
+isb();
 }

 flush_tlb();

-if ( d != current->domain )
+if ( ovttbr != READ_SYSREG64(VTTBR_EL2) )


You should be able to remove this second SYSREG read and optimize the
code further.


I should be able, however I think it will not bring much more 
optimization here but obfuscating a bit more the code.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3] xen-blkfront: dynamic configuration of per-vbd resources

[Roger Pau Monné]

On Wed, Jul 27, 2016 at 05:12:22PM +0800, Bob Liu wrote:
> 
> On 07/27/2016 04:07 PM, Roger Pau Monné wrote:
> ..[snip]..
> >> @@ -2443,6 +2674,22 @@ static void blkfront_connect(struct blkfront_info 
> >> *info)
> >>return;
> >>}
> >>  
> >> +  err = device_create_file(>xbdev->dev, 
> >> _attr_max_ring_page_order);
> >> +  if (err)
> >> +  goto fail;
> >> +
> >> +  err = device_create_file(>xbdev->dev, 
> >> _attr_max_indirect_segs);
> >> +  if (err) {
> >> +  device_remove_file(>xbdev->dev, 
> >> _attr_max_ring_page_order);
> >> +  goto fail;
> >> +  }
> >> +
> >> +  err = device_create_file(>xbdev->dev, _attr_max_queues);
> >> +  if (err) {
> >> +  device_remove_file(>xbdev->dev, 
> >> _attr_max_ring_page_order);
> >> +  device_remove_file(>xbdev->dev, 
> >> _attr_max_indirect_segs);
> >> +  goto fail;
> >> +  }
> >>xenbus_switch_state(info->xbdev, XenbusStateConnected);
> >>  
> >>/* Kick pending requests. */
> >> @@ -2453,6 +2700,12 @@ static void blkfront_connect(struct blkfront_info 
> >> *info)
> >>add_disk(info->gd);
> >>  
> >>info->is_ready = 1;
> >> +  return;
> >> +
> >> +fail:
> >> +  blkif_free(info, 0);
> >> +  xlvbd_release_gendisk(info);
> >> +  return;
> > 
> > Hm, I'm not sure whether this chunk should be in a separate patch, it seems 
> > like blkfront_connect doesn't properly cleanup on error (if 
> > xlvbd_alloc_gendisk fails blkif_free will not be called). Do you think you 
> > could send the addition of the 'fail' label as a separate patch and fix the 
> > error path of xlvbd_alloc_gendisk?
> > 
> 
> Sure, will fix all of your comments above.
> 
> >>  }
> >>  
> >>  /**
> >> @@ -2500,8 +2753,16 @@ static void blkback_changed(struct xenbus_device 
> >> *dev,
> >>break;
> >>  
> >>case XenbusStateClosed:
> >> -  if (dev->state == XenbusStateClosed)
> >> +  if (dev->state == XenbusStateClosed) {
> >> +  if (info->reconfiguring)
> >> +  if (blkfront_resume(info->xbdev)) {
> > 
> > Could you please join those two conditions:
> > 
> > if (info->reconfiguring && blkfront_resume(info->xbdev)) { ...
> > 
> > Also, I'm not sure this is correct, if blkfront sees the "Closing" state on 
> > blkback it will try to close the frontend and destroy the block device (see 
> > blkfront_closing), and this should be avoided. You should call 
> > blkfront_resume as soon as you see the backend move to the Closed or 
> > Closing 
> > states, without calling blkfront_closing.
> > 
> 
> I didn't get how this can happen, backend state won't be changed to 'Closing' 
> before blkfront_closing() is called.
> So I think current logic is fine.

I see, in dynamic_reconfig_device you change the frontend state to "Closed". 
Then if the backend switches to state "Closing" blkfront will call 
blkfront_closing, but that won't do anything because the frontend state is 
already at the "Closed" state, at which point you just wait for the backend 
to finally reach state "Closed" in order to perform the reconnection. I 
stand corrected, I think the current logic is indeed fine.
 
Roger.

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

Re: [Xen-devel] [PATCH 16/22] xen/arm: p2m: Move the vttbr field from arch_domain to p2m_domain

[Julien Grall]

Hi Stefano,

On 27/07/16 01:57, Stefano Stabellini wrote:

On Wed, 20 Jul 2016, Julien Grall wrote:

The field vttbr holds the base address of the translation table for
guest. Its value will depends on how the p2m has been initialized and
will only be used by the code code.

   ^ code code?


I think I wanted to say "P2M code".

Regards,




So move the field from arch_domain to p2m_domain. This will also ease
the implementation of altp2m.
---
 xen/arch/arm/p2m.c   | 11 +++
 xen/arch/arm/traps.c |  2 +-
 xen/include/asm-arm/domain.h |  1 -
 xen/include/asm-arm/p2m.h|  3 +++
 4 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index c407e6a..c52081a 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -107,10 +107,14 @@ void dump_p2m_lookup(struct domain *d, paddr_t addr)

 static void p2m_load_VTTBR(struct domain *d)
 {
+struct p2m_domain *p2m = >arch.p2m;
+
 if ( is_idle_domain(d) )
 return;
-BUG_ON(!d->arch.vttbr);
-WRITE_SYSREG64(d->arch.vttbr, VTTBR_EL2);
+
+ASSERT(p2m->vttbr);
+
+WRITE_SYSREG64(p2m->vttbr, VTTBR_EL2);
 isb(); /* Ensure update is visible */
 }

@@ -1298,8 +1302,7 @@ static int p2m_alloc_table(struct domain *d)

 p2m->root = page;

-d->arch.vttbr = page_to_maddr(p2m->root)
-| ((uint64_t)p2m->vmid&0xff)<<48;
+p2m->vttbr = page_to_maddr(p2m->root) | ((uint64_t)p2m->vmid & 0xff) << 48;

 /*
  * Make sure that all TLBs corresponding to the new VMID are flushed
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 06a8ee5..65c6fb4 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -880,7 +880,7 @@ void vcpu_show_registers(const struct vcpu *v)
 ctxt.ifsr32_el2 = v->arch.ifsr;
 #endif

-ctxt.vttbr_el2 = v->domain->arch.vttbr;
+ctxt.vttbr_el2 = v->domain->arch.p2m.vttbr;

 _show_registers(>arch.cpu_info->guest_cpu_user_regs, , 1, v);
 }
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 4e9d8bf..9452fcd 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -48,7 +48,6 @@ struct arch_domain

 /* Virtual MMU */
 struct p2m_domain p2m;
-uint64_t vttbr;

 struct hvm_domain hvm_domain;
 gfn_t *grant_table_gfn;
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index ce28e8a..53c4d78 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -32,6 +32,9 @@ struct p2m_domain {
 /* Current VMID in use */
 uint8_t vmid;

+/* Current Translation Table Base Register for the p2m */
+uint64_t vttbr;
+
 /*
  * Highest guest frame that's ever been mapped in the p2m
  * Only takes into account ram and foreign mapping
--
1.9.1





--
Julien Grall

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

Re: [Xen-devel] [PATCH v8] x86/mem-sharing: mem-sharing a range of memory

[Andrew Cooper]

On 27/07/16 10:01, George Dunlap wrote:
> On 26/07/16 23:43, Andrew Cooper wrote:
>> On 26/07/2016 16:49, George Dunlap wrote:
>>> On Tue, Jul 26, 2016 at 4:22 PM, Tamas K Lengyel
>>>  wrote:
 On Tue, Jul 26, 2016 at 3:12 AM, George Dunlap  
 wrote:
> On Wed, Jul 20, 2016 at 7:01 PM, Tamas K Lengyel
>  wrote:
>> Currently mem-sharing can be performed on a page-by-page basis from the 
>> control
>> domain. However, this process is quite wasteful when a range of pages 
>> have to
>> be deduplicated.
>>
>> This patch introduces a new mem_sharing memop for range sharing where
>> the user doesn't have to separately nominate each page in both the 
>> source and
>> destination domain, and the looping over all pages happen in the 
>> hypervisor.
>> This significantly reduces the overhead of sharing a range of memory.
>>
>> Signed-off-by: Tamas K Lengyel 
>> Acked-by: Wei Liu 
>> Reviewed-by: Andrew Cooper 
>> ---
>> Cc: Ian Jackson 
>> Cc: George Dunlap 
>> Cc: Jan Beulich 
>> Cc: Andrew Cooper 
>>
>> v8: style fixes and minor adjustments
>> ---
>>  tools/libxc/include/xenctrl.h|  15 
>>  tools/libxc/xc_memshr.c  |  19 +
>>  tools/tests/mem-sharing/memshrtool.c |  22 ++
>>  xen/arch/x86/mm/mem_sharing.c| 140 
>> +++
>>  xen/include/public/memory.h  |  10 ++-
>>  5 files changed, 205 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/libxc/include/xenctrl.h 
>> b/tools/libxc/include/xenctrl.h
>> index e904bd5..3782eff 100644
>> --- a/tools/libxc/include/xenctrl.h
>> +++ b/tools/libxc/include/xenctrl.h
>> @@ -2334,6 +2334,21 @@ int xc_memshr_add_to_physmap(xc_interface *xch,
>>  domid_t client_domain,
>>  unsigned long client_gfn);
>>
>> +/* Allows to deduplicate a range of memory of a client domain. Using
>> + * this function is equivalent of calling xc_memshr_nominate_gfn for 
>> each gfn
>> + * in the two domains followed by xc_memshr_share_gfns.
>> + *
>> + * May fail with -EINVAL if the source and client domain have different
>> + * memory size or if memory sharing is not enabled on either of the 
>> domains.
>> + * May also fail with -ENOMEM if there isn't enough memory available to 
>> store
>> + * the sharing metadata before deduplication can happen.
>> + */
>> +int xc_memshr_range_share(xc_interface *xch,
>> +  domid_t source_domain,
>> +  domid_t client_domain,
>> +  uint64_t start,
>> +  uint64_t end);
>> +
>>  /* Debug calls: return the number of pages referencing the shared frame 
>> backing
>>   * the input argument. Should be one or greater.
>>   *
>> diff --git a/tools/libxc/xc_memshr.c b/tools/libxc/xc_memshr.c
>> index deb0aa4..2b871c7 100644
>> --- a/tools/libxc/xc_memshr.c
>> +++ b/tools/libxc/xc_memshr.c
>> @@ -181,6 +181,25 @@ int xc_memshr_add_to_physmap(xc_interface *xch,
>>  return xc_memshr_memop(xch, source_domain, );
>>  }
>>
>> +int xc_memshr_range_share(xc_interface *xch,
>> +  domid_t source_domain,
>> +  domid_t client_domain,
>> +  uint64_t start,
>> +  uint64_t end)
>> +{
>> +xen_mem_sharing_op_t mso;
>> +
>> +memset(, 0, sizeof(mso));
>> +
>> +mso.op = XENMEM_sharing_op_range_share;
>> +
>> +mso.u.range.client_domain = client_domain;
>> +mso.u.range.start = start;
>> +mso.u.range.end = end;
>> +
>> +return xc_memshr_memop(xch, source_domain, );
>> +}
>> +
>>  int xc_memshr_domain_resume(xc_interface *xch,
>>  domid_t domid)
>>  {
>> diff --git a/tools/tests/mem-sharing/memshrtool.c 
>> b/tools/tests/mem-sharing/memshrtool.c
>> index 437c7c9..2af6a9e 100644
>> --- a/tools/tests/mem-sharing/memshrtool.c
>> +++ b/tools/tests/mem-sharing/memshrtool.c
>> @@ -24,6 +24,8 @@ static int usage(const char* prog)
>>  printf("  nominate- Nominate a page for 
>> sharing.\n");
>>  printf("  share  
>> \n");
>>  printf("  - Share two pages.\n");
>> +printf("  range
>> \n");
>> +printf("  - Share pages between domains in 
>> range.\n");
>>  printf(" 

Re: [Xen-devel] [PATCH 09/22] xen/arm: p2m: Use a whitelist rather than blacklist in get_page_from_gfn

[Julien Grall]

On 26/07/16 23:44, Stefano Stabellini wrote:

On Wed, 20 Jul 2016, Julien Grall wrote:

Currently, the check in get_page_from_gfn is using a blacklist. This is
very fragile because we may forgot to update the check when a new p2m
type is added.

To avoid any possible issue, use a whitelist. All type backed by a RAM
page can could potential be valid. The check is borrowed from x86.

Signed-off-by: Julien Grall 
---
 xen/include/asm-arm/p2m.h | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 3091c04..78d37ab 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -104,9 +104,16 @@ typedef enum {
 #define P2M_RAM_TYPES (p2m_to_mask(p2m_ram_rw) |\
p2m_to_mask(p2m_ram_ro))

+/* Grant mapping types, which map to a real frame in another VM */
+#define P2M_GRANT_TYPES (p2m_to_mask(p2m_grant_map_rw) |  \
+ p2m_to_mask(p2m_grant_map_ro))
+
 /* Useful predicates */
 #define p2m_is_ram(_t) (p2m_to_mask(_t) & P2M_RAM_TYPES)
 #define p2m_is_foreign(_t) (p2m_to_mask(_t) & p2m_to_mask(p2m_map_foreign))
+#define p2m_is_any_ram(_t) (p2m_to_mask(_t) &   \
+(P2M_RAM_TYPES | P2M_GRANT_TYPES |  \
+ p2m_to_mask(p2m_map_foreign)))

 static inline
 void p2m_mem_access_emulate_check(struct vcpu *v,
@@ -224,7 +231,7 @@ static inline struct page_info *get_page_from_gfn(
 if (t)
 *t = p2mt;

-if ( p2mt == p2m_invalid || p2mt == p2m_mmio_direct )
+if ( !p2m_is_any_ram(p2mt) )
 return NULL;


What about the iommu mappings?


iommu mappings (p2m_iommu_map_*) are special mappings for the direct 
mapping workaround. They should not be used in get_page_from_gfn.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 06/22] xen/arm: p2m: Use the typesafe MFN in mfn_to_p2m_entry

[Julien Grall]

Hi Stefano,

On 26/07/16 23:28, Stefano Stabellini wrote:

On Wed, 20 Jul 2016, Julien Grall wrote:

@@ -411,7 +411,7 @@ static int p2m_create_table(struct domain *d, lpae_t *entry,
 if ( splitting )
 {
 p2m_type_t t = entry->p2m.type;
-unsigned long base_pfn = entry->p2m.base;
+mfn_t mfn = _mfn(entry->p2m.base);
 int i;

 /*
@@ -420,8 +420,9 @@ static int p2m_create_table(struct domain *d, lpae_t *entry,
  */
  for ( i=0 ; i < LPAE_ENTRIES; i++ )
  {
- pte = mfn_to_p2m_entry(base_pfn + (i<<(level_shift-LPAE_SHIFT)),
-MATTR_MEM, t, p2m->default_access);
+ pte = mfn_to_p2m_entry(mfn, MATTR_MEM, t, p2m->default_access);
+
+ mfn = mfn_add(mfn, 1UL << (level_shift - LPAE_SHIFT));


Should we be incrementing mfn before calling mfn_to_p2m_entry?


No. The base of the superpage is mfn, after splitting the first entry 
will be equal to the base, the second entry base + level_size...


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3] xen-blkfront: dynamic configuration of per-vbd resources

[Paul Durrant]

> -Original Message-
[snip]
> >
> > Also, I'm not sure this is correct, if blkfront sees the "Closing" state on
> > blkback it will try to close the frontend and destroy the block device (see
> > blkfront_closing), and this should be avoided. You should call
> > blkfront_resume as soon as you see the backend move to the Closed or
> Closing
> > states, without calling blkfront_closing.
> >
> 
> I didn't get how this can happen, backend state won't be changed to 'Closing'
> before blkfront_closing() is called.
> So I think current logic is fine.
> 

Backends can go to closing before frontends, when the PV device is being 
detached.

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

Re: [Xen-devel] [PATCH v3] xen-blkfront: dynamic configuration of per-vbd resources

[Bob Liu]

On 07/27/2016 04:07 PM, Roger Pau Monné wrote:
..[snip]..
>> @@ -2443,6 +2674,22 @@ static void blkfront_connect(struct blkfront_info 
>> *info)
>>  return;
>>  }
>>  
>> +err = device_create_file(>xbdev->dev, 
>> _attr_max_ring_page_order);
>> +if (err)
>> +goto fail;
>> +
>> +err = device_create_file(>xbdev->dev, 
>> _attr_max_indirect_segs);
>> +if (err) {
>> +device_remove_file(>xbdev->dev, 
>> _attr_max_ring_page_order);
>> +goto fail;
>> +}
>> +
>> +err = device_create_file(>xbdev->dev, _attr_max_queues);
>> +if (err) {
>> +device_remove_file(>xbdev->dev, 
>> _attr_max_ring_page_order);
>> +device_remove_file(>xbdev->dev, 
>> _attr_max_indirect_segs);
>> +goto fail;
>> +}
>>  xenbus_switch_state(info->xbdev, XenbusStateConnected);
>>  
>>  /* Kick pending requests. */
>> @@ -2453,6 +2700,12 @@ static void blkfront_connect(struct blkfront_info 
>> *info)
>>  add_disk(info->gd);
>>  
>>  info->is_ready = 1;
>> +return;
>> +
>> +fail:
>> +blkif_free(info, 0);
>> +xlvbd_release_gendisk(info);
>> +return;
> 
> Hm, I'm not sure whether this chunk should be in a separate patch, it seems 
> like blkfront_connect doesn't properly cleanup on error (if 
> xlvbd_alloc_gendisk fails blkif_free will not be called). Do you think you 
> could send the addition of the 'fail' label as a separate patch and fix the 
> error path of xlvbd_alloc_gendisk?
> 

Sure, will fix all of your comments above.

>>  }
>>  
>>  /**
>> @@ -2500,8 +2753,16 @@ static void blkback_changed(struct xenbus_device *dev,
>>  break;
>>  
>>  case XenbusStateClosed:
>> -if (dev->state == XenbusStateClosed)
>> +if (dev->state == XenbusStateClosed) {
>> +if (info->reconfiguring)
>> +if (blkfront_resume(info->xbdev)) {
> 
> Could you please join those two conditions:
> 
> if (info->reconfiguring && blkfront_resume(info->xbdev)) { ...
> 
> Also, I'm not sure this is correct, if blkfront sees the "Closing" state on 
> blkback it will try to close the frontend and destroy the block device (see 
> blkfront_closing), and this should be avoided. You should call 
> blkfront_resume as soon as you see the backend move to the Closed or Closing 
> states, without calling blkfront_closing.
> 

I didn't get how this can happen, backend state won't be changed to 'Closing' 
before blkfront_closing() is called.
So I think current logic is fine.

Btw: could you please ack [PATCH v2 2/3] xen-blkfront: introduce 
blkif_set_queue_limits()?

Thank you!
Bob

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

Re: [Xen-devel] [PATCH linux v3 0/9] xen: pvhvm: support bootup on secondary vCPUs

[Vitaly Kuznetsov]

Stefano Stabellini  writes:

> On Tue, 26 Jul 2016, Vitaly Kuznetsov wrote:
>> David Vrabel  writes:
>> 
>> > On 26/07/16 13:30, Vitaly Kuznetsov wrote:
>> >> It may happen that Xen's and Linux's ideas of vCPU id diverge. In
>> >> particular, when we crash on a secondary vCPU we may want to do kdump
>> >> and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting
>> >> on the vCPU which crashed. This doesn't work very well for PVHVM guests as
>> >> we have a number of hypercalls where we pass vCPU id as a parameter. These
>> >> hypercalls either fail or do something unexpected. To solve the issue we
>> >> need to have a mapping between Linux's and Xen's vCPU ids.
>> >> 
>> >> This series solves the issue for x86 PVHVM guests. PV guests don't (and
>> >> probably won't) support kdump so I always assume Xen's vCPU id == Linux's
>> >> vCPU id. ARM guests will probably need to get proper mapping once we start
>> >> supporting kexec/kdump there.
>> >> 
>> >> Changes since v2:
>> >> - Use 'uint32_t' for xen_vcpu_id mapping [Julien Grall]
>> >> - Rebased to linux-4.7
>> >
>> > I already applied v2.  If you provide an incremental patch I can queue
>> > it for 4.9.
>> 
>> Ok,
>> 
>> in that case we can wait till the real mapping is done for ARM to change
>> the type of xen_vcpu_id I guess.
>
> It would still be nice to make the change. Please send it as an
> incremental patch. It is OK if it is queued for 4.9.

Sure, will do.

-- 
  Vitaly

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

Re: [Xen-devel] [PATCH v8] x86/mem-sharing: mem-sharing a range of memory

[George Dunlap]

On 26/07/16 23:43, Andrew Cooper wrote:
> On 26/07/2016 16:49, George Dunlap wrote:
>> On Tue, Jul 26, 2016 at 4:22 PM, Tamas K Lengyel
>>  wrote:
>>> On Tue, Jul 26, 2016 at 3:12 AM, George Dunlap  
>>> wrote:
 On Wed, Jul 20, 2016 at 7:01 PM, Tamas K Lengyel
  wrote:
> Currently mem-sharing can be performed on a page-by-page basis from the 
> control
> domain. However, this process is quite wasteful when a range of pages 
> have to
> be deduplicated.
>
> This patch introduces a new mem_sharing memop for range sharing where
> the user doesn't have to separately nominate each page in both the source 
> and
> destination domain, and the looping over all pages happen in the 
> hypervisor.
> This significantly reduces the overhead of sharing a range of memory.
>
> Signed-off-by: Tamas K Lengyel 
> Acked-by: Wei Liu 
> Reviewed-by: Andrew Cooper 
> ---
> Cc: Ian Jackson 
> Cc: George Dunlap 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
>
> v8: style fixes and minor adjustments
> ---
>  tools/libxc/include/xenctrl.h|  15 
>  tools/libxc/xc_memshr.c  |  19 +
>  tools/tests/mem-sharing/memshrtool.c |  22 ++
>  xen/arch/x86/mm/mem_sharing.c| 140 
> +++
>  xen/include/public/memory.h  |  10 ++-
>  5 files changed, 205 insertions(+), 1 deletion(-)
>
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index e904bd5..3782eff 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -2334,6 +2334,21 @@ int xc_memshr_add_to_physmap(xc_interface *xch,
>  domid_t client_domain,
>  unsigned long client_gfn);
>
> +/* Allows to deduplicate a range of memory of a client domain. Using
> + * this function is equivalent of calling xc_memshr_nominate_gfn for 
> each gfn
> + * in the two domains followed by xc_memshr_share_gfns.
> + *
> + * May fail with -EINVAL if the source and client domain have different
> + * memory size or if memory sharing is not enabled on either of the 
> domains.
> + * May also fail with -ENOMEM if there isn't enough memory available to 
> store
> + * the sharing metadata before deduplication can happen.
> + */
> +int xc_memshr_range_share(xc_interface *xch,
> +  domid_t source_domain,
> +  domid_t client_domain,
> +  uint64_t start,
> +  uint64_t end);
> +
>  /* Debug calls: return the number of pages referencing the shared frame 
> backing
>   * the input argument. Should be one or greater.
>   *
> diff --git a/tools/libxc/xc_memshr.c b/tools/libxc/xc_memshr.c
> index deb0aa4..2b871c7 100644
> --- a/tools/libxc/xc_memshr.c
> +++ b/tools/libxc/xc_memshr.c
> @@ -181,6 +181,25 @@ int xc_memshr_add_to_physmap(xc_interface *xch,
>  return xc_memshr_memop(xch, source_domain, );
>  }
>
> +int xc_memshr_range_share(xc_interface *xch,
> +  domid_t source_domain,
> +  domid_t client_domain,
> +  uint64_t start,
> +  uint64_t end)
> +{
> +xen_mem_sharing_op_t mso;
> +
> +memset(, 0, sizeof(mso));
> +
> +mso.op = XENMEM_sharing_op_range_share;
> +
> +mso.u.range.client_domain = client_domain;
> +mso.u.range.start = start;
> +mso.u.range.end = end;
> +
> +return xc_memshr_memop(xch, source_domain, );
> +}
> +
>  int xc_memshr_domain_resume(xc_interface *xch,
>  domid_t domid)
>  {
> diff --git a/tools/tests/mem-sharing/memshrtool.c 
> b/tools/tests/mem-sharing/memshrtool.c
> index 437c7c9..2af6a9e 100644
> --- a/tools/tests/mem-sharing/memshrtool.c
> +++ b/tools/tests/mem-sharing/memshrtool.c
> @@ -24,6 +24,8 @@ static int usage(const char* prog)
>  printf("  nominate- Nominate a page for sharing.\n");
>  printf("  share  
> \n");
>  printf("  - Share two pages.\n");
> +printf("  range
> \n");
> +printf("  - Share pages between domains in 
> range.\n");
>  printf("  unshare - Unshare a page by grabbing a 
> writable map.\n");
>  printf("  add-to-physmap 
> \n");
>  printf("  - 

Re: [Xen-devel] [PATCH v3] xen-blkfront: dynamic configuration of per-vbd resources

[Roger Pau Monné]

Hello,

Thanks for the fixes.

On Wed, Jul 27, 2016 at 11:21:25AM +0800, Bob Liu wrote:
> The current VBD layer reserves buffer space for each attached device based on
> three statically configured settings which are read at boot time.
>  * max_indirect_segs: Maximum amount of segments.
>  * max_ring_page_order: Maximum order of pages to be used for the shared ring.
>  * max_queues: Maximum of queues(rings) to be used.
> 
> But the storage backend, workload, and guest memory result in very different
> tuning requirements. It's impossible to centrally predict application
> characteristics so it's best to leave allow the settings can be dynamiclly
> adjusted based on workload inside the Guest.
> 
> Usage:
> Show current values:
> cat /sys/devices/vbd-xxx/max_indirect_segs
> cat /sys/devices/vbd-xxx/max_ring_page_order
> cat /sys/devices/vbd-xxx/max_queues
> 
> Write new values:
> echo  > /sys/devices/vbd-xxx/max_indirect_segs
> echo  > /sys/devices/vbd-xxx/max_ring_page_order
> echo  > /sys/devices/vbd-xxx/max_queues
> 
> Signed-off-by: Bob Liu 
> --
> v3:
>  * Remove new_max_indirect_segments.
>  * Fix BUG_ON().
> v2:
>  * Rename to max_ring_page_order.
>  * Remove the waiting code suggested by Roger.
> ---
>  drivers/block/xen-blkfront.c |  277 
> --
>  1 file changed, 269 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 1b4c380..57baa54 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -212,6 +212,10 @@ struct blkfront_info
>   /* Save uncomplete reqs and bios for migration. */
>   struct list_head requests;
>   struct bio_list bio_list;
> + /* For dynamic configuration. */
> + unsigned int reconfiguring:1;
> + unsigned int max_ring_page_order;
> + unsigned int max_queues;

max_{ring_page_order/queues} should be after max_indirect_segments, and 
reconfigurng should be of type bool (moreover when below you assign 'true' 
or 'false' to it).

>  };
>  
>  static unsigned int nr_minors;
> @@ -1350,6 +1354,31 @@ static void blkif_free(struct blkfront_info *info, int 
> suspend)
>   for (i = 0; i < info->nr_rings; i++)
>   blkif_free_ring(>rinfo[i]);
>  
> + /* Remove old xenstore nodes. */
> + if (info->nr_ring_pages > 1)
> + xenbus_rm(XBT_NIL, info->xbdev->nodename, "ring-page-order");
> +
> + if (info->nr_rings == 1) {
> + if (info->nr_ring_pages == 1) {
> + xenbus_rm(XBT_NIL, info->xbdev->nodename, "ring-ref");
> + } else {
> + for (i = 0; i < info->nr_ring_pages; i++) {
> + char ring_ref_name[RINGREF_NAME_LEN];
> +
> + snprintf(ring_ref_name, RINGREF_NAME_LEN, 
> "ring-ref%u", i);
> + xenbus_rm(XBT_NIL, info->xbdev->nodename, 
> ring_ref_name);
> + }
> + }
> + } else {
> + xenbus_rm(XBT_NIL, info->xbdev->nodename, 
> "multi-queue-num-queues");
> +
> + for (i = 0; i < info->nr_rings; i++) {
> + char queuename[QUEUE_NAME_LEN];
> +
> + snprintf(queuename, QUEUE_NAME_LEN, "queue-%u", i);
> + xenbus_rm(XBT_NIL, info->xbdev->nodename, queuename);
> + }
> + }
>   kfree(info->rinfo);
>   info->rinfo = NULL;
>   info->nr_rings = 0;
> @@ -1763,15 +1792,20 @@ static int talk_to_blkback(struct xenbus_device *dev,
>   const char *message = NULL;
>   struct xenbus_transaction xbt;
>   int err;
> - unsigned int i, max_page_order = 0;
> + unsigned int i, backend_max_order = 0;
>   unsigned int ring_page_order = 0;
>  
>   err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
> -"max-ring-page-order", "%u", _page_order);
> +"max-ring-page-order", "%u", _max_order);
>   if (err != 1)
>   info->nr_ring_pages = 1;
>   else {
> - ring_page_order = min(xen_blkif_max_ring_order, max_page_order);
> + if (info->max_ring_page_order)
> + /* Dynamic configured through /sys. */
> + ring_page_order = min(info->max_ring_page_order, 
> backend_max_order);
> + else
> + /* Default. */
> + ring_page_order = min(xen_blkif_max_ring_order, 
> backend_max_order);
>   info->nr_ring_pages = 1 << ring_page_order;

In order to avoid this 'if' here (and below), what do you think of assigning 
the global values to the blkfront_info structure in blkfront_probe? Then you 
would only have to do min(info->max_ring_page_order, backend_max_order) in 
order to get the min value.

>   }
>  
> @@ -1894,7 +1928,13 @@ static int negotiate_mq(struct blkfront_info *info)
>   if (err < 0)
>   

[Xen-devel] [distros-debian-squeeze test] 66838: tolerable trouble: blocked/broken

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-armhf-pvops 3 host-install(3)  broken like 66621
 build-armhf   3 host-install(3)  broken like 66621
 build-amd64-pvops 3 host-install(3)  broken like 66621
 build-i3863 host-install(3)  broken like 66621
 build-amd64   3 host-install(3)  broken like 66621
 build-i386-pvops  3 host-install(3)  broken like 66621

Tests which did not succeed, but are not blocking:
 test-amd64-i386-amd64-squeeze-netboot-pygrub  1 build-check(1) blocked n/a
 test-amd64-amd64-amd64-squeeze-netboot-pygrub  1 build-check(1)blocked n/a
 test-amd64-i386-i386-squeeze-netboot-pygrub  1 build-check(1)  blocked n/a
 test-amd64-amd64-i386-squeeze-netboot-pygrub  1 build-check(1) blocked n/a

baseline version:
 flight   66621

jobs:
 build-amd64  broken  
 build-armhf  broken  
 build-i386   broken  
 build-amd64-pvopsbroken  
 build-armhf-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-amd64-squeeze-netboot-pygrubblocked 
 test-amd64-i386-amd64-squeeze-netboot-pygrub blocked 
 test-amd64-amd64-i386-squeeze-netboot-pygrub blocked 
 test-amd64-i386-i386-squeeze-netboot-pygrub  blocked 



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

Logs, config files, etc. are available at
http://osstest.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