From: Oleksandr Grytsov
Signed-off-by: Oleksandr Grytsov
Acked-by: Wei Liu
---
docs/man/xl.cfg.pod.5.in | 49
docs/man/xl.pod.1.in | 42 +
2 files changed, 91 insertions(+)
diff --git a/docs/man/xl.cf
From: Oleksandr Grytsov
Add libxl__device_add to simple write XenStore device conifg
and libxl__device_add_async to update domain configuration
and write XenStore device config asynchroniously.
Almost all devices have similar libxl__device__add function.
This generic functions implement same
From: Oleksandr Grytsov
Signed-off-by: Oleksandr Grytsov
Acked-by: Wei Liu
---
tools/libxl/libxl_console.c | 69
tools/libxl/libxl_create.c | 3 +-
tools/libxl/libxl_dm.c | 6 ++--
tools/libxl/libxl_internal.h | 6 +---
4 files changed,
From: Oleksandr Grytsov
Signed-off-by: Oleksandr Grytsov
Acked-by: Wei Liu
---
tools/libxl/libxl.h | 12 +--
tools/libxl/libxl_vtpm.c | 221 +--
tools/xl/xl_vtpm.c | 3 +-
3 files changed, 69 insertions(+), 167 deletions(-)
diff --git
From: Oleksandr Grytsov
Signed-off-by: Oleksandr Grytsov
---
tools/libxl/Makefile | 2 +-
tools/libxl/libxl.h | 24 +++
tools/libxl/libxl_create.c | 1 +
tools/libxl/libxl_internal.h | 1 +
tools/libxl/libxl_types.idl | 36
From: Oleksandr Grytsov
Changes since V4:
* Use new LIBXL_DEFINE_UPDATE_DEVID for all device types;
* Align device setdefault function parameters with set_default
device type callback;
* revert libxl_mac_to_device_nic to existing implementation;
* previous comments are applied.
Patch
flight 113293 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113293/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf 4 host-insta
On 11/09/17 18:01, George Dunlap wrote:
> +### x86/PV
> +
> +Status: Supported
> +
> +Traditional Xen Project PV guest
What's a "Xen Project" PV guest? Just Xen here.
Also, a perhaps a statement of "No hardware requirements" ?
> +### x86/RAM
> +
> +Limit, x86: 16TiB
> +Limit, ARM32:
On 11/09/17 17:39, Stefano Stabellini wrote:
On Mon, 11 Sep 2017, Julien Grall wrote:
On 07/09/17 22:54, Stefano Stabellini wrote:
On Thu, 31 Aug 2017, George Dunlap wrote:
+### Direct-boot kernel image format
+
+Supported, x86: bzImage
+Supported, ARM32: zImage
+Supported, ARM64
On Mon, 11 Sep 2017, Wei Liu wrote:
> Signed-off-by: Wei Liu
Reviewed-by: Stefano Stabellini
> ---
> Cc: Razvan Cojocaru
> Cc: Tamas K Lengyel
> Cc: Stefano Stabellini
> Cc: Julien Grall
> Cc: George Dunlap
> Cc: Jan Beulich
> Cc: Andrew Cooper
> ---
> xen/arch/arm/mem_access.c|
CC'ing xen-devel, and the Xen tools and x86 maintainers.
On Mon, 11 Sep 2017, Igor Mammedov wrote:
> On Mon, 11 Sep 2017 12:41:47 +0800
> Haozhong Zhang wrote:
>
> > This is the QEMU part patches that works with the associated Xen
> > patches to enable vNVDIMM support for Xen HVM domains. Xen re
On Sat, 9 Sep 2017, Rajiv Ranganath wrote:
> On Thu, Sep 07 2017 at 12:29:54 AM, Stefano Stabellini
> wrote:
>
> [...]
>
> >> +QEMU_BRANCH = 'master'
> >
> > I am not sure we want to checkout always the latest QEMU. It is a
> > running target. It makes sense to use one of the latest releases
>
On Sat, 9 Sep 2017, Rajiv Ranganath wrote:
> On Thu, Sep 07 2017 at 12:44:16 AM, Stefano Stabellini
> wrote:
>
> [...]
>
> >> +[root@localhost ~]# ls /opt
> >> +qemu-unstable stage1-xen xen-unstable xen-unstable-runit
> >> +```
> >> +
> >> +This will extract all the build artifacts into `/op
On Sep 11, 2017, at 10:16, George Dunlap wrote:
>
>>> +### vTPM Support
>>> +
>>> +Status: Supported, x86 only
>>
>> This should probably be x86/vTPM. TPM, the way we are discussing it, is
>> an x86-only implementation. ARM-based alternatives are not called TPM
>> AFAIK.
>
> Someone said th
On Sat, 9 Sep 2017, Rajiv Ranganath wrote:
> On Thu, Sep 07 2017 at 12:10:21 AM, Stefano Stabellini
> wrote:
>
> [...]
>
> > The series is much better now thank you. One question: why did you write
> > your own init scripts rather than reusing xencommons (with the caveat
> > that you would have
flight 113321 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113321/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 113313 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113313/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 113143
build-amd64-xsm
On Mon, 11 Sep 2017, Rich Persaud wrote:
> On Sep 11, 2017, at 10:16, George Dunlap wrote:
>
> +### vTPM Support
>
> +
>
> + Status: Supported, x86 only
>
>
> This should probably be x86/vTPM. TPM, the way we are discussing
flight 113297 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113297/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-xsm 12 guest-start fail REGR. vs. 113262
test-amd64-amd64-xl-
flight 113301 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113301/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd broken
test-armhf
From: Manish Jaggi
The set is divided into two patches. First one calculates the size of IORT
while second one writes the IORT table itself.
patch1: estimates size of hardware domain IORT table by parsing all
the pcirc nodes and their idmaps, and thereby calculating size by
removing smmu nodes.
From: Manish Jaggi
This patch writes hardware domain's IORT table. The steps are:
a. First ITS group nodes are written and their offsets are saved
along with the respective offsets from the firmware table.
This is required when smmu node is hidden and smmu node still points
to the old output_refe
From: Manish Jaggi
This patch estimates size of hardware domain IORT table by parsing all
the pcirc nodes and their idmaps, and thereby calculating size by
removing smmu nodes.
Hardware domain IORT table will have only ITS and PCIRC nodes, and PCIRC
nodes' idmap will have output refrences to ITS
On 11/09/2017 21:20, Stefano Stabellini wrote:
> On Sat, 9 Sep 2017, Rajiv Ranganath wrote:
>> On Thu, Sep 07 2017 at 12:10:21 AM, Stefano Stabellini
>> wrote:
>>
>> [...]
>>
>>> The series is much better now thank you. One question: why did you write
>>> your own init scripts rather than reusing
branch xen-unstable
xenbranch xen-unstable
job build-i386-xsm
testid xen-build
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced
flight 113302 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113302/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 113179
test-armhf-armhf-xl-rtds 16 gue
Hey,
I've only been able to reproduce this on ARM64 (trying right now ARM32
as well), and not on x86.
If I compile Xen without CONFIG_SCRUB_DEBUG it works great. But if
enable it and try to load a livepatch it blows up in page_alloc.c:738
This is with origin/staging (d0291f3391)
The test-case (
On Tue, 1 Aug 2017, Juergen Gross wrote:
> +if (sock->sk == NULL)
> +return 0;
> +
> +map = (struct sock_mapping *) READ_ONCE(sock->sk->sk_send_head);
> +if (map == NULL)
> +return 0;
> +
> +spin
On Mon, Sep 11, 2017 at 03:01:15AM -0600, Jan Beulich wrote:
> >>> On 09.09.17 at 14:05, wrote:
> > On Fri, Sep 08, 2017 at 03:30:07AM -0600, Jan Beulich wrote:
> >> >>> On 07.09.17 at 19:36, wrote:
> >> > On Wed, Aug 02, 2017 at 03:20:05AM -0600, Jan Beulich wrote:
> >> >> >>> Konrad Rzeszutek W
flight 11 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/11/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 113143
build-amd64-xsm
This way we can load livepatches with symbol names that
are the same as long as they are local ('static').
The use case here is to replace an existing livepatch
with a newer one - and one which has the same local symbols.
Without this patch we get:
livepatch.c:819: livepatch: xen_local_symbols: d
Without this patch on x86 we would get a DOUBLE FAULT
as the virt_to_mfn does not lookup virtual addresses
that are in vmap region. This means that the livepatch_vmap.funcs
would point to an incorrect MFN (with either garbage or all
zeros).
We only use the livepatch_vmap.funcs to save the old cont
With this change we can use _do_page_walk() to implement
arch_livepatch_lookup_mfn() which can be used to find out
vmap virtual addresses (as under x86 virt_to_mfn won't work
for vmap, but it does for arm!).
Signed-off-by: Blaise Boscaccy
Signed-off-by: Vegard Nossum
Signed-off-by: Konrad Rzeszu
Instead of being writable (.data). This mimics the behavior of what
livepatch-build-tools do.
Other approaches such as 'struct const livepatch_funcs' still result
in the WA section attributes.
Signed-off-by: Konrad Rzeszutek Wilk
---
xen/test/livepatch/Makefile | 4
1 file changed, 4 inser
By default when using objcopy we lose the alignment when we copy it from
xen-syms -
with the result that alignment (on ARM32 for example) can be 1:
[Nr] Name TypeAddr OffSize ES Flg Lk Inf Al
..
[ 6] .livepatch.depend PROGBITS 93 24 0
This is very similar to 137c59b9ff3f7a214f03b52d9c00a0a02374af1f
"bug/x86/arm: Align bug_frames sections."
On ARM and on x86 the C and assembler macros don't include
any alignment information - hence they end up being the default
byte granularity.
On ARM32 it is paramount that the alignment is wo
Under ARM64 the vmap calls were all done with IRQs disabled which
didn't trip the spinlock debug check (as seen on x86):
livepatch.c:1330: livepatch: xen_hello_world: timeout is 3000ns
livepatch.c:1437: livepatch: xen_hello_world: CPU3 - IPIing the other 3 CPUs
Applying xen_hello_world... (XEN
Patch titled "livepatch/arm[32,64]: Modify livepatch_funcs" added
the infrastructure on ARM [32,64] to use vmap as way to
map read-only regions. On x86 we use a global register.
But there is nothing wrong with using on x86 the same method
as on ARM[32,64] - which is exactly what this patch does.
This surfaced due to "xen/livepatch/x86/arm32: Force
.livepatch.depends section to be uint32_t aligned." which switched
to a different way of including the build-id.
Each livepatch ends with a global:
30: 1 OBJECT GLOBAL HIDDEN 7 note_depends
which will cause collision when
Hey,
As I was trying to port livepatch-build-tools.git to work under ARM32 and ARM64
(still ongoing, if somebody wants to help/take over would appreciate it)
I found some inconsistencies compared to the x86 and test-cases:
- The .livepatch.funcs in the test-cases are in RW section but the
livepa
The arch_livepatch_revert is very similar between the platforms.
Lets unify it as much as possible.
Signed-off-by: Konrad Rzeszutek Wilk
---
xen/arch/arm/livepatch.c| 10 +-
xen/arch/x86/livepatch.c| 10 ++
xen/common/livepatch.c | 14 +-
xen/include/xen/
If the .bug.frames.X or .livepatch.funcs sizes are different
than what the hypervisor expects - we fail the payload. To help
in diagnosing this include the expected and the payload
sizes.
Also make it more natural by having "Multiples" in the warning.
Also fix one case where we would fail if the
This was found when porting livepatch-build-tools to ARM64/32.
When livepatch-build-tools are built (and test-case thanks to:
livepatch/tests: Make sure all .livepatch.funcs sections are read-only)
the .livepatch.funcs are in read-only section.
However the hypervisor uses the 'opaque' for its own
If the livepatch has only .rodata sections then it is OK to also
apply/revert/apply the livepatch without having to worry about the
unforseen consequences.
See commit 98b728a7b235c67e210f67f789db5d9eb38ca00c
"livepatch: Disallow applying after an revert" for details.
Signed-off-by: Konrad Rzeszut
The ARM 32&64 ELF specification says "sections containing ARM
code must be at least 32-bit aligned." This patch adds the
check for that. We also make sure that this check is done
when doing relocations for the types that are considered
ARM code. However we don't have to check for all as we only
imp
From: Ross Lagerwall
See docs/features/livepatch.pandoc for the details.
Reviewed-by: Jan Beulich
Signed-off-by: Ross Lagerwall
Signed-off-by: Konrad Rzeszutek Wilk
--
v2:
- Moved it into a feature document.
- Clarified a few bits and pieces based on feedback.
v3:
- default X86
- added J
To exercise the local/global visibility.
With "livepatch: Add local and global symbol resolution."
we can load both xen_hello_world and xen_local_symbols
without having to worry about:
-bash-4.1# xen-livepatch load xen_hello_world.livepatch
Uploading xen_hello_world.livepatch... completed
Applyin
The ELF specification mentions nothing about the sh_size being
modulo the sh_addralign. Only that sh_addr MUST be aligned on
sh_addralign if sh_addralign is not zero or one.
We on loading did not take this in-to account so this patch adds
a check on the ELF file as it is being parsed.
Signed-off-
On 09/11/2017 07:55 PM, Konrad Rzeszutek Wilk wrote:
Hey,
I've only been able to reproduce this on ARM64 (trying right now ARM32
as well), and not on x86.
If I compile Xen without CONFIG_SCRUB_DEBUG it works great. But if
enable it and try to load a livepatch it blows up in page_alloc.c:738
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-qemuu-rhel6hvm-intel
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-tradit
On 09/11/17 11:52 -0700, Stefano Stabellini wrote:
> CC'ing xen-devel, and the Xen tools and x86 maintainers.
>
> On Mon, 11 Sep 2017, Igor Mammedov wrote:
> > On Mon, 11 Sep 2017 12:41:47 +0800
> > Haozhong Zhang wrote:
> >
> > > This is the QEMU part patches that works with the associated Xen
On 11/09/17 19:01, George Dunlap wrote:
> Add a machine-readable file to describe what features are in what
> state of being 'supported', as well as information about how long this
> release will be supported, and so on.
>
> The document should be formatted using "semantic newlines" [1], to make
>
flight 113323 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113323/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken in 113293
build-armhf4 ho
101 - 153 of 153 matches
Mail list logo
