Re: [Xen-devel] [PATCH RFC v2] Add SUPPORT.md

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

Re: [Xen-devel] [RFC QEMU PATCH v3 00/10] Implement vNVDIMM for Xen HVM guest

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

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-qemuu-rhel6hvm-intel

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

Re: [Xen-devel] CONFIG_SCRUB_DEBUG=y + arm64 + livepatch = Xen BUG at page_alloc.c:738

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

[Xen-devel] [PATCH v3 10/17] livepatch: Declare live patching as a supported feature

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

[Xen-devel] [PATCH v3 17/17] livepatch: Add xen_local_symbols test-case

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

[Xen-devel] [PATCH v3 02/17] livepatch: Tighten alignment checks.

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.

[Xen-devel] [PATCH v3 07/17] livepatch/arm/x86: Strip note_depends symbol from test-cases.

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

[Xen-devel] [PATCH v3] Livepatching patch set for 4.10

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

[Xen-devel] [PATCH v3 03/17] livepatch: Include sizes when an mismatch occurs

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

[Xen-devel] [PATCH v3 09/17] livepatch/arm[32, 64]: Modify livepatch_funcs

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

[Xen-devel] [PATCH v3 13/17] livepatch: Expand spin_debug_disable in [apply|revert]_payload

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-devel] [PATCH v3 11/17] livepatch/x86/arm[32, 64]: Use common vmap code for applying.

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.

[Xen-devel] [PATCH v3 12/17] livepatch/x86/arm[32, 64]: Unify arch_livepatch_revert

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-devel] [PATCH v3 01/17] livepatch: Expand check for safe_for_reapply if livepatch has only .rodata.

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

[Xen-devel] [PATCH v3 04/17] xen/livepatch/ARM32: Don't load and crash on livepatches loaded with wrong text alignment.

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

[Xen-devel] [PATCH v3 08/17] livepatch/tests: Make sure all .livepatch.funcs sections are read-only

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

[Xen-devel] [PATCH v3 06/17] xen/livepatch/x86/arm32: Force .livepatch.depends section to be uint32_t aligned.

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

[Xen-devel] [PATCH v3 05/17] alternative/x86/arm32: Align altinstructions (and altinstr_replacement) sections.

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

[Xen-devel] [PATCH v3 16/17] livepatch: Add local and global symbol resolution.

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:

[Xen-devel] [PATCH v3 15/17] livepatch/x86/arm: Utilize the arch_livepatch_lookup_mfn

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

[Xen-devel] [PATCH v3 14/17] livepatch/x86/arm: arch/x86/mm: generalize do_page_walk() and implement arch_livepatch_lookup_mfn

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

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

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

Re: [Xen-devel] [PATCH v2 3/5] xen/livepatch/ARM32: Don't load and crash on livepatches loaded with wrong alignment.

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

Re: [Xen-devel] [PATCH v2 11/13] xen/pvcalls: implement release command

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; > + > +

[Xen-devel] CONFIG_SCRUB_DEBUG=y + arm64 + livepatch = Xen BUG at page_alloc.c:738

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

[Xen-devel] [qemu-mainline test] 113302: tolerable FAIL - PUSHED

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

[Xen-devel] [ovmf bisection] complete build-i386-xsm

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

Re: [Xen-devel] [stage1-xen PATCH v1 06/10] build/fedora: Add `xen-unstable-runit/*` scripts

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

[Xen-devel] [PATCH 1/2] ARM: ACPI: IORT: Estimate the size of hardware domain IORT table

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

[Xen-devel] [PATCH v2 0/2] ARM: ACPI: IORT: Hide SMMU from hardware domain's IORT table

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

[Xen-devel] [PATCH 2/2] ARM: ACPI: IORT: Write Hardware domain's IORT table

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

[Xen-devel] [qemu-upstream-unstable test] 113301: trouble: broken/fail/pass

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

[Xen-devel] [linux-next test] 113297: regressions - FAIL

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

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

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,

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

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

[Xen-devel] [xen-unstable-smoke test] 113321: tolerable all pass - PUSHED

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

Re: [Xen-devel] [stage1-xen PATCH v1 06/10] build/fedora: Add `xen-unstable-runit/*` scripts

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

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

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 >>

Re: [Xen-devel] [stage1-xen PATCH v1 09/10] build/fedora: Add `RUNNING_STAGE1_XEN.md`

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

Re: [Xen-devel] [stage1-xen PATCH v1 04/10] build/fedora: Add `run` and `components/*` scripts

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

Re: [Xen-devel] [RFC QEMU PATCH v3 00/10] Implement vNVDIMM for Xen HVM guest

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

Re: [Xen-devel] [PATCH] mem_access: switch to plain bool

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:

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

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,

Re: [Xen-devel] [PATCH RFC v2] Add SUPPORT.md

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,

[Xen-devel] [linux-linus test] 113293: regressions - trouble: blocked/broken/fail/pass

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

[Xen-devel] [PATCH v5 03/12] libxl: add vdispl device

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

[Xen-devel] [PATCH v5 00/12] libxl: add PV display device driver interface

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

[Xen-devel] [PATCH v5 11/12] libxl: change vtpm to use generec add function

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

[Xen-devel] [PATCH v5 05/12] docs: add PV display driver information

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

[Xen-devel] [PATCH v5 01/12] libxl: add generic function to add device

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

[Xen-devel] [PATCH v5 04/12] xl: add PV display device commands

From: Oleksandr Grytsov Add commands: vdispl-attach, vdispl-list, vdispl-detach and domain config vdispl parser Signed-off-by: Oleksandr Grytsov Acked-by: Wei Liu --- tools/xl/Makefile | 1 + tools/xl/xl.h

[Xen-devel] [PATCH v5 07/12] libxl: change vkb to use generec add function

From: Oleksandr Grytsov Signed-off-by: Oleksandr Grytsov --- tools/libxl/libxl_console.c | 74 +++- tools/libxl/libxl_create.c | 5 +-- tools/libxl/libxl_dm.c | 6 ++--

[Xen-devel] [PATCH v5 10/12] libxl: change nic to use generec add function

From: Oleksandr Grytsov Signed-off-by: Oleksandr Grytsov --- tools/libxl/libxl.h | 9 +- tools/libxl/libxl_checkpoint_device.c | 9 +- tools/libxl/libxl_colo_save.c | 4 +- tools/libxl/libxl_dm.c

[Xen-devel] [PATCH v5 08/12] libxl: change vfb to use generec add function

From: Oleksandr Grytsov Signed-off-by: Oleksandr Grytsov Acked-by: Wei Liu --- tools/libxl/libxl_console.c | 69 tools/libxl/libxl_create.c | 3 +-

[Xen-devel] [PATCH v5 09/12] libxl: change disk to use generic getting list functions

From: Oleksandr Grytsov Signed-off-by: Oleksandr Grytsov --- tools/libxl/libxl.h | 9 +++- tools/libxl/libxl_checkpoint_device.c | 7 ++- tools/libxl/libxl_create.c| 4 +- tools/libxl/libxl_disk.c

[Xen-devel] [PATCH v5 02/12] libxl: add generic functions to get and free device list

From: Oleksandr Grytsov Add libxl__device_list and libxl__device_list_free functions to handle device list using the device framework. Signed-off-by: Oleksandr Grytsov --- tools/libxl/libxl_device.c | 61

[Xen-devel] [PATCH v5 06/12] libxl: change p9 to use generec add function

From: Oleksandr Grytsov Signed-off-by: Oleksandr Grytsov --- tools/libxl/libxl_9pfs.c | 59 tools/libxl/libxl_create.c | 2 +- tools/libxl/libxl_internal.h | 7 +- 3 files changed,

[Xen-devel] [PATCH v5 12/12] libxl: remove unneeded DEVICE_ADD macro

From: Oleksandr Grytsov Signed-off-by: Oleksandr Grytsov Acked-by: Wei Liu --- tools/libxl/libxl_device.c | 6 ++--- tools/libxl/libxl_disk.c | 5 +++-- tools/libxl/libxl_internal.h | 52

[Xen-devel] [PATCH RFC v2] Add SUPPORT.md

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 changes easier. Signed-off-by: Ian Jackson

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

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: Image [XXX -

Re: [Xen-devel] [PATCH 26/27 v8] xen/arm: vpl011: Correct the logic for asserting/de-asserting SBSA UART TX interrupt

Hi Andre, >> diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c >> index 56d9cbe..1e72fca 100644 >> --- a/xen/arch/arm/vpl011.c >> +++ b/xen/arch/arm/vpl011.c >> @@ -152,12 +152,20 @@ static void vpl011_write_data(struct domain *d, >> uint8_t data) >> else >>

Re: [Xen-devel] [RFC XEN PATCH v3 12/39] tools/xen-ndctl: add NVDIMM management util 'xen-ndctl'

On Sun, Sep 10, 2017 at 10:39 PM, Haozhong Zhang wrote: > On 09/10/17 22:10 -0700, Dan Williams wrote: >> On Sun, Sep 10, 2017 at 9:37 PM, Haozhong Zhang >> wrote: >> > The kernel NVDIMM driver and the traditional NVDIMM management >> >

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

On 09/11/2017 05:16 PM, Julien Grall wrote: > > > On 11/09/17 15:16, George Dunlap wrote: >> On 09/07/2017 10:54 PM, Stefano Stabellini wrote: >>> On Thu, 31 Aug 2017, George Dunlap wrote: +### Direct-boot kernel image format + +    Supported, x86: bzImage +    Supported,

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

On 11/09/17 17:15, George Dunlap wrote: On 09/11/2017 04:54 PM, Julien Grall wrote: Hi, Sorry I missed e-mail. It seems I was not CCed on it. Sorry -- already had a pretty large CC list. I'll add you for the next one. +### ARM/SMMU + +Status: Supported, with caveats + +Only ARM

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

On 11/09/17 15:16, George Dunlap wrote: On 09/07/2017 10:54 PM, Stefano Stabellini wrote: On Thu, 31 Aug 2017, George Dunlap wrote: +### Direct-boot kernel image format + +Supported, x86: bzImage +Supported, ARM32: zImage +Supported, ARM64: Image [XXX - Not sure if this is

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

On 09/11/2017 04:54 PM, Julien Grall wrote: > Hi, > > Sorry I missed e-mail. It seems I was not CCed on it. Sorry -- already had a pretty large CC list. I'll add you for the next one. +### ARM/SMMU + +    Status: Supported, with caveats + +Only ARM SMMU hardware is

Re: [Xen-devel] Xen 4.8.2 released

Fixed Apologies Lars On 11/09/2017, 03:26, "Marek Marczykowski-Górecki" wrote: On Mon, Sep 11, 2017 at 03:06:48AM -0600, Jan Beulich wrote: > >>> On 10.09.17 at 01:53, wrote: > > On Wed, Sep 06, 2017 at 08:42:33AM

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

On 09/11/2017 05:00 PM, 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: Image [XXX -

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

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: Image [XXX - Not sure if this is correct] On ARM64 it's called Image.gz. That's

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

Hi, Sorry I missed e-mail. It seems I was not CCed on it. On 07/09/17 22:36, Stefano Stabellini wrote: On Thu, 31 Aug 2017, Roger Pau Monne wrote: +### ARM/Non-PCI device passthrough + +Status: Supported I guess non-pci devices on ARM also use the IOMMU? (SMMU) Yes, they do. +###

Re: [Xen-devel] [PATCH v10 2/3] x86emul: New return code for unimplemented instruction

On Jo, 2017-09-07 at 09:08 -0600, Jan Beulich wrote: > > > > > > > > > > > > > On 07.09.17 at 16:26, wrote: > > After discussing with Andrew I'm willing to agree with the changes > > you do here, with one extra requirement: At least on non-debug > > builds

Re: [Xen-devel] [PATCH] hvmloader: cast to avoid potential overflow in shadow_gs_test

>>> On 11.09.17 at 17:01, wrote: > On Mon, Sep 11, 2017 at 08:55:53AM -0600, Jan Beulich wrote: >> >>> On 11.09.17 at 16:07, wrote: >> > e2fc5bb5cb4 ("hvmloader: dynamically determine scratch memory range >> > for tests") makes the test dependent on

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

On Mon, Sep 11, 2017 at 04:07:08PM +0100, George Dunlap wrote: > On 09/11/2017 04:02 PM, Anthony PERARD wrote: > > On Mon, Sep 11, 2017 at 03:16:13PM +0100, George Dunlap wrote: > >> On 09/07/2017 10:54 PM, Stefano Stabellini wrote: > >>> On Thu, 31 Aug 2017, George Dunlap wrote: > +###

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

On 09/11/2017 04:02 PM, Anthony PERARD wrote: > On Mon, Sep 11, 2017 at 03:16:13PM +0100, George Dunlap wrote: >> On 09/07/2017 10:54 PM, Stefano Stabellini wrote: >>> On Thu, 31 Aug 2017, George Dunlap wrote: +### Netback + +Status, Linux (netback): Supported +Status,

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

On Mon, Sep 11, 2017 at 03:16:13PM +0100, George Dunlap wrote: > On 09/07/2017 10:54 PM, Stefano Stabellini wrote: > > On Thu, 31 Aug 2017, George Dunlap wrote: > >> +### Netback > >> + > >> +Status, Linux (netback): Supported > >> +Status, FreeBSD (netback): Supported > >> +Status,

Re: [Xen-devel] [PATCH] hvmloader: cast to avoid potential overflow in shadow_gs_test

On Mon, Sep 11, 2017 at 08:55:53AM -0600, Jan Beulich wrote: > >>> On 11.09.17 at 16:07, wrote: > > e2fc5bb5cb4 ("hvmloader: dynamically determine scratch memory range > > for tests") makes the test dependent on _end. Coverity reported that > > the shift might overflow and

Re: [Xen-devel] [PATCH] hvmloader: cast to avoid potential overflow in shadow_gs_test

>>> On 11.09.17 at 16:07, wrote: > e2fc5bb5cb4 ("hvmloader: dynamically determine scratch memory range > for tests") makes the test dependent on _end. Coverity reported that > the shift might overflow and suggested we cast i to uint64_t. > > Coverity-ID: 1417660 > >

Re: [Xen-devel] [PATCH] mem_access: switch to plain bool

On 11.09.2017 14:16, Wei Liu wrote: Signed-off-by: Wei Liu --- Cc: Razvan Cojocaru Cc: Tamas K Lengyel Cc: Stefano Stabellini Cc: Julien Grall Cc: George Dunlap

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md\

On 09/07/2017 03:56 PM, Wei Liu wrote: > On Thu, Sep 07, 2017 at 02:52:49PM +0100, George Dunlap wrote: >> On 09/01/2017 04:00 PM, Wei Liu wrote: >>> On Thu, Aug 31, 2017 at 11:27:19AM +0100, George Dunlap wrote: +### Direct-boot kernel image format + +Supported, x86: bzImage

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

On 09/07/2017 10:54 PM, Stefano Stabellini wrote: > On Thu, 31 Aug 2017, George Dunlap wrote: >> +### Direct-boot kernel image format >> + >> +Supported, x86: bzImage >> +Supported, ARM32: zImage >> +Supported, ARM64: Image [XXX - Not sure if this is correct] > > On ARM64 it's called

Re: [Xen-devel] [RFC QEMU PATCH v3 00/10] Implement vNVDIMM for Xen HVM guest

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 relies on > QEMU to build guest NFIT and NVDIMM namespace devices, and allocate >

[Xen-devel] [PATCH] hvmloader: cast to avoid potential overflow in shadow_gs_test

e2fc5bb5cb4 ("hvmloader: dynamically determine scratch memory range for tests") makes the test dependent on _end. Coverity reported that the shift might overflow and suggested we cast i to uint64_t. Coverity-ID: 1417660 Signed-off-by: Wei Liu --- Cc: Jan Beulich

Re: [Xen-devel] Faulting linear address??

On Mon, 2017-09-11 at 02:00 +0900, Minjun Hong wrote: > I made the new Xen4.5 binary with 'debug=y' option that I modified > and install it. > Then, there was a kernel panic caused by the debugging code triggered > by 'debug=y' during booting process(of dom0): > Once again, can you show us here

Re: [Xen-devel] [PATCH v2 2/4] x86/hvm: Rename enum hvm_copy_result to hvm_translation_result

On 11/09/17 14:27, George Dunlap wrote: > On 09/08/2017 05:05 PM, Alexandru Isaila wrote: >> diff --git a/xen/include/asm-x86/hvm/support.h >> b/xen/include/asm-x86/hvm/support.h >> index b18dbb6..e3b035d 100644 >> --- a/xen/include/asm-x86/hvm/support.h >> +++ b/xen/include/asm-x86/hvm/support.h

Re: [Xen-devel] [PATCH v2 2/4] x86/hvm: Rename enum hvm_copy_result to hvm_translation_result

On Mon, Sep 11, 2017 at 02:27:34PM +0100, George Dunlap wrote: > On 09/08/2017 05:05 PM, Alexandru Isaila wrote: > > diff --git a/xen/include/asm-x86/hvm/support.h > > b/xen/include/asm-x86/hvm/support.h > > index b18dbb6..e3b035d 100644 > > --- a/xen/include/asm-x86/hvm/support.h > > +++

Re: [Xen-devel] [PATCH v2 2/4] x86/hvm: Rename enum hvm_copy_result to hvm_translation_result

On 09/08/2017 05:05 PM, Alexandru Isaila wrote: > diff --git a/xen/include/asm-x86/hvm/support.h > b/xen/include/asm-x86/hvm/support.h > index b18dbb6..e3b035d 100644 > --- a/xen/include/asm-x86/hvm/support.h > +++ b/xen/include/asm-x86/hvm/support.h > @@ -53,23 +53,23 @@ extern unsigned int

Re: [Xen-devel] [PATCH v5 12/12] x86/hvm/ioreq: add a new mappable resource type...

On Fri, Sep 08, 2017 at 04:21:37PM +0100, Paul Durrant wrote: > +static int hvm_ioreq_server_alloc_pages(struct hvm_ioreq_server *s) > +{ > +int rc = -ENOMEM; > + Pointless initialisation. With this fixed: Reviewed-by: Wei Liu

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

flight 72091 distros-debian-sid real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72091/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-armhf-sid-netboot-pygrub 1 build-check(1)blocked n/a build-arm64-pvops

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

flight 113307 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/113307/ 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

Re: [Xen-devel] [PATCH v5 11/12] x86/hvm/ioreq: defer mapping gfns until they are actually requsted

On Fri, Sep 08, 2017 at 04:21:36PM +0100, Paul Durrant wrote: > A subsequent patch will introduce a new scheme to allow an emulator to > map ioreq server pages directly from Xen rather than the guest P2M. > > This patch lays the groundwork for that change by deferring mapping of > gfns until

Re: [Xen-devel] [PATCH] vt-d: use two 32-bit writes to update DMAR fault address registers

On 09/11/17 10:38 +0100, Roger Pau Monné wrote: > On Mon, Sep 11, 2017 at 02:00:48PM +0800, Haozhong Zhang wrote: > > The 64-bit DMAR fault address is composed of two 32 bits registers > > DMAR_FEADDR_REG and DMAR_FEUADDR_REG. According to VT-d spec: > > "Software is expected to access 32-bit

Re: [Xen-devel] [RFC] Unicore Subproject Proposal

Hi Alexander, thanks a lot for your review. On 10.09.2017 22:48, Alexander Dubinin wrote: Hi Felipe, all, Great that it's going to start :) Looking forward to join :) I am looking forward to your contributions. ;) Just my 2 cents: 1. Is this academic project, or it have specific goals

[Xen-devel] [xen-unstable test] 113266: FAIL

flight 113266 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/113266/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-amd 12 host-ping-check-native/l1running

Re: [Xen-devel] [PATCH v5 1/8] xen: move XENMAPSPACE_grant_table code into grant_table.c

On 09/08/2017 07:56 AM, Juergen Gross wrote: > The x86 and arm versions of XENMAPSPACE_grant_table handling are nearly > identical. Move the code into a function in grant_table.c and add an > architecture dependant hook to handle the differences. > > Switch to mfn_t in order to be more type safe.

Re: [Xen-devel] [PATCH v5 3/8] xen: delay allocation of grant table sub structures

On 11/09/17 13:02, Jan Beulich wrote: On 11.09.17 at 11:39, wrote: >> On 11/09/17 11:23, Jan Beulich wrote: >> On 11.09.17 at 11:03, wrote: On 08/09/17 17:28, Jan Beulich wrote: On 08.09.17 at 08:56, wrote: > And if

Re: [Xen-devel] [PATCH v4 10/11] public: add XENFEAT_ARM_SMCCC_supported feature

On 04/09/17 10:57, Sergej Proskurin wrote: Hi Julien, On 09/04/2017 08:07 AM, Julien Grall wrote: Hello, Sorry for the formatting, writing from my phone. Ki On Thu, 31 Aug 2017, 22:18 Sergej Proskurin wrote: [...] On your first mail, you started with "smc

Re: [Xen-devel] [PATCH v5 6/8] xen: add new domctl hypercall to set grant table resource limits

On 11/09/17 13:14, Jan Beulich wrote: On 11.09.17 at 12:48, wrote: >> On 08/09/17 17:55, Jan Beulich wrote: >> On 08.09.17 at 08:56, wrote: --- a/xen/common/grant_table.c +++ b/xen/common/grant_table.c @@ -3667,6 +3667,32 @@ void

[Xen-devel] [PATCH] mem_access: switch to plain bool

Signed-off-by: Wei Liu --- Cc: Razvan Cojocaru Cc: Tamas K Lengyel Cc: Stefano Stabellini Cc: Julien Grall Cc: George Dunlap Cc: Jan Beulich

Re: [Xen-devel] [PATCH v5 6/8] xen: add new domctl hypercall to set grant table resource limits

>>> On 11.09.17 at 12:48, wrote: > On 08/09/17 17:55, Jan Beulich wrote: > On 08.09.17 at 08:56, wrote: >>> --- a/xen/common/grant_table.c >>> +++ b/xen/common/grant_table.c >>> @@ -3667,6 +3667,32 @@ void grant_table_init_vcpu(struct vcpu *v) >>>

  1   2   >