Re: [Xen-devel] [Qemu-devel] [RFC][PATCH 1/1] libxl: add one machine property to support IGD GFX passthrough

[Xu, Quan]

> -Original Message-
> From: xen-devel-boun...@lists.xen.org
> [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Wei Liu
> Sent: Friday, January 30, 2015 8:26 PM
> To: Chen, Tiejun
> Cc: Wei Liu; ian.campb...@citrix.com; m...@redhat.com; Ian Jackson;
> qemu-de...@nongnu.org; xen-devel@lists.xen.org; Gerd Hoffmann
> Subject: Re: [Xen-devel] [Qemu-devel] [RFC][PATCH 1/1] libxl: add one machine
> property to support IGD GFX passthrough
> 
> On Fri, Jan 30, 2015 at 08:56:48AM +0800, Chen, Tiejun wrote:
> [...]
> > >>>
> > >>>Just remember to handle old option in libxl if your old option is
> > >>>already released by some older version of QEMUs.
> > >>
> > >>I just drop that old option, -gfx_passthru, if we're under qemu
> > >>upstream circumstance, like this,
> > >>
> > >
> > >The question is, is there any version of qemu upstream that has been
> > >released that has the old option (-gfx-passthru)?
> >
> > No. Just now we're starting to support IGD passthrough in qemu upstream.
> >
> 
> Right, as of QEMU 2.2.0 there's no support of IGD passthrough in QMEU
> upstream.
> 

Just a question:
   Now what features do vt-d support? Thanks.

-Quan

> > >
> > >This gives us a situation that we need to support both the old
> > >(-gfx-passthru) and new (-igd-passthru) options. Presumably we
> > >(libxl) would need to fork a qemu process to determine which option
> > >it has and pass the right one.
> > >
> > >Or you can try to keep both old and new option at the same time but
> >
> > Yeah, actually I also have considered to keep both two options at the
> > same time. Its really friendly to any qemu version.
> >
> > >deprecate the old one. Then in a few qemu release cycles later (or
> >
> > This should be like 'accel=kvm' versus 'enable-kvm' in qemu upstream.
> > They're coexisted now but just the former is a modern option.
> >
> > >probably one year or two?) you can finally remove the old one. The
> > >point is that to give downstream (in this case, Xen) time to cope
> > >with the change.
> >
> > Here I'm fine to this way.
> >
> > So Gerd,
> >
> 
> So you don't actually need to ask Gerd this question because there is no old
> option to keep in qemu upstream.
> 
> Libxl (or any sensible toolstack) will just do the right thing to either pass
> -igd-passthru (or whatever you guys agree upon) to qemu upstream or pass
> -gfx-passthru to qemu traditional. :-)
> 
> Wei.
> 
> > What about this?
> >
> 
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

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

[Andrew Cooper]

On 30/01/2015 23:43, Daniel Kiper wrote:
> On Fri, Jan 30, 2015 at 07:06:53PM +, Andrew Cooper wrote:
>> On 30/01/15 17:54, Daniel Kiper wrote:
>>> +
>>> +efi_multiboot2_proto:
>>> +/* Skip Multiboot2 information fixed part */
>>> +lea MB2_fixed_sizeof(%ebx),%ecx
>>> +
>>> +0:
>>> +/* Get mem_lower from Multiboot2 information */
>>> +cmpl$MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,(%ecx)
>>> +jne 1f
>>> +
>>> +mov MB2_mem_lower(%ecx),%edx
>>> +jmp 4f
>>> +
>>> +1:
>>> +/* Get EFI SystemTable address from Multiboot2 information */
>>> +cmpl$MULTIBOOT2_TAG_TYPE_EFI64,(%ecx)
>>> +jne 2f
>>> +
>>> +lea MB2_efi64_st(%ecx),%esi
>>> +lea efi_st(%rip),%edi
>>> +movsq
>> This is complete overkill for copying a 64bit variable out of the tag
>> and into a local variable.  Just use a plain 64bit load and store.
> I am not sure what do you mean by "64bit load and store" but I have
> just realized that we do not need these variables. They are remnants
> from early developments when I thought that we need ImageHandle
> and SystemTable here and later somewhere else.

mov MB2_efi64_st(%rcx), %rdi
mov %rdi, efi_st(%rip)

But if they are not needed, drop the code completely.

>>> +jmp 4f
>>> +
>>> +3:
>>> +/* Is it the end of Multiboot2 information? */
>>> +cmpl$MULTIBOOT2_TAG_TYPE_END,(%ecx)
>>> +je  run_bs
>>> +
>>> +4:
>>> +/* Go to next Multiboot2 information tag */
>>> +add MB2_tag_size(%ecx),%ecx
>>> +add $(MULTIBOOT2_TAG_ALIGN-1),%ecx
>>> +and $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
>>> +jmp 0b
>>> +
>>> +run_bs:
>>> +push%rax
>>> +push%rdx
>> Does the EFI spec guarantee that we have a good stack to use at this point?
> Unified Extensible Firmware Interface Specification, Version 2.4 Errata B,
> section 2.3.4, x64 Platforms says: During boot services time the processor
> is in the following execution mode: ..., 128 KiB, or more, of available
> stack space. GRUB2 uses this stack too and do not move it to different
> memory region. So, I think that here we are on safe side.

Sounds ok then.

>
>>> +/* Initialize BSS (no nasty surprises!) */
>>> +lea __bss_start(%rip),%rdi
>>> +lea _end(%rip),%rcx
>>> +sub %rdi,%rcx
>>> +xor %rax,%rax
>> xor %eax,%eax is shorter.
>>
>>> +rep stosb
>> It would be more efficient to make sure that the linker aligns
>> __bss_start and _end on 8 byte boundaries, and use stosq instead.
> Right but just for this. Is it pays? We do this only once.

The BSS in Xen is 300k.  It is absolutely better to clear it 8 bytes at
a time rather than 1.

> However, if you wish...
>
>>> +mov efi_ih(%rip),%rdi   /* EFI ImageHandle */
>>> +mov efi_st(%rip),%rsi   /* EFI SystemTable */
>>> +callefi_multiboot2
>>> +
>>> +pop %rcx
>>> +pop %rax
>>> +
>>> +shl $10-4,%rcx  /* Convert multiboot2.mem_lower to 
>>> bytes/16 */
>>> +
>>> +cli
>> This looks suspiciously out of place.  Surely the EFI spec doesn't
>> permit entry with interrupts enabled?
> Unified Extensible Firmware Interface Specification, Version 2.4 Errata B,
> section 2.3.4, x64 Platforms says: During boot services time the processor
> is in the following execution mode: ..., Interrupts are enabled–though no
> interrupt services are supported other than the UEFI boot services timer
> functions (All loaded device drivers are serviced synchronously by 
> “polling.”).
> So, I think that we should use BS with interrupts enabled and disable
> them after ExitBootServices(). Hmmm... Now I think that we should use
> cli immediately after efi_multiboot2() call.

I presume then that the firmware has set up a valid idt somewhere and is
actually serving any interrupts we get.

> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> index f8be3dd..c5725ca 100644
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -75,6 +75,17 @@ static size_t wstrlen(const CHAR16 * s);
>  static int set_color(u32 mask, int bpp, u8 *pos, u8 *sz);
>  static bool_t match_guid(const EFI_GUID *guid1, const EFI_GUID *guid2);
>
> +static void efi_init(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable);
> +static void efi_console_set_mode(void);
> +static EFI_GRAPHICS_OUTPUT_PROTOCOL *efi_get_gop(void);
> +static UINTN efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
> +   UINTN cols, UINTN rows, UINTN depth);
> +static void efi_tables(void);
> +static void setup_efi_pci(void);
> +static void efi_variables(void);
> +static void efi_set_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop, UINTN 
> gop_mode);
> +static void efi_exit_boot(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
> *SystemTable);
> +
>> If any of these forward declarations are ne

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

[Daniel Kiper]

On Fri, Jan 30, 2015 at 07:06:53PM +, Andrew Cooper wrote:
> On 30/01/15 17:54, Daniel Kiper wrote:
> > Signed-off-by: Daniel Kiper 
> > ---
> >  xen/arch/x86/boot/head.S  |  174 
> > +++--
> >  xen/arch/x86/efi/efi-boot.h   |   29 +++
> >  xen/arch/x86/setup.c  |   23 ++---
> >  xen/arch/x86/x86_64/asm-offsets.c |2 +
> >  xen/common/efi/boot.c |   11 +++
> >  5 files changed, 222 insertions(+), 17 deletions(-)
> >
> > diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> > index 7861057..89f5aa7 100644
> > --- a/xen/arch/x86/boot/head.S
> > +++ b/xen/arch/x86/boot/head.S
> > @@ -8,6 +8,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  .text
> >  .code32
> > @@ -57,6 +58,9 @@ ENTRY(start)
> >  .long   .Lmultiboot2_info_req_end - .Lmultiboot2_info_req
> >  .long   MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO
> >  .long   MULTIBOOT2_TAG_TYPE_MMAP
> > +.long   MULTIBOOT2_TAG_TYPE_EFI_BS
> > +.long   MULTIBOOT2_TAG_TYPE_EFI64
> > +.long   MULTIBOOT2_TAG_TYPE_EFI64_IH
> >  .Lmultiboot2_info_req_end:
> >
> >  .align  MULTIBOOT2_TAG_ALIGN
> > @@ -80,6 +84,19 @@ ENTRY(start)
> >  .long   0 /* Number of the lines - no preference. */
> >  .long   0 /* Number of bits per pixel - no preference. */
> >
> > +/* Do not disable EFI boot services. */
> > +.align  MULTIBOOT2_TAG_ALIGN
> > +.short  MULTIBOOT2_HEADER_TAG_EFI_BS
> > +.short  MULTIBOOT2_HEADER_TAG_OPTIONAL
> > +.long   8 /* Tag size. */
> > +
> > +/* EFI64 entry point. */
> > +.align  MULTIBOOT2_TAG_ALIGN
> > +.short  MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI64
> > +.short  MULTIBOOT2_HEADER_TAG_OPTIONAL
> > +.long   12 /* Tag size. */
> > +.long   sym_phys(__efi64_start)
> > +
> >  /* Multiboot2 header end tag. */
> >  .align  MULTIBOOT2_TAG_ALIGN
> >  .short  MULTIBOOT2_HEADER_TAG_END
> > @@ -94,6 +111,17 @@ ENTRY(start)
> >  gdt_boot_descr:
> >  .word   6*8-1
> >  .long   sym_phys(trampoline_gdt)
> > +.long   0 /* Needed for 64-bit lgdt */
> > +
> > +cs32_switch_addr:
> > +.long   sym_phys(cs32_switch)
> > +.long   BOOT_CS32
>
> .word
>
> ljmpl refers to an m32:16 not an m32:32
>
> > +
> > +efi_st:
> > +.quad   0
> > +
> > +efi_ih:
> > +.quad   0
> >
> >  .Lbad_cpu_msg: .asciz "ERR: Not a 64-bit CPU!"
> >  .Lbad_ldr_msg: .asciz "ERR: Not a Multiboot bootloader!"
> > @@ -124,6 +152,133 @@ print_err:
> >  .Lhalt: hlt
> >  jmp .Lhalt
> >
> > +.code64
> > +
> > +__efi64_start:
> > +cld
> > +
> > +/* Bootloaders may set multiboot[12].mem_lower to a nonzero value 
> > */
> > +xor %edx,%edx
> > +
> > +/* Check for Multiboot2 bootloader */
> > +cmp $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
> > +je  efi_multiboot2_proto
> > +
> > +jmp not_multiboot
>
> not_multiboot is 32bit code.  You must drop out of 64bit before using
> it, or make a 64bit variant.
>
> > +
> > +efi_multiboot2_proto:
> > +/* Skip Multiboot2 information fixed part */
> > +lea MB2_fixed_sizeof(%ebx),%ecx
> > +
> > +0:
> > +/* Get mem_lower from Multiboot2 information */
> > +cmpl$MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,(%ecx)
> > +jne 1f
> > +
> > +mov MB2_mem_lower(%ecx),%edx
> > +jmp 4f
> > +
> > +1:
> > +/* Get EFI SystemTable address from Multiboot2 information */
> > +cmpl$MULTIBOOT2_TAG_TYPE_EFI64,(%ecx)
> > +jne 2f
> > +
> > +lea MB2_efi64_st(%ecx),%esi
> > +lea efi_st(%rip),%edi
> > +movsq
>
> This is complete overkill for copying a 64bit variable out of the tag
> and into a local variable.  Just use a plain 64bit load and store.

I am not sure what do you mean by "64bit load and store" but I have
just realized that we do not need these variables. They are remnants
from early developments when I thought that we need ImageHandle
and SystemTable here and later somewhere else.

> > +/* Do not go into real mode on EFI platform */
> > +movb$1,skip_realmode(%rip)
> > +
> > +jmp 4f
> > +
> > +2:
> > +/* Get EFI ImageHandle address from Multiboot2 information */
> > +cmpl$MULTIBOOT2_TAG_TYPE_EFI64_IH,(%ecx)
> > +jne 3f
> > +
> > +lea MB2_efi64_ih(%ecx),%esi
> > +lea efi_ih(%rip),%edi
> > +movsq
>
> And here.

Ditto.

> > +jmp 4f
> > +
> > +3:
> > +/* Is it the end of Multiboot2 information? */
> > +cmpl$MULTIBOOT2_TAG_TYPE_END,(%ecx)
> > +je  run_bs
> > +
> > +4:
> > +/* Go to next Multiboot2 information tag */
> > +add MB2_tag_size(%ecx),%ecx
> > +add $(MULTIBOOT2

Re: [Xen-devel] how to generate a smaller core with xm dump-core

[Don Slutz]

On 01/16/15 03:39, Zhenzhong Duan wrote:
> 在 2015/1/16 0:16, Don Slutz 写道:
>> On 01/15/15 05:20, Ian Campbell wrote:
>>> On Thu, 2015-01-15 at 11:31 +0800, Zhenzhong Duan wrote:
 Hi Maintainers,
...
>> If these are Linux guests then the patch:
>>
>> http://lists.xenproject.org/archives/html/xen-devel/2013-11/msg02351.html
>>
>> Can be used to enable crash to access the crashed guest and collect
>> some basic info. I would also include the output of xen-hvmctx and/or
>> xenctx.
>> -- This is the quick way I would do Ian's minicore .
>>
>> Note: dump-core currently does not include xen-hvmctx output (nor does
>> it include
>> xenctx -a output).
>>
>> Using the results from this may allow you to not need a copy of every
>> dump (
>> not to imply that 2 similar minicore's would insure that a copy of
>> each core
>> was not needed).
>>
>> I also think that makedumpfile can process a xen dump-core file and
>> make it
>> smaller.
> Looks similar as gdbsx.

Sigh, I somehow missing this email till now.

It is like gdbsx, but for crash not gdb.

> This patch will help if I could reproduce the issue locally.
> But I can't access customer's env in most situation and they will not
> wait me to do online debug remotely.

Clearly I did not get my message across. I was not trying to say
"reproduce the issue locally".  What I was trying to say was that
this patch (to generate code) that can be used in a script to generate a
"minicore".  Also a script could use this "minicore" to decide if a full
core was needed.

crash is good at providing a summary of a core and can give high level
info about the state of linux.  I do not know of scripts that use just
gdb that can get this data.

This would be a way to save time and storage.

(Info on crash at http://people.redhat.com/anderson/ )

For example:

[root@hyper-0-21-51 C63-min-tools]# xl list
NameID   Mem VCPUs  State
Time(s)
Domain-0 0  2048 4 r-
11563.1
C63-min-tools4  2080 1 ---sc-
   32.3
[root@hyper-0-21-51 C63-min-tools]# /usr/lib/xen/bin/xen-crashd 4 &
[1] 30786
[root@hyper-0-21-51 C63-min-tools]# 30 Jan 15 22:37:53.363 socket ready
on port  after 1 bind call
crash localhost:
/home/don/C63-min-tools/kernel-debuginfo-2.6.32-279/usr/lib/debug/lib/modules/2.6.32-279.el6.x86_64/vmlinux

crash 7.0.9
Copyright (C) 2002-2014  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
Copyright (C) 1999-2006  Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011  NEC Corporation
Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions.  Enter "help copying" to see the conditions.
This program has absolutely no warranty.  Enter "help warranty" for details.

30 Jan 15 22:38:03.373 Accepted a connection.
WARNING: daemon cannot access /proc/version

GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...

  KERNEL:
/home/don/C63-min-tools/kernel-debuginfo-2.6.32-279/usr/lib/debug/lib/modules/2.6.32-279.el6.x86_64/vmlinux
DUMPFILE: /dev/mem@localhost  (remote live system)
CPUS: 1
DATE: Fri Jan 30 22:16:13 2015
  UPTIME: 00:21:06
LOAD AVERAGE: 0.07, 0.05, 0.02
   TASKS: 96
NODENAME: C63-min-tools.tc5.don.cloudswitch.com
 RELEASE: 2.6.32-279.el6.x86_64
 VERSION: #1 SMP Fri Jun 22 12:19:21 UTC 2012
 MACHINE: x86_64  (2000 Mhz)
  MEMORY: 2 GB
 PID: 0
 COMMAND: "swapper"
TASK: 81a8d020  [THREAD_INFO: 81a0]
 CPU: 0
   STATE: TASK_RUNNING

crash> dmesg | tail -100
udev: renamed network interface rename17 to eth17
udev: renamed network interface eth5 to rename7
udev: renamed network interface eth9 to rename11
udev: renamed network interface rename14 to eth14
udev: renamed network interface eth4 to rename6
udev: renamed network interface eth8 to rename10
udev: renamed network interface eth2 to rename4
udev: renamed network interface eth6 to rename8
udev: renamed network interface eth1 to rename3
udev: renamed network interface eth0 to eth18
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 0:0:1:0: Attached scsi generic sg1 type 0
sr 1:0:0:0: Attached scsi generic sg2 type 5
sr 1:0:1:0: Attached scsi generic sg3 type 5
piix4_smbus :00:07.3: SMBus Host Controller at 0xb100, revision 0
shpchp: Standa

Re: [Xen-devel] [RFC v2] misc/xenmicrocode: Upload /lib/firmware/ to the hypervisor

[Luis R. Rodriguez]

On Fri, Jan 30, 2015 at 08:37:33PM +, Andrew Cooper wrote:
> On 30/01/15 19:51, Luis R. Rodriguez wrote:
> > On Fri, Jan 30, 2015 at 02:23:48PM +, Andrew Cooper wrote:
> >> On 30/01/15 01:14, Luis R. Rodriguez wrote:
> >>> From: "Luis R. Rodriguez" 
> >>>
> >>> There are several ways that a Xen system can update the
> >>> CPU microcode on a pvops kernel [0] now, the preferred way
> >>> is through the early microcode update mechanism. At run
> >>> time folks should use this new xenmicrocode tool and use
> >>> the same CPU microcode file as present on /lib/firmware.
> >>>
> >>> Some distributions may use the historic sysfs rescan interface,
> >>> users of that mechanism should be aware that the interface will
> >>> not be available when using Xen and as such should first check
> >>> the presence of the interface before usage, as an alternative
> >>> this xenmicrocode tool can be used on priviledged domains.
> >>>
> >>> Folks wishing to update CPU microcode at run time should be
> >>> aware that not all CPU microcode can be updated on a system
> >>> and should take care to ensure that only known-to-work and
> >>> supported CPU microcode updates are used [0]. To avoid issues
> >>> with delays on the hypercall / microcode update this
> >>> implementation will quiesce all domains prior to updating
> >>> the microcode, and then only queisce'd domains will be
> >>> unpaused once done.
> >>>
> >>> [0] http://wiki.xenproject.org/wiki/XenParavirtOps/microcode_update
> >>>
> >>> Based on original work by: Konrad Rzeszutek Wilk 
> >>> Cc: Konrad Rzeszutek Wilk 
> >>> Cc: Andrew Cooper 
> >>> Cc: Borislav Petkov 
> >>> Cc: Takashi Iwai 
> >>> Cc: Olaf Hering 
> >>> Cc: Jan Beulich 
> >>> Cc: Jason Douglas 
> >>> Cc: Juergen Gross 
> >>> Cc: Michal Marek 
> >>> Cc: Henrique de Moraes Holschuh 
> >>> Signed-off-by: Konrad Rzeszutek Wilk 
> >>> Signed-off-by: Luis R. Rodriguez 
> >>> ---
> >>>
> >>> Just wrote this, haven't tested it. This does some queiscing prior
> >>> to doing the microcode update. The quiescing is done by pausing
> >>> all domains. Once the microcode update is done we only unpause
> >>> domains which we queisced as part of our work. Let me know if this
> >>> is on the right track to help avoid issues noted on the list.
> >> There is also a TOCTOU race with your paused check, which itself is
> >> buggy as it you should unconditionally pause all VMs (userspace pause
> >> refcounting has been fixed for a little while now).
> > Also, currently __domain_pause_by_systemcontroller() has a limit to 255
> > guests. Are the fixes that you describe to the refcounting sufficient
> > to remove that limitation from __domain_pause_by_systemcontroller()?
> 
> The limit is the number of concurrent userspace refs taken on an
> individual domain.  I.e. you can plausibly have 255 different bits of
> the toolstack each taking a pause reference for a specific reason.
> 
> 255 was chosen an arbitrary limit, which is used to prevent buggy
> toolstacks from being able to overflow the refcounts used by the
> scheduler by using the pause domain hypercall 4 billion times.
> 
> >
> > My implementation uses 1024 but has no check on nb_domain (the amount of
> > domains set) so that requires fixing as well but I figure we should also
> > review the above first too. Artificial limits bother me and I went with
> > 1024 as I also saw that limit used elsewhere, not sure if it was a stack
> > concern or what.
> >
> >> However, xenmicrocode (even indirectly via xc_microcode_update()) is not
> >> in a position to safely pause all domains as there is no interlock to
> >> preventing a new domain being created.  Even if all domains do get
> >> successfully paused, 
> > I did think about this and figured we could use this as a segway into
> > a discussion about how we would want to implement this sort of
> > interlocking or see if there is anything available already for this
> > sort of thing. Also, are there other future users of this that could benefit
> > from it ? If so then perhaps we can wrap the requirements up together.
> >
> >> the idle loops are substantially less trivial than
> >> ideal.
> > Interesting, can you elaborate on the possible issues that might creep
> > up on the idle loops while a guest is paused during a microcode update?
> > Any single issue would suffice, just curious.
> >
> > Do we need something more intricate than pause implemented then? Using
> > suspend seemed rather grotesque to shove down a guest's throat. If
> > pause / suspend do not suffice perhaps some new artificial virtual
> > tempory quiesce is needed to ensure integrity here, which would address
> > some of the idle concerns you highligted might creep up.
> >
> >> The toolstack should not hack around hypervisor bugs, and indeed is not
> >> capable of doing so.
> > Agreed. I figured I'd at least do what I can with what is available
> > and use this as a discussoin for what is the Right Thing To Do (TM)
> > in the future.
> 
> The right thing to d

Re: [Xen-devel] [RFC v2] misc/xenmicrocode: Upload /lib/firmware/ to the hypervisor

[Andrew Cooper]

On 30/01/2015 21:24, Boris Ostrovsky wrote:
> On 01/30/2015 03:37 PM, Andrew Cooper wrote:
>
>>
>> The actions Xen needs to take are:
>>
>> - Copy the buffer into Xen.
>> - Scan the buffer for the correct patch
>
>
> Why not have the toolstack search for the right patch? Hypervisor will
> verify that it's appropriate but won't have to spend time scanning the
> (potentially large) buffer.
>
> (The logic for scanning the buffer is in the hypervisor code but we
> could move it to a library)

a) Xen already needs to scan for the boot time patching and b) because
the interface already has this property.

One could certainly prepare the patch in userspace and that would be
more efficient (patches welcome if you are feeling particularly keen),
but I am not going to loose sleep over it.  It is likely that the
majority of users will delay a microcode update until a maintenance
window and plan time for a reboot.

~Andrew

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

Re: [Xen-devel] [PATCHv5 00/14] xen: fix many long-standing grant mapping bugs

[Konrad Rzeszutek Wilk]

On Tue, Jan 27, 2015 at 04:44:02PM +, David Vrabel wrote:
> This series fixes a number of long-standing bugs in the handling of
> grant maps.  Refer to the following for all the details.
> 
>   http://xenbits.xen.org/people/dvrabel/grant-improvements-C.pdf
> 
> In summary, the important uses that this enables are:
> 
> 1. Block backends can use networked storage safely.
> 
> 2. Block backends can use network storage provided by other guests on
>the same host.
> 
> 3. User space block backends can use direct I/O or asynchronous I/O.
> 
> The first two patches are the core MM changes necessary.  These have
> already been acked.
> 
> Patches #3 and #4 remove existing (broken) mechanisms.  This does
> temporarily break some previously working use cases, but it does make
> the subsequent additions much easier to review.
> 
> Only patches #3, #4, and #13 need acks from other Xen maintainers.

I took a look at the patches and they look good to me.

> 
> As a happy side effect, performance is also likely to be improved in
> some areas (but I've not got any measurements yet).  User space
> backends using grant mapping should see some good improvements from
> reduced overheads and better unmap batching.  VIF to VIF network
> traffic may also see a small improvement.
> 
> Finally, thanks to Jenny who did much of the implementation.
> 
> Changes in v5:
> - Fix gntdev for auto-xlate guests.
> 
> Changes in v4:
> - Removed xen_blkbk_unmap_done().
> - Fixed bug in blkback when using mixed persistent and non-persistent
>   grants.
> 
> Changes in v3:
> - find_page renamed to find_special_page.
> - Added documentation for mm changes.
> - Fixed mangled forward port of blkback's safe unmap patch.
> - Export gnttab_alloc_pages() and gnttab_free_pages().
> - Fix 32-bit build.
> 
> Changes in v2:
> - Add find_page() VMA op instead of pages field (so struct
>   vm_area_struct doesn't increase in size.
> - Make foreign page tracking arch-independant and improve the API.
> - Alloc extra memory (for 32-bit archs) for the (domain, gref) when
>   allocating the page (instead of during the map).
> - Convert gntdev's lock to a mutex.
> 
> David
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

Re: [Xen-devel] [RFC v2] misc/xenmicrocode: Upload /lib/firmware/ to the hypervisor

[Luis R. Rodriguez]

On Fri, Jan 30, 2015 at 1:14 PM, Boris Ostrovsky
 wrote:
> But then I thought that Andrew is advocating having the hypervisor doing the
> pause.

A system wide well implemented quiesce with one simple return value
only if all were quiesced seems better for tools to deal with. Let's
wait for that then.

 Luis

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

Re: [Xen-devel] [RFC v2] misc/xenmicrocode: Upload /lib/firmware/ to the hypervisor

[Boris Ostrovsky]

On 01/30/2015 03:37 PM, Andrew Cooper wrote:



The actions Xen needs to take are:

- Copy the buffer into Xen.
- Scan the buffer for the correct patch



Why not have the toolstack search for the right patch? Hypervisor will 
verify that it's appropriate but won't have to spend time scanning the 
(potentially large) buffer.


(The logic for scanning the buffer is in the hypervisor code but we 
could move it to a library)


-boris



- Rendezvous all online cpus in an IPI to apply the patch, and keep the
processors in until all have completed the patch.




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

Re: [Xen-devel] [RFC v2] misc/xenmicrocode: Upload /lib/firmware/ to the hypervisor

[Boris Ostrovsky]

On 01/30/2015 03:05 PM, Luis R. Rodriguez wrote:

On Fri, Jan 30, 2015 at 09:44:56AM -0500, Boris Ostrovsky wrote:

On 01/29/2015 08:14 PM, Luis R. Rodriguez wrote:

From: "Luis R. Rodriguez" 
+/*
+ * Do not pause already paused domains, and allow us to
+ * unpause only quiesced domains.
+ */
+static int quiesce_all_domains(xc_interface *xch,
+  struct xc_quiesce_request *quiesce_request)
+{
+xc_domaininfo_t info[1024];
+int i, nb_domain;
+
+nb_domain = xc_domain_getinfolist(xch, 0, 1024, info);
+if ( nb_domain < 0 )
+{
+   return -1;
+}
+
+for ( i = 0; i < nb_domain; i++ )
+{
+if ( info[i].domain == 0 )
+   continue;
+   if ( info[i].flags & XEN_DOMINF_paused )
+   continue;
+
+xc_domain_pause(xch, info[i].domain);


You are not handling errors returned by xc_domain_pause().

Thanks for the review, shall we just bail if that cannot happen?


I think so (after unpausing the already-paused domains, obviously).

But then I thought that Andrew is advocating having the hypervisor doing 
the pause.





So then you will
try to unpause a domain that may not have been paused and (I think more
importantly) may proceed with microcode update while not all domains are
paused.

Yeah this would be bad. Perhaps bail and tell the user the domain that
we could not pause / quiesce (depending on what we decide to do).


+
+   quiesce_request->domids[quiesce_request->num_quiesced] = info[i].domain;
+   quiesce_request->num_quiesced++;
+}
+
+return 0;
+}
+
+static void unquiesce_all_domains(xc_interface *xch,
+  struct xc_quiesce_request *quiesce_request)
+{
+int i;
+
+for ( i = 0; i < quiesce_request->num_quiesced; i++ )
+{
+   xc_domain_unpause(xch, quiesce_request->domids[i]);


Same here --- you may fail unpausing a domain and noone will know about it.

True, that seems like a rather informational thing we can spit out, do we want
to return an error for that though too?


I'd print the error and continue unpausing.


-boris

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

[Xen-devel] [PATCH v3] libxl: Wait for ballooning if free memory is increasing

[Mike Latimer]

During domain startup, all required memory ballooning must complete
within a maximum window of 33 seconds (3 retries, 11 seconds of delay).
If not, domain creation is aborted with a 'failed to free memory' error.

In order to accommodate large domains or slower hardware (which require
substantially longer to balloon memory) the free memory process should
continue retrying if the amount of free memory is increasing on each
iteration of the loop.

---
 tools/libxl/xl_cmdimpl.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 0b02a6c..9ff3c4f 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2194,8 +2194,9 @@ static int preserve_domain(uint32_t *r_domid, libxl_event 
*event,
 
 static int freemem(uint32_t domid, libxl_domain_build_info *b_info)
 {
-int rc, retries = 3;
-uint32_t need_memkb, free_memkb;
+int rc, retries;
+const int MAX_RETRIES = 3;
+uint32_t need_memkb, free_memkb, free_memkb_prev = 0;
 
 if (!autoballoon)
 return 0;
@@ -2204,6 +2205,7 @@ static int freemem(uint32_t domid, 
libxl_domain_build_info *b_info)
 if (rc < 0)
 return rc;
 
+retries = MAX_RETRIES;
 do {
 rc = libxl_get_free_memory(ctx, &free_memkb);
 if (rc < 0)
@@ -2228,7 +2230,16 @@ static int freemem(uint32_t domid, 
libxl_domain_build_info *b_info)
 if (rc < 0)
 return rc;
 
-retries--;
+/*
+ * If the amount of free mem has increased on this iteration (i.e.
+ * some progress has been made) then reset the retry counter.
+ */
+if (free_memkb > free_memkb_prev) {
+retries = MAX_RETRIES;
+free_memkb_prev = free_memkb;
+} else {
+retries--;
+}
 } while (retries > 0);
 
 return ERROR_NOMEM;
-- 
1.8.4.5


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

Re: [Xen-devel] [PATCH v2] libxl: Wait for ballooning if free memory is increasing

[Mike Latimer]

On Friday, January 30, 2015 01:04:00 PM Mike Latimer wrote:
> +if (free_memkb > free_memkb_prev) {
> +retries = MAX_RETRIES;
> +free_memkb_prev = free_memkb;
> +} else {
> +retires--;
> +}

Please ignore. Typo 'retires' in the above...  I'll fix and resend.

-Mike

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

Re: [Xen-devel] [RFC v2] misc/xenmicrocode: Upload /lib/firmware/ to the hypervisor

[Andrew Cooper]

On 30/01/15 19:51, Luis R. Rodriguez wrote:
> On Fri, Jan 30, 2015 at 02:23:48PM +, Andrew Cooper wrote:
>> On 30/01/15 01:14, Luis R. Rodriguez wrote:
>>> From: "Luis R. Rodriguez" 
>>>
>>> There are several ways that a Xen system can update the
>>> CPU microcode on a pvops kernel [0] now, the preferred way
>>> is through the early microcode update mechanism. At run
>>> time folks should use this new xenmicrocode tool and use
>>> the same CPU microcode file as present on /lib/firmware.
>>>
>>> Some distributions may use the historic sysfs rescan interface,
>>> users of that mechanism should be aware that the interface will
>>> not be available when using Xen and as such should first check
>>> the presence of the interface before usage, as an alternative
>>> this xenmicrocode tool can be used on priviledged domains.
>>>
>>> Folks wishing to update CPU microcode at run time should be
>>> aware that not all CPU microcode can be updated on a system
>>> and should take care to ensure that only known-to-work and
>>> supported CPU microcode updates are used [0]. To avoid issues
>>> with delays on the hypercall / microcode update this
>>> implementation will quiesce all domains prior to updating
>>> the microcode, and then only queisce'd domains will be
>>> unpaused once done.
>>>
>>> [0] http://wiki.xenproject.org/wiki/XenParavirtOps/microcode_update
>>>
>>> Based on original work by: Konrad Rzeszutek Wilk 
>>> Cc: Konrad Rzeszutek Wilk 
>>> Cc: Andrew Cooper 
>>> Cc: Borislav Petkov 
>>> Cc: Takashi Iwai 
>>> Cc: Olaf Hering 
>>> Cc: Jan Beulich 
>>> Cc: Jason Douglas 
>>> Cc: Juergen Gross 
>>> Cc: Michal Marek 
>>> Cc: Henrique de Moraes Holschuh 
>>> Signed-off-by: Konrad Rzeszutek Wilk 
>>> Signed-off-by: Luis R. Rodriguez 
>>> ---
>>>
>>> Just wrote this, haven't tested it. This does some queiscing prior
>>> to doing the microcode update. The quiescing is done by pausing
>>> all domains. Once the microcode update is done we only unpause
>>> domains which we queisced as part of our work. Let me know if this
>>> is on the right track to help avoid issues noted on the list.
>> There is also a TOCTOU race with your paused check, which itself is
>> buggy as it you should unconditionally pause all VMs (userspace pause
>> refcounting has been fixed for a little while now).
> Also, currently __domain_pause_by_systemcontroller() has a limit to 255
> guests. Are the fixes that you describe to the refcounting sufficient
> to remove that limitation from __domain_pause_by_systemcontroller()?

The limit is the number of concurrent userspace refs taken on an
individual domain.  I.e. you can plausibly have 255 different bits of
the toolstack each taking a pause reference for a specific reason.

255 was chosen an arbitrary limit, which is used to prevent buggy
toolstacks from being able to overflow the refcounts used by the
scheduler by using the pause domain hypercall 4 billion times.

>
> My implementation uses 1024 but has no check on nb_domain (the amount of
> domains set) so that requires fixing as well but I figure we should also
> review the above first too. Artificial limits bother me and I went with
> 1024 as I also saw that limit used elsewhere, not sure if it was a stack
> concern or what.
>
>> However, xenmicrocode (even indirectly via xc_microcode_update()) is not
>> in a position to safely pause all domains as there is no interlock to
>> preventing a new domain being created.  Even if all domains do get
>> successfully paused, 
> I did think about this and figured we could use this as a segway into
> a discussion about how we would want to implement this sort of
> interlocking or see if there is anything available already for this
> sort of thing. Also, are there other future users of this that could benefit
> from it ? If so then perhaps we can wrap the requirements up together.
>
>> the idle loops are substantially less trivial than
>> ideal.
> Interesting, can you elaborate on the possible issues that might creep
> up on the idle loops while a guest is paused during a microcode update?
> Any single issue would suffice, just curious.
>
> Do we need something more intricate than pause implemented then? Using
> suspend seemed rather grotesque to shove down a guest's throat. If
> pause / suspend do not suffice perhaps some new artificial virtual
> tempory quiesce is needed to ensure integrity here, which would address
> some of the idle concerns you highligted might creep up.
>
>> The toolstack should not hack around hypervisor bugs, and indeed is not
>> capable of doing so.
> Agreed. I figured I'd at least do what I can with what is available
> and use this as a discussoin for what is the Right Thing To Do (TM)
> in the future.

The right thing to do is to fix the hypercall implementation, at which
point the utility below is fine and xc_microcode_update() can be a thing
wrapper around the hypercall.

The actions Xen needs to take are:

- Copy the buffer into Xen.
- Scan the buffer for the correct patch
- 

Re: [Xen-devel] [RFC v2] misc/xenmicrocode: Upload /lib/firmware/ to the hypervisor

[Luis R. Rodriguez]

On Fri, Jan 30, 2015 at 09:44:56AM -0500, Boris Ostrovsky wrote:
> On 01/29/2015 08:14 PM, Luis R. Rodriguez wrote:
>> From: "Luis R. Rodriguez" 
>> +/*
>> + * Do not pause already paused domains, and allow us to
>> + * unpause only quiesced domains.
>> + */
>> +static int quiesce_all_domains(xc_interface *xch,
>> +   struct xc_quiesce_request *quiesce_request)
>> +{
>> +xc_domaininfo_t info[1024];
>> +int i, nb_domain;
>> +
>> +nb_domain = xc_domain_getinfolist(xch, 0, 1024, info);
>> +if ( nb_domain < 0 )
>> +{
>> +return -1;
>> +}
>> +
>> +for ( i = 0; i < nb_domain; i++ )
>> +{
>> +if ( info[i].domain == 0 )
>> +continue;
>> +if ( info[i].flags & XEN_DOMINF_paused )
>> +continue;
>> +
>> +xc_domain_pause(xch, info[i].domain);
>
>
> You are not handling errors returned by xc_domain_pause().

Thanks for the review, shall we just bail if that cannot happen?

> So then you will 
> try to unpause a domain that may not have been paused and (I think more 
> importantly) may proceed with microcode update while not all domains are 
> paused.

Yeah this would be bad. Perhaps bail and tell the user the domain that
we could not pause / quiesce (depending on what we decide to do).

>> +
>> +quiesce_request->domids[quiesce_request->num_quiesced] = info[i].domain;
>> +quiesce_request->num_quiesced++;
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +static void unquiesce_all_domains(xc_interface *xch,
>> +  struct xc_quiesce_request 
>> *quiesce_request)
>> +{
>> +int i;
>> +
>> +for ( i = 0; i < quiesce_request->num_quiesced; i++ )
>> +{
>> +xc_domain_unpause(xch, quiesce_request->domids[i]);
>
>
> Same here --- you may fail unpausing a domain and noone will know about it.

True, that seems like a rather informational thing we can spit out, do we want
to return an error for that though too?

>> +}
>> +}
>> +
>> +int xc_microcode_update(xc_interface *xch, uint8_t *fbuf, size_t len)
>> +{
>> +int ret = 0;
>> +DECLARE_HYPERCALL_BUFFER(struct xenpf_microcode_update, uc);
>> +DECLARE_HYPERCALL;
>> +struct xen_platform_op op_s;
>> +struct xen_platform_op *op = &op_s;
>> +DECLARE_HYPERCALL_BOUNCE(op, sizeof(*op), 
>> XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
>> +struct xc_quiesce_request quiesce_request;
>> +
>> +memset(&quiesce_request, 0, sizeof(struct xc_quiesce_request));
>> +
>> +if ( !xch )
>> +{
>> +return -1;
>> +}
>
>
> Not sure what tools coding convention is but you may not need {} here (and 
> a few more places)

I was not sure so went with that. I'm happy to remove that stuff from
one liners.

>> +/* microcode file as present on /lib/firmware/ */
>
> On Linux but not necessarily on other OSs. You code doesn't require it to 
> be there so you probably want to avoid referring to this path in comments 
> and commit subject/body.

Amended.

>> +printf("%s: %ld\n", filename, buf.st_size);
>
>
> Do you need this? (probably leftover from debugging?)

Killed.

  Luis

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

[Xen-devel] [PATCH v2] libxl: Wait for ballooning if free memory is increasing

[Mike Latimer]

During domain startup, all required memory ballooning must complete
within a maximum window of 33 seconds (3 retries, 11 seconds of delay).
If not, domain creation is aborted with a 'failed to free memory' error.

In order to accommodate large domains or slower hardware (which require
substantially longer to balloon memory) the free memory process should
continue retrying if the amount of free memory is increasing on each
iteration of the loop.

---
 tools/libxl/xl_cmdimpl.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 0b02a6c..9ff3c4f 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2194,8 +2194,9 @@ static int preserve_domain(uint32_t *r_domid, libxl_event 
*event,
 
 static int freemem(uint32_t domid, libxl_domain_build_info *b_info)
 {
-int rc, retries = 3;
-uint32_t need_memkb, free_memkb;
+int rc, retries;
+const int MAX_RETRIES = 3;
+uint32_t need_memkb, free_memkb, free_memkb_prev = 0;
 
 if (!autoballoon)
 return 0;
@@ -2204,6 +2205,7 @@ static int freemem(uint32_t domid, 
libxl_domain_build_info *b_info)
 if (rc < 0)
 return rc;
 
+retries = MAX_RETRIES;
 do {
 rc = libxl_get_free_memory(ctx, &free_memkb);
 if (rc < 0)
@@ -2228,7 +2230,16 @@ static int freemem(uint32_t domid, 
libxl_domain_build_info *b_info)
 if (rc < 0)
 return rc;
 
-retries--;
+/*
+ * If the amount of free mem has increased on this iteration (i.e.
+ * some progress has been made) then reset the retry counter.
+ */
+if (free_memkb > free_memkb_prev) {
+retries = MAX_RETRIES;
+free_memkb_prev = free_memkb;
+} else {
+retires--;
+}
 } while (retries > 0);
 
 return ERROR_NOMEM;
-- 
1.8.4.5


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

Re: [Xen-devel] [PATCH] libxl: Wait for ballooning if free memory is increasing

[Mike Latimer]

On Thursday, January 29, 2015 10:14:26 AM Ian Campbell wrote:
> I'm thinking it would be clearer if the comment and the condition were
> logically inverted. e.g.:
> 
> /*
>  * If the amount of free mem has increased on this iteration (i.e.
>  * some progress has been made) then reset the retry counter.
>  */
> if (freemem_kb > freemem_kb_prev) {
> retries = MAX_RETRIES;
> free_memkb_prev = free_memkb;
> } else {
> retires--;
> }

Thanks for the comments, Ian. Inverting the logic makes sense, and I'll send a 
v2 shortly.

> > > Given that this new loop can take significantly longer to fail I wonder
> > > if we should add some progress logging? xl has an xtl logger instance
> > > available so using xtl_progress might be an easy option. Maybe a
> > > separate patch though.

xtl_progress looks interesting. I'll do some additional testing before I 
submit a patch containing this improvement.

-Mike

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

Re: [Xen-devel] [RFC v2] misc/xenmicrocode: Upload /lib/firmware/ to the hypervisor

[Luis R. Rodriguez]

On Fri, Jan 30, 2015 at 02:23:48PM +, Andrew Cooper wrote:
> On 30/01/15 01:14, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" 
> >
> > There are several ways that a Xen system can update the
> > CPU microcode on a pvops kernel [0] now, the preferred way
> > is through the early microcode update mechanism. At run
> > time folks should use this new xenmicrocode tool and use
> > the same CPU microcode file as present on /lib/firmware.
> >
> > Some distributions may use the historic sysfs rescan interface,
> > users of that mechanism should be aware that the interface will
> > not be available when using Xen and as such should first check
> > the presence of the interface before usage, as an alternative
> > this xenmicrocode tool can be used on priviledged domains.
> >
> > Folks wishing to update CPU microcode at run time should be
> > aware that not all CPU microcode can be updated on a system
> > and should take care to ensure that only known-to-work and
> > supported CPU microcode updates are used [0]. To avoid issues
> > with delays on the hypercall / microcode update this
> > implementation will quiesce all domains prior to updating
> > the microcode, and then only queisce'd domains will be
> > unpaused once done.
> >
> > [0] http://wiki.xenproject.org/wiki/XenParavirtOps/microcode_update
> >
> > Based on original work by: Konrad Rzeszutek Wilk 
> > Cc: Konrad Rzeszutek Wilk 
> > Cc: Andrew Cooper 
> > Cc: Borislav Petkov 
> > Cc: Takashi Iwai 
> > Cc: Olaf Hering 
> > Cc: Jan Beulich 
> > Cc: Jason Douglas 
> > Cc: Juergen Gross 
> > Cc: Michal Marek 
> > Cc: Henrique de Moraes Holschuh 
> > Signed-off-by: Konrad Rzeszutek Wilk 
> > Signed-off-by: Luis R. Rodriguez 
> > ---
> >
> > Just wrote this, haven't tested it. This does some queiscing prior
> > to doing the microcode update. The quiescing is done by pausing
> > all domains. Once the microcode update is done we only unpause
> > domains which we queisced as part of our work. Let me know if this
> > is on the right track to help avoid issues noted on the list.
> 
> There is also a TOCTOU race with your paused check, which itself is
> buggy as it you should unconditionally pause all VMs (userspace pause
> refcounting has been fixed for a little while now).

Also, currently __domain_pause_by_systemcontroller() has a limit to 255
guests. Are the fixes that you describe to the refcounting sufficient
to remove that limitation from __domain_pause_by_systemcontroller()?

My implementation uses 1024 but has no check on nb_domain (the amount of
domains set) so that requires fixing as well but I figure we should also
review the above first too. Artificial limits bother me and I went with
1024 as I also saw that limit used elsewhere, not sure if it was a stack
concern or what.

> However, xenmicrocode (even indirectly via xc_microcode_update()) is not
> in a position to safely pause all domains as there is no interlock to
> preventing a new domain being created.  Even if all domains do get
> successfully paused, 

I did think about this and figured we could use this as a segway into
a discussion about how we would want to implement this sort of
interlocking or see if there is anything available already for this
sort of thing. Also, are there other future users of this that could benefit
from it ? If so then perhaps we can wrap the requirements up together.

> the idle loops are substantially less trivial than
> ideal.

Interesting, can you elaborate on the possible issues that might creep
up on the idle loops while a guest is paused during a microcode update?
Any single issue would suffice, just curious.

Do we need something more intricate than pause implemented then? Using
suspend seemed rather grotesque to shove down a guest's throat. If
pause / suspend do not suffice perhaps some new artificial virtual
tempory quiesce is needed to ensure integrity here, which would address
some of the idle concerns you highligted might creep up.

> The toolstack should not hack around hypervisor bugs, and indeed is not
> capable of doing so.

Agreed. I figured I'd at least do what I can with what is available
and use this as a discussoin for what is the Right Thing To Do (TM)
in the future.

> >  tools/libxc/include/xenctrl.h |   2 +
> >  tools/libxc/xc_misc.c | 102 
> > ++
> >  tools/misc/Makefile   |   4 ++
> >  tools/misc/xenmicrocode.c | 101 
> > +
> >  4 files changed, 209 insertions(+)
> >  create mode 100644 tools/misc/xenmicrocode.c
> >
> > diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> > index 0ad8b8d..d5db0b8 100644
> > --- a/tools/libxc/include/xenctrl.h
> > +++ b/tools/libxc/include/xenctrl.h
> > @@ -55,6 +55,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #endif
> >  
> >  #define XC_PAGE_SHIFT   12
> > @@ -2145,6 +2146,7 @@ int xc_cpuid_apply_policy(xc_interface *xch,
> >  void xc_cpuid_to_

Re: [Xen-devel] [PATCH 3/5] hvmemul_do_io: If the send to the ioreq server failed do not retry.

[Don Slutz]

On 01/30/15 13:17, Don Slutz wrote:
> On 01/30/15 05:23, Jan Beulich wrote:
> On 30.01.15 at 01:52,  wrote:
>>> I.E. do just what no backing DM does.
>>
>> _If_ this is correct, the if() modified here should be folded with the
>> one a few lines up.
> 
> Ok, will fold with the one a few lines up.  As expected without this
> change the guest will hang (more details below).
> 
> 
>> But looking at the description of the commit that
>> introduced this (bac0999325 "x86 hvm: Do not incorrectly retire an
>> instruction emulation...", almost immediately modified by f20f3c8ece
>> "x86 hvm: On failed hvm_send_assist_req(), io emulation...") I doubt
>> this is really what we want, or at the very least your change
>> description should explain what was wrong with the original commit.
>>
> 
> Looking at these 2 commits, it looks to me like I need to handle these
> cases also.  So it looks like having hvm_send_assist_req() return an int
> 0, 1, & 2 is the simpler way.  V2 on the way soon.
> 

Soon after sending this, I came up with a 2nd way for fix.
Change hvm_has_dm() to use hvm_select_ioreq_server().  Then
the correct answer will be found, and so will not retry.

To avoid 2 calls to hvm_select_ioreq_server(), it makes
snes to me to return s.  Also adding a call to hvm_complete_assist_req()
would help.  So based on all this is is a possible v2:


commit 24eb5a839427ba80c1adf16ab656c19729f906be
Author: Don Slutz 
Date:   Fri Jan 30 13:54:43 2015 -0500

fixup use of hvm_send_assist_req

Signed-off-by: Don Slutz 

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 2ed4344..7c3c654 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -218,8 +218,11 @@ static int hvmemul_do_io(
 vio->io_state = HVMIO_handle_mmio_awaiting_completion;
 break;
 case X86EMUL_UNHANDLEABLE:
+{
+void *s = hvm_has_dm(curr->domain, &p);
+
 /* If there is no backing DM, just ignore accesses */
-if ( !hvm_has_dm(curr->domain) )
+if ( !s )
 {
 rc = X86EMUL_OKAY;
 vio->io_state = HVMIO_none;
@@ -227,11 +230,12 @@ static int hvmemul_do_io(
 else
 {
 rc = X86EMUL_RETRY;
-if ( !hvm_send_assist_req(&p) )
+if ( !hvm_send_assist_req(s, &p) )
 vio->io_state = HVMIO_none;
 else if ( p_data == NULL )
 rc = X86EMUL_OKAY;
 }
+}
 break;
 default:
 BUG();
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 984af81..21d4a73 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2507,9 +2507,45 @@ int hvm_buffered_io_send(ioreq_t *p)
 return 1;
 }

-bool_t hvm_has_dm(struct domain *d)
+static bool_t hvm_complete_assist_req(ioreq_t *p)
 {
-return !list_empty(&d->arch.hvm_domain.ioreq_server.list);
+HVMTRACE_1D(COMPLETE_ASSIST, p->type);
+ASSERT(p->type != IOREQ_TYPE_PCI_CONFIG);
+switch ( p->type )
+{
+case IOREQ_TYPE_COPY:
+case IOREQ_TYPE_PIO:
+if ( p->dir == IOREQ_READ )
+{
+if ( !p->data_is_ptr )
+p->data = ~0ul;
+else
+{
+int i, step = p->df ? -p->size : p->size;
+uint32_t data = ~0;
+
+for ( i = 0; i < p->count; i++ )
+hvm_copy_to_guest_phys(p->data + step * i, &data,
+   p->size);
+}
+}
+/* FALLTHRU */
+default:
+p->state = STATE_IORESP_READY;
+hvm_io_assist(p);
+break;
+}
+
+return 1;
+}
+
+void *hvm_has_dm(struct domain *d, ioreq_t *p)
+{
+struct hvm_ioreq_server *s = hvm_select_ioreq_server(d, p);
+
+if ( !s )
+hvm_complete_assist_req(p);
+return (void *)s;
 }

 bool_t hvm_send_assist_req_to_ioreq_server(struct hvm_ioreq_server *s,
@@ -2571,44 +2607,15 @@ bool_t
hvm_send_assist_req_to_ioreq_server(struct hvm_ioreq_server *s,
 return 0;
 }

-static bool_t hvm_complete_assist_req(ioreq_t *p)
-{
-HVMTRACE_1D(COMPLETE_ASSIST, p->type);
-ASSERT(p->type != IOREQ_TYPE_PCI_CONFIG);
-switch ( p->type )
-{
-case IOREQ_TYPE_COPY:
-case IOREQ_TYPE_PIO:
-if ( p->dir == IOREQ_READ )
-{
-if ( !p->data_is_ptr )
-p->data = ~0ul;
-else
-{
-int i, step = p->df ? -p->size : p->size;
-uint32_t data = ~0;
-
-for ( i = 0; i < p->count; i++ )
-hvm_copy_to_guest_phys(p->data + step * i, &data,
-   p->size);
-}
-}
-/* FALLTHRU */
-default:
-p->state = STATE_IORESP_READY;
-hvm_io_assist(p);
-break;
-}
-
-return 0; /* implicitly bins the i/o operation */
-}
-
-bool_t hvm_send_assist_req(ioreq_t *p)
+bool_t hvm_send_assist_req(void *v

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

[Andrew Cooper]

On 30/01/15 17:54, Daniel Kiper wrote:
> Signed-off-by: Daniel Kiper 
> ---
>  xen/arch/x86/boot/head.S  |  174 
> +++--
>  xen/arch/x86/efi/efi-boot.h   |   29 +++
>  xen/arch/x86/setup.c  |   23 ++---
>  xen/arch/x86/x86_64/asm-offsets.c |2 +
>  xen/common/efi/boot.c |   11 +++
>  5 files changed, 222 insertions(+), 17 deletions(-)
>
> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> index 7861057..89f5aa7 100644
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -8,6 +8,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  .text
>  .code32
> @@ -57,6 +58,9 @@ ENTRY(start)
>  .long   .Lmultiboot2_info_req_end - .Lmultiboot2_info_req
>  .long   MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO
>  .long   MULTIBOOT2_TAG_TYPE_MMAP
> +.long   MULTIBOOT2_TAG_TYPE_EFI_BS
> +.long   MULTIBOOT2_TAG_TYPE_EFI64
> +.long   MULTIBOOT2_TAG_TYPE_EFI64_IH
>  .Lmultiboot2_info_req_end:
>  
>  .align  MULTIBOOT2_TAG_ALIGN
> @@ -80,6 +84,19 @@ ENTRY(start)
>  .long   0 /* Number of the lines - no preference. */
>  .long   0 /* Number of bits per pixel - no preference. */
>  
> +/* Do not disable EFI boot services. */
> +.align  MULTIBOOT2_TAG_ALIGN
> +.short  MULTIBOOT2_HEADER_TAG_EFI_BS
> +.short  MULTIBOOT2_HEADER_TAG_OPTIONAL
> +.long   8 /* Tag size. */
> +
> +/* EFI64 entry point. */
> +.align  MULTIBOOT2_TAG_ALIGN
> +.short  MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI64
> +.short  MULTIBOOT2_HEADER_TAG_OPTIONAL
> +.long   12 /* Tag size. */
> +.long   sym_phys(__efi64_start)
> +
>  /* Multiboot2 header end tag. */
>  .align  MULTIBOOT2_TAG_ALIGN
>  .short  MULTIBOOT2_HEADER_TAG_END
> @@ -94,6 +111,17 @@ ENTRY(start)
>  gdt_boot_descr:
>  .word   6*8-1
>  .long   sym_phys(trampoline_gdt)
> +.long   0 /* Needed for 64-bit lgdt */
> +
> +cs32_switch_addr:
> +.long   sym_phys(cs32_switch)
> +.long   BOOT_CS32

.word

ljmpl refers to an m32:16 not an m32:32

> +
> +efi_st:
> +.quad   0
> +
> +efi_ih:
> +.quad   0
>  
>  .Lbad_cpu_msg: .asciz "ERR: Not a 64-bit CPU!"
>  .Lbad_ldr_msg: .asciz "ERR: Not a Multiboot bootloader!"
> @@ -124,6 +152,133 @@ print_err:
>  .Lhalt: hlt
>  jmp .Lhalt
>  
> +.code64
> +
> +__efi64_start:
> +cld
> +
> +/* Bootloaders may set multiboot[12].mem_lower to a nonzero value */
> +xor %edx,%edx
> +
> +/* Check for Multiboot2 bootloader */
> +cmp $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
> +je  efi_multiboot2_proto
> +
> +jmp not_multiboot

not_multiboot is 32bit code.  You must drop out of 64bit before using
it, or make a 64bit variant.

> +
> +efi_multiboot2_proto:
> +/* Skip Multiboot2 information fixed part */
> +lea MB2_fixed_sizeof(%ebx),%ecx
> +
> +0:
> +/* Get mem_lower from Multiboot2 information */
> +cmpl$MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,(%ecx)
> +jne 1f
> +
> +mov MB2_mem_lower(%ecx),%edx
> +jmp 4f
> +
> +1:
> +/* Get EFI SystemTable address from Multiboot2 information */
> +cmpl$MULTIBOOT2_TAG_TYPE_EFI64,(%ecx)
> +jne 2f
> +
> +lea MB2_efi64_st(%ecx),%esi
> +lea efi_st(%rip),%edi
> +movsq

This is complete overkill for copying a 64bit variable out of the tag
and into a local variable.  Just use a plain 64bit load and store.

> +
> +/* Do not go into real mode on EFI platform */
> +movb$1,skip_realmode(%rip)
> +
> +jmp 4f
> +
> +2:
> +/* Get EFI ImageHandle address from Multiboot2 information */
> +cmpl$MULTIBOOT2_TAG_TYPE_EFI64_IH,(%ecx)
> +jne 3f
> +
> +lea MB2_efi64_ih(%ecx),%esi
> +lea efi_ih(%rip),%edi
> +movsq

And here.

> +jmp 4f
> +
> +3:
> +/* Is it the end of Multiboot2 information? */
> +cmpl$MULTIBOOT2_TAG_TYPE_END,(%ecx)
> +je  run_bs
> +
> +4:
> +/* Go to next Multiboot2 information tag */
> +add MB2_tag_size(%ecx),%ecx
> +add $(MULTIBOOT2_TAG_ALIGN-1),%ecx
> +and $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
> +jmp 0b
> +
> +run_bs:
> +push%rax
> +push%rdx

Does the EFI spec guarantee that we have a good stack to use at this point?

> +
> +/* Initialize BSS (no nasty surprises!) */
> +lea __bss_start(%rip),%rdi
> +lea _end(%rip),%rcx
> +sub %rdi,%rcx
> +xor %rax,%rax

xor %eax,%eax is shorter.

> +rep stosb

It would be more efficient to make sure that the linker aligns
__bss_start and _end on 8 byte boundaries, and use stos

[Xen-devel] [PATCH v3 02/13] xen/arm: vgic: Drop unecessary include asm/device.h

[Julien Grall]

The header asm/device.h has been included in the vgic code during
splitting to support multiple version. But no code within those files
requires it.

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

---
Changes in v3:
- Add Stefano's ack
---
 xen/arch/arm/vgic-v2.c | 1 -
 xen/arch/arm/vgic-v3.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index 515faf7..cd8f7d1 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -26,7 +26,6 @@
 #include 
 
 #include 
-#include 
 
 #include 
 #include 
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index bece189..cab3b63 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -27,7 +27,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
2.1.4


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

[Xen-devel] [PATCH v3 09/13] xen/iommu: arm: Import the SMMU driver from Linux

[Julien Grall]

Based on commit e6b5be2be4e30037eb551e0ed09dd97bd00d85d3.

It's a verbatim of the Linux SMMU drivers code. No Xen code has yet been added
and the file is not built.

Compare to the previous drivers it gains support of PCI. Though it will
need a bit of plumbing for Xen.

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

---
Changes in v3:
- Update the commit message based on Stefano's review
- Add Stefano's ack

Changes in v2:
- Fix typo in the Signed-off-by
---
 xen/drivers/passthrough/arm/smmu.c | 2193 
 1 file changed, 2193 insertions(+)
 create mode 100644 xen/drivers/passthrough/arm/smmu.c

diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
new file mode 100644
index 000..6cd47b7
--- /dev/null
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -0,0 +1,2193 @@
+/*
+ * IOMMU API for ARM architected SMMU implementations.
+ *
+ * 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, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright (C) 2013 ARM Limited
+ *
+ * Author: Will Deacon 
+ *
+ * This driver currently supports:
+ * - SMMUv1 and v2 implementations
+ * - Stream-matching and stream-indexing
+ * - v7/v8 long-descriptor format
+ * - Non-secure access to the SMMU
+ * - 4k and 64k pages, with contiguous pte hints.
+ * - Up to 48-bit addressing (dependent on VA_BITS)
+ * - Context fault reporting
+ */
+
+#define pr_fmt(fmt) "arm-smmu: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+
+/* Maximum number of stream IDs assigned to a single device */
+#define MAX_MASTER_STREAMIDS   MAX_PHANDLE_ARGS
+
+/* Maximum number of context banks per SMMU */
+#define ARM_SMMU_MAX_CBS   128
+
+/* Maximum number of mapping groups per SMMU */
+#define ARM_SMMU_MAX_SMRS  128
+
+/* SMMU global address space */
+#define ARM_SMMU_GR0(smmu) ((smmu)->base)
+#define ARM_SMMU_GR1(smmu) ((smmu)->base + (1 << (smmu)->pgshift))
+
+/*
+ * SMMU global address space with conditional offset to access secure
+ * aliases of non-secure registers (e.g. nsCR0: 0x400, nsGFSR: 0x448,
+ * nsGFSYNR0: 0x450)
+ */
+#define ARM_SMMU_GR0_NS(smmu)  \
+   ((smmu)->base + \
+   ((smmu->options & ARM_SMMU_OPT_SECURE_CFG_ACCESS)   \
+   ? 0x400 : 0))
+
+/* Page table bits */
+#define ARM_SMMU_PTE_XN(((pteval_t)3) << 53)
+#define ARM_SMMU_PTE_CONT  (((pteval_t)1) << 52)
+#define ARM_SMMU_PTE_AF(((pteval_t)1) << 10)
+#define ARM_SMMU_PTE_SH_NS (((pteval_t)0) << 8)
+#define ARM_SMMU_PTE_SH_OS (((pteval_t)2) << 8)
+#define ARM_SMMU_PTE_SH_IS (((pteval_t)3) << 8)
+#define ARM_SMMU_PTE_PAGE  (((pteval_t)3) << 0)
+
+#if PAGE_SIZE == SZ_4K
+#define ARM_SMMU_PTE_CONT_ENTRIES  16
+#elif PAGE_SIZE == SZ_64K
+#define ARM_SMMU_PTE_CONT_ENTRIES  32
+#else
+#define ARM_SMMU_PTE_CONT_ENTRIES  1
+#endif
+
+#define ARM_SMMU_PTE_CONT_SIZE (PAGE_SIZE * ARM_SMMU_PTE_CONT_ENTRIES)
+#define ARM_SMMU_PTE_CONT_MASK (~(ARM_SMMU_PTE_CONT_SIZE - 1))
+
+/* Stage-1 PTE */
+#define ARM_SMMU_PTE_AP_UNPRIV (((pteval_t)1) << 6)
+#define ARM_SMMU_PTE_AP_RDONLY (((pteval_t)2) << 6)
+#define ARM_SMMU_PTE_ATTRINDX_SHIFT2
+#define ARM_SMMU_PTE_nG(((pteval_t)1) << 11)
+
+/* Stage-2 PTE */
+#define ARM_SMMU_PTE_HAP_FAULT (((pteval_t)0) << 6)
+#define ARM_SMMU_PTE_HAP_READ  (((pteval_t)1) << 6)
+#define ARM_SMMU_PTE_HAP_WRITE (((pteval_t)2) << 6)
+#define ARM_SMMU_PTE_MEMATTR_OIWB  (((pteval_t)0xf) << 2)
+#define ARM_SMMU_PTE_MEMATTR_NC(((pteval_t)0x5) << 2)
+#define ARM_SMMU_PTE_MEMATTR_DEV   (((pteval_t)0x1) << 2)
+
+/* Configuration registers */
+#define ARM_SMMU_GR0_sCR0  0x0
+#define sCR0_CLIENTPD  (1 << 0)
+#define sCR0_GFRE  (1 << 1)
+#define sCR0_GFIE  (1 << 2)
+#define sCR0_GCFGFRE   (1 << 4)
+#define sCR0_GCFGFIE   (1 << 5)
+#define sCR0_USFCFG   

[Xen-devel] [PATCH v3 12/13] xen/iommu: smmu: Add Xen specific code to be able to use the driver

[Julien Grall]

The main goal is to modify as little the Linux code to be able to port
easily new feature added in Linux repo for the driver.

To achieve that we:
- Add helpers to Linux function not implemented on Xen
- Add callbacks used by Xen to do our own stuff and call Linux ones
- Only modify when required the code which comes from Linux. If so a
comment has been added with /* Xen: ... */ explaining why it's
necessary.

The support for PCI has been commented because it's not yet supported by
Xen ARM and therefore won't compile.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Add the ACCESS_ONCE definition in the drivers. The patch to
introduce the one in common code has been dropped.
- The include xen/device.h has been dropped in favor of
asm/device.h
---
 xen/drivers/passthrough/arm/Makefile |   1 +
 xen/drivers/passthrough/arm/smmu.c   | 678 +++
 2 files changed, 612 insertions(+), 67 deletions(-)

diff --git a/xen/drivers/passthrough/arm/Makefile 
b/xen/drivers/passthrough/arm/Makefile
index 0484b79..f4cd26e 100644
--- a/xen/drivers/passthrough/arm/Makefile
+++ b/xen/drivers/passthrough/arm/Makefile
@@ -1 +1,2 @@
 obj-y += iommu.o
+obj-y += smmu.o
diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index 8a6514f..373eee8 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -18,6 +18,13 @@
  *
  * Author: Will Deacon 
  *
+ * Based on Linux drivers/iommu/arm-smmu.c
+ * => commit e6b5be2be4e30037eb551e0ed09dd97bd00d85d3
+ *
+ * Xen modification:
+ * Julien Grall 
+ * Copyright (C) 2014 Linaro Limited.
+ *
  * This driver currently supports:
  * - SMMUv1 and v2 implementations
  * - Stream-matching and stream-indexing
@@ -28,26 +35,164 @@
  * - Context fault reporting
  */
 
-#define pr_fmt(fmt) "arm-smmu: " fmt
 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Xen: The below defines are redefined within the file. Undef it */
+#undef SCTLR_AFE
+#undef SCTLR_TRE
+#undef SCTLR_M
+#undef TTBCR_EAE
+
+/* Alias to Xen device tree helpers */
+#define device_node dt_device_node
+#define of_phandle_args dt_phandle_args
+#define of_device_id dt_device_match
+#define of_match_node dt_match_node
+#define of_property_read_u32(np, pname, out) (!dt_property_read_u32(np, pname, 
out))
+#define of_property_read_bool dt_property_read_bool
+#define of_parse_phandle_with_args dt_parse_phandle_with_args
+
+/* Xen: Helpers to get device MMIO and IRQs */
+struct resource
+{
+   u64 addr;
+   u64 size;
+   unsigned int type;
+};
+
+#define resource_size(res) (res)->size;
+
+#define platform_device dt_device_node
+
+#define IORESOURCE_MEM 0
+#define IORESOURCE_IRQ 1
+
+static struct resource *platform_get_resource(struct platform_device *pdev,
+ unsigned int type,
+ unsigned int num)
+{
+   /*
+* The resource is only used between 2 calls of platform_get_resource.
+* It's quite ugly but it's avoid to add too much code in the part
+* imported from Linux
+*/
+   static struct resource res;
+   int ret = 0;
+
+   res.type = type;
+
+   switch (type) {
+   case IORESOURCE_MEM:
+   ret = dt_device_get_address(pdev, num, &res.addr, &res.size);
+
+   return ((ret) ? NULL : &res);
+
+   case IORESOURCE_IRQ:
+   ret = platform_get_irq(pdev, num);
+   if (ret < 0)
+   return NULL;
+
+   res.addr = ret;
+   res.size = 1;
+
+   return &res;
+
+   default:
+   return NULL;
+   }
+}
+
+/* Alias to Xen IRQ functions */
+#define request_irq(irq, func, flags, name, dev) request_irq(irq, flags, func, 
name, dev)
+#define free_irq release_irq
+
+/*
+ * Device logger functions
+ * TODO: Handle PCI
+ */
+#define dev_print(dev, lvl, fmt, ...)  
\
+printk(lvl "smmu: %s: " fmt, dt_node_full_name(dev_to_dt(dev)), ## 
__VA_ARGS__)
+
+#define dev_dbg(dev, fmt, ...) dev_print(dev, XENLOG_DEBUG, fmt, ## 
__VA_ARGS__)
+#define dev_notice(dev, fmt, ...) dev_print(dev, XENLOG_INFO, fmt, ## 
__VA_ARGS__)
+#define dev_warn(dev, fmt, ...) dev_print(dev, XENLOG_WARNING, fmt, ## 
__VA_ARGS__)
+#define dev_err(dev, fmt, ...) dev_print(dev, XENLOG_ERR, fmt, ## __VA_ARGS__)
+
+#define dev_err_ratelimited(dev, fmt, ...) 
\
+dev_print(dev, XENLOG_ERR, fmt, ## __VA_ARGS__)
 
-#include 
+#define dev_name(dev) dt_node_full_name(dev_to_dt(dev))
 
-#include 

[Xen-devel] [PATCH v3 06/13] xen/arm: Introduce a generic way to describe device

[Julien Grall]

Currently, Xen is supporting PCI and Platform device (based on Device Tree).

While Xen only supports Platform device on ARM, Xen will gain support of
PCI soon.

Some drivers, such as IOMMU drivers, may handle PCI and platform device in
the same way. Only few lines of code differs.

Rather than requesting to provide 2 set of functions (one for PCI and
one for platform device), introduce a generic structure "device" which
is embedded in each specialized device.

As x86 only supports PCI, introduce a new type device_t which will be an
alias to pci_dev for this architecture. It will avoid to add a new field
for this place.

Signed-off-by: Julien Grall 
CC: Jan Beulich 
CC: Keir Fraser 
CC: Andrew Cooper 

---
Changes in v3:
- Drop common/device.c as it wasn't used after v1

Changes in v2:
- As x86 will only support PCI, only introduce the generic
device on ARM
- Introduce a typedef device_t to be used in common code
- Drop the PCI code for ARM for now. It will be reintroduced
when PCI support will be added
- s#asm/device.h#xen/device.h# is not anymore needed
---
 xen/common/device_tree.c  |  3 +++
 xen/include/asm-arm/device.h  | 26 ++
 xen/include/asm-x86/device.h  | 25 +
 xen/include/xen/device_tree.h | 13 +
 xen/include/xen/iommu.h   |  1 +
 xen/include/xen/pci.h |  1 +
 6 files changed, 69 insertions(+)
 create mode 100644 xen/include/asm-x86/device.h

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 34a1b9e..d1c716f 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -1454,6 +1454,9 @@ static unsigned long __init unflatten_dt_node(const void 
*fdt,
 ((char *)pp->value)[sz - 1] = 0;
 dt_dprintk("fixed up name for %s -> %s\n", pathp,
(char *)pp->value);
+/* Generic device initialization */
+np->dev.type = DEV_DT;
+np->dev.of_node = np;
 }
 }
 if ( allnextpp )
diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index b6b32bc..a3d45dd 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -2,8 +2,34 @@
 #define __ASM_ARM_DEVICE_H
 
 #include 
+
+enum device_type
+{
+DEV_DT,
+};
+
+struct dev_archdata {
+void *iommu;/* IOMMU private data */
+};
+
+/* struct device - The basic device structure */
+struct device
+{
+enum device_type type;
+#ifdef HAS_DEVICE_TREE
+struct dt_device_node *of_node; /* Used by drivers imported from Linux */
+#endif
+struct dev_archdata archdata;
+};
+
+typedef struct device device_t;
+
 #include 
 
+/* TODO: Correctly implement dev_is_pci when PCI will be supported on ARM */
+#define dev_is_pci(dev) ((void)(dev), 0)
+#define dev_is_dt(dev)  ((dev->type == DEV_DT)
+
 enum device_class
 {
 DEVICE_SERIAL,
diff --git a/xen/include/asm-x86/device.h b/xen/include/asm-x86/device.h
new file mode 100644
index 000..a016112
--- /dev/null
+++ b/xen/include/asm-x86/device.h
@@ -0,0 +1,25 @@
+#ifndef __ASM_X86_DEVICE_H
+#define __ASM_X86_DEVICE_H
+
+#include 
+
+/*
+ * x86 is only supported PCI. Therefore it's possible to directly use
+ * pci_dev to avoid adding new field.
+ */
+
+typedef struct pci_dev device_t;
+
+#define dev_is_pci(dev) ((void)(dev), 1)
+#define pci_to_dev(pci) (pci)
+
+#endif /* __ASM_X86_DEVICE_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 6502369..c8a0375 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -11,7 +11,9 @@
 #define __XEN_DEVICE_TREE_H__
 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -80,8 +82,19 @@ struct dt_device_node {
 /* IOMMU specific fields */
 bool is_protected;
 struct list_head domain_list;
+
+struct device dev;
 };
 
+#define dt_to_dev(dt_node)  (&(dt_node)->dev)
+
+static inline struct dt_device_node *dev_to_dt(struct device *dev)
+{
+ASSERT(dev->type == DEV_DT);
+
+return container_of(dev, struct dt_device_node, dev);
+}
+
 #define MAX_PHANDLE_ARGS 16
 struct dt_phandle_args {
 struct dt_device_node *np;
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 8eb764a..ecb2627 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 extern bool_t iommu_enable, iommu_enabled;
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 5f295f3..3988ee68 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*
-- 
2.1.4


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

[Xen-devel] [PATCH v3 04/13] xen/arm: device: Rename device_type into device_class

[Julien Grall]

This enum was used for matching a specific class of device and not to get the
type of device.

Hence the name device_type will be used for another purpose later.

Also rename device_get_type into device_get_class to reflect the change.

Signed-off-by: Julien Grall 

---
Changes in v3:
- Use device_class rather than device_match
- Rename device_get_type to device_class
---
 xen/arch/arm/device.c|  8 
 xen/arch/arm/domain_build.c  |  2 +-
 xen/include/asm-arm/device.h | 16 
 3 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/xen/arch/arm/device.c b/xen/arch/arm/device.c
index 59e94c0..1f9dbf7 100644
--- a/xen/arch/arm/device.c
+++ b/xen/arch/arm/device.c
@@ -40,7 +40,7 @@ static bool_t __init device_is_compatible(const struct 
device_desc *desc,
 return 0;
 }
 
-int __init device_init(struct dt_device_node *dev, enum device_type type,
+int __init device_init(struct dt_device_node *dev, enum device_class class,
const void *data)
 {
 const struct device_desc *desc;
@@ -52,7 +52,7 @@ int __init device_init(struct dt_device_node *dev, enum 
device_type type,
 
 for ( desc = _sdevice; desc != _edevice; desc++ )
 {
-if ( desc->type != type )
+if ( desc->class != class )
 continue;
 
 if ( device_is_compatible(desc, dev) )
@@ -67,7 +67,7 @@ int __init device_init(struct dt_device_node *dev, enum 
device_type type,
 return -EBADF;
 }
 
-enum device_type device_get_type(const struct dt_device_node *dev)
+enum device_class device_get_class(const struct dt_device_node *dev)
 {
 const struct device_desc *desc;
 
@@ -76,7 +76,7 @@ enum device_type device_get_type(const struct dt_device_node 
*dev)
 for ( desc = _sdevice; desc != _edevice; desc++ )
 {
 if ( device_is_compatible(desc, dev) )
-return desc->type;
+return desc->class;
 }
 
 return DEVICE_UNKNOWN;
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index c2dcb49..7b923e0 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1084,7 +1084,7 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
 /* Even if the IOMMU device is not used by Xen, it should not be
  * passthrough to DOM0
  */
-if ( device_get_type(node) == DEVICE_IOMMU )
+if ( device_get_class(node) == DEVICE_IOMMU )
 {
 DPRINT(" IOMMU, skip it\n");
 return 0;
diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index 74a80c6..b6b32bc 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -4,7 +4,7 @@
 #include 
 #include 
 
-enum device_type
+enum device_class
 {
 DEVICE_SERIAL,
 DEVICE_IOMMU,
@@ -16,8 +16,8 @@ enum device_type
 struct device_desc {
 /* Device name */
 const char *name;
-/* Device type */
-enum device_type type;
+/* Device class */
+enum device_class class;
 /* Array of device tree 'compatible' strings */
 const char *const *compatible;
 /* Device initialization */
@@ -27,12 +27,12 @@ struct device_desc {
 /**
  *  device_init - Initialize a device
  *  @dev: device to initialize
- *  @type: type of the device (serial, network...)
+ *  @class: class of the device (serial, network...)
  *  @data: specific data for initializing the device
  *
  *  Return 0 on success.
  */
-int __init device_init(struct dt_device_node *dev, enum device_type type,
+int __init device_init(struct dt_device_node *dev, enum device_class class,
const void *data);
 
 /**
@@ -41,13 +41,13 @@ int __init device_init(struct dt_device_node *dev, enum 
device_type type,
  *
  * Return the device type on success or DEVICE_ANY on failure
  */
-enum device_type device_get_type(const struct dt_device_node *dev);
+enum device_class device_get_class(const struct dt_device_node *dev);
 
-#define DT_DEVICE_START(_name, _namestr, _type) \
+#define DT_DEVICE_START(_name, _namestr, _class)\
 static const struct device_desc __dev_desc_##_name __used   \
 __attribute__((__section__(".dev.info"))) = {   \
 .name = _namestr,   \
-.type = _type,  \
+.class = _class,\
 
 #define DT_DEVICE_END   \
 };
-- 
2.1.4


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

[Xen-devel] [PATCH v3 08/13] xen/arm: Describe device supported by a driver with dt_match_node

[Julien Grall]

Xen is currently using list a compatible string to know if the driver
can use device node. This leads to have double definition in the GIC
code.

Futhermore Linux drivers is using dt_match_node (actually called of_device_id
in Linux) to list device supported by the drivers.

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

---
Changes in v3:
- Add Stefano's ack
---
 xen/arch/arm/device.c  | 21 ++---
 xen/arch/arm/gic-v2.c  | 10 --
 xen/arch/arm/gic-v3.c  |  8 
 xen/drivers/char/exynos4210-uart.c |  8 
 xen/drivers/char/ns16550.c | 12 ++--
 xen/drivers/char/omap-uart.c   |  8 
 xen/drivers/char/pl011.c   |  8 
 xen/include/asm-arm/device.h   |  4 ++--
 xen/include/asm-arm/gic.h  | 15 +--
 9 files changed, 35 insertions(+), 59 deletions(-)

diff --git a/xen/arch/arm/device.c b/xen/arch/arm/device.c
index 1f9dbf7..675784c 100644
--- a/xen/arch/arm/device.c
+++ b/xen/arch/arm/device.c
@@ -23,23 +23,6 @@
 
 extern const struct device_desc _sdevice[], _edevice[];
 
-static bool_t __init device_is_compatible(const struct device_desc *desc,
-  const struct dt_device_node *dev)
-{
-const char *const *compat;
-
-if ( !desc->compatible )
-return 0;
-
-for ( compat = desc->compatible; *compat; compat++ )
-{
-if ( dt_device_is_compatible(dev, *compat) )
-return 1;
-}
-
-return 0;
-}
-
 int __init device_init(struct dt_device_node *dev, enum device_class class,
const void *data)
 {
@@ -55,7 +38,7 @@ int __init device_init(struct dt_device_node *dev, enum 
device_class class,
 if ( desc->class != class )
 continue;
 
-if ( device_is_compatible(desc, dev) )
+if ( dt_match_node(desc->dt_match, dev) )
 {
 ASSERT(desc->init != NULL);
 
@@ -75,7 +58,7 @@ enum device_class device_get_class(const struct 
dt_device_node *dev)
 
 for ( desc = _sdevice; desc != _edevice; desc++ )
 {
-if ( device_is_compatible(desc, dev) )
+if ( dt_match_node(desc->dt_match, dev) )
 return desc->class;
 }
 
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index ee400b6..01aa46d 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -762,16 +762,14 @@ static int __init gicv2_init(struct dt_device_node *node, 
const void *data)
 return 0;
 }
 
-static const char * const gicv2_dt_compat[] __initconst =
+static const struct dt_device_match gicv2_dt_match[] __initconst =
 {
-DT_COMPAT_GIC_CORTEX_A15,
-DT_COMPAT_GIC_CORTEX_A7,
-DT_COMPAT_GIC_400,
-NULL
+DT_MATCH_GIC_V2,
+{ /* sentinel */ },
 };
 
 DT_DEVICE_START(gicv2, "GICv2", DEVICE_GIC)
-.compatible = gicv2_dt_compat,
+.dt_match = gicv2_dt_match,
 .init = gicv2_init,
 DT_DEVICE_END
 
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 47452ca..4f1fd51 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1276,14 +1276,14 @@ static int __init gicv3_init(struct dt_device_node 
*node, const void *data)
 return res;
 }
 
-static const char * const gicv3_dt_compat[] __initconst =
+static const struct dt_device_match gicv3_dt_match[] __initconst =
 {
-DT_COMPAT_GIC_V3,
-NULL
+DT_MATCH_GIC_V3,
+{ /* sentinel */ },
 };
 
 DT_DEVICE_START(gicv3, "GICv3", DEVICE_GIC)
-.compatible = gicv3_dt_compat,
+.dt_match = gicv3_dt_match,
 .init = gicv3_init,
 DT_DEVICE_END
 
diff --git a/xen/drivers/char/exynos4210-uart.c 
b/xen/drivers/char/exynos4210-uart.c
index cba8729..bac1c2b 100644
--- a/xen/drivers/char/exynos4210-uart.c
+++ b/xen/drivers/char/exynos4210-uart.c
@@ -352,14 +352,14 @@ static int __init exynos4210_uart_init(struct 
dt_device_node *dev,
 return 0;
 }
 
-static const char * const exynos4210_dt_compat[] __initconst =
+static const struct dt_device_match exynos4210_dt_match[] __initconst =
 {
-"samsung,exynos4210-uart",
-NULL
+DT_MATCH_COMPATIBLE("samsung,exynos4210-uart"),
+{ /* sentinel */ },
 };
 
 DT_DEVICE_START(exynos4210, "Exynos 4210 UART", DEVICE_SERIAL)
-.compatible = exynos4210_dt_compat,
+.dt_match = exynos4210_dt_match,
 .init = exynos4210_uart_init,
 DT_DEVICE_END
 
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index 161b251..d443880 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -1185,16 +1185,16 @@ static int __init ns16550_uart_dt_init(struct 
dt_device_node *dev,
 return 0;
 }
 
-static const char * const ns16550_dt_compat[] __initconst =
+static const struct dt_device_match ns16550_dt_match[] __initconst =
 {
-"ns16550",
-"ns16550a",
-"snps,dw-apb-uart",
-NULL
+DT_MATCH_COMPATIBLE("ns16550"),
+DT_MATCH_COMPATIBLE("ns16550a"),
+DT_MATCH_COMPATIBLE(

[Xen-devel] [PATCH v3 13/13] xen/iommu: smmu: Advertise when the SMMU support coherent table walk

[Julien Grall]

When SMMU doesn't support coherent table walk, Xen may need to clean
updated PT (see commit 4c5f4cb "xen/arm: p2m: Clean cache PT when the
IOMMU doesn't support coherent walk").

If one SMMU of the platform doesn't support coherent table walk, the
feature is disabled for the whole platform. This is because device is
assigned to a domain after the page table are populated.

This could impact performance on domain which doesn't use device
passthrough. But, as the spec strongly recommends the support of this
feature for maintstream platform, I expect server will always have SMMUs
supporting coherent table walk. If not, we may need to enable this feature
per-domain.

Signed-off-by: Julien Grall 

---
I've just noticed that the support on the previous driver (i.e in
Xen 4.5) may incorrectly expose this feature when all the SMMUs is
not supporting coherent table walk.

I'm not sure, if I should send a patch for it.

Also I didn't squash this patch into "xen/iommu: smmu: Add Xen specific
code to be able to use the driver" to help for review and to catch
possible error in this patch.

Changes in v3:
- Patch added
---
 xen/drivers/passthrough/arm/smmu.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index 373eee8..f4c7e49 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -577,6 +577,13 @@ struct arm_smmu_domain {
spinlock_t  lock;
 };
 
+/*
+ * Xen: Platform features. It indicates the list of features support by all the
+ * SMMUs.
+ * Actually we only care about coherent table walk.
+ */
+static u32 platform_features = ARM_SMMU_FEAT_COHERENT_WALK;
+
 /* Xen: Dummy iommu_domain */
 struct iommu_domain
 {
@@ -2810,6 +2817,13 @@ static int arm_smmu_iommu_domain_init(struct domain *d)
 
domain_hvm_iommu(d)->arch.priv = xen_domain;
 
+   /*
+* The feature coherent walk can be enabled only when all SMMUs
+* support it.
+*/
+   if (platform_features & ARM_SMMU_FEAT_COHERENT_WALK)
+   iommu_set_feature(d, IOMMU_FEAT_COHERENT_WALK);
+
return 0;
 }
 
@@ -2885,6 +2899,7 @@ static __init int arm_smmu_dt_init(struct dt_device_node 
*dev,
   const void *data)
 {
int rc;
+   struct arm_smmu_device *smmu;
 
/*
 * Even if the device can't be initialized, we don't want to
@@ -2896,6 +2911,16 @@ static __init int arm_smmu_dt_init(struct dt_device_node 
*dev,
if ( !rc )
iommu_set_ops(&arm_smmu_iommu_ops);
 
+   /*
+* The last added SMMU is the first element of arm_smmu_devices.
+* It's not necessary to take the lock because only the boot CPU is
+* initialized the SMMU devices.
+*/
+   smmu = list_entry(arm_smmu_devices.next, typeof(*smmu), list);
+   ASSERT(smmu != NULL);
+
+   platform_features &= smmu->features;
+
return rc;
 }
 
-- 
2.1.4


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

[Xen-devel] [PATCH v3 05/13] xen/iommu: arm: Remove temporary the SMMU driver

[Julien Grall]

The current SMMU driver has completly diverged. That makes me hard to
maintain.

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

---
Changes in v3:
- Add Stefano's ack
---
 xen/drivers/passthrough/arm/Makefile |1 -
 xen/drivers/passthrough/arm/smmu.c   | 1784 --
 2 files changed, 1785 deletions(-)
 delete mode 100644 xen/drivers/passthrough/arm/smmu.c

diff --git a/xen/drivers/passthrough/arm/Makefile 
b/xen/drivers/passthrough/arm/Makefile
index f4cd26e..0484b79 100644
--- a/xen/drivers/passthrough/arm/Makefile
+++ b/xen/drivers/passthrough/arm/Makefile
@@ -1,2 +1 @@
 obj-y += iommu.o
-obj-y += smmu.o
diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
deleted file mode 100644
index 42bde75..000
--- a/xen/drivers/passthrough/arm/smmu.c
+++ /dev/null
@@ -1,1784 +0,0 @@
-/*
- * IOMMU API for ARM architected SMMU implementations.
- *
- * 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, write to the Free Software
- * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- *
- * Based on Linux drivers/iommu/arm-smmu.c (commit 89a23cd)
- * Copyright (C) 2013 ARM Limited
- *
- * Author: Will Deacon 
- *
- * Xen modification:
- * Julien Grall 
- * Copyright (C) 2014 Linaro Limited.
- *
- * This driver currently supports:
- *  - SMMUv1 and v2 implementations (didn't try v2 SMMU)
- *  - Stream-matching and stream-indexing
- *  - v7/v8 long-descriptor format
- *  - Non-secure access to the SMMU
- *  - 4k pages, p2m shared with the processor
- *  - Up to 40-bit addressing
- *  - Context fault reporting
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-/* Driver options */
-#define SMMU_OPT_SECURE_CONFIG_ACCESS   (1 << 0)
-
-/* Maximum number of stream IDs assigned to a single device */
-#define MAX_MASTER_STREAMIDSMAX_PHANDLE_ARGS
-
-/* Maximum stream ID */
-#define SMMU_MAX_STREAMIDS  (PAGE_SIZE_64K - 1)
-
-/* Maximum number of context banks per SMMU */
-#define SMMU_MAX_CBS128
-
-/* Maximum number of mapping groups per SMMU */
-#define SMMU_MAX_SMRS   128
-
-/* SMMU global address space */
-#define SMMU_GR0(smmu)  ((smmu)->base)
-#define SMMU_GR1(smmu)  ((smmu)->base + (smmu)->pagesize)
-
-/*
- * SMMU global address space with conditional offset to access secure aliases 
of
- * non-secure registers (e.g. nsCR0: 0x400, nsGFSR: 0x448, nsGFSYNR0: 0x450)
- */
-#define SMMU_GR0_NS(smmu)   \
-((smmu)->base + \
- ((smmu->options & SMMU_OPT_SECURE_CONFIG_ACCESS)\
-? 0x400 : 0))
-
-/* Page table bits */
-#define SMMU_PTE_PAGE   (((pteval_t)3) << 0)
-#define SMMU_PTE_CONT   (((pteval_t)1) << 52)
-#define SMMU_PTE_AF (((pteval_t)1) << 10)
-#define SMMU_PTE_SH_NS  (((pteval_t)0) << 8)
-#define SMMU_PTE_SH_OS  (((pteval_t)2) << 8)
-#define SMMU_PTE_SH_IS  (((pteval_t)3) << 8)
-
-#if PAGE_SIZE == PAGE_SIZE_4K
-#define SMMU_PTE_CONT_ENTRIES   16
-#elif PAGE_SIZE == PAGE_SIZE_64K
-#define SMMU_PTE_CONT_ENTRIES   32
-#else
-#define SMMU_PTE_CONT_ENTRIES   1
-#endif
-
-#define SMMU_PTE_CONT_SIZE  (PAGE_SIZE * SMMU_PTE_CONT_ENTRIES)
-#define SMMU_PTE_CONT_MASK  (~(SMMU_PTE_CONT_SIZE - 1))
-#define SMMU_PTE_HWTABLE_SIZE   (PTRS_PER_PTE * sizeof(pte_t))
-
-/* Stage-1 PTE */
-#define SMMU_PTE_AP_UNPRIV  (((pteval_t)1) << 6)
-#define SMMU_PTE_AP_RDONLY  (((pteval_t)2) << 6)
-#define SMMU_PTE_ATTRINDX_SHIFT 2
-#define SMMU_PTE_nG (((pteval_t)1) << 11)
-
-/* Stage-2 PTE */
-#define SMMU_PTE_HAP_FAULT  (((pteval_t)0) << 6)
-#define SMMU_PTE_HAP_READ   (((pteval_t)1) << 6)
-#define SMMU_PTE_HAP_WRITE  (((pteval_t)2) << 6)
-#define SMMU_PTE_MEMATTR_OIWB   (((pteval_t)0xf) << 2)
-#define SMMU_PTE_MEMATTR_NC (((pteval_t)0x5) << 2)
-#define SMMU_PTE_MEMATTR_DEV(((pteval_t)0x1) << 2)
-
-/* Configuration registers */
-#define SMMU_GR0_sCR0   0x0
-#define SMMU_sCR0_CLIENTPD  (1 << 0)
-#define SMMU_sCR0_GFRE  (1 << 1)
-#define SMMU_sCR0_GFIE  (1 << 2)
-#define SMMU_sCR0_GCFGFRE   (1 << 4)
-#define SMMU_sCR0_GCFGFIE   (1 << 5)
-#define SMMU_sCR0_USFCFG(1 << 10)
-#define SMMU_sCR0_VMIDPNE   (1 << 11)
-#define SMMU_sCR0_PTM   (1 << 12)
-#define SMMU_sCR0_FB

[Xen-devel] [PATCH v3 07/13] xen/iommu: Consolidate device assignment ops into a single set

[Julien Grall]

On ARM, the way to assign device tree node is exactly the same as PCI.
Futhermore, all devices can be represented by a 'device_t'.
Therefore there is no need to add separate ops.

The x86 iommu drivers has not been modified to replace 'struct pci_dev'
by "device_t" because the latter is an alias of the former.

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

---
Changes in v3:
- Add Stefano and Jan's ack

Changes in v2:
- Use the newly type device_t
- It's not neccessary to modify the x86 iommu drivers
---
 xen/drivers/passthrough/device_tree.c |  5 +++--
 xen/drivers/passthrough/pci.c | 20 +++-
 xen/include/xen/iommu.h   | 17 ++---
 3 files changed, 20 insertions(+), 22 deletions(-)

diff --git a/xen/drivers/passthrough/device_tree.c 
b/xen/drivers/passthrough/device_tree.c
index 3e47df5..377d41d 100644
--- a/xen/drivers/passthrough/device_tree.c
+++ b/xen/drivers/passthrough/device_tree.c
@@ -41,7 +41,7 @@ int iommu_assign_dt_device(struct domain *d, struct 
dt_device_node *dev)
 if ( !list_empty(&dev->domain_list) )
 goto fail;
 
-rc = hd->platform_ops->assign_dt_device(d, dev);
+rc = hd->platform_ops->assign_device(d, 0, dt_to_dev(dev));
 
 if ( rc )
 goto fail;
@@ -68,7 +68,8 @@ int iommu_deassign_dt_device(struct domain *d, struct 
dt_device_node *dev)
 
 spin_lock(&dtdevs_lock);
 
-rc = hd->platform_ops->reassign_dt_device(d, hardware_domain, dev);
+rc = hd->platform_ops->reassign_device(d, hardware_domain,
+   0, dt_to_dev(dev));
 if ( rc )
 goto fail;
 
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 78c6977..71415d1 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1254,7 +1254,7 @@ int iommu_add_device(struct pci_dev *pdev)
 if ( !iommu_enabled || !hd->platform_ops )
 return 0;
 
-rc = hd->platform_ops->add_device(pdev->devfn, pdev);
+rc = hd->platform_ops->add_device(pdev->devfn, pci_to_dev(pdev));
 if ( rc || !pdev->phantom_stride )
 return rc;
 
@@ -1263,7 +1263,7 @@ int iommu_add_device(struct pci_dev *pdev)
 devfn += pdev->phantom_stride;
 if ( PCI_SLOT(devfn) != PCI_SLOT(pdev->devfn) )
 return 0;
-rc = hd->platform_ops->add_device(devfn, pdev);
+rc = hd->platform_ops->add_device(devfn, pci_to_dev(pdev));
 if ( rc )
 printk(XENLOG_WARNING "IOMMU: add %04x:%02x:%02x.%u failed (%d)\n",
pdev->seg, pdev->bus, PCI_SLOT(devfn), PCI_FUNC(devfn), rc);
@@ -1284,7 +1284,7 @@ int iommu_enable_device(struct pci_dev *pdev)
  !hd->platform_ops->enable_device )
 return 0;
 
-return hd->platform_ops->enable_device(pdev);
+return hd->platform_ops->enable_device(pci_to_dev(pdev));
 }
 
 int iommu_remove_device(struct pci_dev *pdev)
@@ -1306,7 +1306,7 @@ int iommu_remove_device(struct pci_dev *pdev)
 devfn += pdev->phantom_stride;
 if ( PCI_SLOT(devfn) != PCI_SLOT(pdev->devfn) )
 break;
-rc = hd->platform_ops->remove_device(devfn, pdev);
+rc = hd->platform_ops->remove_device(devfn, pci_to_dev(pdev));
 if ( !rc )
 continue;
 
@@ -1315,7 +1315,7 @@ int iommu_remove_device(struct pci_dev *pdev)
 return rc;
 }
 
-return hd->platform_ops->remove_device(pdev->devfn, pdev);
+return hd->platform_ops->remove_device(pdev->devfn, pci_to_dev(pdev));
 }
 
 /*
@@ -1376,7 +1376,7 @@ static int assign_device(struct domain *d, u16 seg, u8 
bus, u8 devfn)
 
 pdev->fault.count = 0;
 
-if ( (rc = hd->platform_ops->assign_device(d, devfn, pdev)) )
+if ( (rc = hd->platform_ops->assign_device(d, devfn, pci_to_dev(pdev))) )
 goto done;
 
 for ( ; pdev->phantom_stride; rc = 0 )
@@ -1384,7 +1384,7 @@ static int assign_device(struct domain *d, u16 seg, u8 
bus, u8 devfn)
 devfn += pdev->phantom_stride;
 if ( PCI_SLOT(devfn) != PCI_SLOT(pdev->devfn) )
 break;
-rc = hd->platform_ops->assign_device(d, devfn, pdev);
+rc = hd->platform_ops->assign_device(d, devfn, pci_to_dev(pdev));
 if ( rc )
 printk(XENLOG_G_WARNING "d%d: assign %04x:%02x:%02x.%u failed 
(%d)\n",
d->domain_id, seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
@@ -1419,7 +1419,8 @@ int deassign_device(struct domain *d, u16 seg, u8 bus, u8 
devfn)
 devfn += pdev->phantom_stride;
 if ( PCI_SLOT(devfn) != PCI_SLOT(pdev->devfn) )
 break;
-ret = hd->platform_ops->reassign_device(d, hardware_domain, devfn, 
pdev);
+ret = hd->platform_ops->reassign_device(d, hardware_domain, devfn,
+pci_to_dev(pdev));
 if ( !ret )
 continue;
 
@@ -1429,7 +1430,8 @@ int deassign_device(struct dom

[Xen-devel] [PATCH v3 11/13] xen/iommu: smmu: Introduce automatic stream-id-masking

[Julien Grall]

From: Andreas Herrmann 

Try to determine mask/id values that match several stream IDs of a
master device when doing Stream ID matching. Thus the number of used
SMR groups that are required to map all stream IDs of a master device
to a context should be less than the number of SMR groups used so far
(currently one SMR group is used for one stream ID).

Taken from the Linux ML:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/226100.html

Changes compare to the Linux ML version:
- _fls doesn't exist on Xen so use fls
- Use num_s2crs rather than num_streamids in the arm_smmu_free_smrs.
This former is the field used to configure SRMS

Cc: Andreas Herrmann 
Signed-off-by: Andreas Herrmann 
Signed-off-by: Julien Grall 

---

This patch was sent on Linux ML back to January 2014. It has never
been pushed upstream as it was only useful for Calxeda.

The SMMU used to protect the SATA on this platform has more stream
id than the number of stream matching registers. Therefore we have
to use stream id masking to configure correctly all the stream IDs.

Note that SMMU bindings for Calxeda is not upstreamed.
---
 xen/drivers/passthrough/arm/smmu.c | 177 +
 1 file changed, 162 insertions(+), 15 deletions(-)

diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index bfc1069..8a6514f 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -346,8 +347,10 @@ struct arm_smmu_smr {
 };
 
 struct arm_smmu_master_cfg {
-   int num_streamids;
+   u32 num_streamids;
u16 streamids[MAX_MASTER_STREAMIDS];
+   int num_s2crs;
+
struct arm_smmu_smr *smrs;
 };
 
@@ -392,6 +395,9 @@ struct arm_smmu_device {
u32 num_context_irqs;
unsigned int*irqs;
 
+   u32 smr_mask_mask;
+   u32 smr_id_mask;
+
struct list_headlist;
struct rb_root  masters;
 };
@@ -1113,6 +1119,137 @@ static void arm_smmu_free_pgtables(struct 
arm_smmu_domain *smmu_domain)
kfree(pgd_base);
 }
 
+/*
+ * For a given set N of 2**order different stream IDs (no duplicates
+ * please!) we determine values mask and id such that
+ *
+ * (1)  (x & mask) == id
+ *
+ * for each stream ID x from the given set N.
+ *
+ * If the number of bits that are set in mask equals n, then there
+ * exist 2**n different values y for which
+ *
+ * (2)  (y & mask) == id
+ *
+ * Thus if n equals order we know that for the calculated mask and id
+ * values there are exactly 2**order == 2**n stream IDs for which (1)
+ * is true. And we finally can use mask and id to configure an SMR to
+ * match all stream IDs in the set N.
+ */
+static int determine_smr_mask(struct arm_smmu_device *smmu,
+ struct arm_smmu_master_cfg *cfg,
+ struct arm_smmu_smr *smr, int start, int order)
+{
+   u16 i, zero_bits_mask, one_bits_mask, const_mask;
+   int nr;
+
+   nr = 1 << order;
+
+   if (nr == 1) {
+   /* no mask, use streamid to match and be done with it */
+   smr->mask = 0;
+   smr->id = cfg->streamids[start];
+   return 0;
+   }
+
+   zero_bits_mask = 0;
+   one_bits_mask = 0x;
+   for (i = start; i < start + nr; i++) {
+   zero_bits_mask |= cfg->streamids[i];/* const 0 bits */
+   one_bits_mask &= cfg->streamids[i]; /* const 1 bits */
+   }
+   zero_bits_mask = ~zero_bits_mask;
+
+   /* bits having constant values (either 0 or 1) */
+   const_mask = zero_bits_mask | one_bits_mask;
+
+   i = hweight16(~const_mask);
+   if (i == order) {
+   /*
+* We have found a mask/id pair that matches exactly
+* nr = 2**order stream IDs which we used for its
+* calculation.
+*/
+   smr->mask = ~const_mask;
+   smr->id = one_bits_mask;
+   } else {
+   /*
+* No usable mask/id pair for this set of streamids.
+* If i > order then mask/id would match more than nr
+* streamids.
+* If i < order then mask/id would match less than nr
+* streamids. (In this case we potentially have used
+* some duplicate streamids for the calculation.)
+*/
+   return 1;
+   }
+
+   if (((smr->mask & smmu->smr_mask_mask) != smr->mask) ||
+   ((smr->id & smmu->smr_id_mask) != smr->id))
+   /* insufficient number of ma

[Xen-devel] [PATCH v3 10/13] xen/iommu: smmu: Check for duplicate stream IDs when registering master devices

[Julien Grall]

From: Andreas Herrmann 

If DT information lists one stream ID twice for the master devices of
an SMMU this can cause a multi match when stream ID matching is used.
For stream ID indexing this might trigger an overwrite of an S2CR that
is already in use.

So better check for duplicates when DT information is parsed.

Taken from the linux ML:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/226099.html

Cc: Andreas Herrmann 
Signed-off-by: Andreas Herrmann 
Signed-off-by: Julien Grall 

---
This patch was sent on Linux ML back to January 2014. It has never
been pushed upstream as the only use was for Calxeda.

Note that SMMU bindings for Calxeda is not upstreamed.
---
 xen/drivers/passthrough/arm/smmu.c | 25 +++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index 6cd47b7..bfc1069 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -51,6 +51,9 @@
 /* Maximum number of stream IDs assigned to a single device */
 #define MAX_MASTER_STREAMIDS   MAX_PHANDLE_ARGS
 
+/* Maximum stream ID */
+#define ARM_SMMU_MAX_STREAMID  (SZ_64K - 1)
+
 /* Maximum number of context banks per SMMU */
 #define ARM_SMMU_MAX_CBS   128
 
@@ -519,7 +522,8 @@ static int insert_smmu_master(struct arm_smmu_device *smmu,
 
 static int register_smmu_master(struct arm_smmu_device *smmu,
struct device *dev,
-   struct of_phandle_args *masterspec)
+   struct of_phandle_args *masterspec,
+   unsigned long *smmu_sids)
 {
int i;
struct arm_smmu_master *master;
@@ -556,6 +560,12 @@ static int register_smmu_master(struct arm_smmu_device 
*smmu,
masterspec->np->name, smmu->num_mapping_groups);
return -ERANGE;
}
+
+   if (test_and_set_bit(streamid, smmu_sids)) {
+   dev_err(dev, "duplicate stream ID (%d)\n", streamid);
+   return -EEXIST;
+   }
+
master->cfg.streamids[i] = streamid;
}
return insert_smmu_master(smmu, master);
@@ -1977,6 +1987,7 @@ static int arm_smmu_device_dt_probe(struct 
platform_device *pdev)
struct device *dev = &pdev->dev;
struct rb_node *node;
struct of_phandle_args masterspec;
+   unsigned long *smmu_sids;
int num_irqs, i, err;
 
smmu = devm_kzalloc(dev, sizeof(*smmu), GFP_KERNEL);
@@ -2035,20 +2046,30 @@ static int arm_smmu_device_dt_probe(struct 
platform_device *pdev)
if (err)
return err;
 
+   smmu_sids = kzalloc(BITS_TO_LONGS(ARM_SMMU_MAX_STREAMID) *
+   sizeof(long), GFP_KERNEL);
+   if (!smmu_sids) {
+   dev_err(dev,
+   "failed to allocate bitmap for stream ID tracking\n");
+   return -ENOMEM;
+   }
+
i = 0;
smmu->masters = RB_ROOT;
while (!of_parse_phandle_with_args(dev->of_node, "mmu-masters",
   "#stream-id-cells", i,
   &masterspec)) {
-   err = register_smmu_master(smmu, dev, &masterspec);
+   err = register_smmu_master(smmu, dev, &masterspec, smmu_sids);
if (err) {
dev_err(dev, "failed to add master %s\n",
masterspec.np->name);
+   kfree(smmu_sids);
goto out_put_masters;
}
 
i++;
}
+   kfree(smmu_sids);
dev_notice(dev, "registered %d master devices\n", i);
 
parse_driver_options(smmu);
-- 
2.1.4


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

[Xen-devel] [PATCH v3 01/13] xen/arm: gic-v2: Change the device name in DT_DEVICE_START

[Julien Grall]

I'm not sure why a ':' has been added in the name... But none of the
other usages doesn't have it.

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

---
Changes in v3:
- Add Stefano's ack
---
 xen/arch/arm/gic-v2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 31fb81a..ee400b6 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -770,7 +770,7 @@ static const char * const gicv2_dt_compat[] __initconst =
 NULL
 };
 
-DT_DEVICE_START(gicv2, "GICv2:", DEVICE_GIC)
+DT_DEVICE_START(gicv2, "GICv2", DEVICE_GIC)
 .compatible = gicv2_dt_compat,
 .init = gicv2_init,
 DT_DEVICE_END
-- 
2.1.4


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

[Xen-devel] [PATCH v3 00/13] xen/arm: Resync the SMMU driver with the Linux one

[Julien Grall]

Hello,

The SMMU drivers has diverged from Linux. Having our own driver doesn't make
any benefits and make difficult to backport fixes and/or porting features such
as PCI.

With this series, the code of the SMMU drivers (copied from Linux) is mostly
not modified. If it's the case a comment /* Xen: ... */ has been added to
explain why. It's based on Linux 3.19. Even if they have plan to move out
most of the page table code in a separate library for 3.20, I think we should
stay on the 3.19 version. Indeed Linux drivers can move fast.

To make the change obvious the resync of the SMMU code is made in several step
1) Revert the current SMMU driver (patch #5)
2) Import as it is the driver from Linux (patch #9)
3) Apply 2 fixes which are useful to correctly use the SATA with SMMU on
calxeda. I don't know why Linux didn't yet applied (patch #10-11)
4) Chanes for Xen (patch #12)

I also took the opportunity of the resync to consolidate the iommu ops in a
single set. When I added the IOMMU set to handle platform device passthrough (
ops assing_dt_device and reassign_dt_device), I didn't think about merging the
ops with the PCI one. In fact Linux is using a single set and have only few
lines per driver specific to each set (PCI or platform device).

A branch is available with all the changes:
git::/xenbits.xen.org/people/julieng/xen-unstable.git branch smmu-rework-v2

Major changes in v3:
- Add back coherent walk support (see patch #13)

Major changes in v2:
- Introduce the generic struct to describe device on ARM. Alias it
to pci_dev on x86
- Defer the introduction of PCI in the generic device later

For all changes see each patches.

I have summarize below the patch acked/modified:

A: Patch acked
N: New patch
M: Patch modified in this version

Regards,

Andreas Herrmann (2):
 xen/iommu: smmu: Check for duplicate stream IDs when registering
   master devices
 xen/iommu: smmu: Introduce automatic stream-id-masking

Julien Grall (11):
 A   xen/arm: gic-v2: Change the device name in DT_DEVICE_START
 A   xen/arm: vgic: Drop unecessary include asm/device.h
   M xen/dt: Extend dt_device_match to possibly store data
   M xen/arm: device: Rename device_type into device_class
 A   xen/iommu: arm: Remove temporary the SMMU driver
   M xen/arm: Introduce a generic way to describe device
 A   xen/iommu: Consolidate device assignment ops into a single set
 A   xen/arm: Describe device supported by a driver with dt_match_node
   M xen/iommu: arm: Import the SMMU driver from Linux
 xen/iommu: smmu: Add Xen specific code to be able to use the driver
   N xen/iommu: smmu: Advertise when the SMMU support coherent table walk

 xen/arch/arm/device.c |   29 +-
 xen/arch/arm/domain_build.c   |2 +-
 xen/arch/arm/gic-v2.c |   12 +-
 xen/arch/arm/gic-v3.c |8 +-
 xen/arch/arm/platform.c   |2 +-
 xen/arch/arm/vgic-v2.c|1 -
 xen/arch/arm/vgic-v3.c|1 -
 xen/common/device_tree.c  |   15 +-
 xen/drivers/char/exynos4210-uart.c|8 +-
 xen/drivers/char/ns16550.c|   12 +-
 xen/drivers/char/omap-uart.c  |8 +-
 xen/drivers/char/pl011.c  |8 +-
 xen/drivers/passthrough/arm/smmu.c| 4146 +
 xen/drivers/passthrough/device_tree.c |5 +-
 xen/drivers/passthrough/pci.c |   20 +-
 xen/include/asm-arm/device.h  |   46 +-
 xen/include/asm-arm/gic.h |   15 +-
 xen/include/asm-x86/device.h  |   25 +
 xen/include/xen/device_tree.h |   19 +-
 xen/include/xen/iommu.h   |   18 +-
 xen/include/xen/pci.h |1 +
 21 files changed, 2795 insertions(+), 1606 deletions(-)
 create mode 100644 xen/include/asm-x86/device.h

-- 
2.1.4


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

[Xen-devel] [PATCH v3 03/13] xen/dt: Extend dt_device_match to possibly store data

[Julien Grall]

Some drivers may want to configure differently the device depending on
the compatible string. For this purpose, add a new field in the
dt_device_match to store the data.

Also modify the return type of dt_match_node to return the matching
structure.

Signed-off-by: Julien Grall 

---
Changes in v3:
- Make clear in the commit message that we add a new field...
---
 xen/arch/arm/platform.c   |  2 +-
 xen/common/device_tree.c  | 12 ++--
 xen/include/xen/device_tree.h |  6 --
 3 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/platform.c b/xen/arch/arm/platform.c
index cb4cda8..a79a098 100644
--- a/xen/arch/arm/platform.c
+++ b/xen/arch/arm/platform.c
@@ -157,7 +157,7 @@ bool_t platform_device_is_blacklisted(const struct 
dt_device_node *node)
 if ( platform && platform->blacklist_dev )
 blacklist = platform->blacklist_dev;
 
-return dt_match_node(blacklist, node);
+return (dt_match_node(blacklist, node) != NULL);
 }
 
 unsigned int platform_dom0_evtchn_ppi(void)
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index f72b2e9..34a1b9e 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -290,11 +290,12 @@ struct dt_device_node *dt_find_node_by_alias(const char 
*alias)
 return NULL;
 }
 
-bool_t dt_match_node(const struct dt_device_match *matches,
- const struct dt_device_node *node)
+const struct dt_device_match *
+dt_match_node(const struct dt_device_match *matches,
+  const struct dt_device_node *node)
 {
 if ( !matches )
-return 0;
+return NULL;
 
 while ( matches->path || matches->type ||
 matches->compatible || matches->not_available )
@@ -314,12 +315,11 @@ bool_t dt_match_node(const struct dt_device_match 
*matches,
 match &= !dt_device_is_available(node);
 
 if ( match )
-return match;
-
+return matches;
 matches++;
 }
 
-return 0;
+return NULL;
 }
 
 const struct dt_device_node *dt_get_parent(const struct dt_device_node *node)
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 08db8bc..6502369 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -28,6 +28,7 @@ struct dt_device_match {
 const char *type;
 const char *compatible;
 const bool_t not_available;
+const void *data;
 };
 
 #define DT_MATCH_PATH(p){ .path = p }
@@ -547,8 +548,9 @@ bool_t dt_device_is_available(const struct dt_device_node 
*device);
  *
  * Returns true if the device node match one of dt_device_match.
  */
-bool_t dt_match_node(const struct dt_device_match *matches,
- const struct dt_device_node *node);
+const struct dt_device_match *
+dt_match_node(const struct dt_device_match *matches,
+  const struct dt_device_node *node);
 
 /**
  * dt_find_matching_node - Find a node based on an dt_device_match match table
-- 
2.1.4


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

Re: [Xen-devel] New IOREQ type -- IOREQ_TYPE_VMWARE_PORT

[Don Slutz]

On 01/30/15 05:23, Paul Durrant wrote:
>> -Original Message-
>> From: Don Slutz [mailto:dsl...@verizon.com]
>> Sent: 29 January 2015 19:41
>> To: Paul Durrant; Don Slutz; qemu-de...@nongnu.org; Stefano Stabellini
>> Cc: Peter Maydell; Olaf Hering; Alexey Kardashevskiy; Stefan Weil; Michael
>> Tokarev; Alexander Graf; Gerd Hoffmann; Stefan Hajnoczi; Paolo Bonzini;
>> xen-devel
>> Subject: New IOREQ type -- IOREQ_TYPE_VMWARE_PORT
>>
 On 01/29/15 07:09, Paul Durrant wrote:
>> ...
 Given that IIRC you are using a new dedicated IOREQ type, I
 think there needs to be something that allows an emulator to
 register for this IOREQ type. How about adding a new type to
 those defined for HVMOP_map_io_range_to_ioreq_server for your
 case? (In your case the start and end values in the hypercall
 would be meaningless but it could be used to steer
 hvm_select_ioreq_server() into sending all emulation requests or
 your new type to QEMU.

>>
>> This is an interesting idea.  Will need to spend more time on it.
>>

This does look very doable.  The only issue I see is that it requires
a QEMU change in order to work.  This would prevent Xen 4.6 from using
QEMU 2.2.0 and vmport (vmware-tools, vmware-mouse).

What makes sense to me is to "invert it"  I.E. the default is to send
IOREQ_TYPE_VMWARE_PORT via io_range, and an ioreq server can say stop
sending them.

The reason this is safe so far is that IOREQ_TYPE_VMWARE_PORT can only
be sent if vmport is configured on.  And in that case QEMU will be
started with vmport=on which will cause all QEMUs that do not support
IOREQ_TYPE_VMWARE_PORT to crash.




>>
 Actually such a mechanism could be used
 to steer IOREQ_TYPE_TIMEOFFSET requests as, with the new QEMU
 patches, they are going nowhere. Upstream QEMU (as default) used
 to ignore them anyway, which is why I didn't bother with such a
 patch to Xen before but since you now need one maybe you could
 add that too?

>>
>> I think it would not be that hard.  Will look into adding it.
>>
>>
>> Currently I do not see how hvm_do_resume() works with 2 ioreq servers.
>> It looks like to me that if a vpcu (like 0) needs to wait for the
>> 2nd ioreq server, hvm_do_resume() will check the 1st ioreq server
>> and return as if the ioreq is done.  What am I missing?
>>
> 
> hvm_do_resume() walks the ioreq server list looking at the IOREQ state in the 
> shared page of each server in turn. If no IOREQ was sent to that server then 
> then state will be IOREQ_NONE and hvm_wait_for_io() will return 1 immediately 
> so the outer loop in hvm_do_resume() will move on to the next server. If a 
> state of IOREQ_READY or IOREQ_INPROCESS is found then the vcpu blocks on the 
> relevant event channel until the state transitions to IORESP_READY. The IOREQ 
> is then completed and the loop moves on to the next server.
> Normally an IOREQ would only be directed at one server and indeed IOREQs that 
> are issued for emulation requests (i.e. when io_state != HVMIO_none) fall 
> into this category but there is one case of a broadcast IOREQ, which is the 
> INVALIDATE IOREQ (sent to tell emulators to invalidate any mappings of guest 
> memory they may have cached) and that is why hvm_do_resume() has to iterate 
> over all servers.
> 
> Does that make sense?
> 

Thanks for the clear info.  It does make sense.

   -Don Slutz

>   Paul
> 
>>-Don Slutz
> 

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

Re: [Xen-devel] [PATCH v3 0/2] x86/arm64: add xenconfig

[Luis R. Rodriguez]

On Fri, Jan 30, 2015 at 2:49 AM, Michal Marek  wrote:
> On 2015-01-29 21:47, Paul Bolle wrote:
>> [Added Michal. Removed Yann.]
>>
>> On Thu, 2015-01-29 at 12:38 -0800, Luis R. Rodriguez wrote:
>>> On Tue, Jan 27, 2015 at 12:00 PM, Luis R. Rodriguez  wrote:
 On Fri, Jan 23, 2015 at 03:19:25PM +, Stefano Stabellini wrote:
> On Fri, 23 Jan 2015, Luis R. Rodriguez wrote:
>> On Wed, Jan 14, 2015 at 11:33:45AM -0800, Luis R. Rodriguez wrote:
>>> From: "Luis R. Rodriguez" 
>>>
>>> This v3 addresses Stefano's feedback from the v2 series, namely
>>> moving PCI stuff to x86 as its all x86 specific and also just
>>> removing the CONFIG_TCG_XEN=m from the general config. To be
>>> clear the changes from the v2 series are below.
>>>
>>> Luis R. Rodriguez (2):
>>>   x86, platform, xen, kconfig: clarify kvmconfig is for kvm
>>>   x86, arm, platform, xen, kconfig: add xen defconfig helper
>>>
>>>  arch/x86/configs/xen.config | 10 ++
>>>  kernel/configs/xen.config   | 26 ++
>>>  scripts/kconfig/Makefile|  7 ++-
>>>  3 files changed, 42 insertions(+), 1 deletion(-)
>>>  create mode 100644 arch/x86/configs/xen.config
>>>  create mode 100644 kernel/configs/xen.config
>>
>> Who could these changes go through?
>
> I would be OK with taking it in the Xen tree, but I would feel more
> comfortable doing that if you had an ack from Yann Morin (CC'ed).

 *Poke*
>>>
>>> Hey Yann, wondering if you had any feedback. Thanks.
>>
>> Yann has disappeared a year ago. Michal now, informally, keeps an eye on
>> kconfig related patches.
>
> I did not see this. Can you please bounce me the original series?

Done, let me know if you did not get them, and sorry for not adding
you on the original To list, in no way did I consider this had to go
through you as it didn't include any major kconfig changes and though
this was rather more of an x86 / xen tree thing.

 Luis

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

Re: [Xen-devel] [PATCH 3/5] hvmemul_do_io: If the send to the ioreq server failed do not retry.

[Don Slutz]

On 01/30/15 05:23, Jan Beulich wrote:
 On 30.01.15 at 01:52,  wrote:
>> I.E. do just what no backing DM does.
> 
> _If_ this is correct, the if() modified here should be folded with the
> one a few lines up.

Ok, will fold with the one a few lines up.  As expected without this
change the guest will hang (more details below).


> But looking at the description of the commit that
> introduced this (bac0999325 "x86 hvm: Do not incorrectly retire an
> instruction emulation...", almost immediately modified by f20f3c8ece
> "x86 hvm: On failed hvm_send_assist_req(), io emulation...") I doubt
> this is really what we want, or at the very least your change
> description should explain what was wrong with the original commit.
> 

Looking at these 2 commits, it looks to me like I need to handle these
cases also.  So it looks like having hvm_send_assist_req() return an int
0, 1, & 2 is the simpler way.  V2 on the way soon.

Which is the better codding style:

1) Add #defines for the return values?
2) Just use numbers?
3) Invert the sense 0 means worked, 1 is shutdown_deferral or
   domain_crash, 2 is hvm_complete_assist_req()?


I.E. (for just adding 2):


diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 2ed4344..c565151 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -227,10 +227,19 @@ static int hvmemul_do_io(
 else
 {
 rc = X86EMUL_RETRY;
-if ( !hvm_send_assist_req(&p) )
-vio->io_state = HVMIO_none;
-else if ( p_data == NULL )
+switch ( hvm_send_assist_req(&p) )
+{
+case 2:
 rc = X86EMUL_OKAY;
+/* fall through */
+case 0:
+vio->io_state = HVMIO_none;
+break;
+case 1:
+if ( p_data == NULL )
+rc = X86EMUL_OKAY;
+break;
+}
 }


???



I would think it would be good for the code using hvm_has_dm()
to also call on hvm_complete_assist_req().  hvm_has_dm() is a subset of
the cases that hvm_select_ioreq_server() checks for.

Based on this, I think it would be better to remove the call on
hvm_has_dm() instead of adding a call to hvm_complete_assist_req().


   -Don Slutz
P.S. Details for hang:

Using:

 static bool_t hvm_complete_assist_req(ioreq_t *p)
 {
+HVMTRACE_1D(COMPLETE_ASSIST, p->type);
...
):

I get the trace:

CPU1  745455716325 (+1362)  VMEXIT  [ exitcode = 0x001e, rIP
 = 0x00101581 ]
CPU1  0 (+   0)  COMPLETE_ASSIST [ type = 0 ]
CPU1  0 (+   0)  HANDLE_PIO [ port = 0x0cfe size = 2 dir = 1
io_state = 0 ret = 0 ]
CPU1  745455717846 (+1521)  vlapic_accept_pic_intr [ i8259_target =
1, accept_pic_int = 1 ]
CPU1  745455718209 (+ 363)  VMENTRY
CPU1  745455719568 (+1359)  VMEXIT  [ exitcode = 0x001e, rIP
 = 0x00101581 ]
CPU1  0 (+   0)  COMPLETE_ASSIST [ type = 0 ]
CPU1  0 (+   0)  HANDLE_PIO [ port = 0x0cfe size = 2 dir = 1
io_state = 0 ret = 0 ]
CPU1  745455721083 (+1515)  vlapic_accept_pic_intr [ i8259_target =
1, accept_pic_int = 1 ]
CPU1  745455721422 (+ 339)  VMENTRY
CPU1  745455722781 (+1359)  VMEXIT  [ exitcode = 0x001e, rIP
 = 0x00101581 ]
CPU1  0 (+   0)  COMPLETE_ASSIST [ type = 0 ]
CPU1  0 (+   0)  HANDLE_PIO [ port = 0x0cfe size = 2 dir = 1
io_state = 0 ret = 0 ]
CPU1  745455724299 (+1518)  vlapic_accept_pic_intr [ i8259_target =
1, accept_pic_int = 1 ]
CPU1  745455724656 (+ 357)  VMENTRY
CPU1  745455726009 (+1353)  VMEXIT  [ exitcode = 0x001e, rIP
 = 0x00101581 ]
CPU1  0 (+   0)  COMPLETE_ASSIST [ type = 0 ]
CPU1  0 (+   0)  HANDLE_PIO [ port = 0x0cfe size = 2 dir = 1
io_state = 0 ret = 0 ]
CPU1  745455727539 (+1530)  vlapic_accept_pic_intr [ i8259_target =
1, accept_pic_int = 1 ]
CPU1  745455727899 (+ 360)  VMENTRY
CPU1  745455729276 (+1377)  VMEXIT  [ exitcode = 0x001e, rIP
 = 0x00101581 ]
CPU1  0 (+   0)  COMPLETE_ASSIST [ type = 0 ]
CPU1  0 (+   0)  HANDLE_PIO [ port = 0x0cfe size = 2 dir = 1
io_state = 0 ret = 0 ]
CPU1  745455730803 (+1527)  vlapic_accept_pic_intr [ i8259_target =
1, accept_pic_int = 1 ]
CPU1  745455731163 (+ 360)  VMENTRY
CPU1  745455732525 (+1362)  VMEXIT  [ exitcode = 0x001e, rIP
 = 0x00101581 ]
CPU1  0 (+   0)  COMPLETE_ASSIST [ type = 0 ]
CPU1  0 (+   0)  HANDLE_PIO [ port = 0x0cfe size = 2 dir = 1
io_state = 0 ret = 0 ]
CPU1  745455734049 (+1524)  vlapic_accept_pic_intr [ i8259_target =
1, accept_pic_int = 1 ]
CPU1  745455734385 (+ 336)  VMENTRY
...


> Jan
> 
>> --- a/xen/arch/x86/hvm/emulate.c
>> +++ b/xen/arch/x86/hvm/emulate.c
>> @@ -228,7 +228,11 @@ static int hvmemul_do_io(
>>  {
>>  rc = X86EMUL_RETRY;
>>  if ( !hvm_send_assist_req(&p) )
>> +{
>> +/* Since the send failed, do not retry */
>> +rc = X86EMUL_OKAY;
>

Re: [Xen-devel] [PATCH 04/18] xen/x86: add multiboot2 protocol support

[Andrew Cooper]

On 30/01/15 17:54, Daniel Kiper wrote:
> Add multiboot2 protocol support. Alter min memory limit handling as we
> now may not find it from either multiboot (v1) or multiboot2.
>
> This way we are laying the foundation for EFI + GRUB2 + Xen development.
>
> Signed-off-by: Daniel Kiper 

I have not reviewed the multiboot2 protocol in detail, but it appears
sane and I presume it is suitably tested and works.

As far as the mb1/mb2 interaction goes, this is looking far better.

Reviewed-by: Andrew Cooper 

> ---
>  xen/arch/x86/boot/Makefile|3 +-
>  xen/arch/x86/boot/head.S  |  104 --
>  xen/arch/x86/boot/reloc.c |  174 
> -
>  xen/arch/x86/x86_64/asm-offsets.c |6 ++
>  xen/include/xen/multiboot2.h  |  169 +++
>  5 files changed, 429 insertions(+), 27 deletions(-)
>  create mode 100644 xen/include/xen/multiboot2.h
>
> diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
> index 5fdb5ae..0efa7d2 100644
> --- a/xen/arch/x86/boot/Makefile
> +++ b/xen/arch/x86/boot/Makefile
> @@ -1,6 +1,7 @@
>  obj-bin-y += head.o
>  
> -RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h 
> $(BASEDIR)/include/xen/multiboot.h
> +RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h 
> $(BASEDIR)/include/xen/compiler.h \
> +  $(BASEDIR)/include/xen/multiboot.h 
> $(BASEDIR)/include/xen/multiboot2.h
>  
>  head.o: reloc.S
>  
> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> index 6180783..7861057 100644
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -1,5 +1,6 @@
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -32,6 +33,59 @@ ENTRY(start)
>  .long   MULTIBOOT_HEADER_FLAGS
>  /* Checksum: must be the negated sum of the first two fields. */
>  .long   -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)
> + 
> +/*** MULTIBOOT2 HEADER /
> +/* Some ideas are taken from grub-2.00/grub-core/tests/boot/kernel-i386.S 
> file. */
> +.align  MULTIBOOT2_HEADER_ALIGN
> +
> +.Lmultiboot2_header:
> +/* Magic number indicating a Multiboot2 header. */
> +.long   MULTIBOOT2_HEADER_MAGIC
> +/* Architecture: i386. */
> +.long   MULTIBOOT2_ARCHITECTURE_I386
> +/* Multiboot2 header length. */
> +.long   .Lmultiboot2_header_end - .Lmultiboot2_header
> +/* Multiboot2 header checksum. */
> +.long   -(MULTIBOOT2_HEADER_MAGIC + MULTIBOOT2_ARCHITECTURE_I386 + \
> +(.Lmultiboot2_header_end - .Lmultiboot2_header))
> +
> +/* Multiboot2 tags... */
> +.Lmultiboot2_info_req:
> +/* Multiboot2 information request tag. */
> +.short  MULTIBOOT2_HEADER_TAG_INFORMATION_REQUEST
> +.short  MULTIBOOT2_HEADER_TAG_REQUIRED
> +.long   .Lmultiboot2_info_req_end - .Lmultiboot2_info_req
> +.long   MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO
> +.long   MULTIBOOT2_TAG_TYPE_MMAP
> +.Lmultiboot2_info_req_end:
> +
> +.align  MULTIBOOT2_TAG_ALIGN
> +.short  MULTIBOOT2_HEADER_TAG_MODULE_ALIGN
> +.short  MULTIBOOT2_HEADER_TAG_REQUIRED
> +.long   8 /* Tag size. */
> +
> +/* Console flags tag. */
> +.align  MULTIBOOT2_TAG_ALIGN
> +.short  MULTIBOOT2_HEADER_TAG_CONSOLE_FLAGS
> +.short  MULTIBOOT2_HEADER_TAG_OPTIONAL
> +.long   12 /* Tag size. */
> +.long   MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED
> +
> +/* Framebuffer tag. */
> +.align  MULTIBOOT2_TAG_ALIGN
> +.short  MULTIBOOT2_HEADER_TAG_FRAMEBUFFER
> +.short  MULTIBOOT2_HEADER_TAG_OPTIONAL
> +.long   20 /* Tag size. */
> +.long   0 /* Number of the columns - no preference. */
> +.long   0 /* Number of the lines - no preference. */
> +.long   0 /* Number of bits per pixel - no preference. */
> +
> +/* Multiboot2 header end tag. */
> +.align  MULTIBOOT2_TAG_ALIGN
> +.short  MULTIBOOT2_HEADER_TAG_END
> +.short  0
> +.long   8 /* Tag size. */
> +.Lmultiboot2_header_end:
>  
>  .section .init.rodata, "a", @progbits
>  .align 4
> @@ -81,10 +135,51 @@ __start:
>  mov %ecx,%es
>  mov %ecx,%ss
>  
> +/* Bootloaders may set multiboot[12].mem_lower to a nonzero value */
> +xor %edx,%edx
> +
>  /* Check for Multiboot bootloader */
>  cmp $MULTIBOOT_BOOTLOADER_MAGIC,%eax
> -jne not_multiboot
> +je  multiboot1_proto
>  
> +/* Check for Multiboot2 bootloader */
> +cmp $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
> +je  multiboot2_proto
> +
> +jmp not_multiboot
> +
> +multiboot1_proto:
> +/* Get mem_lower from Multiboot information */
> +testb   $MBI_MEMLIMITS,(%ebx)
> +jz  trampoline_setup/* not available? BDA value will be 

Re: [Xen-devel] [PATCH 00/18] x86: multiboot2 protocol support

[Daniel Kiper]

On Fri, Jan 30, 2015 at 06:54:04PM +0100, Daniel Kiper wrote:
> Hi,
>
> I am sending, long awaited, first version of multiboot2 protocol
> support for legacy BIOS and EFI platforms.

By mistake I forgot to thank you Andrew and Konrad for support
during development of this series. Sorry guys.

Daniel

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

Re: [Xen-devel] [PATCH 02/18] x86/boot/reloc: create generic alloc and copy functions

[Andrew Cooper]

On 30/01/15 17:54, Daniel Kiper wrote:
> Create generic alloc and copy functions. We need
> separate tools for memory allocation and copy to
> provide multiboot2 protocol support.
>
> Signed-off-by: Daniel Kiper 

Reviewed-by: Andrew Cooper 

> ---
>  xen/arch/x86/boot/reloc.c |   52 
> -
>  1 file changed, 33 insertions(+), 19 deletions(-)
>
> diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
> index 63045c0..f964cda 100644
> --- a/xen/arch/x86/boot/reloc.c
> +++ b/xen/arch/x86/boot/reloc.c
> @@ -33,9 +33,10 @@ asm (
>  typedef unsigned int u32;
>  #include "../../../include/xen/multiboot.h"
>  
> -static void *reloc_mbi_struct(void *old, unsigned int bytes)
> +static u32 alloc_struct(u32 bytes)
>  {
> -void *new;
> +u32 s;
> +
>  asm(
>  "call 1f  \n"
>  "1:  pop  %%edx   \n"
> @@ -43,50 +44,63 @@ static void *reloc_mbi_struct(void *old, unsigned int 
> bytes)
>  "sub  %1,%0   \n"
>  "and  $~15,%0 \n"
>  "mov  %0,alloc-1b(%%edx)  \n"
> -"mov  %0,%%edi\n"
> -"rep  movsb   \n"
> -   : "=&r" (new), "+c" (bytes), "+S" (old)
> - : : "edx", "edi", "memory");
> -return new;
> +   : "=&r" (s) : "r" (bytes) : "edx", "memory");
> +
> +return s;
> +}
> +
> +static u32 copy_struct(u32 src, u32 bytes)
> +{
> +u32 dst, dst_asm;
> +
> +dst = alloc_struct(bytes);
> +dst_asm = dst;
> +
> +asm volatile("rep movsb" : "+S" (src), "+D" (dst_asm), "+c" (bytes) : : 
> "memory");
> +
> +return dst;
>  }
>  
> -static char *reloc_mbi_string(char *old)
> +static u32 copy_string(u32 src)
>  {
>  char *p;
> -for ( p = old; *p != '\0'; p++ )
> +
> +if ( src == 0 )
> +return 0;
> +
> +for ( p = (char *)src; *p != '\0'; p++ )
>  continue;
> -return reloc_mbi_struct(old, p - old + 1);
> +
> +return copy_struct(src, p - (char *)src + 1);
>  }
>  
>  multiboot_info_t *reloc(multiboot_info_t *mbi_old)
>  {
> -multiboot_info_t *mbi = reloc_mbi_struct(mbi_old, sizeof(*mbi));
> +multiboot_info_t *mbi = (multiboot_info_t *)copy_struct((u32)mbi_old, 
> sizeof(*mbi));
>  int i;
>  
>  if ( mbi->flags & MBI_CMDLINE )
> -mbi->cmdline = (u32)reloc_mbi_string((char *)mbi->cmdline);
> +mbi->cmdline = copy_string(mbi->cmdline);
>  
>  if ( mbi->flags & MBI_MODULES )
>  {
> -module_t *mods = reloc_mbi_struct(
> -(module_t *)mbi->mods_addr, mbi->mods_count * sizeof(module_t));
> +module_t *mods = (module_t *)copy_struct(
> +mbi->mods_addr, mbi->mods_count * sizeof(module_t));
>  
>  mbi->mods_addr = (u32)mods;
>  
>  for ( i = 0; i < mbi->mods_count; i++ )
>  {
>  if ( mods[i].string )
> -mods[i].string = (u32)reloc_mbi_string((char 
> *)mods[i].string);
> +mods[i].string = copy_string(mods[i].string);
>  }
>  }
>  
>  if ( mbi->flags & MBI_MEMMAP )
> -mbi->mmap_addr = (u32)reloc_mbi_struct(
> -(memory_map_t *)mbi->mmap_addr, mbi->mmap_length);
> +mbi->mmap_addr = copy_struct(mbi->mmap_addr, mbi->mmap_length);
>  
>  if ( mbi->flags & MBI_LOADERNAME )
> -mbi->boot_loader_name = (u32)reloc_mbi_string(
> -(char *)mbi->boot_loader_name);
> +mbi->boot_loader_name = copy_string(mbi->boot_loader_name);
>  
>  /* Mask features we don't understand or don't relocate. */
>  mbi->flags &= (MBI_MEMLIMITS |


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

[Xen-devel] [PATCH 4/5] i386/relocator: Add grub_relocator64_efi relocator

[Daniel Kiper]

Add grub_relocator64_efi relocator. It will be used on EFI 64-bit platforms
when multiboot2 compatible image requests MULTIBOOT_TAG_TYPE_EFI_BS. Relocator
will set lower parts of %rax and %rbx accordingly to multiboot2 specification.
On the other hand processor mode, just before jumping into loaded image, will
be set accordingly to Unified Extensible Firmware Interface Specification,
Version 2.4 Errata B, section 2.3.4, x64 Platforms, boot services. This way
loaded image will be able to use EFI boot services without any issues.

If idea is accepted I will prepare grub_relocator32_efi relocator too.

Signed-off-by: Daniel Kiper 
---
 grub-core/Makefile.core.def  |1 +
 grub-core/lib/i386/relocator.c   |   53 +++
 grub-core/lib/i386/relocator64_efi.S |   77 ++
 grub-core/loader/multiboot.c |   29 +++--
 grub-core/loader/multiboot_mbi2.c|   19 +++--
 include/grub/i386/multiboot.h|   11 +
 include/grub/i386/relocator.h|   21 ++
 include/multiboot2.h |9 
 8 files changed, 213 insertions(+), 7 deletions(-)
 create mode 100644 grub-core/lib/i386/relocator64_efi.S

diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 42443bc..3a01189 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -1533,6 +1533,7 @@ module = {
   x86 = lib/i386/relocator_common_c.c;
   ieee1275 = lib/ieee1275/relocator.c;
   efi = lib/efi/relocator.c;
+  x86_64_efi = lib/i386/relocator64_efi.S;
   mips = lib/mips/relocator_asm.S;
   mips = lib/mips/relocator.c;
   powerpc = lib/powerpc/relocator_asm.S;
diff --git a/grub-core/lib/i386/relocator.c b/grub-core/lib/i386/relocator.c
index b879e5b..f4d688e 100644
--- a/grub-core/lib/i386/relocator.c
+++ b/grub-core/lib/i386/relocator.c
@@ -69,6 +69,19 @@ extern grub_uint64_t grub_relocator64_rsi;
 extern grub_addr_t grub_relocator64_cr3;
 extern struct grub_i386_idt grub_relocator16_idt;
 
+#ifdef GRUB_MACHINE_EFI
+#ifdef __x86_64__
+extern grub_uint8_t grub_relocator64_efi_start;
+extern grub_uint8_t grub_relocator64_efi_end;
+extern grub_uint64_t grub_relocator64_efi_rax;
+extern grub_uint64_t grub_relocator64_efi_rbx;
+extern grub_uint64_t grub_relocator64_efi_rcx;
+extern grub_uint64_t grub_relocator64_efi_rdx;
+extern grub_uint64_t grub_relocator64_efi_rip;
+extern grub_uint64_t grub_relocator64_efi_rsi;
+#endif
+#endif
+
 #define RELOCATOR_SIZEOF(x)(&grub_relocator##x##_end - 
&grub_relocator##x##_start)
 
 grub_err_t
@@ -213,3 +226,43 @@ grub_relocator64_boot (struct grub_relocator *rel,
   /* Not reached.  */
   return GRUB_ERR_NONE;
 }
+
+#ifdef GRUB_MACHINE_EFI
+#ifdef __x86_64__
+grub_err_t
+grub_relocator64_efi_boot (struct grub_relocator *rel,
+  struct grub_relocator64_efi_state state)
+{
+  grub_err_t err;
+  void *relst;
+  grub_relocator_chunk_t ch;
+
+  err = grub_relocator_alloc_chunk_align (rel, &ch, 0,
+ 0x4000 - RELOCATOR_SIZEOF 
(64_efi),
+ RELOCATOR_SIZEOF (64_efi), 16,
+ GRUB_RELOCATOR_PREFERENCE_NONE, 1);
+  if (err)
+return err;
+
+  grub_relocator64_efi_rax = state.rax;
+  grub_relocator64_efi_rbx = state.rbx;
+  grub_relocator64_efi_rcx = state.rcx;
+  grub_relocator64_efi_rdx = state.rdx;
+  grub_relocator64_efi_rip = state.rip;
+  grub_relocator64_efi_rsi = state.rsi;
+
+  grub_memmove (get_virtual_current_address (ch), &grub_relocator64_efi_start,
+   RELOCATOR_SIZEOF (64_efi));
+
+  err = grub_relocator_prepare_relocs (rel, get_physical_target_address (ch),
+  &relst, NULL);
+  if (err)
+return err;
+
+  ((void (*) (void)) relst) ();
+
+  /* Not reached.  */
+  return GRUB_ERR_NONE;
+}
+#endif
+#endif
diff --git a/grub-core/lib/i386/relocator64_efi.S 
b/grub-core/lib/i386/relocator64_efi.S
new file mode 100644
index 000..6baaec6
--- /dev/null
+++ b/grub-core/lib/i386/relocator64_efi.S
@@ -0,0 +1,77 @@
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2009,2010  Free Software Foundation, Inc.
+ *  Copyright (C) 2014,2015  Oracle Corp.
+ *  Author: Daniel Kiper
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB 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 GRUB.  If not, see .
+ */
+
+#include "relocator_common.S"
+
+   .p2align   

[Xen-devel] [PATCH 3/5] i386/relocator: Remove unused avoid_efi_bootservices argument

[Daniel Kiper]

Signed-off-by: Daniel Kiper 
---
 grub-core/lib/i386/relocator.c   |5 ++---
 grub-core/loader/i386/bsd.c  |6 +++---
 grub-core/loader/i386/coreboot/chainloader.c |2 +-
 grub-core/loader/i386/linux.c|2 +-
 grub-core/loader/i386/pc/plan9.c |2 +-
 grub-core/loader/i386/xnu.c  |4 ++--
 grub-core/loader/multiboot.c |4 
 include/grub/i386/relocator.h|3 +--
 8 files changed, 11 insertions(+), 17 deletions(-)

diff --git a/grub-core/lib/i386/relocator.c b/grub-core/lib/i386/relocator.c
index 71dd4f0..b879e5b 100644
--- a/grub-core/lib/i386/relocator.c
+++ b/grub-core/lib/i386/relocator.c
@@ -73,8 +73,7 @@ extern struct grub_i386_idt grub_relocator16_idt;
 
 grub_err_t
 grub_relocator32_boot (struct grub_relocator *rel,
-  struct grub_relocator32_state state,
-  int avoid_efi_bootservices)
+  struct grub_relocator32_state state)
 {
   grub_err_t err;
   void *relst;
@@ -87,7 +86,7 @@ grub_relocator32_boot (struct grub_relocator *rel,
  0x9a000 - RELOCATOR_SIZEOF (32),
  RELOCATOR_SIZEOF (32), 16,
  GRUB_RELOCATOR_PREFERENCE_LOW,
- avoid_efi_bootservices);
+ 0);
   if (err)
 return err;
 
diff --git a/grub-core/loader/i386/bsd.c b/grub-core/loader/i386/bsd.c
index bc377b3..c2bf09f 100644
--- a/grub-core/loader/i386/bsd.c
+++ b/grub-core/loader/i386/bsd.c
@@ -797,7 +797,7 @@ grub_freebsd_boot (void)
   stack[6] = stack_target + 9 * sizeof (grub_uint32_t);
   stack[7] = bi.tags;
   stack[8] = kern_end;
-  return grub_relocator32_boot (relocator, state, 0);
+  return grub_relocator32_boot (relocator, state);
 }
 
   /* Not reached.  */
@@ -913,7 +913,7 @@ grub_openbsd_boot (void)
   stack[7] = (grub_uint8_t *) curarg - (grub_uint8_t *) arg0;
   stack[8] = ((grub_uint8_t *) arg0 - (grub_uint8_t *) buf0) + buf_target;
 
-  return grub_relocator32_boot (relocator, state, 0);
+  return grub_relocator32_boot (relocator, state);
 }
 
 static grub_err_t
@@ -1228,7 +1228,7 @@ grub_netbsd_boot (void)
   stack[5] = grub_mmap_get_upper () >> 10;
   stack[6] = grub_mmap_get_lower () >> 10;
 
-  return grub_relocator32_boot (relocator, state, 0);
+  return grub_relocator32_boot (relocator, state);
 }
 
 static grub_err_t
diff --git a/grub-core/loader/i386/coreboot/chainloader.c 
b/grub-core/loader/i386/coreboot/chainloader.c
index d4cc40b..4bf6dff 100644
--- a/grub-core/loader/i386/coreboot/chainloader.c
+++ b/grub-core/loader/i386/coreboot/chainloader.c
@@ -47,7 +47,7 @@ grub_chain_boot (void)
   grub_video_set_mode ("text", 0, 0);
 
   state.eip = entry;
-  return grub_relocator32_boot (relocator, state, 0);
+  return grub_relocator32_boot (relocator, state);
 }
 
 static grub_err_t
diff --git a/grub-core/loader/i386/linux.c b/grub-core/loader/i386/linux.c
index 291f728..a554da8 100644
--- a/grub-core/loader/i386/linux.c
+++ b/grub-core/loader/i386/linux.c
@@ -661,7 +661,7 @@ grub_linux_boot (void)
   state.esi = ctx.real_mode_target;
   state.esp = ctx.real_mode_target;
   state.eip = ctx.params->code32_start;
-  return grub_relocator32_boot (relocator, state, 0);
+  return grub_relocator32_boot (relocator, state);
 }
 
 static grub_err_t
diff --git a/grub-core/loader/i386/pc/plan9.c b/grub-core/loader/i386/pc/plan9.c
index 814a49d..bfff497 100644
--- a/grub-core/loader/i386/pc/plan9.c
+++ b/grub-core/loader/i386/pc/plan9.c
@@ -90,7 +90,7 @@ grub_plan9_boot (void)
   };
   grub_video_set_mode ("text", 0, 0);
 
-  return grub_relocator32_boot (rel, state, 0);
+  return grub_relocator32_boot (rel, state);
 }
 
 static grub_err_t
diff --git a/grub-core/loader/i386/xnu.c b/grub-core/loader/i386/xnu.c
index e0506a6..a2bc876 100644
--- a/grub-core/loader/i386/xnu.c
+++ b/grub-core/loader/i386/xnu.c
@@ -791,7 +791,7 @@ grub_xnu_boot_resume (void)
   state.eip = grub_xnu_entry_point;
   state.eax = grub_xnu_arg1;
 
-  return grub_relocator32_boot (grub_xnu_relocator, state, 0); 
+  return grub_relocator32_boot (grub_xnu_relocator, state); 
 }
 
 /* Setup video for xnu. */
@@ -1099,7 +1099,7 @@ grub_xnu_boot (void)
   grub_outb (0xff, 0x21);
   grub_outb (0xff, 0xa1);
 
-  return grub_relocator32_boot (grub_xnu_relocator, state, 0);
+  return grub_relocator32_boot (grub_xnu_relocator, state);
 }
 
 static grub_command_t cmd_devprop_load;
diff --git a/grub-core/loader/multiboot.c b/grub-core/loader/multiboot.c
index 4b71f33..307da32 100644
--- a/grub-core/loader/multiboot.c
+++ b/grub-core/loader/multiboot.c
@@ -131,11 +131,7 @@ grub_multiboot_boot (void)
   if (err)
 return err;
 
-#if defined (__i386__) || defined (__x86_64__)
-  grub_relocator32_boot (grub_multiboot_relocator, state, 0);
-#else
   grub_relocator

[Xen-devel] [PATCH 0/5] multiboot2: Enable EFI boot services usage in loaded images

[Daniel Kiper]

Hi,

This patch series enable EFI boot services usage
in loaded images by multiboot2 protocol.

Daniel

 grub-core/Makefile.core.def  |1 +
 grub-core/lib/i386/relocator.c   |   59 
++
 grub-core/lib/i386/relocator64_efi.S |   77 
+++
 grub-core/loader/i386/bsd.c  |6 +++---
 grub-core/loader/i386/coreboot/chainloader.c |2 +-
 grub-core/loader/i386/linux.c|2 +-
 grub-core/loader/i386/pc/plan9.c |2 +-
 grub-core/loader/i386/xnu.c  |4 ++--
 grub-core/loader/multiboot.c |   29 ++-
 grub-core/loader/multiboot_mbi2.c|   57 
++--
 include/grub/i386/multiboot.h|   11 +++
 include/grub/i386/relocator.h|   24 --
 include/multiboot2.h |   25 +++
 13 files changed, 270 insertions(+), 29 deletions(-)

Daniel Kiper (5):
  multiboot2: Fix information request tag size calculation
  i386/relocator: Remove unused extern grub_relocator64_rip_addr
  i386/relocator: Remove unused avoid_efi_bootservices argument
  i386/relocator: Add grub_relocator64_efi relocator
  multiboot2: Add tags used to pass ImageHandle to loaded image


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

[Xen-devel] [PATCH 5/5] multiboot2: Add tags used to pass ImageHandle to loaded image

[Daniel Kiper]

Add tags used to pass ImageHandle to loaded image. It is used
by at least ExitBootServices() function.

Signed-off-by: Daniel Kiper 
---
 grub-core/loader/multiboot_mbi2.c |   36 +++-
 include/multiboot2.h  |   16 
 2 files changed, 47 insertions(+), 5 deletions(-)

diff --git a/grub-core/loader/multiboot_mbi2.c 
b/grub-core/loader/multiboot_mbi2.c
index 8d66e3f..865267c 100644
--- a/grub-core/loader/multiboot_mbi2.c
+++ b/grub-core/loader/multiboot_mbi2.c
@@ -172,6 +172,8 @@ grub_multiboot_load (grub_file_t file, const char *filename)
  case MULTIBOOT_TAG_TYPE_NETWORK:
  case MULTIBOOT_TAG_TYPE_EFI_MMAP:
  case MULTIBOOT_TAG_TYPE_EFI_BS:
+ case MULTIBOOT_TAG_TYPE_EFI32_IH:
+ case MULTIBOOT_TAG_TYPE_EFI64_IH:
break;
 
  default:
@@ -906,11 +908,35 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
 
   if (keep_bs)
 {
-  struct multiboot_tag *tag = (struct multiboot_tag *) ptrorig;
-  tag->type = MULTIBOOT_TAG_TYPE_EFI_BS;
-  tag->size = sizeof (struct multiboot_tag);
-  ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
-   / sizeof (grub_properly_aligned_t);
+  {
+   struct multiboot_tag *tag = (struct multiboot_tag *) ptrorig;
+   tag->type = MULTIBOOT_TAG_TYPE_EFI_BS;
+   tag->size = sizeof (struct multiboot_tag);
+   ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
+ / sizeof (grub_properly_aligned_t);
+  }
+
+#ifdef __x86_64__
+  {
+   struct multiboot_tag_efi64_ih *tag = (struct multiboot_tag_efi64_ih *) 
ptrorig;
+   tag->type = MULTIBOOT_TAG_TYPE_EFI64_IH;
+   tag->size = sizeof (*tag);
+   tag->pointer = (grub_addr_t) grub_efi_image_handle;
+   ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
+ / sizeof (grub_properly_aligned_t);
+  }
+#endif
+
+#ifdef __i386__
+  {
+   struct multiboot_tag_efi32_ih *tag = (struct multiboot_tag_efi32_ih *) 
ptrorig;
+   tag->type = MULTIBOOT_TAG_TYPE_EFI32_IH;
+   tag->size = sizeof (*tag);
+   tag->pointer = (grub_addr_t) grub_efi_image_handle;
+   ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
+ / sizeof (grub_properly_aligned_t);
+  }
+#endif
 }
 #endif
 
diff --git a/include/multiboot2.h b/include/multiboot2.h
index 75cc99b..36372f4 100644
--- a/include/multiboot2.h
+++ b/include/multiboot2.h
@@ -60,6 +60,8 @@
 #define MULTIBOOT_TAG_TYPE_NETWORK   16
 #define MULTIBOOT_TAG_TYPE_EFI_MMAP  17
 #define MULTIBOOT_TAG_TYPE_EFI_BS18
+#define MULTIBOOT_TAG_TYPE_EFI32_IH  19
+#define MULTIBOOT_TAG_TYPE_EFI64_IH  20
 
 #define MULTIBOOT_HEADER_TAG_END  0
 #define MULTIBOOT_HEADER_TAG_INFORMATION_REQUEST  1
@@ -382,6 +384,20 @@ struct multiboot_tag_efi_mmap
   multiboot_uint8_t efi_mmap[0];
 }; 
 
+struct multiboot_tag_efi32_ih
+{
+  multiboot_uint32_t type;
+  multiboot_uint32_t size;
+  multiboot_uint32_t pointer;
+};
+
+struct multiboot_tag_efi64_ih
+{
+  multiboot_uint32_t type;
+  multiboot_uint32_t size;
+  multiboot_uint64_t pointer;
+};
+
 #endif /* ! ASM_FILE */
 
 #endif /* ! MULTIBOOT_HEADER */
-- 
1.7.10.4


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

[Xen-devel] [PATCH 2/5] i386/relocator: Remove unused extern grub_relocator64_rip_addr

[Daniel Kiper]

Signed-off-by: Daniel Kiper 
---
 grub-core/lib/i386/relocator.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/grub-core/lib/i386/relocator.c b/grub-core/lib/i386/relocator.c
index ffaf25f..71dd4f0 100644
--- a/grub-core/lib/i386/relocator.c
+++ b/grub-core/lib/i386/relocator.c
@@ -64,7 +64,6 @@ extern grub_uint64_t grub_relocator64_rbx;
 extern grub_uint64_t grub_relocator64_rcx;
 extern grub_uint64_t grub_relocator64_rdx;
 extern grub_uint64_t grub_relocator64_rip;
-extern grub_uint64_t grub_relocator64_rip_addr;
 extern grub_uint64_t grub_relocator64_rsp;
 extern grub_uint64_t grub_relocator64_rsi;
 extern grub_addr_t grub_relocator64_cr3;
-- 
1.7.10.4


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

Re: [Xen-devel] [PATCH 01/18] x86/boot/reloc: mask out MBI_BOOTDEV from mbi flags

[Andrew Cooper]

On 30/01/15 17:54, Daniel Kiper wrote:
> ..because it is ignored by Xen.
>
> Signed-off-by: Daniel Kiper 

Reviewed-by: Andrew Cooper 

> ---
>  xen/arch/x86/boot/reloc.c |1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
> index f971920..63045c0 100644
> --- a/xen/arch/x86/boot/reloc.c
> +++ b/xen/arch/x86/boot/reloc.c
> @@ -90,7 +90,6 @@ multiboot_info_t *reloc(multiboot_info_t *mbi_old)
>  
>  /* Mask features we don't understand or don't relocate. */
>  mbi->flags &= (MBI_MEMLIMITS |
> -   MBI_BOOTDEV |
> MBI_CMDLINE |
> MBI_MODULES |
> MBI_MEMMAP |


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

[Xen-devel] [PATCH 1/5] multiboot2: Fix information request tag size calculation

[Daniel Kiper]

Signed-off-by: Daniel Kiper 
---
 grub-core/loader/multiboot_mbi2.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/grub-core/loader/multiboot_mbi2.c 
b/grub-core/loader/multiboot_mbi2.c
index 6f74aee..d7c19bc 100644
--- a/grub-core/loader/multiboot_mbi2.c
+++ b/grub-core/loader/multiboot_mbi2.c
@@ -150,7 +150,7 @@ grub_multiboot_load (grub_file_t file, const char *filename)
= (struct multiboot_header_tag_information_request *) tag;
  if (request_tag->flags & MULTIBOOT_HEADER_TAG_OPTIONAL)
break;
- for (i = 0; i < (request_tag->size - sizeof (request_tag))
+ for (i = 0; i < (request_tag->size - sizeof (*request_tag))
 / sizeof (request_tag->requests[0]); i++)
switch (request_tag->requests[i])
  {
-- 
1.7.10.4


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

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

[Daniel Kiper]

Signed-off-by: Daniel Kiper 
---
 xen/arch/x86/boot/head.S  |  174 +++--
 xen/arch/x86/efi/efi-boot.h   |   29 +++
 xen/arch/x86/setup.c  |   23 ++---
 xen/arch/x86/x86_64/asm-offsets.c |2 +
 xen/common/efi/boot.c |   11 +++
 5 files changed, 222 insertions(+), 17 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 7861057..89f5aa7 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 
 .text
 .code32
@@ -57,6 +58,9 @@ ENTRY(start)
 .long   .Lmultiboot2_info_req_end - .Lmultiboot2_info_req
 .long   MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO
 .long   MULTIBOOT2_TAG_TYPE_MMAP
+.long   MULTIBOOT2_TAG_TYPE_EFI_BS
+.long   MULTIBOOT2_TAG_TYPE_EFI64
+.long   MULTIBOOT2_TAG_TYPE_EFI64_IH
 .Lmultiboot2_info_req_end:
 
 .align  MULTIBOOT2_TAG_ALIGN
@@ -80,6 +84,19 @@ ENTRY(start)
 .long   0 /* Number of the lines - no preference. */
 .long   0 /* Number of bits per pixel - no preference. */
 
+/* Do not disable EFI boot services. */
+.align  MULTIBOOT2_TAG_ALIGN
+.short  MULTIBOOT2_HEADER_TAG_EFI_BS
+.short  MULTIBOOT2_HEADER_TAG_OPTIONAL
+.long   8 /* Tag size. */
+
+/* EFI64 entry point. */
+.align  MULTIBOOT2_TAG_ALIGN
+.short  MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI64
+.short  MULTIBOOT2_HEADER_TAG_OPTIONAL
+.long   12 /* Tag size. */
+.long   sym_phys(__efi64_start)
+
 /* Multiboot2 header end tag. */
 .align  MULTIBOOT2_TAG_ALIGN
 .short  MULTIBOOT2_HEADER_TAG_END
@@ -94,6 +111,17 @@ ENTRY(start)
 gdt_boot_descr:
 .word   6*8-1
 .long   sym_phys(trampoline_gdt)
+.long   0 /* Needed for 64-bit lgdt */
+
+cs32_switch_addr:
+.long   sym_phys(cs32_switch)
+.long   BOOT_CS32
+
+efi_st:
+.quad   0
+
+efi_ih:
+.quad   0
 
 .Lbad_cpu_msg: .asciz "ERR: Not a 64-bit CPU!"
 .Lbad_ldr_msg: .asciz "ERR: Not a Multiboot bootloader!"
@@ -124,6 +152,133 @@ print_err:
 .Lhalt: hlt
 jmp .Lhalt
 
+.code64
+
+__efi64_start:
+cld
+
+/* Bootloaders may set multiboot[12].mem_lower to a nonzero value */
+xor %edx,%edx
+
+/* Check for Multiboot2 bootloader */
+cmp $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
+je  efi_multiboot2_proto
+
+jmp not_multiboot
+
+efi_multiboot2_proto:
+/* Skip Multiboot2 information fixed part */
+lea MB2_fixed_sizeof(%ebx),%ecx
+
+0:
+/* Get mem_lower from Multiboot2 information */
+cmpl$MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,(%ecx)
+jne 1f
+
+mov MB2_mem_lower(%ecx),%edx
+jmp 4f
+
+1:
+/* Get EFI SystemTable address from Multiboot2 information */
+cmpl$MULTIBOOT2_TAG_TYPE_EFI64,(%ecx)
+jne 2f
+
+lea MB2_efi64_st(%ecx),%esi
+lea efi_st(%rip),%edi
+movsq
+
+/* Do not go into real mode on EFI platform */
+movb$1,skip_realmode(%rip)
+
+jmp 4f
+
+2:
+/* Get EFI ImageHandle address from Multiboot2 information */
+cmpl$MULTIBOOT2_TAG_TYPE_EFI64_IH,(%ecx)
+jne 3f
+
+lea MB2_efi64_ih(%ecx),%esi
+lea efi_ih(%rip),%edi
+movsq
+jmp 4f
+
+3:
+/* Is it the end of Multiboot2 information? */
+cmpl$MULTIBOOT2_TAG_TYPE_END,(%ecx)
+je  run_bs
+
+4:
+/* Go to next Multiboot2 information tag */
+add MB2_tag_size(%ecx),%ecx
+add $(MULTIBOOT2_TAG_ALIGN-1),%ecx
+and $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
+jmp 0b
+
+run_bs:
+push%rax
+push%rdx
+
+/* Initialize BSS (no nasty surprises!) */
+lea __bss_start(%rip),%rdi
+lea _end(%rip),%rcx
+sub %rdi,%rcx
+xor %rax,%rax
+rep stosb
+
+mov efi_ih(%rip),%rdi   /* EFI ImageHandle */
+mov efi_st(%rip),%rsi   /* EFI SystemTable */
+callefi_multiboot2
+
+pop %rcx
+pop %rax
+
+shl $10-4,%rcx  /* Convert multiboot2.mem_lower to 
bytes/16 */
+
+cli
+
+/* Initialise GDT */
+lgdtgdt_boot_descr(%rip)
+
+/* Reload code selector */
+ljmpl   *cs32_switch_addr(%rip)
+
+.code32
+
+cs32_switch:
+/* Initialise basic data segments */
+mov $BOOT_DS,%edx
+mov %edx,%ds
+mov %edx,%es
+mov %edx,%fs
+mov %edx,%gs
+mov %edx,%ss
+
+mov $sym_phys(cpu0_stack)+1024,%esp
+
+/* Disable paging */
+mov %cr0,%edx
+and $(~X86_CR0_PG),%edx
+mov %e

[Xen-devel] [PATCH 10/18] efi: create efi_console_set_mode()

[Daniel Kiper]

..which sets console mode. We need this to support
multiboot2 protocol on EFI platforms.

Signed-off-by: Daniel Kiper 
---
 xen/common/efi/boot.c |   37 -
 1 file changed, 20 insertions(+), 17 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 1bf88e4..9ce8a25 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -601,6 +601,25 @@ static void __init efi_init(EFI_HANDLE ImageHandle, 
EFI_SYSTEM_TABLE *SystemTabl
 StdErr = SystemTable->StdErr ?: StdOut;
 }
 
+static void __init efi_console_set_mode(void)
+{
+UINTN cols, rows, size;
+unsigned int best, i;
+
+for ( i = 0, size = 0, best = StdOut->Mode->Mode;
+  i < StdOut->Mode->MaxMode; ++i )
+{
+if ( StdOut->QueryMode(StdOut, i, &cols, &rows) == EFI_SUCCESS &&
+ cols * rows > size )
+{
+size = cols * rows;
+best = i;
+}
+}
+if ( best != StdOut->Mode->Mode )
+StdOut->SetMode(StdOut, best);
+}
+
 static void __init setup_efi_pci(void)
 {
 EFI_STATUS status;
@@ -787,23 +806,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
*SystemTable)
 }
 
 if ( !base_video )
-{
-unsigned int best;
-UINTN cols, rows, size;
-
-for ( i = 0, size = 0, best = StdOut->Mode->Mode;
-  i < StdOut->Mode->MaxMode; ++i )
-{
-if ( StdOut->QueryMode(StdOut, i, &cols, &rows) == EFI_SUCCESS 
&&
- cols * rows > size )
-{
-size = cols * rows;
-best = i;
-}
-}
-if ( best != StdOut->Mode->Mode )
-StdOut->SetMode(StdOut, best);
-}
+efi_console_set_mode();
 }
 
 PrintStr(L"Xen " __stringify(XEN_VERSION) "." __stringify(XEN_SUBVERSION)
-- 
1.7.10.4


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

[Xen-devel] [PATCH 04/18] xen/x86: add multiboot2 protocol support

[Daniel Kiper]

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

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

Signed-off-by: Daniel Kiper 
---
 xen/arch/x86/boot/Makefile|3 +-
 xen/arch/x86/boot/head.S  |  104 --
 xen/arch/x86/boot/reloc.c |  174 -
 xen/arch/x86/x86_64/asm-offsets.c |6 ++
 xen/include/xen/multiboot2.h  |  169 +++
 5 files changed, 429 insertions(+), 27 deletions(-)
 create mode 100644 xen/include/xen/multiboot2.h

diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index 5fdb5ae..0efa7d2 100644
--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -1,6 +1,7 @@
 obj-bin-y += head.o
 
-RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h 
$(BASEDIR)/include/xen/multiboot.h
+RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h 
$(BASEDIR)/include/xen/compiler.h \
+$(BASEDIR)/include/xen/multiboot.h 
$(BASEDIR)/include/xen/multiboot2.h
 
 head.o: reloc.S
 
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 6180783..7861057 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -1,5 +1,6 @@
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -32,6 +33,59 @@ ENTRY(start)
 .long   MULTIBOOT_HEADER_FLAGS
 /* Checksum: must be the negated sum of the first two fields. */
 .long   -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)
+ 
+/*** MULTIBOOT2 HEADER /
+/* Some ideas are taken from grub-2.00/grub-core/tests/boot/kernel-i386.S 
file. */
+.align  MULTIBOOT2_HEADER_ALIGN
+
+.Lmultiboot2_header:
+/* Magic number indicating a Multiboot2 header. */
+.long   MULTIBOOT2_HEADER_MAGIC
+/* Architecture: i386. */
+.long   MULTIBOOT2_ARCHITECTURE_I386
+/* Multiboot2 header length. */
+.long   .Lmultiboot2_header_end - .Lmultiboot2_header
+/* Multiboot2 header checksum. */
+.long   -(MULTIBOOT2_HEADER_MAGIC + MULTIBOOT2_ARCHITECTURE_I386 + \
+(.Lmultiboot2_header_end - .Lmultiboot2_header))
+
+/* Multiboot2 tags... */
+.Lmultiboot2_info_req:
+/* Multiboot2 information request tag. */
+.short  MULTIBOOT2_HEADER_TAG_INFORMATION_REQUEST
+.short  MULTIBOOT2_HEADER_TAG_REQUIRED
+.long   .Lmultiboot2_info_req_end - .Lmultiboot2_info_req
+.long   MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO
+.long   MULTIBOOT2_TAG_TYPE_MMAP
+.Lmultiboot2_info_req_end:
+
+.align  MULTIBOOT2_TAG_ALIGN
+.short  MULTIBOOT2_HEADER_TAG_MODULE_ALIGN
+.short  MULTIBOOT2_HEADER_TAG_REQUIRED
+.long   8 /* Tag size. */
+
+/* Console flags tag. */
+.align  MULTIBOOT2_TAG_ALIGN
+.short  MULTIBOOT2_HEADER_TAG_CONSOLE_FLAGS
+.short  MULTIBOOT2_HEADER_TAG_OPTIONAL
+.long   12 /* Tag size. */
+.long   MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED
+
+/* Framebuffer tag. */
+.align  MULTIBOOT2_TAG_ALIGN
+.short  MULTIBOOT2_HEADER_TAG_FRAMEBUFFER
+.short  MULTIBOOT2_HEADER_TAG_OPTIONAL
+.long   20 /* Tag size. */
+.long   0 /* Number of the columns - no preference. */
+.long   0 /* Number of the lines - no preference. */
+.long   0 /* Number of bits per pixel - no preference. */
+
+/* Multiboot2 header end tag. */
+.align  MULTIBOOT2_TAG_ALIGN
+.short  MULTIBOOT2_HEADER_TAG_END
+.short  0
+.long   8 /* Tag size. */
+.Lmultiboot2_header_end:
 
 .section .init.rodata, "a", @progbits
 .align 4
@@ -81,10 +135,51 @@ __start:
 mov %ecx,%es
 mov %ecx,%ss
 
+/* Bootloaders may set multiboot[12].mem_lower to a nonzero value */
+xor %edx,%edx
+
 /* Check for Multiboot bootloader */
 cmp $MULTIBOOT_BOOTLOADER_MAGIC,%eax
-jne not_multiboot
+je  multiboot1_proto
 
+/* Check for Multiboot2 bootloader */
+cmp $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
+je  multiboot2_proto
+
+jmp not_multiboot
+
+multiboot1_proto:
+/* Get mem_lower from Multiboot information */
+testb   $MBI_MEMLIMITS,(%ebx)
+jz  trampoline_setup/* not available? BDA value will be fine */
+
+mov MB_mem_lower(%ebx),%edx
+jmp trampoline_setup
+
+multiboot2_proto:
+/* Skip Multiboot2 information fixed part */
+lea MB2_fixed_sizeof(%ebx),%ecx
+
+0:
+/* Get mem_lower from Multiboot2 information */
+cmpl$MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,(%ecx)
+jne 1f
+
+mov MB2_mem_lower(%ecx),%edx
+jmp trampoline_setup
+
+1:
+/* Is it the end of Multiboot2 information? */
+cmpl$MULT

[Xen-devel] [PATCH 11/18] efi: create efi_get_gop()

[Daniel Kiper]

..which gets pointer to GOP device. We need this to support
multiboot2 protocol on EFI platforms.

Signed-off-by: Daniel Kiper 
---
 xen/common/efi/boot.c |   59 ++---
 1 file changed, 36 insertions(+), 23 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 9ce8a25..6bbcb3b 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -620,6 +620,41 @@ static void __init efi_console_set_mode(void)
 StdOut->SetMode(StdOut, best);
 }
 
+static EFI_GRAPHICS_OUTPUT_PROTOCOL __init *efi_get_gop(void)
+{
+EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *mode_info;
+EFI_GRAPHICS_OUTPUT_PROTOCOL *gop;
+EFI_HANDLE *handles;
+EFI_STATUS status;
+UINTN info_size, size = 0;
+static EFI_GUID __initdata gop_guid = EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID;
+unsigned int i;
+
+status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size, NULL);
+if ( status == EFI_BUFFER_TOO_SMALL )
+status = efi_bs->AllocatePool(EfiLoaderData, size, (void **)&handles);
+if ( !EFI_ERROR(status) )
+status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size,
+  handles);
+if ( EFI_ERROR(status) )
+size = 0;
+for ( i = 0; i < size / sizeof(*handles); ++i )
+{
+status = efi_bs->HandleProtocol(handles[i], &gop_guid, (void **)&gop);
+if ( EFI_ERROR(status) )
+continue;
+status = gop->QueryMode(gop, gop->Mode->Mode, &info_size, &mode_info);
+if ( !EFI_ERROR(status) )
+break;
+}
+if ( handles )
+efi_bs->FreePool(handles);
+if ( EFI_ERROR(status) )
+gop = NULL;
+
+return gop;
+}
+
 static void __init setup_efi_pci(void)
 {
 EFI_STATUS status;
@@ -726,14 +761,12 @@ void EFIAPI __init noreturn
 efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 {
 static EFI_GUID __initdata loaded_image_guid = LOADED_IMAGE_PROTOCOL;
-static EFI_GUID __initdata gop_guid = EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID;
 static EFI_GUID __initdata shim_lock_guid = SHIM_LOCK_PROTOCOL_GUID;
 EFI_LOADED_IMAGE *loaded_image;
 EFI_STATUS status;
 unsigned int i, argc;
 CHAR16 **argv, *file_name, *cfg_file_name = NULL, *options = NULL;
 UINTN map_key, info_size, gop_mode = ~0;
-EFI_HANDLE *handles = NULL;
 EFI_SHIM_LOCK_PROTOCOL *shim_lock;
 EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL;
 EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *mode_info;
@@ -825,27 +858,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
*SystemTable)
&cols, &rows) == EFI_SUCCESS )
 efi_arch_console_init(cols, rows);
 
-status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size, 
NULL);
-if ( status == EFI_BUFFER_TOO_SMALL )
-status = efi_bs->AllocatePool(EfiLoaderData, size, (void 
**)&handles);
-if ( !EFI_ERROR(status) )
-status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size,
-  handles);
-if ( EFI_ERROR(status) )
-size = 0;
-for ( i = 0; i < size / sizeof(*handles); ++i )
-{
-status = efi_bs->HandleProtocol(handles[i], &gop_guid, (void 
**)&gop);
-if ( EFI_ERROR(status) )
-continue;
-status = gop->QueryMode(gop, gop->Mode->Mode, &info_size, 
&mode_info);
-if ( !EFI_ERROR(status) )
-break;
-}
-if ( handles )
-efi_bs->FreePool(handles);
-if ( EFI_ERROR(status) )
-gop = NULL;
+gop = efi_get_gop();
 
 /* Get the file system interface. */
 dir_handle = get_parent_handle(loaded_image, &file_name);
-- 
1.7.10.4


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

[Xen-devel] [PATCH 15/18] efi: create efi_set_gop_mode()

[Daniel Kiper]

..which sets chosen GOP mode. We need this to support
multiboot2 protocol on EFI platforms.

Signed-off-by: Daniel Kiper 
---
 xen/common/efi/boot.c |   35 +--
 1 file changed, 21 insertions(+), 14 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 2379022..63c930d 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -845,6 +845,25 @@ static void __init efi_variables(void)
 }
 }
 
+static void __init efi_set_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop, UINTN 
gop_mode)
+{
+EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *mode_info;
+EFI_STATUS status;
+UINTN info_size;
+
+if ( !gop )
+return;
+
+/* Set graphics mode. */
+if ( gop_mode < gop->Mode->MaxMode && gop_mode != gop->Mode->Mode )
+gop->SetMode(gop, gop_mode);
+
+/* Get graphics and frame buffer info. */
+status = gop->QueryMode(gop, gop->Mode->Mode, &info_size, &mode_info);
+if ( !EFI_ERROR(status) )
+efi_arch_video_init(gop, info_size, mode_info);
+}
+
 static int __init __maybe_unused set_color(u32 mask, int bpp, u8 *pos, u8 *sz)
 {
if ( bpp < 0 )
@@ -869,10 +888,9 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
*SystemTable)
 EFI_STATUS status;
 unsigned int i, argc;
 CHAR16 **argv, *file_name, *cfg_file_name = NULL, *options = NULL;
-UINTN map_key, info_size, gop_mode = ~0;
+UINTN map_key, gop_mode = ~0;
 EFI_SHIM_LOCK_PROTOCOL *shim_lock;
 EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL;
-EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *mode_info;
 union string section = { NULL }, name;
 bool_t base_video = 0, retry;
 char *option_str;
@@ -1088,18 +1106,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
*SystemTable)
 
 efi_arch_memory_setup();
 
-if ( gop )
-{
-
-/* Set graphics mode. */
-if ( gop_mode < gop->Mode->MaxMode && gop_mode != gop->Mode->Mode )
-gop->SetMode(gop, gop_mode);
-
-/* Get graphics and frame buffer info. */
-status = gop->QueryMode(gop, gop->Mode->Mode, &info_size, &mode_info);
-if ( !EFI_ERROR(status) )
-efi_arch_video_init(gop, info_size, mode_info);
-}
+efi_set_gop_mode(gop, gop_mode);
 
 efi_bs->GetMemoryMap(&efi_memmap_size, NULL, &map_key,
  &efi_mdesc_size, &mdesc_ver);
-- 
1.7.10.4


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

[Xen-devel] [PATCH 16/18] efi: create efi_exit_boot()

[Daniel Kiper]

..which gets memory map and calls ExitBootServices(). We need this
to support multiboot2 protocol on EFI platforms.

Signed-off-by: Daniel Kiper 
---
 xen/common/efi/boot.c |   79 +++--
 1 file changed, 44 insertions(+), 35 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 63c930d..f8be3dd 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -864,6 +864,47 @@ static void __init 
efi_set_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop, UINTN gop
 efi_arch_video_init(gop, info_size, mode_info);
 }
 
+static void __init efi_exit_boot(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
*SystemTable)
+{
+EFI_STATUS status;
+UINTN map_key;
+bool_t retry;
+
+efi_bs->GetMemoryMap(&efi_memmap_size, NULL, &map_key,
+ &efi_mdesc_size, &mdesc_ver);
+efi_memmap = efi_arch_allocate_mmap_buffer(&efi_memmap_size);
+if ( !efi_memmap )
+blexit(L"Unable to allocate memory for EFI memory map");
+
+for ( retry = 0; ; retry = 1 )
+{
+status = efi_bs->GetMemoryMap(&efi_memmap_size, efi_memmap, &map_key,
+  &efi_mdesc_size, &mdesc_ver);
+if ( EFI_ERROR(status) )
+PrintErrMesg(L"Cannot obtain memory map", status);
+
+efi_arch_process_memory_map(SystemTable, efi_memmap, efi_memmap_size,
+efi_mdesc_size, mdesc_ver);
+
+efi_arch_pre_exit_boot();
+
+status = efi_bs->ExitBootServices(ImageHandle, map_key);
+if ( status != EFI_INVALID_PARAMETER || retry )
+break;
+}
+
+if ( EFI_ERROR(status) )
+PrintErrMesg(L"Cannot exit boot services", status);
+
+/* Adjust pointers into EFI. */
+efi_ct = (void *)efi_ct + DIRECTMAP_VIRT_START;
+#ifdef USE_SET_VIRTUAL_ADDRESS_MAP
+efi_rs = (void *)efi_rs + DIRECTMAP_VIRT_START;
+#endif
+efi_memmap = (void *)efi_memmap + DIRECTMAP_VIRT_START;
+efi_fw_vendor = (void *)efi_fw_vendor + DIRECTMAP_VIRT_START;
+}
+
 static int __init __maybe_unused set_color(u32 mask, int bpp, u8 *pos, u8 *sz)
 {
if ( bpp < 0 )
@@ -888,11 +929,11 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
*SystemTable)
 EFI_STATUS status;
 unsigned int i, argc;
 CHAR16 **argv, *file_name, *cfg_file_name = NULL, *options = NULL;
-UINTN map_key, gop_mode = ~0;
+UINTN gop_mode = ~0;
 EFI_SHIM_LOCK_PROTOCOL *shim_lock;
 EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL;
 union string section = { NULL }, name;
-bool_t base_video = 0, retry;
+bool_t base_video = 0;
 char *option_str;
 bool_t use_cfg_file;
 
@@ -1108,39 +1149,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
*SystemTable)
 
 efi_set_gop_mode(gop, gop_mode);
 
-efi_bs->GetMemoryMap(&efi_memmap_size, NULL, &map_key,
- &efi_mdesc_size, &mdesc_ver);
-efi_memmap = efi_arch_allocate_mmap_buffer(&efi_memmap_size);
-if ( !efi_memmap )
-blexit(L"Unable to allocate memory for EFI memory map");
-
-for ( retry = 0; ; retry = 1 )
-{
-status = efi_bs->GetMemoryMap(&efi_memmap_size, efi_memmap, &map_key,
-  &efi_mdesc_size, &mdesc_ver);
-if ( EFI_ERROR(status) )
-PrintErrMesg(L"Cannot obtain memory map", status);
-
-efi_arch_process_memory_map(SystemTable, efi_memmap, efi_memmap_size,
-efi_mdesc_size, mdesc_ver);
-
-efi_arch_pre_exit_boot();
-
-status = efi_bs->ExitBootServices(ImageHandle, map_key);
-if ( status != EFI_INVALID_PARAMETER || retry )
-break;
-}
-
-if ( EFI_ERROR(status) )
-PrintErrMesg(L"Cannot exit boot services", status);
-
-/* Adjust pointers into EFI. */
-efi_ct = (void *)efi_ct + DIRECTMAP_VIRT_START;
-#ifdef USE_SET_VIRTUAL_ADDRESS_MAP
-efi_rs = (void *)efi_rs + DIRECTMAP_VIRT_START;
-#endif
-efi_memmap = (void *)efi_memmap + DIRECTMAP_VIRT_START;
-efi_fw_vendor = (void *)efi_fw_vendor + DIRECTMAP_VIRT_START;
+efi_exit_boot(ImageHandle, SystemTable);
 
 efi_arch_post_exit_boot();
 for( ; ; ); /* not reached */
-- 
1.7.10.4


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

[Xen-devel] [PATCH 17/18] x86/efi: create new early memory allocator

[Daniel Kiper]

There is a problem with place_string() which is used as early memory
allocator. It gets memory chunks starting from start symbol and
going down. Sadly this does not work when Xen is loaded using multiboot2
protocol because start lives on 1 MiB address. So, I tried to use
mem_lower address calculated by GRUB2. However, it works only on some
machines. There are machines in the wild (e.g. Dell PowerEdge R820)
which uses first ~640 KiB for boot services code or data... :-(((

In case of multiboot2 protocol we need that place_string() only allocate
memory chunk for EFI memory map. However, I think that it should be fixed
instead of making another function used just in one case. I thought about
two solutions.

1) We could use native EFI allocation functions (e.g. AllocatePool()
   or AllocatePages()) to get memory chunk. However, later (somewhere
   in __start_xen()) we must copy its contents to safe place or reserve
   this in e820 memory map and map it in Xen virtual address space.
   In later case we must also care about conflicts with e.g. crash
   kernel regions which could be quite difficult.

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

Now solution #2 is implemented but maybe we should consider #1 too.

Signed-off-by: Daniel Kiper 
---
 xen/arch/x86/efi/efi-boot.h |   37 +
 xen/arch/x86/setup.c|3 +--
 2 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
index 3a3b4fe..6e98bc8 100644
--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -103,9 +103,35 @@ static void __init relocate_trampoline(unsigned long phys)
 *(u16 *)(*trampoline_ptr + (long)trampoline_ptr) = phys >> 4;
 }
 
+#define __MALLOC_SIZE  65536
+
+static char __malloc_mem[__MALLOC_SIZE];
+static char *__malloc_free = NULL;
+
+static void __init *__malloc(size_t size)
+{
+void *ptr;
+
+/*
+ * Init __malloc_free on runtime. Static initialization
+ * will not work because it puts virtual address there.
+ */
+if ( __malloc_free == NULL )
+__malloc_free = __malloc_mem;
+
+ptr = __malloc_free;
+
+__malloc_free += size;
+
+if ( __malloc_free - __malloc_mem > sizeof(__malloc_mem) )
+blexit(L"Out of static memory\r\n");
+
+return ptr;
+}
+
 static void __init place_string(u32 *addr, const char *s)
 {
-static char *__initdata alloc = start;
+char *alloc = NULL;
 
 if ( s && *s )
 {
@@ -113,7 +139,7 @@ static void __init place_string(u32 *addr, const char *s)
 const char *old = (char *)(long)*addr;
 size_t len2 = *addr ? strlen(old) + 1 : 0;
 
-alloc -= len1 + len2;
+alloc = __malloc(len1 + len2);
 /*
  * Insert new string before already existing one. This is needed
  * for options passed on the command line to override options from
@@ -192,12 +218,7 @@ static void __init 
efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
 
 static void *__init efi_arch_allocate_mmap_buffer(UINTN *map_size)
 {
-place_string(&mbi.mem_upper, NULL);
-mbi.mem_upper -= *map_size;
-mbi.mem_upper &= -__alignof__(EFI_MEMORY_DESCRIPTOR);
-if ( mbi.mem_upper < xen_phys_start )
-return NULL;
-return (void *)(long)mbi.mem_upper;
+return __malloc(*map_size);
 }
 
 static void __init efi_arch_pre_exit_boot(void)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 711fdb0..aebd010 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -962,8 +962,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 
 if ( !xen_phys_start )
 panic("Not enough memory to relocate Xen.");
-reserve_e820_ram(&boot_e820, efi_loader 

[Xen-devel] [PATCH 12/18] efi: create efi_find_gop_mode()

[Daniel Kiper]

..which finds suitable GOP mode. We need this to support
multiboot2 protocol on EFI platforms.

Signed-off-by: Daniel Kiper 
---
 xen/common/efi/boot.c |   94 -
 1 file changed, 54 insertions(+), 40 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 6bbcb3b..114019e 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -655,6 +655,58 @@ static EFI_GRAPHICS_OUTPUT_PROTOCOL __init 
*efi_get_gop(void)
 return gop;
 }
 
+static UINTN __init efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
+  UINTN cols, UINTN rows, UINTN depth)
+{
+EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *mode_info;
+EFI_STATUS status;
+UINTN gop_mode = ~0, info_size, size;
+unsigned int i;
+
+if ( !gop )
+return gop_mode;
+
+for ( i = size = 0; i < gop->Mode->MaxMode; ++i )
+{
+unsigned int bpp = 0;
+
+status = gop->QueryMode(gop, i, &info_size, &mode_info);
+if ( EFI_ERROR(status) )
+continue;
+switch ( mode_info->PixelFormat )
+{
+case PixelBitMask:
+bpp = hweight32(mode_info->PixelInformation.RedMask |
+mode_info->PixelInformation.GreenMask |
+mode_info->PixelInformation.BlueMask);
+break;
+case PixelRedGreenBlueReserved8BitPerColor:
+case PixelBlueGreenRedReserved8BitPerColor:
+bpp = 24;
+break;
+default:
+continue;
+}
+if ( cols == mode_info->HorizontalResolution &&
+ rows == mode_info->VerticalResolution &&
+ (!depth || bpp == depth) )
+{
+gop_mode = i;
+break;
+}
+if ( !cols && !rows &&
+ mode_info->HorizontalResolution *
+ mode_info->VerticalResolution > size )
+{
+size = mode_info->HorizontalResolution *
+   mode_info->VerticalResolution;
+gop_mode = i;
+}
+}
+
+return gop_mode;
+}
+
 static void __init setup_efi_pci(void)
 {
 EFI_STATUS status;
@@ -966,46 +1018,8 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
*SystemTable)
 
 dir_handle->Close(dir_handle);
 
-if ( gop && !base_video )
-{
-for ( i = size = 0; i < gop->Mode->MaxMode; ++i )
-{
-unsigned int bpp = 0;
-
-status = gop->QueryMode(gop, i, &info_size, &mode_info);
-if ( EFI_ERROR(status) )
-continue;
-switch ( mode_info->PixelFormat )
-{
-case PixelBitMask:
-bpp = hweight32(mode_info->PixelInformation.RedMask |
-mode_info->PixelInformation.GreenMask |
-mode_info->PixelInformation.BlueMask);
-break;
-case PixelRedGreenBlueReserved8BitPerColor:
-case PixelBlueGreenRedReserved8BitPerColor:
-bpp = 24;
-break;
-default:
-continue;
-}
-if ( cols == mode_info->HorizontalResolution &&
- rows == mode_info->VerticalResolution &&
- (!depth || bpp == depth) )
-{
-gop_mode = i;
-break;
-}
-if ( !cols && !rows &&
- mode_info->HorizontalResolution *
- mode_info->VerticalResolution > size )
-{
-size = mode_info->HorizontalResolution *
-   mode_info->VerticalResolution;
-gop_mode = i;
-}
-}
-}
+if ( !base_video )
+gop_mode = efi_find_gop_mode(gop, cols, rows, depth);
 }
 
 efi_arch_edd();
-- 
1.7.10.4


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

[Xen-devel] [PATCH 06/18] x86: remove commented out stale references to efi_enabled

[Daniel Kiper]

Signed-off-by: Daniel Kiper 
---
 xen/arch/x86/e820.c |   29 ++---
 1 file changed, 10 insertions(+), 19 deletions(-)

diff --git a/xen/arch/x86/e820.c b/xen/arch/x86/e820.c
index bf84bae..47920a3 100644
--- a/xen/arch/x86/e820.c
+++ b/xen/arch/x86/e820.c
@@ -74,20 +74,18 @@ static void __init add_memory_region(unsigned long long 
start,
 {
 int x;
 
-/*if (!efi_enabled)*/ {
-x = e820.nr_map;
+x = e820.nr_map;
 
-if (x == E820MAX) {
-printk(KERN_ERR "Ooops! Too many entries in the memory map!\n");
-return;
-}
-
-e820.map[x].addr = start;
-e820.map[x].size = size;
-e820.map[x].type = type;
-e820.nr_map++;
+if (x == E820MAX) {
+printk(KERN_ERR "Ooops! Too many entries in the memory map!\n");
+return;
 }
-} /* add_memory_region */
+
+e820.map[x].addr = start;
+e820.map[x].size = size;
+e820.map[x].type = type;
+e820.nr_map++;
+}
 
 static void __init print_e820_memory_map(struct e820entry *map, unsigned int 
entries)
 {
@@ -349,13 +347,6 @@ static unsigned long __init find_max_pfn(void)
 int i;
 unsigned long max_pfn = 0;
 
-#if 0
-if (efi_enabled) {
-efi_memmap_walk(efi_find_max_pfn, &max_pfn);
-return;
-}
-#endif
-
 for (i = 0; i < e820.nr_map; i++) {
 unsigned long start, end;
 /* RAM? */
-- 
1.7.10.4


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

[Xen-devel] [PATCH 09/18] efi: create efi_init()

[Daniel Kiper]

..which initializes basic EFI variables. We need this to support
multiboot2 protocol on EFI platforms.

Signed-off-by: Daniel Kiper 
---
 xen/common/efi/boot.c |   26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 89d081d..1bf88e4 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -586,6 +586,21 @@ static char *__init get_value(const struct file *cfg, 
const char *section,
 return NULL;
 }
 
+static void __init efi_init(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
*SystemTable)
+{
+efi_ih = ImageHandle;
+efi_bs = SystemTable->BootServices;
+efi_rs = SystemTable->RuntimeServices;
+efi_ct = SystemTable->ConfigurationTable;
+efi_num_ct = SystemTable->NumberOfTableEntries;
+efi_version = SystemTable->Hdr.Revision;
+efi_fw_vendor = SystemTable->FirmwareVendor;
+efi_fw_revision = SystemTable->FirmwareRevision;
+
+StdOut = SystemTable->ConOut;
+StdErr = SystemTable->StdErr ?: StdOut;
+}
+
 static void __init setup_efi_pci(void)
 {
 EFI_STATUS status;
@@ -713,17 +728,8 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
*SystemTable)
 efi_loader = 1;
 #endif
 
-efi_ih = ImageHandle;
-efi_bs = SystemTable->BootServices;
-efi_rs = SystemTable->RuntimeServices;
-efi_ct = SystemTable->ConfigurationTable;
-efi_num_ct = SystemTable->NumberOfTableEntries;
-efi_version = SystemTable->Hdr.Revision;
-efi_fw_vendor = SystemTable->FirmwareVendor;
-efi_fw_revision = SystemTable->FirmwareRevision;
+efi_init(ImageHandle, SystemTable);
 
-StdOut = SystemTable->ConOut;
-StdErr = SystemTable->StdErr ?: StdOut;
 use_cfg_file = efi_arch_use_config_file(SystemTable);
 
 status = efi_bs->HandleProtocol(ImageHandle, &loaded_image_guid,
-- 
1.7.10.4


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

[Xen-devel] [PATCH 13/18] efi: create efi_tables()

[Daniel Kiper]

..which collects system tables data. We need this to support
multiboot2 protocol on EFI platforms.

Signed-off-by: Daniel Kiper 
---
 xen/common/efi/boot.c |   51 -
 1 file changed, 29 insertions(+), 22 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 114019e..cf0fbc2 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -707,6 +707,34 @@ static UINTN __init 
efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
 return gop_mode;
 }
 
+static void __init efi_tables(void)
+{
+unsigned int i;
+
+/* Obtain basic table pointers. */
+for ( i = 0; i < efi_num_ct; ++i )
+{
+static EFI_GUID __initdata acpi2_guid = ACPI_20_TABLE_GUID;
+static EFI_GUID __initdata acpi_guid = ACPI_TABLE_GUID;
+static EFI_GUID __initdata mps_guid = MPS_TABLE_GUID;
+static EFI_GUID __initdata smbios_guid = SMBIOS_TABLE_GUID;
+
+if ( match_guid(&acpi2_guid, &efi_ct[i].VendorGuid) )
+  efi.acpi20 = (long)efi_ct[i].VendorTable;
+if ( match_guid(&acpi_guid, &efi_ct[i].VendorGuid) )
+  efi.acpi = (long)efi_ct[i].VendorTable;
+if ( match_guid(&mps_guid, &efi_ct[i].VendorGuid) )
+  efi.mps = (long)efi_ct[i].VendorTable;
+if ( match_guid(&smbios_guid, &efi_ct[i].VendorGuid) )
+  efi.smbios = (long)efi_ct[i].VendorTable;
+}
+
+#ifndef CONFIG_ARM /* TODO - disabled until implemented on ARM */
+if (efi.smbios != EFI_INVALID_TABLE_ADDR)
+dmi_efi_get_table((void *)(long)efi.smbios);
+#endif
+}
+
 static void __init setup_efi_pci(void)
 {
 EFI_STATUS status;
@@ -1027,28 +1055,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
*SystemTable)
 /* XXX Collect EDID info. */
 efi_arch_cpu();
 
-/* Obtain basic table pointers. */
-for ( i = 0; i < efi_num_ct; ++i )
-{
-static EFI_GUID __initdata acpi2_guid = ACPI_20_TABLE_GUID;
-static EFI_GUID __initdata acpi_guid = ACPI_TABLE_GUID;
-static EFI_GUID __initdata mps_guid = MPS_TABLE_GUID;
-static EFI_GUID __initdata smbios_guid = SMBIOS_TABLE_GUID;
-
-if ( match_guid(&acpi2_guid, &efi_ct[i].VendorGuid) )
-  efi.acpi20 = (long)efi_ct[i].VendorTable;
-if ( match_guid(&acpi_guid, &efi_ct[i].VendorGuid) )
-  efi.acpi = (long)efi_ct[i].VendorTable;
-if ( match_guid(&mps_guid, &efi_ct[i].VendorGuid) )
-  efi.mps = (long)efi_ct[i].VendorTable;
-if ( match_guid(&smbios_guid, &efi_ct[i].VendorGuid) )
-  efi.smbios = (long)efi_ct[i].VendorTable;
-}
-
-#ifndef CONFIG_ARM /* TODO - disabled until implemented on ARM */
-if (efi.smbios != EFI_INVALID_TABLE_ADDR)
-dmi_efi_get_table((void *)(long)efi.smbios);
-#endif
+efi_tables();
 
 /* Collect PCI ROM contents. */
 setup_efi_pci();
-- 
1.7.10.4


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

[Xen-devel] [PATCH 14/18] efi: create efi_variables()

[Daniel Kiper]

..which collects variable store parameters. We need this to support
multiboot2 protocol on EFI platforms.

Signed-off-by: Daniel Kiper 
---
 xen/common/efi/boot.c |   41 -
 1 file changed, 24 insertions(+), 17 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index cf0fbc2..2379022 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -822,6 +822,29 @@ static void __init setup_efi_pci(void)
 efi_bs->FreePool(handles);
 }
 
+static void __init efi_variables(void)
+{
+EFI_STATUS status;
+
+status = (efi_rs->Hdr.Revision >> 16) >= 2 ?
+ efi_rs->QueryVariableInfo(EFI_VARIABLE_NON_VOLATILE |
+   EFI_VARIABLE_BOOTSERVICE_ACCESS |
+   EFI_VARIABLE_RUNTIME_ACCESS,
+   &efi_boot_max_var_store_size,
+   &efi_boot_remain_var_store_size,
+   &efi_boot_max_var_size) :
+ EFI_INCOMPATIBLE_VERSION;
+if ( EFI_ERROR(status) )
+{
+efi_boot_max_var_store_size = 0;
+efi_boot_remain_var_store_size = 0;
+efi_boot_max_var_size = status;
+PrintStr(L"Warning: Could not query variable store: ");
+DisplayUint(status, 0);
+PrintStr(newline);
+}
+}
+
 static int __init __maybe_unused set_color(u32 mask, int bpp, u8 *pos, u8 *sz)
 {
if ( bpp < 0 )
@@ -1061,23 +1084,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
*SystemTable)
 setup_efi_pci();
 
 /* Get snapshot of variable store parameters. */
-status = (efi_rs->Hdr.Revision >> 16) >= 2 ?
- efi_rs->QueryVariableInfo(EFI_VARIABLE_NON_VOLATILE |
-   EFI_VARIABLE_BOOTSERVICE_ACCESS |
-   EFI_VARIABLE_RUNTIME_ACCESS,
-   &efi_boot_max_var_store_size,
-   &efi_boot_remain_var_store_size,
-   &efi_boot_max_var_size) :
- EFI_INCOMPATIBLE_VERSION;
-if ( EFI_ERROR(status) )
-{
-efi_boot_max_var_store_size = 0;
-efi_boot_remain_var_store_size = 0;
-efi_boot_max_var_size = status;
-PrintStr(L"Warning: Could not query variable store: ");
-DisplayUint(status, 0);
-PrintStr(newline);
-}
+efi_variables();
 
 efi_arch_memory_setup();
 
-- 
1.7.10.4


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

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

[Daniel Kiper]

Hi,

I am sending, long awaited, first version of multiboot2 protocol
support for legacy BIOS and EFI platforms.

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

GRUB2 patch series will follow this patch series.

GRUB2 guys should check patch #18 but I am sending
to you all Xen related patches just in case.

Daniel

 xen/arch/x86/Makefile |   17 ++--
 xen/arch/x86/boot/Makefile|3 +-
 xen/arch/x86/boot/head.S  |  291 
++
 xen/arch/x86/boot/reloc.c |  219 
++---
 xen/arch/x86/dmi_scan.c   |4 +-
 xen/arch/x86/domain_page.c|2 +-
 xen/arch/x86/e820.c   |   29 ++
 xen/arch/x86/efi/Makefile |   12 +--
 xen/arch/x86/efi/efi-boot.h   |   66 +++--
 xen/arch/x86/efi/stub.c   |   41 
 xen/arch/x86/mpparse.c|4 +-
 xen/arch/x86/setup.c  |   30 +++---
 xen/arch/x86/shutdown.c   |3 +-
 xen/arch/x86/time.c   |2 +-
 xen/arch/x86/x86_64/asm-offsets.c |8 ++
 xen/arch/x86/xen.lds.S|2 -
 xen/common/efi/boot.c |  441 
+-
 xen/common/efi/runtime.c  |   11 ++-
 xen/drivers/acpi/osl.c|2 +-
 xen/include/xen/efi.h |6 +-
 xen/include/xen/multiboot2.h  |  169 
 21 files changed, 1018 insertions(+), 344 deletions(-)

Daniel Kiper (18):
  x86/boot/reloc: mask out MBI_BOOTDEV from mbi flags
  x86/boot/reloc: create generic alloc and copy functions
  x86/boot: use %ecx instead of %eax
  xen/x86: add multiboot2 protocol support
  efi: split efi_enabled to efi_platform and efi_loader
  x86: remove commented out stale references to efi_enabled
  efi: run EFI specific code on EFI platform only
  efi: build xen.gz with EFI code
  efi: create efi_init()
  efi: create efi_console_set_mode()
  efi: create efi_get_gop()
  efi: create efi_find_gop_mode()
  efi: create efi_tables()
  efi: create efi_variables()
  efi: create efi_set_gop_mode()
  efi: create efi_exit_boot()
  x86/efi: create new early memory allocator
  x86: add multiboot2 protocol support for EFI platforms


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

[Xen-devel] [PATCH 07/18] efi: run EFI specific code on EFI platform only

[Daniel Kiper]

Signed-off-by: Daniel Kiper 
---
 xen/arch/x86/shutdown.c  |3 ++-
 xen/common/efi/boot.c|5 +
 xen/common/efi/runtime.c |6 ++
 3 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/shutdown.c b/xen/arch/x86/shutdown.c
index 21f6cf5..1c8336f 100644
--- a/xen/arch/x86/shutdown.c
+++ b/xen/arch/x86/shutdown.c
@@ -504,7 +504,8 @@ void machine_restart(unsigned int delay_millisecs)
 tboot_shutdown(TB_SHUTDOWN_REBOOT);
 }
 
-efi_reset_system(reboot_mode != 0);
+if ( efi_platform )
+efi_reset_system(reboot_mode != 0);
 
 /* Rebooting needs to touch the page at absolute address 0. */
 *((unsigned short *)__va(0x472)) = reboot_mode;
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 8aafcfd..89d081d 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1154,6 +1154,11 @@ void __init efi_init_memory(void)
 } *extra, *extra_head = NULL;
 #endif
 
+#ifndef CONFIG_ARM /* TODO - disabled until implemented on ARM */
+if ( !efi_platform )
+return;
+#endif
+
 printk(XENLOG_INFO "EFI memory map:\n");
 for ( i = 0; i < efi_memmap_size; i += efi_mdesc_size )
 {
diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
index b229c69..7c767e4 100644
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -164,6 +164,9 @@ int efi_get_info(uint32_t idx, union xenpf_efi_info *info)
 {
 unsigned int i, n;
 
+if ( !efi_platform )
+return -ENOSYS;
+
 switch ( idx )
 {
 case XEN_FW_EFI_VERSION:
@@ -298,6 +301,9 @@ int efi_runtime_call(struct xenpf_efi_runtime_call *op)
 EFI_STATUS status = EFI_NOT_STARTED;
 int rc = 0;
 
+if ( !efi_platform )
+return -ENOSYS;
+
 switch ( op->function )
 {
 case XEN_EFI_get_time:
-- 
1.7.10.4


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

[Xen-devel] [PATCH 02/18] x86/boot/reloc: create generic alloc and copy functions

[Daniel Kiper]

Create generic alloc and copy functions. We need
separate tools for memory allocation and copy to
provide multiboot2 protocol support.

Signed-off-by: Daniel Kiper 
---
 xen/arch/x86/boot/reloc.c |   52 -
 1 file changed, 33 insertions(+), 19 deletions(-)

diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
index 63045c0..f964cda 100644
--- a/xen/arch/x86/boot/reloc.c
+++ b/xen/arch/x86/boot/reloc.c
@@ -33,9 +33,10 @@ asm (
 typedef unsigned int u32;
 #include "../../../include/xen/multiboot.h"
 
-static void *reloc_mbi_struct(void *old, unsigned int bytes)
+static u32 alloc_struct(u32 bytes)
 {
-void *new;
+u32 s;
+
 asm(
 "call 1f  \n"
 "1:  pop  %%edx   \n"
@@ -43,50 +44,63 @@ static void *reloc_mbi_struct(void *old, unsigned int bytes)
 "sub  %1,%0   \n"
 "and  $~15,%0 \n"
 "mov  %0,alloc-1b(%%edx)  \n"
-"mov  %0,%%edi\n"
-"rep  movsb   \n"
-   : "=&r" (new), "+c" (bytes), "+S" (old)
-   : : "edx", "edi", "memory");
-return new;
+   : "=&r" (s) : "r" (bytes) : "edx", "memory");
+
+return s;
+}
+
+static u32 copy_struct(u32 src, u32 bytes)
+{
+u32 dst, dst_asm;
+
+dst = alloc_struct(bytes);
+dst_asm = dst;
+
+asm volatile("rep movsb" : "+S" (src), "+D" (dst_asm), "+c" (bytes) : : 
"memory");
+
+return dst;
 }
 
-static char *reloc_mbi_string(char *old)
+static u32 copy_string(u32 src)
 {
 char *p;
-for ( p = old; *p != '\0'; p++ )
+
+if ( src == 0 )
+return 0;
+
+for ( p = (char *)src; *p != '\0'; p++ )
 continue;
-return reloc_mbi_struct(old, p - old + 1);
+
+return copy_struct(src, p - (char *)src + 1);
 }
 
 multiboot_info_t *reloc(multiboot_info_t *mbi_old)
 {
-multiboot_info_t *mbi = reloc_mbi_struct(mbi_old, sizeof(*mbi));
+multiboot_info_t *mbi = (multiboot_info_t *)copy_struct((u32)mbi_old, 
sizeof(*mbi));
 int i;
 
 if ( mbi->flags & MBI_CMDLINE )
-mbi->cmdline = (u32)reloc_mbi_string((char *)mbi->cmdline);
+mbi->cmdline = copy_string(mbi->cmdline);
 
 if ( mbi->flags & MBI_MODULES )
 {
-module_t *mods = reloc_mbi_struct(
-(module_t *)mbi->mods_addr, mbi->mods_count * sizeof(module_t));
+module_t *mods = (module_t *)copy_struct(
+mbi->mods_addr, mbi->mods_count * sizeof(module_t));
 
 mbi->mods_addr = (u32)mods;
 
 for ( i = 0; i < mbi->mods_count; i++ )
 {
 if ( mods[i].string )
-mods[i].string = (u32)reloc_mbi_string((char *)mods[i].string);
+mods[i].string = copy_string(mods[i].string);
 }
 }
 
 if ( mbi->flags & MBI_MEMMAP )
-mbi->mmap_addr = (u32)reloc_mbi_struct(
-(memory_map_t *)mbi->mmap_addr, mbi->mmap_length);
+mbi->mmap_addr = copy_struct(mbi->mmap_addr, mbi->mmap_length);
 
 if ( mbi->flags & MBI_LOADERNAME )
-mbi->boot_loader_name = (u32)reloc_mbi_string(
-(char *)mbi->boot_loader_name);
+mbi->boot_loader_name = copy_string(mbi->boot_loader_name);
 
 /* Mask features we don't understand or don't relocate. */
 mbi->flags &= (MBI_MEMLIMITS |
-- 
1.7.10.4


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

[Xen-devel] [PATCH 03/18] x86/boot: use %ecx instead of %eax

[Daniel Kiper]

Use %ecx instead of %eax to store low memory upper limit from EBDA.
This way we do not wipe multiboot protocol identifier. It is needed
in reloc() to differentiate between multiboot (v1) and
multiboot2 protocol.

Signed-off-by: Daniel Kiper 
Reviewed-by: Andrew Cooper 
---
 xen/arch/x86/boot/head.S |   27 ++-
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index c99f739..6180783 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -86,14 +86,14 @@ __start:
 jne not_multiboot
 
 /* Set up trampoline segment 64k below EBDA */
-movzwl  0x40e,%eax  /* EBDA segment */
-cmp $0xa000,%eax/* sanity check (high) */
+movzwl  0x40e,%ecx  /* EBDA segment */
+cmp $0xa000,%ecx/* sanity check (high) */
 jae 0f
-cmp $0x4000,%eax/* sanity check (low) */
+cmp $0x4000,%ecx/* sanity check (low) */
 jae 1f
 0:
-movzwl  0x413,%eax  /* use base memory size on failure */
-shl $10-4,%eax
+movzwl  0x413,%ecx  /* use base memory size on failure */
+shl $10-4,%ecx
 1:
 /*
  * Compare the value in the BDA with the information from the
@@ -105,21 +105,22 @@ __start:
 cmp $0x100,%edx /* is the multiboot value too small? */
 jb  2f  /* if so, do not use it */
 shl $10-4,%edx
-cmp %eax,%edx   /* compare with BDA value */
-cmovb   %edx,%eax   /* and use the smaller */
+cmp %ecx,%edx   /* compare with BDA value */
+cmovb   %edx,%ecx   /* and use the smaller */
 
 2:  /* Reserve 64kb for the trampoline */
-sub $0x1000,%eax
+sub $0x1000,%ecx
 
 /* From arch/x86/smpboot.c: start_eip had better be page-aligned! */
-xor %al, %al
-shl $4, %eax
-mov %eax,sym_phys(trampoline_phys)
+xor %cl, %cl
+shl $4, %ecx
+mov %ecx,sym_phys(trampoline_phys)
 
 /* Save the Multiboot info struct (after relocation) for later use. */
 mov $sym_phys(cpu0_stack)+1024,%esp
-push%ebx
-callreloc
+mov %ecx,%eax
+push%ebx/* Multiboot information address */
+callreloc   /* %eax contains trampoline address */
 mov %eax,sym_phys(multiboot_ptr)
 
 /* Initialize BSS (no nasty surprises!) */
-- 
1.7.10.4


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

[Xen-devel] [PATCH 08/18] efi: build xen.gz with EFI code

[Daniel Kiper]

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

If we wish to load not ELF file using multiboot (v1) or multiboot2 then
it must contain "linear" (or "flat") representation of code and data.
Currently, PE file contains many sections which are not "linear" (one
after another without any holes) or even do not have representation
in a file (e.g. BSS). In theory there is a chance that we could build
proper PE file using current build system. However, it means that
xen.efi further diverge from xen ELF file (in terms of contents and
build method). ELF have all needed properties. So, it means that this
is good starting point for further development. Additionally, I think
that this is also good starting point for further xen.efi code and
build optimizations. It looks that there is a chance that finaly we
can generate xen.efi directly from xen ELF using just simple objcopy.

Signed-off-by: Daniel Kiper 
---
 xen/arch/x86/Makefile |   17 +++--
 xen/arch/x86/efi/Makefile |   12 ++--
 xen/arch/x86/efi/stub.c   |   42 --
 xen/arch/x86/xen.lds.S|2 --
 4 files changed, 13 insertions(+), 60 deletions(-)
 delete mode 100644 xen/arch/x86/efi/stub.c

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 86ca5f8..5d63a1f 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -88,29 +88,29 @@ prelink-efi_lto.o: $(ALL_OBJS) efi/runtime.o efi/compat.o
 prelink.o: $(patsubst %/built_in.o,%/built_in_bin.o,$(ALL_OBJS)) prelink_lto.o
$(LD) $(LDFLAGS) -r -o $@ $^
 
-prelink-efi.o: $(patsubst %/built_in.o,%/built_in_bin.o,$(ALL_OBJS)) 
prelink-efi_lto.o efi/boot.init.o
+prelink-efi.o: $(patsubst %/built_in.o,%/built_in_bin.o,$(ALL_OBJS)) 
prelink-efi_lto.o
$(guard) $(LD) $(LDFLAGS) -r -o $@ $^
 else
 prelink.o: $(ALL_OBJS)
$(LD) $(LDFLAGS) -r -o $@ $^
 
-prelink-efi.o: $(ALL_OBJS) efi/boot.init.o efi/runtime.o efi/compat.o
-   $(guard) $(LD) $(LDFLAGS) -r -o $@ $(filter-out %/efi/built_in.o,$^)
+prelink-efi.o: $(ALL_OBJS)
+   $(guard) $(LD) $(LDFLAGS) -r -o $@ $^
 endif
 
 $(BASEDIR)/common/symbols-dummy.o:
$(MAKE) -f $(BASEDIR)/Rules.mk -C $(BASEDIR)/common symbols-dummy.o
 
-$(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o
-   $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+$(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o 
efi/relocs-dummy.o
+   $(LD) $(LDFLAGS) -T xen.lds -N prelink.o efi/relocs-dummy.o \
$(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
$(NM) -n $(@D)/.$(@F).0 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).0.S
$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
-   $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+   $(LD) $(LDFLAGS) -T xen.lds -N prelink.o efi/relocs-dummy.o \
$(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
$(NM) -n $(@D)/.$(@F).1 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).1.S
$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
-   $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+   $(LD) $(LDFLAGS) -T xen.lds -N prelink.o efi/relocs-dummy.o \
$(@D)/.$(@F).1.o -o $@
rm -f $(@D)/.$(@F).[0-9]*
 
@@ -144,9 +144,6 @@ $(TARGET).efi: prelink-efi.o efi.lds efi/relocs-dummy.o 
$(BASEDIR)/common/symbol
if $(guard) false; then rm -f $@; echo 'EFI support disabled'; fi
rm -f $(@D)/.$(@F).[0-9]*
 
-efi/boot.init.o efi/runtime.o efi/compat.o: $(BASEDIR)/arch/x86/efi/built_in.o
-efi/boot.init.o efi/runtime.o efi/compat.o: ;
-
 asm-offsets.s: $(TARGET_SUBARCH)/asm-offsets.c
$(CC) $(filter-out -flto,$(CFLAGS)) -S -o $@ $<
 
diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
index 1daa7ac..13e59dc 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -1,14 +1,14 @@
 CFLAGS += -fshort-wchar
 
-obj-y += stub.o
+obj-y += boot.o
+obj-y += compat.o
+obj-y += runtime.o
+
+extra-y += relocs-dummy.o
 
 create = test -e $(1) || touch -t 19990101 $(1)
 
 efi := $(filter y,$(x86_64)$(shell rm -f disabled))
 efi := $(if $(efi),$(shell $(CC) $(filter-out $(CFLAGS-y) .%.d,$(CFLAGS)) -c 
check.c 2>disabled && echo y))
 efi := $(if $(efi),$(shell $(LD) -mi386pep --subsystem=10 -o check.efi check.o 
2>disabled && echo y))
-efi := $(if $(efi),$(shell rm disabled)y,$(shell $(call create,boot.init.o); 
$(call create,runtime.o)))
-
-extra-$(efi) += boot.init.o relocs-dummy.o runtime.o compat.o
-
-stub.o: $(extra-y)
+efi := $(if $(efi),$(shell rm disabled)y)
diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub.c
deleted file mode 100644
index 5060e6f..000
--- a/xen/arch/x86/efi/stub.c
+++ /dev/null
@@ -1,42 +0,0 @@
-#include 
-#include 
-#include 
-#include 
-
-#ifndef efi_platform
-bool_t efi_platform = 0;
-bool_t efi_loader = 0;
-#endif
-
-void __init efi_init_memory(void) { }
-
-paddr_t efi_rs_page_table(void)
-{
-BUG();
-return 0;
-}
-
-unsigned long efi_get_time(void)
-{
-BUG(

[Xen-devel] [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader

[Daniel Kiper]

We need more fine grained knowledge about EFI environment and check
for EFI platform and EFI loader separately to properly support
multiboot2 protocol. In general Xen loaded by this protocol uses
memory mappings and loaded modules in simliar way to Xen loaded
by multiboot (v1) protocol. Hence, split efi_enabled to efi_platform
and efi_loader.

Signed-off-by: Daniel Kiper 
---
 xen/arch/x86/dmi_scan.c|4 ++--
 xen/arch/x86/domain_page.c |2 +-
 xen/arch/x86/efi/stub.c|5 +++--
 xen/arch/x86/mpparse.c |4 ++--
 xen/arch/x86/setup.c   |8 
 xen/arch/x86/time.c|2 +-
 xen/common/efi/boot.c  |5 +
 xen/common/efi/runtime.c   |5 +++--
 xen/drivers/acpi/osl.c |2 +-
 xen/include/xen/efi.h  |6 +-
 10 files changed, 27 insertions(+), 16 deletions(-)

diff --git a/xen/arch/x86/dmi_scan.c b/xen/arch/x86/dmi_scan.c
index 500133a..63b976c 100644
--- a/xen/arch/x86/dmi_scan.c
+++ b/xen/arch/x86/dmi_scan.c
@@ -150,7 +150,7 @@ int __init dmi_get_table(u32 *base, u32 *len)
struct dmi_eps eps;
char __iomem *p, *q;
 
-   if (efi_enabled) {
+   if (efi_platform) {
if (!efi_dmi_size)
return -1;
*base = efi_dmi_address;
@@ -516,7 +516,7 @@ static void __init dmi_decode(struct dmi_header *dm)
 
 void __init dmi_scan_machine(void)
 {
-   if ((!efi_enabled ? dmi_iterate(dmi_decode) :
+   if ((!efi_platform ? dmi_iterate(dmi_decode) :
dmi_efi_iterate(dmi_decode)) == 0)
dmi_check_system(dmi_blacklist);
else
diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
index 158a164..5d4564c 100644
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -45,7 +45,7 @@ static inline struct vcpu *mapcache_current_vcpu(void)
 sync_local_execstate();
 /* We must now be running on the idle page table. */
 ASSERT((cr3 = read_cr3()) == __pa(idle_pg_table) ||
-   (efi_enabled && cr3 == efi_rs_page_table()));
+   (efi_platform && cr3 == efi_rs_page_table()));
 }
 
 return v;
diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub.c
index b8f49f8..5060e6f 100644
--- a/xen/arch/x86/efi/stub.c
+++ b/xen/arch/x86/efi/stub.c
@@ -3,8 +3,9 @@
 #include 
 #include 
 
-#ifndef efi_enabled
-const bool_t efi_enabled = 0;
+#ifndef efi_platform
+bool_t efi_platform = 0;
+bool_t efi_loader = 0;
 #endif
 
 void __init efi_init_memory(void) { }
diff --git a/xen/arch/x86/mpparse.c b/xen/arch/x86/mpparse.c
index a38e016..c4e3041 100644
--- a/xen/arch/x86/mpparse.c
+++ b/xen/arch/x86/mpparse.c
@@ -540,7 +540,7 @@ static inline void __init construct_default_ISA_mptable(int 
mpc_default_type)
 
 static __init void efi_unmap_mpf(void)
 {
-   if (efi_enabled)
+   if (efi_platform)
__set_fixmap(FIX_EFI_MPF, 0, 0);
 }
 
@@ -698,7 +698,7 @@ void __init find_smp_config (void)
 {
unsigned int address;
 
-   if (efi_enabled) {
+   if (efi_platform) {
efi_check_config();
return;
}
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index c27c49c..711fdb0 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -431,7 +431,7 @@ static void __init parse_video_info(void)
 struct boot_video_info *bvi = &bootsym(boot_vid_info);
 
 /* The EFI loader fills vga_console_info directly. */
-if ( efi_enabled )
+if ( efi_platform )
 return;
 
 if ( (bvi->orig_video_isVGA == 1) && (bvi->orig_video_mode == 3) )
@@ -663,7 +663,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 if ( ((unsigned long)cpu0_stack & (STACK_SIZE-1)) != 0 )
 panic("Misaligned CPU0 stack.");
 
-if ( efi_enabled )
+if ( efi_loader )
 {
 set_pdx_range(xen_phys_start >> PAGE_SHIFT,
   (xen_phys_start + BOOTSTRAP_MAP_BASE) >> PAGE_SHIFT);
@@ -774,7 +774,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
  * we can relocate the dom0 kernel and other multiboot modules. Also, on
  * x86/64, we relocate Xen to higher memory.
  */
-for ( i = 0; !efi_enabled && i < mbi->mods_count; i++ )
+for ( i = 0; !efi_loader && i < mbi->mods_count; i++ )
 {
 if ( mod[i].mod_start & (PAGE_SIZE - 1) )
 panic("Bootloader didn't honor module alignment request.");
@@ -962,7 +962,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 
 if ( !xen_phys_start )
 panic("Not enough memory to relocate Xen.");
-reserve_e820_ram(&boot_e820, efi_enabled ? mbi->mem_upper : __pa(&_start),
+reserve_e820_ram(&boot_e820, efi_loader ? mbi->mem_upper : __pa(&_start),
  __pa(&_end));
 
 /* Late kexec reservation (dynamic start address). */
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index 74c01e3..cdd17cb 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ 

[Xen-devel] [PATCH 01/18] x86/boot/reloc: mask out MBI_BOOTDEV from mbi flags

[Daniel Kiper]

..because it is ignored by Xen.

Signed-off-by: Daniel Kiper 
---
 xen/arch/x86/boot/reloc.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
index f971920..63045c0 100644
--- a/xen/arch/x86/boot/reloc.c
+++ b/xen/arch/x86/boot/reloc.c
@@ -90,7 +90,6 @@ multiboot_info_t *reloc(multiboot_info_t *mbi_old)
 
 /* Mask features we don't understand or don't relocate. */
 mbi->flags &= (MBI_MEMLIMITS |
-   MBI_BOOTDEV |
MBI_CMDLINE |
MBI_MODULES |
MBI_MEMMAP |
-- 
1.7.10.4


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

Re: [Xen-devel] [PATCH 3/5] hvmemul_do_io: If the send to the ioreq server failed do not retry.

[Don Slutz]

On 01/30/15 05:37, Paul Durrant wrote:
>> -Original Message-
>> From: Don Slutz [mailto:dsl...@verizon.com]
>> Sent: 30 January 2015 00:52
>> To: xen-devel@lists.xen.org
>> Cc: Andrew Cooper; George Dunlap; Ian Campbell; Ian Jackson; Jan Beulich;
>> Keir (Xen.org); Stefano Stabellini; Wei Liu; Paul Durrant; Don Slutz
>> Subject: [PATCH 3/5] hvmemul_do_io: If the send to the ioreq server failed
>> do not retry.
>>
>> I.E. do just what no backing DM does.
>>
>> Signed-off-by: Don Slutz 
>> ---
>>  xen/arch/x86/hvm/emulate.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
>> index 2ed4344..e9fc070 100644
>> --- a/xen/arch/x86/hvm/emulate.c
>> +++ b/xen/arch/x86/hvm/emulate.c
>> @@ -228,7 +228,11 @@ static int hvmemul_do_io(
>>  {
>>  rc = X86EMUL_RETRY;
>>  if ( !hvm_send_assist_req(&p) )
>> +{
>> +/* Since the send failed, do not retry */
>> +rc = X86EMUL_OKAY;
> 
> I guess this is probably ok. It's a bit moot though as the only circumstance 
> under which hvm_send_assist_req() will return 0 AFAICT, domain_crash() will 
> have been called, or the vcpu is shutting down.
> 


Turns out this is not ok.  Jan pointed out that for guest suspend to
work correctly, you need to retry.

   -Don Slutz


>   Paul
> 
>>  vio->io_state = HVMIO_none;
>> +}
>>  else if ( p_data == NULL )
>>  rc = X86EMUL_OKAY;
>>  }
>> --
>> 1.8.4
> 

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

Re: [Xen-devel] [PATCH 5/5] hvm_complete_assist_req: Tell caller we failed to send

[Don Slutz]

On 01/30/15 05:53, Paul Durrant wrote:
>> -Original Message-
>> From: Don Slutz [mailto:dsl...@verizon.com]
>> Sent: 30 January 2015 00:53
>> To: xen-devel@lists.xen.org
>> Cc: Andrew Cooper; George Dunlap; Ian Campbell; Ian Jackson; Jan Beulich;
>> Keir (Xen.org); Stefano Stabellini; Wei Liu; Paul Durrant; Don Slutz
>> Subject: [PATCH 5/5] hvm_complete_assist_req: Tell caller we failed to send
>>
>> This saves a VMENTRY and a VMEXIT since we not longer retry the
>> ioport read.
>>
>> hvmemul_do_io() will retry in order to complete an ioport read when
>> hvm_send_assist_req() is successful.
>>
>> Signed-off-by: Don Slutz 
>> ---
>>  xen/arch/x86/hvm/hvm.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>> index 6f7b407..bad410e 100644
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -2599,7 +2599,7 @@ static bool_t hvm_complete_assist_req(ioreq_t *p)
>>  break;
>>  }
>>
>> -return 1;
>> +return 0; /* implicitly bins the i/o operation */
> 
> Actually that comment is not right. The operation is not binned; it's just 
> already been done.
> 

Will adjust, I expect the return to go away.
   -Don Slutz

>   Paul
> 
>>  }
>>
>>  bool_t hvm_send_assist_req(ioreq_t *p)
>> --
>> 1.8.4
> 

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

Re: [Xen-devel] [PATCH 5/5] hvm_complete_assist_req: Tell caller we failed to send

[Don Slutz]

On 01/30/15 05:24, Jan Beulich wrote:
 On 30.01.15 at 01:52,  wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -2599,7 +2599,7 @@ static bool_t hvm_complete_assist_req(ioreq_t *p)
>>  break;
>>  }
>>  
>> -return 1;
>> +return 0; /* implicitly bins the i/o operation */
>>  }
> 
> This change points out that having hvm_complete_assist_req() be a
> separate function yet having only a single caller, and it returning
> non-void with only a single possible return value isn't the best
> arrangement. I think this should be brought back into
> hvm_send_assist_req(), by inverting the if() condition there. Unless
> there are intentions for it to have another caller, but in that case
> it should still be made return void, with the caller choosing what to
> return.
> 

Sounds good to me will do.
   -Don Slutz

> Jan
> 

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

Re: [Xen-devel] [PATCH 5/5] hvm_complete_assist_req: Tell caller we failed to send

[Don Slutz]

On 01/30/15 05:40, Paul Durrant wrote:
>> -Original Message-
>> From: Don Slutz [mailto:dsl...@verizon.com]
>> Sent: 30 January 2015 00:53
>> To: xen-devel@lists.xen.org
>> Cc: Andrew Cooper; George Dunlap; Ian Campbell; Ian Jackson; Jan Beulich;
>> Keir (Xen.org); Stefano Stabellini; Wei Liu; Paul Durrant; Don Slutz
>> Subject: [PATCH 5/5] hvm_complete_assist_req: Tell caller we failed to send
>>
>> This saves a VMENTRY and a VMEXIT since we not longer retry the
>> ioport read.
>>
>> hvmemul_do_io() will retry in order to complete an ioport read when
>> hvm_send_assist_req() is successful.
>>
>> Signed-off-by: Don Slutz 
> 
> It seems like this change should be folded into patch 3? I think the two 
> changes only make sense in combination.
> 

Happy to do so.
   -Don Slutz


>   Paul
> 
>> ---
>>  xen/arch/x86/hvm/hvm.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>> index 6f7b407..bad410e 100644
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -2599,7 +2599,7 @@ static bool_t hvm_complete_assist_req(ioreq_t *p)
>>  break;
>>  }
>>
>> -return 1;
>> +return 0; /* implicitly bins the i/o operation */
>>  }
>>
>>  bool_t hvm_send_assist_req(ioreq_t *p)
>> --
>> 1.8.4
> 

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

Re: [Xen-devel] [PATCH v3 2/3] x86/VPMU: Disable VPMU when NMI watchdog is on

[Andrew Cooper]

On 30/01/15 17:15, Boris Ostrovsky wrote:
> NMI watchdog sets APIC_LVTPC register to generate an NMI when PMU counter
> overflow occurs. This may be overwritten by VPMU code later, effectively
> turning off the watchdog.
>
> We should disable VPMU when NMI watchdog is running.
>
> Signed-off-by: Boris Ostrovsky 

Reviewed-by: Andrew Cooper 

> ---
>  docs/misc/xen-command-line.markdown |  2 ++
>  xen/arch/x86/hvm/vpmu.c | 13 +
>  2 files changed, 15 insertions(+)
>
> diff --git a/docs/misc/xen-command-line.markdown 
> b/docs/misc/xen-command-line.markdown
> index 2274e74..bc316be 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1346,6 +1346,8 @@ wrong behaviour (see handle\_pmc\_quirk()).
>  If 'vpmu=bts' is specified the virtualisation of the Branch Trace Store (BTS)
>  feature is switched on on Intel processors supporting this feature.
>  
> +Note that if **watchdog** option is also specified vpmu will be turned off.
> +
>  *Warning:*
>  As the BTS virtualisation is not 100% safe and because of the nehalem quirk
>  don't use the vpmu flag on production systems with Intel cpus!
> diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
> index 63b2158..b2e8e65 100644
> --- a/xen/arch/x86/hvm/vpmu.c
> +++ b/xen/arch/x86/hvm/vpmu.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -288,3 +289,15 @@ void vpmu_dump(struct vcpu *v)
>  vpmu->arch_vpmu_ops->arch_vpmu_dump(v);
>  }
>  
> +static int __init vpmu_init(void)
> +{
> +/* NMI watchdog uses LVTPC and HW counter */
> +if ( opt_watchdog && opt_vpmu_enabled )
> +{
> +printk(XENLOG_WARNING "NMI watchdog is enabled. Turning VPMU 
> off.\n");
> +opt_vpmu_enabled = 0;
> +}
> +
> +return 0;
> +}
> +__initcall(vpmu_init);


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

Re: [Xen-devel] [PATCH v3 1/3] x86/nmi: Cleanup usage of nmi_watchdog

[Andrew Cooper]

On 30/01/15 17:15, Boris Ostrovsky wrote:
> Use NMI_NONE when testing whether NMI watchdog is off.
>
> Remove unused NMI_INVALID macro.
>
> Signed-off-by: Boris Ostrovsky 

Reviewed-by: Andrew Cooper 

> ---
>  xen/arch/x86/nmi.c | 4 ++--
>  xen/arch/x86/traps.c   | 3 ++-
>  xen/include/asm-x86/apic.h | 1 -
>  3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/xen/arch/x86/nmi.c b/xen/arch/x86/nmi.c
> index 98c1e15..2ab97a0 100644
> --- a/xen/arch/x86/nmi.c
> +++ b/xen/arch/x86/nmi.c
> @@ -148,7 +148,7 @@ int __init check_nmi_watchdog (void)
>  int cpu;
>  bool_t ok = 1;
>  
> -if ( !nmi_watchdog )
> +if ( nmi_watchdog == NMI_NONE )
>  return 0;
>  
>  printk("Testing NMI watchdog on all CPUs:");
> @@ -361,7 +361,7 @@ static int __pminit setup_p4_watchdog(void)
>  
>  void __pminit setup_apic_nmi_watchdog(void)
>  {
> -if (!nmi_watchdog)
> +if ( nmi_watchdog == NMI_NONE )
>  return;
>  
>  switch (boot_cpu_data.x86_vendor) {
> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> index ec324b0..f5516dc 100644
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -3385,7 +3385,8 @@ void do_nmi(const struct cpu_user_regs *regs)
>  if ( nmi_callback(regs, cpu) )
>  return;
>  
> -if ( !nmi_watchdog || (!nmi_watchdog_tick(regs) && watchdog_force) )
> +if ( (nmi_watchdog == NMI_NONE) ||
> + (!nmi_watchdog_tick(regs) && watchdog_force) )
>  handle_unknown = 1;
>  
>  /* Only the BSP gets external NMIs from the system. */
> diff --git a/xen/include/asm-x86/apic.h b/xen/include/asm-x86/apic.h
> index 6697245..be9a535 100644
> --- a/xen/include/asm-x86/apic.h
> +++ b/xen/include/asm-x86/apic.h
> @@ -221,7 +221,6 @@ extern unsigned int nmi_watchdog;
>  #define NMI_NONE 0
>  #define NMI_IO_APIC  1
>  #define NMI_LOCAL_APIC   2
> -#define NMI_INVALID  3
>  
>  #else /* !CONFIG_X86_LOCAL_APIC */
>  static inline int lapic_suspend(void) {return 0;}


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

[Xen-devel] [PATCH v3 3/3] x86/VPMU: Handle APIC_LVTPC accesses

[Boris Ostrovsky]

Don't have the hypervisor update APIC_LVTPC when _it_ thinks the vector
should be updated. Instead, handle guest's APIC_LVTPC accesses and write what
the guest explicitly wanted (but only when VPMU is enabled).

This is updated version of commit 8097616fbdda that was reverted by
cc3404093c85. Unlike the previous version, we don't update APIC_LVTPC
when VPMU is disabled to avoid interfering with NMI watchdog (which
runs only when VPMU is off).

Signed-off-by: Boris Ostrovsky 
Acked-by: Kevin Tian 
---
 xen/arch/x86/hvm/svm/vpmu.c   |  4 
 xen/arch/x86/hvm/vlapic.c |  3 +++
 xen/arch/x86/hvm/vmx/vpmu_core2.c | 17 -
 xen/arch/x86/hvm/vpmu.c   | 13 +
 xen/include/asm-x86/hvm/vpmu.h|  1 +
 5 files changed, 17 insertions(+), 21 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 19777e3..64dc167 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -302,8 +302,6 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 if ( !acquire_pmu_ownership(PMU_OWNER_HVM) )
 return 1;
 vpmu_set(vpmu, VPMU_RUNNING);
-apic_write(APIC_LVTPC, PMU_APIC_VECTOR);
-vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR;
 
 if ( has_hvm_container_vcpu(v) &&
  !((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
@@ -314,8 +312,6 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 if ( (get_pmu_reg_type(msr) == MSR_TYPE_CTRL) &&
 (is_pmu_enabled(msr_content) == 0) && vpmu_is_set(vpmu, VPMU_RUNNING) )
 {
-apic_write(APIC_LVTPC, PMU_APIC_VECTOR | APIC_LVT_MASKED);
-vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | APIC_LVT_MASKED;
 vpmu_reset(vpmu, VPMU_RUNNING);
 if ( has_hvm_container_vcpu(v) &&
  ((struct amd_vpmu_context *)vpmu->context)->msr_bitmap_set )
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 8062f31..5da6d8f 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -777,6 +778,8 @@ static int vlapic_reg_write(struct vcpu *v,
 }
 if ( (offset == APIC_LVTT) && !(val & APIC_LVT_MASKED) )
 pt_may_unmask_irq(NULL, &vlapic->pt);
+if ( offset == APIC_LVTPC )
+vpmu_lvtpc_update(val);
 break;
 
 case APIC_TMICT:
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c 
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 4d0e9a8..7793145 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -519,19 +519,6 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 else
 vpmu_reset(vpmu, VPMU_RUNNING);
 
-/* Setup LVTPC in local apic */
-if ( vpmu_is_set(vpmu, VPMU_RUNNING) &&
- is_vlapic_lvtpc_enabled(vcpu_vlapic(v)) )
-{
-apic_write_around(APIC_LVTPC, PMU_APIC_VECTOR);
-vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR;
-}
-else
-{
-apic_write_around(APIC_LVTPC, PMU_APIC_VECTOR | APIC_LVT_MASKED);
-vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | APIC_LVT_MASKED;
-}
-
 if ( type != MSR_TYPE_GLOBAL )
 {
 u64 mask;
@@ -697,10 +684,6 @@ static int core2_vpmu_do_interrupt(struct cpu_user_regs 
*regs)
 return 0;
 }
 
-/* HW sets the MASK bit when performance counter interrupt occurs*/
-vpmu->hw_lapic_lvtpc = apic_read(APIC_LVTPC) & ~APIC_LVT_MASKED;
-apic_write_around(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
-
 return 1;
 }
 
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index b2e8e65..0e6b6c0 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -65,6 +65,19 @@ static void __init parse_vpmu_param(char *s)
 }
 }
 
+void vpmu_lvtpc_update(uint32_t val)
+{
+struct vpmu_struct *vpmu;
+
+if ( !opt_vpmu_enabled )
+return;
+
+vpmu = vcpu_vpmu(current);
+
+vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | (val & APIC_LVT_MASKED);
+apic_write(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
+}
+
 int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported)
 {
 struct vpmu_struct *vpmu = vcpu_vpmu(current);
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index ddc2748..9c4e65a 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -104,6 +104,7 @@ static inline bool_t vpmu_are_all_set(const struct 
vpmu_struct *vpmu,
 return !!((vpmu->flags & mask) == mask);
 }
 
+void vpmu_lvtpc_update(uint32_t val);
 int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported);
 int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content);
 void vpmu_do_interrupt(struct cpu_user_regs *regs);
-- 
1.8.1.4


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

[Xen-devel] [PATCH v3 1/3] x86/nmi: Cleanup usage of nmi_watchdog

[Boris Ostrovsky]

Use NMI_NONE when testing whether NMI watchdog is off.

Remove unused NMI_INVALID macro.

Signed-off-by: Boris Ostrovsky 
---
 xen/arch/x86/nmi.c | 4 ++--
 xen/arch/x86/traps.c   | 3 ++-
 xen/include/asm-x86/apic.h | 1 -
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/nmi.c b/xen/arch/x86/nmi.c
index 98c1e15..2ab97a0 100644
--- a/xen/arch/x86/nmi.c
+++ b/xen/arch/x86/nmi.c
@@ -148,7 +148,7 @@ int __init check_nmi_watchdog (void)
 int cpu;
 bool_t ok = 1;
 
-if ( !nmi_watchdog )
+if ( nmi_watchdog == NMI_NONE )
 return 0;
 
 printk("Testing NMI watchdog on all CPUs:");
@@ -361,7 +361,7 @@ static int __pminit setup_p4_watchdog(void)
 
 void __pminit setup_apic_nmi_watchdog(void)
 {
-if (!nmi_watchdog)
+if ( nmi_watchdog == NMI_NONE )
 return;
 
 switch (boot_cpu_data.x86_vendor) {
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index ec324b0..f5516dc 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -3385,7 +3385,8 @@ void do_nmi(const struct cpu_user_regs *regs)
 if ( nmi_callback(regs, cpu) )
 return;
 
-if ( !nmi_watchdog || (!nmi_watchdog_tick(regs) && watchdog_force) )
+if ( (nmi_watchdog == NMI_NONE) ||
+ (!nmi_watchdog_tick(regs) && watchdog_force) )
 handle_unknown = 1;
 
 /* Only the BSP gets external NMIs from the system. */
diff --git a/xen/include/asm-x86/apic.h b/xen/include/asm-x86/apic.h
index 6697245..be9a535 100644
--- a/xen/include/asm-x86/apic.h
+++ b/xen/include/asm-x86/apic.h
@@ -221,7 +221,6 @@ extern unsigned int nmi_watchdog;
 #define NMI_NONE   0
 #define NMI_IO_APIC1
 #define NMI_LOCAL_APIC 2
-#define NMI_INVALID3
 
 #else /* !CONFIG_X86_LOCAL_APIC */
 static inline int lapic_suspend(void) {return 0;}
-- 
1.8.1.4


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

[Xen-devel] [PATCH v3 0/3] A few VPMU/watchdog-related patches

[Boris Ostrovsky]

Changes in v3:
* Moved opt_watchdog check into initcall

Changes in v2:
* Added NMI cleanup patch
* Disaple VPMU in vpmu_initialise() instead of doing it in options parsing 
routines
* Update documentation by mentioning that VPMU doesn't work with watchdog
* Drop some sign-off area tags


The first patch is a light cleanup of nmi_watchdog usage.

The second patch is to disable VPMU when watchdog is on since both are using
APIC_LVTPC register and VPMU, when running, will overwrite watchdog's settings.

The last patch is update to the earlier (reverted) commit 8097616. We prevent
guests's updates to APIC_LVTPC when VPMU is disabled. Without this a guest may
redirect a watchdog interrupt to VPMU which will not be able to handle it.

Boris Ostrovsky (3):
  x86/nmi: Cleanup usage of nmi_watchdog
  x86/VPMU: Disable VPMU when NMI watchdog is on
  x86/VPMU: Handle APIC_LVTPC accesses

 docs/misc/xen-command-line.markdown |  2 ++
 xen/arch/x86/hvm/svm/vpmu.c |  4 
 xen/arch/x86/hvm/vlapic.c   |  3 +++
 xen/arch/x86/hvm/vmx/vpmu_core2.c   | 17 -
 xen/arch/x86/hvm/vpmu.c | 26 ++
 xen/arch/x86/nmi.c  |  4 ++--
 xen/arch/x86/traps.c|  3 ++-
 xen/include/asm-x86/apic.h  |  1 -
 xen/include/asm-x86/hvm/vpmu.h  |  1 +
 9 files changed, 36 insertions(+), 25 deletions(-)

-- 
1.8.1.4


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

[Xen-devel] [PATCH v3 2/3] x86/VPMU: Disable VPMU when NMI watchdog is on

[Boris Ostrovsky]

NMI watchdog sets APIC_LVTPC register to generate an NMI when PMU counter
overflow occurs. This may be overwritten by VPMU code later, effectively
turning off the watchdog.

We should disable VPMU when NMI watchdog is running.

Signed-off-by: Boris Ostrovsky 
---
 docs/misc/xen-command-line.markdown |  2 ++
 xen/arch/x86/hvm/vpmu.c | 13 +
 2 files changed, 15 insertions(+)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 2274e74..bc316be 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1346,6 +1346,8 @@ wrong behaviour (see handle\_pmc\_quirk()).
 If 'vpmu=bts' is specified the virtualisation of the Branch Trace Store (BTS)
 feature is switched on on Intel processors supporting this feature.
 
+Note that if **watchdog** option is also specified vpmu will be turned off.
+
 *Warning:*
 As the BTS virtualisation is not 100% safe and because of the nehalem quirk
 don't use the vpmu flag on production systems with Intel cpus!
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 63b2158..b2e8e65 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -288,3 +289,15 @@ void vpmu_dump(struct vcpu *v)
 vpmu->arch_vpmu_ops->arch_vpmu_dump(v);
 }
 
+static int __init vpmu_init(void)
+{
+/* NMI watchdog uses LVTPC and HW counter */
+if ( opt_watchdog && opt_vpmu_enabled )
+{
+printk(XENLOG_WARNING "NMI watchdog is enabled. Turning VPMU off.\n");
+opt_vpmu_enabled = 0;
+}
+
+return 0;
+}
+__initcall(vpmu_init);
-- 
1.8.1.4


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

Re: [Xen-devel] [RFC PATCH V3 05/12] xen: Introduce vm_event

[Daniel De Graaf]

On 01/29/2015 04:46 PM, Tamas K Lengyel wrote:

To make it easier to review the renaming process of mem_event -> vm_event,
the process is broken into three pieces, of which this patch is the first.
In this patch the vm_event subsystem is introduced and hooked into the build
process, but it is not yet used anywhere.

Signed-off-by: Tamas K Lengyel 


[...]

diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index f20e89c..d6d403a 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -525,6 +525,18 @@ static XSM_INLINE int xsm_mem_event_op(XSM_DEFAULT_ARG 
struct domain *d, int op)
  XSM_ASSERT_ACTION(XSM_DM_PRIV);
  return xsm_default_action(action, current->domain, d);
  }
+
+static XSM_INLINE int xsm_vm_event_control(XSM_DEFAULT_ARG struct domain *d, 
int mode, int op)
+{
+XSM_ASSERT_ACTION(XSM_PRIV);
+return xsm_default_action(action, current->domain, d);
+}
+
+static XSM_INLINE int xsm_vm_event_op(XSM_DEFAULT_ARG struct domain *d, int op)
+{
+XSM_ASSERT_ACTION(XSM_DM_PRIV);
+return xsm_default_action(action, current->domain, d);
+}
  #endif


[...]

diff --git a/xen/xsm/flask/policy/access_vectors 
b/xen/xsm/flask/policy/access_vectors
index 1da9f63..a4241b5 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -250,6 +250,7 @@ class hvm
  hvmctl
  # XEN_DOMCTL_set_access_required
  mem_event
+vm_event
  # XEN_DOMCTL_mem_sharing_op and XENMEM_sharing_op_{share,add_physmap} with:
  #  source = the domain making the hypercall
  #  target = domain whose memory is being shared



This implies that device model domains should be allowed to use the operations
covered by xsm_vm_event_op but not those covered by xsm_vm_event_control.
If this is how the eventual operations are intended to be used, the FLASK
permissions also need to be split so that a similar distinction can be made in
the policy.

After looking at the later patches in this series, this appears to be a flaw in
the existing FLASK hooks that got copied over.  While it is still useful to fix,
it  may be better to make the split in a separate patch from the renames.  Now
that VM events apply to more than just HVM domains, it may be useful to move
the new permission(s) from class hvm to either domain2 or mmu.

--
Daniel De Graaf
National Security Agency

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

Re: [Xen-devel] [RFC PATCH V3 07/12] xen: Remove mem_event

[Daniel De Graaf]

On 01/29/2015 04:46 PM, Tamas K Lengyel wrote:

This is the third and final patch in the mem_event -> vm_event renaming process
which removes all references and remaining code of mem_event from the Xen
source.

Signed-off-by: Tamas K Lengyel 
---
  MAINTAINERS|   1 -
  docs/misc/xsm-flask.txt|   1 -
  tools/libxc/Makefile   |   1 -
  tools/libxc/xc_mem_access.c|  16 +-
  tools/libxc/xc_mem_event.c | 162 -
  tools/libxc/xc_private.h   |  12 -
  xen/common/Makefile|   1 -
  xen/common/mem_event.c | 738 -
  xen/include/public/domctl.h|  90 +
  xen/include/public/mem_event.h | 192 ---
  xen/include/xen/mem_event.h| 143 
  xen/include/xen/sched.h|  41 ---
  xen/include/xsm/dummy.h|  12 -
  xen/include/xsm/xsm.h  |  12 -
  xen/xsm/dummy.c|   2 -
  xen/xsm/flask/hooks.c  |  12 -
  16 files changed, 14 insertions(+), 1422 deletions(-)
  delete mode 100644 tools/libxc/xc_mem_event.c
  delete mode 100644 xen/common/mem_event.c
  delete mode 100644 xen/include/public/mem_event.h
  delete mode 100644 xen/include/xen/mem_event.h


You should also remove mem_event from xen/xsm/flask/policy/access_vectors
in this patch.

--
Daniel De Graaf
National Security Agency

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

Re: [Xen-devel] [PATCH 4/5] hvm_complete_assist_req: We should not be able to get here on IOREQ_TYPE_PCI_CONFIG

[Don Slutz]

On 01/30/15 05:24, Jan Beulich wrote:
 >>> On 30.01.15 at 01:52,  wrote:
> According to your 0/5
> Suggested-by: Paul Durrant 
> ?

Yes, added.
   -Don Slutz

> 
> Jan
> 
>> > Signed-off-by: Don Slutz 
>> > ---
>> >  xen/arch/x86/hvm/hvm.c | 1 +
>> >  1 file changed, 1 insertion(+)
>> > 
>> > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>> > index c7984d1..6f7b407 100644
>> > --- a/xen/arch/x86/hvm/hvm.c
>> > +++ b/xen/arch/x86/hvm/hvm.c
>> > @@ -2573,6 +2573,7 @@ bool_t hvm_send_assist_req_to_ioreq_server(struct 
>> > hvm_ioreq_server *s,
>> >  
>> >  static bool_t hvm_complete_assist_req(ioreq_t *p)
>> >  {
>> > +ASSERT(p->type != IOREQ_TYPE_PCI_CONFIG);
>> >  switch ( p->type )
>> >  {
>> >  case IOREQ_TYPE_COPY:
>> > -- 
>> > 1.8.4
> 
> 

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

Re: [Xen-devel] [PATCH v3 3/3] xen/arm: Introduce support for Renesas R-Car Gen2 platform

[Julien Grall]

On 30/01/15 16:44, Oleksandr Tyshchenko wrote:
> On Fri, Jan 30, 2015 at 5:52 PM, Julien Grall  wrote:
>> Hi Oleksandr,
> Hi Julien
> 
>>
>> On 30/01/15 15:38, Oleksandr Tyshchenko wrote:
>>> For example, such a simple thing as a formula for calculating divider
>>> value for uart baudrate can differs from one family to
>>> another despite the fact that these families use the same UART IP
>>> block named SCIF (clock may be differs - ext/int, another freq).
>>> Or FIFO size, etc.
>>
>> IHMO this look more configuration than logic change in the UART driver.
>> We don't ask you to support all the configuration of the UART right now
>> ;). However, if someone comes with a new platform using the SCIF, I
>> expect him to reuse and fix this driver rather than creating a new one.
>>
>> FWIW, the compatible string is "renesas,scif" not rcar smth. So, SCIF
>> sounds a better name for this UART.
> ok
> 
> Just to clarify:
> - Should I remove all references to "R-Car Gen2" from UART stuff?

Yes please.

> - Can I keep your "Reviewed-by" after there mechanical changes.

Sure.

> It would be nice to hear your and Ian's opinions about board file.

I'm not sure about this one. I will let Ian decides.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH RFC] p2m: p2m_mmio_direct set RW permissions

[Jan Beulich]

>>> On 30.01.15 at 17:34,  wrote:
> On Tue, Jan 27, 2015 at 08:24:36AM +, Jan Beulich wrote:
>> >>> On 26.01.15 at 18:30,  wrote:
>> > On Mon, Jan 26, 2015 at 05:06:12PM +, Jan Beulich wrote:
>> >> >>> On 26.01.15 at 17:57,  wrote:
>> >> > On Fri, Jan 23, 2015 at 10:50:23AM +, Jan Beulich wrote:
>> >> >> >>> On 22.01.15 at 18:34,  wrote:
>> >> >> > (XEN)  d56f - d5fff000 (reserved)
>> >> >> 
>> >> >> So this is where one of the RMRRs sits in (and also where
>> >> >> the faults occur according to the two numbers you sent
>> >> >> earlier, which - as others have already said - is an indication
>> >> >> of the reported RMRRs being incomplete), ...
>> >> >> 
>> >> >> > (XEN)  d5fff000 - d600 (usable)
>> >> >> > (XEN)  d700 - df20 (reserved)
>> >> >> 
>> >> >> ... and this is the exact range of the other one. But the usable
>> >> >> entry between them is a sign of the firmware not doing the
>> >> >> best job in assigning resources.
>> >> >> 
>> >> >> I don't, btw, think that blindly mapping all the reserved regions
>> >> >> into PVH Dom0's P2M would be (or is, if that's what's happening
>> >> >> today) correct - these regions are named reserved for a
>> >> >> reason. In the case here it's actually RAM, not MMIO, and
>> >> >> Dom0 (as well as Xen) has no business accessing these (for others
>> >> >> this may be different, e.g. the LAPIC and IO-APIC ones below,
>> >> >> but Xen learns/knows of them by means different from looking
>> >> >> at the memory map).
>> >> > 
>> >> > I understand this this. At the same time I think pv dom0 does exactly
>> >> > this blind mapping. I also tried to map these regions as read-only and
>> >> > that worked. Can be this an option for these ram regions?
>> >> 
>> >> No - they're reserved, so there shouldn't be _any_ access to them.
>> >> The only possible workaround I see as acceptable would be the
>> >> already proposed addition of a command line option allowing to
>> >> specify additional RMRR-like regions.
>> >> 
>> > 
>> > Understood. And I am guessing the permissions overloading option should
>> > be available as well? For example, RW or R only. RMRRs are always mapped 
>> > with RW.
>> 
>> That's an option, but not a requirement imo.
>> 
>> > Why can be this a platform quirk?
>> 
>> Did you mean "can't"? If not, I don't understand the question. If so,
>> remember that we're talking about RAM allocated by the firmware
>> for special purposes. Hence such a quirk would need tailoring to any
>> particular published firmware version, and would need to take into
>> account any differences in the memory use that may result from
>> setting firmware options differently (and assuming that the memory
>> use is deterministic across boots when the options don't change -
>> I've seen systems where memory use differed between warm and
>> cold boots). IOW, not something that's likely to be practical.
> 
> What about pv dom0 case? pv dom0 maps these reserved memory ranges with
> RW access rights. Should be this unified in some way?

I'm again having some difficulty relating the question to the context
given. But anyway - where do you see Dom0 getting reserved
memory regions mapped RW unconditionally? The fact that
iommu_inclusive_mapping=1 by default is to cover firmware bugs
afaik. I could see us altering this at some point to only behave that
way on older systems. But that's a decision mainly to be made by
the VT-d maintainers.

Jan


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

Re: [Xen-devel] [PATCH v3 3/3] xen/arm: Introduce support for Renesas R-Car Gen2 platform

[Oleksandr Tyshchenko]

On Fri, Jan 30, 2015 at 5:52 PM, Julien Grall  wrote:
> Hi Oleksandr,
Hi Julien

>
> On 30/01/15 15:38, Oleksandr Tyshchenko wrote:
>> For example, such a simple thing as a formula for calculating divider
>> value for uart baudrate can differs from one family to
>> another despite the fact that these families use the same UART IP
>> block named SCIF (clock may be differs - ext/int, another freq).
>> Or FIFO size, etc.
>
> IHMO this look more configuration than logic change in the UART driver.
> We don't ask you to support all the configuration of the UART right now
> ;). However, if someone comes with a new platform using the SCIF, I
> expect him to reuse and fix this driver rather than creating a new one.
>
> FWIW, the compatible string is "renesas,scif" not rcar smth. So, SCIF
> sounds a better name for this UART.
ok

Just to clarify:
- Should I remove all references to "R-Car Gen2" from UART stuff?
- Can I keep your "Reviewed-by" after there mechanical changes.

It would be nice to hear your and Ian's opinions about board file.

>
> Regards,
>
> --
> Julien Grall



-- 

Oleksandr Tyshchenko | Embedded Dev
GlobalLogic
www.globallogic.com

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

Re: [Xen-devel] Is: kexec & EFI Was: Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues

[Jan Beulich]

>>> On 30.01.15 at 17:24,  wrote:
> On Fri, Jan 30, 2015 at 03:34:19PM +, Jan Beulich wrote:
>> >>> On 30.01.15 at 16:09,  wrote:
>> > I suppose that we should provide additional kexec hypercall
>> > function which will return info about RS. kexec-tools should
>> > load new kernel as usual and add relevant argument to its
>> > command line. Most things are in place so we should just
>> > learn kexec-tools to do new things.
>>
>> There is a reason why the RS table info can't currently be
>> obtained via a hypercall - Dom0 has nothing to do with it. Plus any
>> kexec-ed kernel (Linux or other) will, under EFI, want this
>> information, so a mechanism by which to pass the information to
>> the secondary kernel without exposing it to entities not having a
>> need to know would be preferable (albeit I have no idea so far
>> how that might look like).
> 
> Currently, anybody able to use HYPERVISOR_memory_op hypercall on dom0
> is able to get full machine memory map. So, what is the problem with
> exposing more details about RS? Do you think about security? I suppose
> that we expose to dom0 other hardware details which potentially could
> be used in malicious way and RS details exposure will not undermine
> our security so strong.

I'm not seeing what the exposure of the machine memory map has
to do with the RS table. Anyway - my concern isn't a malicious
consumer, but an ignorant one (e.g. then trying to make runtime
calls directly from Dom0).

>> Plus, this still doesn't in any way deal with the aspect that was
>> so far discussed in this thread - SetVirtualAddressMap() being
>> callable only once.
> 
> Well, we must live with it because this is part of UEFI spec. Or change
> UEFI spec. Still thinking why spec does not allow OS do this operation
> more then once. OTH, Konrad pointed out a solution (workaround) for this
> issue used in Linux which seems sensible and could be used by us too.

Like Konrad, you're thinking too Linux-centric here: Yes, a Linux-
specific workaround is possible, but a finding a proper generic
solution would be much better. And a very obvious one is: Don't
call SetVirtualAddressMap() when you may want to kexec.

Jan


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

Re: [Xen-devel] [PATCH RFC] p2m: p2m_mmio_direct set RW permissions

[Elena Ufimtseva]

On Tue, Jan 27, 2015 at 08:24:36AM +, Jan Beulich wrote:
> >>> On 26.01.15 at 18:30,  wrote:
> > On Mon, Jan 26, 2015 at 05:06:12PM +, Jan Beulich wrote:
> >> >>> On 26.01.15 at 17:57,  wrote:
> >> > On Fri, Jan 23, 2015 at 10:50:23AM +, Jan Beulich wrote:
> >> >> >>> On 22.01.15 at 18:34,  wrote:
> >> >> > (XEN)  d56f - d5fff000 (reserved)
> >> >> 
> >> >> So this is where one of the RMRRs sits in (and also where
> >> >> the faults occur according to the two numbers you sent
> >> >> earlier, which - as others have already said - is an indication
> >> >> of the reported RMRRs being incomplete), ...
> >> >> 
> >> >> > (XEN)  d5fff000 - d600 (usable)
> >> >> > (XEN)  d700 - df20 (reserved)
> >> >> 
> >> >> ... and this is the exact range of the other one. But the usable
> >> >> entry between them is a sign of the firmware not doing the
> >> >> best job in assigning resources.
> >> >> 
> >> >> I don't, btw, think that blindly mapping all the reserved regions
> >> >> into PVH Dom0's P2M would be (or is, if that's what's happening
> >> >> today) correct - these regions are named reserved for a
> >> >> reason. In the case here it's actually RAM, not MMIO, and
> >> >> Dom0 (as well as Xen) has no business accessing these (for others
> >> >> this may be different, e.g. the LAPIC and IO-APIC ones below,
> >> >> but Xen learns/knows of them by means different from looking
> >> >> at the memory map).
> >> > 
> >> > I understand this this. At the same time I think pv dom0 does exactly
> >> > this blind mapping. I also tried to map these regions as read-only and
> >> > that worked. Can be this an option for these ram regions?
> >> 
> >> No - they're reserved, so there shouldn't be _any_ access to them.
> >> The only possible workaround I see as acceptable would be the
> >> already proposed addition of a command line option allowing to
> >> specify additional RMRR-like regions.
> >> 
> > 
> > Understood. And I am guessing the permissions overloading option should
> > be available as well? For example, RW or R only. RMRRs are always mapped 
> > with RW.
> 
> That's an option, but not a requirement imo.
> 
> > Why can be this a platform quirk?
> 
> Did you mean "can't"? If not, I don't understand the question. If so,
> remember that we're talking about RAM allocated by the firmware
> for special purposes. Hence such a quirk would need tailoring to any
> particular published firmware version, and would need to take into
> account any differences in the memory use that may result from
> setting firmware options differently (and assuming that the memory
> use is deterministic across boots when the options don't change -
> I've seen systems where memory use differed between warm and
> cold boots). IOW, not something that's likely to be practical.
> 
> Jan

What about pv dom0 case? pv dom0 maps these reserved memory ranges with
RW access rights. Should be this unified in some way?

> 

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

Re: [Xen-devel] [PATCH] xen/arm: Fix rtds scheduler for arm

[Julien Grall]

On 30/01/15 16:19, Denys Drozdov wrote:
> Julien,
> 
> The details of this issue can be found in the current mailing list.
> Please have a look
> athttp://lists.xen.org/archives/html/xen-devel/2014-09/msg04250.html
> .
> This is exactly the same behaviour we are observing when running on our
> arm setup.

I understood the problem... I just pointed out that the commit message
is not useful. Hence the request of more background.

If we have to read the log in a couple of years time. We should be able
to understand the problem/solution with the commit message.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] Is: kexec & EFI Was: Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues

[Daniel Kiper]

On Fri, Jan 30, 2015 at 03:34:19PM +, Jan Beulich wrote:
> >>> On 30.01.15 at 16:09,  wrote:
> > I suppose that we should provide additional kexec hypercall
> > function which will return info about RS. kexec-tools should
> > load new kernel as usual and add relevant argument to its
> > command line. Most things are in place so we should just
> > learn kexec-tools to do new things.
>
> There is a reason why the RS table info can't currently be
> obtained via a hypercall - Dom0 has nothing to do with it. Plus any
> kexec-ed kernel (Linux or other) will, under EFI, want this
> information, so a mechanism by which to pass the information to
> the secondary kernel without exposing it to entities not having a
> need to know would be preferable (albeit I have no idea so far
> how that might look like).

Currently, anybody able to use HYPERVISOR_memory_op hypercall on dom0
is able to get full machine memory map. So, what is the problem with
exposing more details about RS? Do you think about security? I suppose
that we expose to dom0 other hardware details which potentially could
be used in malicious way and RS details exposure will not undermine
our security so strong.

> Plus, this still doesn't in any way deal with the aspect that was
> so far discussed in this thread - SetVirtualAddressMap() being
> callable only once.

Well, we must live with it because this is part of UEFI spec. Or change
UEFI spec. Still thinking why spec does not allow OS do this operation
more then once. OTH, Konrad pointed out a solution (workaround) for this
issue used in Linux which seems sensible and could be used by us too.

Daniel

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

Re: [Xen-devel] [PATCH] xen/arm: Fix rtds scheduler for arm

[Denys Drozdov]

Julien,

The details of this issue can be found in the current mailing list.
Please have a look at
http://lists.xen.org/archives/html/xen-devel/2014-09/msg04250.html.
This is exactly the same behaviour we are observing when running on our arm
setup.

The fix changes spin_lock_irq/spin_unlock_irq to
spin_lock_irq_save/spin_lock_irq_restore,
since context_save executed right from IRQ level. The arm interrupt
handling differs from x86. ARM is handling  context_saved with IRQ disabled
in CPSR, though x86 has IRQs on. Thus it is failing on ASSERT inside
spin_lock_irq when running on ARM. I guess it should work on x86, so this
issue is ARM platform specific.

On Fri, Jan 30, 2015 at 6:10 PM, Julien Grall 
wrote:

> On 30/01/15 15:56, Andrew Cooper wrote:
> > On 30/01/15 15:46, Julien Grall wrote:
> >> Hello Denys,
> >>
> >> On 30/01/15 15:40, Denis Drozdov wrote:
> >>> From: denys drozdov 
> >>>
> >>> Update RT scheduler to run on arm platform
> >> You need to give more background of the problem (i.e why you have to
> >> disable the IRQ on ARM).
> >>
> >> As the scheduler is common with x86, I would expect the problem is also
> >> happening on this architecture.
> >
> > Changing a spinlock_irq into an irqsave is safe, functionally speaking,
> > but it is concerning that the scheduler appears to be called in
> > different interrupt states between architectures.
>
> For instance credit2 is also using vcpu_schedule_lock_irq... Although,
> IIRC, it's not used by default. So it has to be fixed too on ARM.
>
> In any case, the commit message needs more background such as stack
> trace and/or explaining why we have to take spinlock_irq.
>
> This may also need to document context_saved to explain the IRQs may not
> be enabled when this function is called.
>
> Regards,
>
> --
> Julien Grall
>



-- 

Denis Drozdov
GlobalLogic
M +(380)988969537  S denis.drozdov
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen/arm: Fix rtds scheduler for arm

[Julien Grall]

On 30/01/15 15:56, Andrew Cooper wrote:
> On 30/01/15 15:46, Julien Grall wrote:
>> Hello Denys,
>>
>> On 30/01/15 15:40, Denis Drozdov wrote:
>>> From: denys drozdov 
>>>
>>> Update RT scheduler to run on arm platform
>> You need to give more background of the problem (i.e why you have to
>> disable the IRQ on ARM).
>>
>> As the scheduler is common with x86, I would expect the problem is also
>> happening on this architecture.
> 
> Changing a spinlock_irq into an irqsave is safe, functionally speaking,
> but it is concerning that the scheduler appears to be called in
> different interrupt states between architectures.

For instance credit2 is also using vcpu_schedule_lock_irq... Although,
IIRC, it's not used by default. So it has to be fixed too on ARM.

In any case, the commit message needs more background such as stack
trace and/or explaining why we have to take spinlock_irq.

This may also need to document context_saved to explain the IRQs may not
be enabled when this function is called.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] rcu_sched self-detect stall when disable vif device

[David Vrabel]

On 28/01/15 17:27, Julien Grall wrote:
> On 28/01/15 17:06, David Vrabel wrote:
>> On 28/01/15 16:45, Julien Grall wrote:
>>> On 27/01/15 16:53, Wei Liu wrote:
 On Tue, Jan 27, 2015 at 04:47:45PM +, Julien Grall wrote:
> On 27/01/15 16:45, Wei Liu wrote:
>> On Tue, Jan 27, 2015 at 04:03:52PM +, Julien Grall wrote:
>>> Hi,
>>>
>>> While I'm working on support for 64K page in netfront, I got
>>> an rcu_sced self-detect message. It happens when netback is
>>> disabling the vif device due to an error.
>>>
>>> I'm using Linux 3.19-rc5 on seattle (ARM64). Any idea why
>>> the processor is stucked in xenvif_rx_queue_purge?
>>>
>>
>> When you try to release a SKB, core network driver need to enter some
>> RCU cirital region to clean up. dst_release for one, calls call_rcu.
>
> But this message shouldn't happen in normal condition or because of
> netfront. Right?
>

 Never saw  report like this before, even in the case that netfront is
 buggy.
>>>
>>> This is only happening when preemption is not enabled (i.e
>>> CONFIG_PREEMPT_NONE in the config file) in the backend kernel.
>>>
>>> When the vif is disabled, the loop in xenvif_kthread_guest_rx turned
>>> into an infinite loop. In my case, the code executed looks like:
>>>
>>>
>>>  1. for (;;) {
>>>  2. xenvif_wait_for_rx_work(queue);
>>>  3.
>>>  4. if (kthread_should_stop())
>>>  5. break;
>>>  6.
>>>  7. if (unlikely(vif->disabled && queue->id == 0) {
>>>  8. xenvif_carrier_off(vif);
>>>  9. xenvif_rx_queue_purge(queue);
>>> 10. continue;
>>> 11. }
>>> 12. }
>>>
>>> The wait on line 2 will return directly because the vif is disabled
>>> (see xenvif_have_rx_work)
>>>
>>> We are on queue 0, so the condition on line 7 is true. Therefore we will
>>> loop on line 10. And so on...
>>>
>>> On platform where preemption is not enabled, this thread will never
>>> yield/give the hand to another thread (unless the domain is destroyed).
>>
>> I'm not sure why we have a continue in the vif->disabled case and not
>> just a break.  Can you try that?
> 
> So I applied this small patches:
> 
> diff --git a/drivers/net/xen-netback/netback.c 
> b/drivers/net/xen-netback/netback.c
> index 908e65e..9448c6c 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -2110,7 +2110,7 @@ int xenvif_kthread_guest_rx(void *data)
> if (unlikely(vif->disabled && queue->id == 0)) {
> xenvif_carrier_off(vif);
> xenvif_rx_queue_purge(queue);
> -   continue;
> +   break;
> }
>  
> if (!skb_queue_empty(&queue->rx_queue))

How about this?

8<--
xen-netback: stop the guest rx thread after a fatal error

After commit e9d8b2c2968499c1f96563e6522c56958d5a1d0d (xen-netback:
disable rogue vif in kthread context), a fatal (protocol) error would
leave the guest Rx thread spinning, wasting CPU time.  Commit
ecf08d2dbb96d5a4b4bcc53a39e8d29cc8fef02e (xen-netback: reintroduce
guest Rx stall detection) made this even worse by removing a
cond_resched() from this path.

A fatal error is non-recoverable so just allow the guest Rx thread to
exit.  This requires taking additional refs to the task so the thread
exiting early is handled safely.

Signed-off-by: David Vrabel 

diff --git a/drivers/net/xen-netback/interface.c
b/drivers/net/xen-netback/interface.c
index 9259a73..037f74f 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -578,6 +578,7 @@ int xenvif_connect(struct xenvif_queue *queue,
unsigned long tx_ring_ref,
goto err_rx_unbind;
}
queue->task = task;
+   get_task_struct(task);

task = kthread_create(xenvif_dealloc_kthread,
  (void *)queue, "%s-dealloc", queue->name);
@@ -634,6 +635,7 @@ void xenvif_disconnect(struct xenvif *vif)

if (queue->task) {
kthread_stop(queue->task);
+   put_task_struct(queue->task);
queue->task = NULL;
}

diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index 908e65e..c8ce701 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -2109,8 +2109,7 @@ int xenvif_kthread_guest_rx(void *data)
 */
if (unlikely(vif->disabled && queue->id == 0)) {
xenvif_carrier_off(vif);
-   xenvif_rx_queue_purge(queue);
-   continue;
+   break;
}

if (!skb_queue_empty(&queue->rx_queue))


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

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

[xen . org]

flight 33931 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33931/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-winxpsp3  7 windows-install   fail REGR. vs. 33637

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 33637

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-armhf-armhf-xl  10 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt  9 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-amd64-amd64-libvirt  9 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel  9 guest-start  fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop   fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass

version targeted for testing:
 xen  9f7798eb6ea20ba94617772ed0f3b8862b826533
baseline version:
 xen  7106c691a6332cffab4037186d1caa3012ae051e


People who touched revisions under test:
  Andrew Cooper 
  Boris Ostrovsky 
  Chao Peng 
  Dan Carpenter 
  Daniel De Graaf 
  David Scott 
  David Vrabel 
  Dietmar Hahn 
  Fabio Fantoni 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Kevin Tian 
  Konrad Rzeszutek Wilk 
  Oleksandr Tyshchenko 
  Quan Xu 
  Roger Pau Monné 
  Sander Eikelenboom 
  Stefano Stabellini 
  Tim Deegan 
  Wei Liu 


jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-rhel6hvm-amd pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   pass
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64   

Re: [Xen-devel] [PATCH] xen/arm: Fix rtds scheduler for arm

[Andrew Cooper]

On 30/01/15 15:46, Julien Grall wrote:
> Hello Denys,
>
> On 30/01/15 15:40, Denis Drozdov wrote:
>> From: denys drozdov 
>>
>> Update RT scheduler to run on arm platform
> You need to give more background of the problem (i.e why you have to
> disable the IRQ on ARM).
>
> As the scheduler is common with x86, I would expect the problem is also
> happening on this architecture.

Changing a spinlock_irq into an irqsave is safe, functionally speaking,
but it is concerning that the scheduler appears to be called in
different interrupt states between architectures.

~Andrew


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

Re: [Xen-devel] [PATCH v3 3/3] xen/arm: Introduce support for Renesas R-Car Gen2 platform

[Julien Grall]

Hi Oleksandr,

On 30/01/15 15:38, Oleksandr Tyshchenko wrote:
> For example, such a simple thing as a formula for calculating divider
> value for uart baudrate can differs from one family to
> another despite the fact that these families use the same UART IP
> block named SCIF (clock may be differs - ext/int, another freq).
> Or FIFO size, etc.

IHMO this look more configuration than logic change in the UART driver.
We don't ask you to support all the configuration of the UART right now
;). However, if someone comes with a new platform using the SCIF, I
expect him to reuse and fix this driver rather than creating a new one.

FWIW, the compatible string is "renesas,scif" not rcar smth. So, SCIF
sounds a better name for this UART.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH] xen/arm: Fix rtds scheduler for arm

[Julien Grall]

Hello Denys,

On 30/01/15 15:40, Denis Drozdov wrote:
> From: denys drozdov 
> 
> Update RT scheduler to run on arm platform

You need to give more background of the problem (i.e why you have to
disable the IRQ on ARM).

As the scheduler is common with x86, I would expect the problem is also
happening on this architecture.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH v4] xen/arm: split the init_xen_time() in 2 parts

[Oleksandr Tyshchenko]

On Thu, Jan 29, 2015 at 3:18 PM, Julien Grall  wrote:
> Hi Oleksandr,
Hi Julien
>
> On 28/01/15 10:54, Oleksandr Tyshchenko wrote:
>> diff --git a/xen/include/xen/time.h b/xen/include/xen/time.h
>> index 709501f..bb6259d 100644
>> --- a/xen/include/xen/time.h
>> +++ b/xen/include/xen/time.h
>> @@ -12,6 +12,7 @@
>>  #include 
>>
>>  extern int init_xen_time(void);
>> +void preinit_xen_time(void);
>
> This declaration should not be in xen/time.h but asm-arm/time.h.
>
> I spotted a bit too late, sorry. I will send a patch for fixing it.
Thank you.

>
> Regards,
>
> --
> Julien Grall



-- 

Oleksandr Tyshchenko | Embedded Dev
GlobalLogic
www.globallogic.com

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

[Xen-devel] [PATCH] xen/arm: Fix rtds scheduler for arm

[Denis Drozdov]

From: denys drozdov 

Update RT scheduler to run on arm platform

Signed-off-by: denys drozdov 
---
 xen/common/sched_rt.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index e70d6c7..5fcc205 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -1011,7 +1011,8 @@ rt_context_saved(const struct scheduler *ops, struct vcpu 
*vc)
 struct rt_dom *sdom = NULL;
 struct rt_private *prv = rt_priv(ops);
 cpumask_t *online;
-spinlock_t *lock = vcpu_schedule_lock_irq(vc);
+unsigned long flags;
+spinlock_t *lock = vcpu_schedule_lock_irqsave(vc, &flags);
 
 clear_bit(__RTDS_scheduled, &svc->flags);
 /* not insert idle vcpu to runq */
@@ -1032,7 +1033,7 @@ rt_context_saved(const struct scheduler *ops, struct vcpu 
*vc)
 runq_tickle(ops, snext);
 }
 out:
-vcpu_schedule_unlock_irq(lock, vc);
+vcpu_schedule_unlock_irqrestore(lock, flags, vc);
 }
 
 /*
-- 
1.7.9.5


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

Re: [Xen-devel] [PATCH v3 3/3] xen/arm: Introduce support for Renesas R-Car Gen2 platform

[Oleksandr Tyshchenko]

Hi, Ian.
Sorry for late response.

As I understood from
http://am.renesas.com/products/soc/assp/soc_pf/index.jsp
The "R-Mobile" and "R-Car" are the different platforms designed for
different areas.

The "R-Mobile" is a new integrated platform for mobile applications.
Integrated SH-Mobile, EMMA Mobile.
http://am.renesas.com/products/soc/assp/mobile/index.jsp

The "R-Car" is a new integrated platform for car information systems.
http://am.renesas.com/products/soc/assp/automotive/index.jsp

So, It seems that RCAR2 it is not a subset of shmobile.
Sure, they might have a lot in common, the same IP blocks, etc.
But I didn't investigate carefully how similar they are. And I can't
guarantee that they are similar enough to be a single platform in Xen.

Unfortunately, I have no glue why they all reside in
arch/arm/mach-shmobile in kernel.
Maybe for historical reasons.

I can only guarantee that uart stuff from this patch series should
works on all SoCs in R-Car Gen2 family.
At the same time the Iurii can guarantee that the board file he
introduced should be
suitable for R-Car Gen2 family.

For example, such a simple thing as a formula for calculating divider
value for uart baudrate can differs from one family to
another despite the fact that these families use the same UART IP
block named SCIF (clock may be differs - ext/int, another freq).
Or FIFO size, etc.
For second example, the R-Car Gen1, R-Mobile A1 based on ARM Cortex-A9
which is ARMv6, so it doesn't support
virt extensions at all. Also, there are many other SoCs for mobile
applications in R-Mobile/SH-Mobile series
based on non-ARM SoC. I think it would be worse to assign for the
platform in Xen another name than "RCAR2".
So, I would rename "SHMOBILE" for "RCAR2".

On Wed, Jan 28, 2015 at 6:16 PM, Andrii Anisov
 wrote:
> Hello Ian,
>
> When I discussed with Iurii Konovalenko about this naming during
> review I mentioned following the Linux kernel way.
>
> Shmobile within kernel is arm specific, not the same as arch/sh. In
> the kernel you would find arch/arm/mach-shmobile folder where
> Renesas'es R-CarX SoCs support reside. F.e. R8A7790 what is R-Car H2
> we have on our table. Browsing the kernel configs you will find
> shmobile not rcar as well.
>
> From other hand I do not like rcar2 naming for uart. I would prefer
> the IP block naming - scif.
>
> Andrii Anisov | Team Lead
> GlobalLogic
> Kyiv, 03038, Protasov Business Park, M.Grinchenka, 2/1
> P +38.044.492.9695x3664  M +380505738852  S andriyanisov
> www.globallogic.com
>
> http://www.globallogic.com/email_disclaimer.txt
>
> On Wed, Jan 28, 2015 at 4:16 PM, Ian Campbell  wrote:
>>
>> On Wed, 2015-01-28 at 15:48 +0200, Oleksandr Tyshchenko wrote:
>> > Hi Ian
>> >
>> > On Wed, Jan 28, 2015 at 3:26 PM, Ian Campbell  
>> > wrote:
>> > > On Fri, 2015-01-23 at 17:33 +0200, Oleksandr Tyshchenko wrote:
>> > >> From: Iurii Konovalenko 
>> > >>
>> > >> Signed-off-by: Iurii Konovalenko 
>> > >> Reviewed-by: Julien Grall 
>> > >> ---
>> > >>  xen/arch/arm/platforms/Makefile   |  1 +
>> > >>  xen/arch/arm/platforms/shmobile.c | 71 
>> > >> +++
>> > >>  2 files changed, 72 insertions(+)
>> > >>  create mode 100644 xen/arch/arm/platforms/shmobile.c
>> > >>
>> > >> diff --git a/xen/arch/arm/platforms/Makefile 
>> > >> b/xen/arch/arm/platforms/Makefile
>> > >> index 8f47c16..29e931a 100644
>> > >> --- a/xen/arch/arm/platforms/Makefile
>> > >> +++ b/xen/arch/arm/platforms/Makefile
>> > >> @@ -4,5 +4,6 @@ obj-$(CONFIG_ARM_32) += exynos5.o
>> > >>  obj-$(CONFIG_ARM_32) += midway.o
>> > >>  obj-$(CONFIG_ARM_32) += omap5.o
>> > >>  obj-$(CONFIG_ARM_32) += sunxi.o
>> > >> +obj-$(CONFIG_ARM_32) += shmobile.o
>> > >
>> > > Everything else calls the platform rcar. How does shmobile relate to
>> > > that?
>> > Unfortunately, the author of this patch in vacation now.
>> >
>> > Perhaps Iurii took this name from kernel part 
>> > (Linux/arch/arm/mach-shmobile/...)
>> > where the arch specific things for this platform is located,
>> > especially the SMP and timer support.
>> >
>> > I would rename shmobile to rcar2.
>>
>> I'd prefer us to be consistent one way or another.
>>
>> Is RCAR2 a subset of shmobile or the other way around?
>>
>> http://am.renesas.com/applications/automotive/cis/cis_highend/rcar_h2/index.jsp
>>  doesn't mention shmobile at all.
>>
>> Having determined which is the "parent"/superset my next question would
>> be how similar are the various "children" -- similar enough to be a
>> single platform in Xen, or different enough that we will need multiple
>> platforms, since that would have an impact on which name I think we
>> should pick.
>>
>> (To some extent we can fidge this since we can always git mv stuff, but
>> we should at least give it our best guess up front)
>>
>>
>> Ian.
>>
>>
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel



-- 

Oleksandr Tyshchenko | Embedded Dev
GlobalLogic
w

Re: [Xen-devel] Is: kexec & EFI Was: Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues

[Jan Beulich]

>>> On 30.01.15 at 16:09,  wrote:
> I suppose that we should provide additional kexec hypercall
> function which will return info about RS. kexec-tools should
> load new kernel as usual and add relevant argument to its
> command line. Most things are in place so we should just
> learn kexec-tools to do new things.

There is a reason why the RS table info can't currently be
obtained via a hypercall - Dom0 has nothing to do with it. Plus any
kexec-ed kernel (Linux or other) will, under EFI, want this
information, so a mechanism by which to pass the information to
the secondary kernel without exposing it to entities not having a
need to know would be preferable (albeit I have no idea so far
how that might look like).

Plus, this still doesn't in any way deal with the aspect that was
so far discussed in this thread - SetVirtualAddressMap() being
callable only once.

Jan


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

Re: [Xen-devel] [PATCH v17 13/23] x86/VPMU: Interface for setting PMU mode and flags

[Boris Ostrovsky]

On 01/30/2015 08:31 AM, Jan Beulich wrote:

On 05.01.15 at 22:44,  wrote:

+static long vpmu_unload_next(void *arg)
+{
+struct vcpu *last;
+int ret;
+unsigned int thiscpu = smp_processor_id();
+
+if ( thiscpu != vpmu_next_unload_cpu )
+{
+/* Continuation thread may have been moved due to CPU hot-unplug */
+vpmu_mode = (unsigned long)arg;
+vpmu_first_unload_cpu = VPMU_INVALID_CPU;
+return -EAGAIN;
+}
+
+local_irq_disable(); /* so that last_vcpu doesn't change under us. */
+
+last = this_cpu(last_vcpu);
+if ( last )
+{
+vpmu_unload(vcpu_vpmu(last));
+this_cpu(last_vcpu) = NULL;
+}

So you do this for last_vcpu here, but ...



+static int vpmu_unload_all(unsigned long old_mode)
+{
+int ret = 0;
+
+vpmu_unload(vcpu_vpmu(current));

... for current here, also without clearing this_cpu(last_vcpu). Is
that really correct?


No, I should clear it here as well.




+long do_xenpmu_op(int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
+{
+int ret;
+struct xen_pmu_params pmu_params;
+
+ret = xsm_pmu_op(XSM_OTHER, current->domain, op);
+if ( ret )
+return ret;
+
+switch ( op )
+{
+case XENPMU_mode_set:
+{
+unsigned int old_mode;
+static DEFINE_SPINLOCK(xenpmu_mode_lock);
+
+if ( copy_from_guest(&pmu_params, arg, 1) )
+return -EFAULT;
+
+if ( pmu_params.val & ~(XENPMU_MODE_SELF | XENPMU_MODE_HV) )
+return -EINVAL;
+
+/* 32-bit dom0 can only sample itself. */
+if ( is_pv_32bit_vcpu(current) && (pmu_params.val & XENPMU_MODE_HV) )
+return -EINVAL;
+
+/*
+ * Return error if someone else is in the middle of changing mode ---
+ * this is most likely indication of two system administrators
+ * working against each other.
+ */
+if ( !spin_trylock(&xenpmu_mode_lock) )
+return -EAGAIN;
+if ( vpmu_first_unload_cpu != VPMU_INVALID_CPU )
+{
+spin_unlock(&xenpmu_mode_lock);
+return -EAGAIN;
+}
+
+old_mode = vpmu_mode;
+vpmu_mode = pmu_params.val;
+
+if ( vpmu_mode == XENPMU_MODE_OFF )
+{
+/* Make sure all (non-dom0) VCPUs have unloaded their VPMUs. */
+ret = vpmu_unload_all(old_mode);
+if ( ret )
+vpmu_mode = old_mode;
+}
+
+spin_unlock(&xenpmu_mode_lock);
+
+break;
+}
+
+case XENPMU_mode_get:
+memset(&pmu_params, 0, sizeof(pmu_params));
+pmu_params.val = vpmu_mode;
+
+pmu_params.version.maj = XENPMU_VER_MAJ;
+pmu_params.version.min = XENPMU_VER_MIN;
+
+if ( copy_to_guest(arg, &pmu_params, 1) )
+return -EFAULT;
+break;
+
+case XENPMU_feature_set:
+if ( copy_from_guest(&pmu_params, arg, 1) )
+return -EFAULT;
+
+if ( pmu_params.val & ~XENPMU_FEATURE_INTEL_BTS )
+return -EINVAL;
+
+vpmu_features = pmu_params.val;
+break;
+
+case XENPMU_feature_get:
+pmu_params.val = vpmu_features;
+if ( copy_field_to_guest(arg, &pmu_params, val) )
+return -EFAULT;
+break;
+
+default:
+ret = -EINVAL;
+}
+
+return ret;
+}

Throughout this function, the "pad" field isn't being checked to be
zero (and XENPMU_feature_get also doesn't clear it, but that seems
secondary, at least as long as it's being declared "IN" only). As I'm
sure I said before - we ought to do this in order to be able to assign
meaning to the field later on. Perhaps it would even better be
renamed to e.g. "mbz".


If we decide to start using this filed then presumably we will have to 
bump interface version. If pad field becomes something else it will only 
be considered when minor version is > 1. (And I should probably add 
major version check.)


-boris

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

Re: [Xen-devel] Is: kexec & EFI Was: Re: EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues

[Daniel Kiper]

On Fri, Jan 30, 2015 at 02:57:32PM +, David Vrabel wrote:
> On 30/01/15 14:52, Konrad Rzeszutek Wilk wrote:
> > On Fri, Jan 30, 2015 at 02:40:46PM +, David Vrabel wrote:
> >> On 30/01/15 14:17, Konrad Rzeszutek Wilk wrote:
> >>>
> >>>  kexec is OS agnostic?
> >>
> >> Yes.
> >>
> >> Extra information to be passed to (e.g., a Linux kernel being kexec'd)
> >> can be supplied in an additional segment and marshalled into a suitable
> >> format/location for the exec'd kernel by purgatory (or similar).
> >>
> >> There shouldn't be a need to extend the hypervisor ABI for this.
> >
> > How are you planning to make kexec work under EFI?
>
> I don't know at this time.

I suppose that we should provide additional kexec hypercall
function which will return info about RS. kexec-tools should
load new kernel as usual and add relevant argument to its
command line. Most things are in place so we should just
learn kexec-tools to do new things.

Daniel

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

Re: [Xen-devel] [PATCH linux-2.6.18] support suspend/resume in pvscsi drivers

[Juergen Gross]

On 01/30/2015 04:05 PM, Jan Beulich wrote:

On 30.01.15 at 15:54,  wrote:

On 01/30/2015 03:46 PM, Jan Beulich wrote:

On 30.01.15 at 14:52, <"jgr...@suse.com".non-mime.internet> wrote:

@@ -231,8 +242,23 @@ static int scsifront_cmd_done(struct vsc
return more_to_do;
   }

+void scsifront_finish_all(struct vscsifrnt_info *info)
+{
+   unsigned i;
+   struct vscsiif_response resp;

+   scsifront_ring_drain(info);


Shouldn't you at least issue some kind of warning when this returns
non-zero?


If a warning should be issued, then this should be done after the
following loop in case of at least one request terminated there.

I'm really not sure, whether a warning is required here. If you like,
I can add one.


I'm not sure, I'm merely asking because I saw the function return
value being ignored here.


I think it can be 0 only. We are handling resume, so the ring which is
being drained will no longer be filled by the backend.

Juergen


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

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

[xen . org]

flight 33958 ovmf real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33958/

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-sedf  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-pcipt-intel  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-winxpsp3   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-win7-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a

version targeted for testing:
 ovmf 49a228ca6980b197bb854dc88c909d712959cb47
baseline version:
 ovmf 447d264115c476142f884af0be287622cd244423


People who touched revisions under test:
  "Gao, Liming" 
  "Long, Qin" 
  "Yao, Jiewen" 
  Aaron Pop 
  Abner Chang 
  Alex Williamson 
  Anderw Fish 
  Andrew Fish 
  Anthony PERARD 
  Ard Biesheuvel 
  Ari Zigler 
  Brendan Jackman 
  Bruce Cran 
  Cecil Sheng 
  Chao Zhang 
  Chao, Zhang 
  Chen Fan 
  Chris Phillips 
  Chris Ruffin 
  Cinnamon Shia 
  Daryl McDaniel  
  Daryl McDaniel 
  daryl.mcdaniel 
  daryl.mcdan...@intel.com
  darylm503 
  David Wei 
  David Woodhouse 
  Deric Cole 
  Dong Eric 
  Dong Guo 
  Dong, Guo 
  Elvin Li 
  Eric Dong 
  Eugene Cohen 
  Feng Tian 
  Feng, Bob C 
  Fu Siyuan 
  Fu, Siyuan 
  Gabriel Somlo 
  Gao, Liming 
  Gao, Liming liming.gao 
  Gao, Liming liming@intel.com
  Garrett Kirkendall 
  Gary Lin 
  Grzegorz Milos 
  Hao Wu 
  Harry Liebel 
  Hess Chen 
  Hot Tian 
  isakov-sl 
  isakov...@bk.ru
  Jaben Carsey 
  jcarsey 
  jcarsey 
  Jeff Bobzin (jeff.bobzin 
  Jeff Bobzin (