[Xen-devel] [libvirt test] 105805: regressions - FAIL

flight 105805 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/105805/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-pair 9 xen-boot/src_host fail REGR. vs. 105785 Regressions which are

Re: [Xen-devel] [PATCH v3] displif: add ABI for para-virtual display

On 02/14/2017 10:27 PM, Konrad Rzeszutek Wilk wrote: On Mon, Feb 13, 2017 at 10:50:49AM +0200, Oleksandr Andrushchenko wrote: Hi, Konrad! Thank you for reviewing this. On 02/10/2017 11:27 PM, Konrad Rzeszutek Wilk wrote: On Fri, Feb 10, 2017 at 09:29:58AM +0200, Oleksandr Andrushchenko

Re: [Xen-devel] [PATCH 1/1] xen/arm: Add pl011 uart support in Xen for guest domains

Hi Konrad, Thanks for the feedback. On 7 February 2017 at 00:05, Konrad Rzeszutek Wilk wrote: > On Mon, Feb 06, 2017 at 11:39:08PM +0530, Bhupinder Thakur wrote: >> As per "VM System Specification for ARM Processors", there is a requirement >> for Xen to support guest

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

flight 105803 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/105803/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 4 host-build-prep fail REGR. vs. 59254

[Xen-devel] [qemu-mainline baseline-only test] 68560: regressions - trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 68560 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68560/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-amd 6 xen-boot

Re: [Xen-devel] [PATCH v3 4/4] KVM: VMX: Simplify segment_base

On Tue, Feb 14, 2017 at 11:42 AM, Thomas Garnier wrote: > The KVM segment_base function is confusing. This patch replaces integers > with appropriate flags, simplify constructs and add comments. It could pay to put this first in the series, but last is probably fine, too. >

[Xen-devel] [xen-unstable test] 105799: trouble: blocked/broken/fail/pass

flight 105799 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/105799/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-xsm 3 host-install(3)broken REGR. vs.

Re: [Xen-devel] [PATCH 20/28] ARM: vITS: handle MAPD command

On Mon, 30 Jan 2017, Andre Przywara wrote: > The MAPD command maps a device by associating a memory region for > storing ITTEs with a certain device ID. > We just store the given guest physical address in the device table. > We don't map the device tables permanently, as their alignment >

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

flight 105795 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/105795/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail REGR. vs.

Re: [Xen-devel] [PATCH 17/28] ARM: vITS: handle CLEAR command

On Mon, 30 Jan 2017, Andre Przywara wrote: > This introduces the ITS command handler for the CLEAR command, which > clears the pending state of an LPI. > This removes a not-yet injected, but already queued IRQ from a VCPU. > > Signed-off-by: Andre Przywara Please see

Re: [Xen-devel] [RFC PATCH v2 14/26] ARM: vGICv3: introduce basic ITS emulation bits

On Thu, 22 Dec 2016, Andre Przywara wrote: > Create a new file to hold the emulation code for the ITS widget. > For now we emulate the memory mapped ITS registers and provide a stub > to introduce the ITS command handling framework (but without actually > emulating any commands at this time). > >

Re: [Xen-devel] [PATCH 13/28] ARM: vGICv3: handle virtual LPI pending and property tables

On Mon, 30 Jan 2017, Andre Przywara wrote: > Allow a guest to provide the address and size for the memory regions > it has reserved for the GICv3 pending and property tables. > We sanitise the various fields of the respective redistributor > registers and map those pages into Xen's address space

Re: [Xen-devel] [PATCH 14/28] ARM: vGICv3: Handle disabled LPIs

On Mon, 30 Jan 2017, Andre Przywara wrote: > If a guest disables an LPI, we do not forward this to the associated > host LPI to avoid queueing commands to the host ITS command queue. > So it may happen that an LPI fires nevertheless on the host. In this > case we can bail out early, but have to

Re: [Xen-devel] Unable to boot Xen 4.8 with iommu=0

On 14/02/2017 22:47, Tamas K Lengyel wrote: > (XEN) Switched to APIC driver x2apic_cluster. > (XEN) XSM Framework v1.0.0 initialized > (XEN) Flask: 128 avtab hash slots, 394 rules. > (XEN) Flask: 128 avtab hash slots, 394 rules. > (XEN) Flask: 5 users, 3 roles, 43 types, 2 bools > (XEN) Flask:

Re: [Xen-devel] [PATCH 12/28] ARM: GICv3: enable ITS and LPIs on the host

On Mon, 30 Jan 2017, Andre Przywara wrote: > Now that the host part of the ITS code is in place, we can enable the > ITS and also LPIs on each redistributor to get the show rolling. > At this point there would be no LPIs mapped, as guests don't know about > the ITS yet. > > Signed-off-by: Andre

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

flight 105796 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/105796/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 105787

[Xen-devel] Unable to boot Xen 4.8 with iommu=0

Hi all, I'm having some strange issues with Xen 4.8 when I try to boot with iommu disabled. (XEN) Xen version 4.8.0 (root@lan) (gcc (Debian 5.4.1-4) 5.4.1 20161202) debug=n Tue Feb 14 15:32:55 MST 2017 (XEN) Latest ChangeSet: (XEN) Bootloader: GRUB 2.02~beta3-4 (XEN) Command line: placeholder

Re: [Xen-devel] [PATCH 2/2] x86: package up context switch hook pointers

On 02/14/2017 05:29 AM, Jan Beulich wrote: They're all solely dependent on guest type, so we don't need to repeat all the same four pointers in every vCPU control structure. Instead use static const structures, and store pointers to them in the domain control structure. Since touching it

Re: [Xen-devel] [PATCH 00/28] arm64: Dom0 ITS emulation

On Mon, 13 Feb 2017, Vijay Kilari wrote: > Hi Andre, > > I tried your patch series on HW. Dom0 boots but no LPIs are coming to Dom0. > So I made below patch to consider segment ID in generating devid, > I see below panic from _xmalloc(). > > Complete log is here > http://pastebin.com/btythn2V

[Xen-devel] [qemu-mainline baseline-only test] 68559: regressions - trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 68559 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68559/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-xsm 11 guest-start

Re: [Xen-devel] [DOC v9] PV Calls protocol design

On Tue, 14 Feb 2017, Konrad Rzeszutek Wilk wrote: > On Mon, Feb 13, 2017 at 11:46:40AM -0800, Stefano Stabellini wrote: > > Changes in v9: > > - specify max-page-order must be >= 1 > > - clarifications > > - add "Expanding the protocol" > > - add padding after out_error > > - add "Why ring.h is

Re: [Xen-devel] [DOC v5] Xen transport for 9pfs

On Tue, 14 Feb 2017, Konrad Rzeszutek Wilk wrote: > On Mon, Feb 13, 2017 at 11:47:26AM -0800, Stefano Stabellini wrote: > > Reviewed-by: Konrad Rzeszutek Wilk Thank you! For your convenience: --- docs: add Xen transport for 9pfs Signed-off-by: Stefano Stabellini

Re: [Xen-devel] [PATCH 05/28] ARM: GICv3 ITS: map ITS command buffer

On Tue, 14 Feb 2017, Julien Grall wrote: > Hi Stefano, > > On 02/14/2017 12:59 AM, Stefano Stabellini wrote: > > On Mon, 30 Jan 2017, Andre Przywara wrote: > > > static int its_map_baser(void __iomem *basereg, uint64_t regc, int > > > nr_items) > > > @@ -150,6 +191,11 @@ int

Re: [Xen-devel] [PATCH 11/28] ARM: GICv3: forward pending LPIs to guests

On Mon, 30 Jan 2017, Andre Przywara wrote: > Upon receiving an LPI, we need to find the right VCPU and virtual IRQ > number to get this IRQ injected. > Iterate our two-level LPI table to find this information quickly when > the host takes an LPI. Call the existing injection function to let the >

Re: [Xen-devel] [PATCH 05/28] ARM: GICv3 ITS: map ITS command buffer

Hi Stefano, On 02/14/2017 12:59 AM, Stefano Stabellini wrote: On Mon, 30 Jan 2017, Andre Przywara wrote: static int its_map_baser(void __iomem *basereg, uint64_t regc, int nr_items) @@ -150,6 +191,11 @@ int gicv3_its_init(struct host_its *hw_its) } } +hw_its->cmd_buf =

Re: [Xen-devel] [PATCH 10/28] ARM: GICv3: introduce separate pending_irq structs for LPIs

On Mon, 30 Jan 2017, Andre Przywara wrote: > For the same reason that allocating a struct irq_desc for each > possible LPI is not an option, having a struct pending_irq for each LPI > is also not feasible. However we actually only need those when an > interrupt is on a vCPU (or is about to be

Re: [Xen-devel] [PATCH v3] displif: add ABI for para-virtual display

On Mon, Feb 13, 2017 at 10:50:49AM +0200, Oleksandr Andrushchenko wrote: > Hi, Konrad! > > Thank you for reviewing this. > > On 02/10/2017 11:27 PM, Konrad Rzeszutek Wilk wrote: > > On Fri, Feb 10, 2017 at 09:29:58AM +0200, Oleksandr Andrushchenko wrote: > > > From: Oleksandr Andrushchenko

Re: [Xen-devel] STAO spec in xen.git

On Tue, Feb 14, 2017 at 09:02:14PM +0100, Olaf Hering wrote: > On Tue, Feb 14, Stefano Stabellini wrote: > > > Interestingly, my "git am" is unable to apply those patches. Does it > > work for you? I cannot see anything wrong with them, but they don't > > work. If the problem is that they are too

Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document

Hi Stefano, On 02/14/2017 06:20 PM, Stefano Stabellini wrote: On Tue, 14 Feb 2017, Julien Grall wrote: Hi Stefano, On 02/13/2017 07:59 PM, Stefano Stabellini wrote: On Mon, 13 Feb 2017, Julien Grall wrote: Hi Stefano, On 10/02/17 01:01, Stefano Stabellini wrote: On Fri, 3 Feb 2017, Edgar

Re: [Xen-devel] [ARM] SMC (and HVC) handling in hypervisor

On Tue, Feb 14, 2017 at 12:11 PM, Stefano Stabellini wrote: > On Tue, 14 Feb 2017, Julien Grall wrote: >> > > > 10. Domains on which the monitor privileged call feature is enabled >> > > > (which is by default disabled for all domains) should not be able to >> > > >

Re: [Xen-devel] [PATCH 09/28] ARM: GICv3 ITS: map device and LPIs to the ITS on physdev_op hypercall

On Mon, 30 Jan 2017, Andre Przywara wrote: > To get MSIs from devices forwarded to a CPU, we need to name the device > and its MSIs by mapping them to an ITS. > Since this involves queueing commands to the ITS command queue, we can't > really afford to do this during the guest's runtime, as this

Re: [Xen-devel] [PATCH 08/28] ARM: GICv3 ITS: introduce host LPI array

On Mon, 30 Jan 2017, Andre Przywara wrote: > The number of LPIs on a host can be potentially huge (millions), > although in practise will be mostly reasonable. So prematurely allocating > an array of struct irq_desc's for each LPI is not an option. > However Xen itself does not care about LPIs, as

Re: [Xen-devel] STAO spec in xen.git

On Tue, Feb 14, Stefano Stabellini wrote: > Interestingly, my "git am" is unable to apply those patches. Does it > work for you? I cannot see anything wrong with them, but they don't > work. If the problem is that they are too large, please send the files > as attachments. Its the '\ No newline

[Xen-devel] [PATCH v3 3/4] x86: Make the GDT remapping read-only on 64-bit

This patch makes the GDT remapped pages read-only to prevent corruption. This change is done only on 64-bit. The native_load_tr_desc function was adapted to correctly handle a read-only GDT. The LTR instruction always writes to the GDT TSS entry. This generates a page fault if the GDT is

[Xen-devel] [PATCH v3 1/4] x86/mm: Adapt MODULES_END based on Fixmap section size

This patch aligns MODULES_END to the beginning of the Fixmap section. It optimizes the space available for both sections. The address is pre-computed based on the number of pages required by the Fixmap section. It will allow GDT remapping in the Fixmap section. The current MODULES_END static

[Xen-devel] [PATCH v3 2/4] x86: Remap GDT tables in the Fixmap section

Each processor holds a GDT in its per-cpu structure. The sgdt instruction gives the base address of the current GDT. This address can be used to bypass KASLR memory randomization. With another bug, an attacker could target other per-cpu structures or deduce the base of the main memory section

[Xen-devel] [PATCH v3 4/4] KVM: VMX: Simplify segment_base

The KVM segment_base function is confusing. This patch replaces integers with appropriate flags, simplify constructs and add comments. Signed-off-by: Thomas Garnier --- Based on next-20170213 --- arch/x86/kvm/vmx.c | 26 ++ 1 file changed, 18

Re: [Xen-devel] [DOC v9] PV Calls protocol design

On Mon, Feb 13, 2017 at 11:46:40AM -0800, Stefano Stabellini wrote: > Changes in v9: > - specify max-page-order must be >= 1 > - clarifications > - add "Expanding the protocol" > - add padding after out_error > - add "Why ring.h is not needed" Reviewed-by: Konrad Rzeszutek Wilk

Re: [Xen-devel] [DOC v5] Xen transport for 9pfs

On Mon, Feb 13, 2017 at 11:47:26AM -0800, Stefano Stabellini wrote: Reviewed-by: Konrad Rzeszutek Wilk > Changes in v5: > - add padding after out_prod > - add "Why ring.h is not needed" > - specify max-ring-page-order >= 1 ___

Re: [Xen-devel] [ARM] SMC (and HVC) handling in hypervisor

On Tue, 14 Feb 2017, Julien Grall wrote: > > > > 10. Domains on which the monitor privileged call feature is enabled > > > > (which is by default disabled for all domains) should not be able to > > > > issue firmware calls via SMCs/HVCs so that such calls reach the > > > > firmware

Re: [Xen-devel] [PATCH v15 01/10] x86: add "w" flag to .init.data section definition

On 14/02/17 18:33, Daniel Kiper wrote: > init.data section is clearly writable, so, add "w" flag to its > definition in xen/arch/x86/boot/x86_64.S. > > Signed-off-by: Daniel Kiper Reviewed-by: Andrew Cooper

Re: [Xen-devel] [ARM] SMC (and HVC) handling in hypervisor

On Tue, Feb 14, 2017 at 11:06 AM, Julien Grall wrote: > Hi, > > > On 02/13/2017 10:14 PM, Stefano Stabellini wrote: >> >> On Mon, 13 Feb 2017, Tamas K Lengyel wrote: >>> >>> On Mon, Feb 13, 2017 at 2:54 PM, Stefano Stabellini >>> wrote: On

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

flight 105797 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/105797/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 5

Re: [Xen-devel] STAO spec in xen.git

On Tue, Feb 14, Stefano Stabellini wrote: > Also, I tried to do the same conversion with my copy of Libreoffice and > the FODT files produced are significantly different from yours, which > means, even if we use FODT docs, we are probably going to be unable to > send changes as meaningful text

Re: [Xen-devel] [PATCH v3 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP

On Tue, 14 Feb 2017, Boris Ostrovsky wrote: > On 02/13/2017 12:03 PM, Paul Durrant wrote: > > Recently a new dm_op[1] hypercall was added to Xen to provide a mechanism > > for restricting device emulators (such as QEMU) to a limited set of > > hypervisor operations, and being able to audit those

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

On Tue, Feb 14, 2017 at 07:33:24PM +0100, Daniel Kiper wrote: > This way Xen can be loaded on EFI platforms using GRUB2 and > other boot loaders which support multiboot2 protocol. > > Signed-off-by: Daniel Kiper I am posting diff between v14 and v15 for your convenience.

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

flight 105790 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/105790/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-buildfail REGR. vs. 105756

[Xen-devel] [PATCH v15 10/10] x86: add multiboot2 protocol support for relocatable images

Add multiboot2 protocol support for relocatable images. Only GRUB2 with "multiboot2: Add support for relocatable images" patch understands that feature. Older multiboot protocol (regardless of version) compatible loaders ignore it and everything works as usual. Signed-off-by: Daniel Kiper

[Xen-devel] [PATCH v15 07/10] x86/setup: use XEN_IMG_OFFSET instead of...

..calculating its value during runtime. Signed-off-by: Daniel Kiper Acked-by: Jan Beulich Reviewed-by: Doug Goldstein --- xen/arch/x86/setup.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git

[Xen-devel] [PATCH v15 09/10] x86/boot: rename sym_phys() to sym_offs()

This way macro name better describes its function. Currently it is used to calculate symbol offset in relation to the beginning of Xen image mapping. However, value returned by sym_offs() for a given symbol is not always equal its physical address. There is no functional change. Suggested-by:

[Xen-devel] [PATCH v15 08/10] x86: make Xen early boot code relocatable

Every multiboot protocol (regardless of version) compatible image must specify its load address (in ELF or multiboot header). Multiboot protocol compatible loader have to load image at specified address. However, there is no guarantee that the requested memory region (in case of Xen it starts at 2

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

This way Xen can be loaded on EFI platforms using GRUB2 and other boot loaders which support multiboot2 protocol. Signed-off-by: Daniel Kiper --- v15 - suggestions/fixes: - rearrange inline assembly arguments in xen/arch/x86/efi/stub.c:efi_multiboot2()

[Xen-devel] [PATCH v15 01/10] x86: add "w" flag to .init.data section definition

init.data section is clearly writable, so, add "w" flag to its definition in xen/arch/x86/boot/x86_64.S. Signed-off-by: Daniel Kiper --- xen/arch/x86/boot/x86_64.S |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/boot/x86_64.S

[Xen-devel] [PATCH v15 03/10] efi: build xen.gz with EFI code

Build xen.gz with EFI code. We need this to support multiboot2 protocol on EFI platforms. If we wish to load non-ELF file using multiboot (v1) or multiboot2 then it must contain "linear" (or "flat") representation of code and data. This is requirement of both boot protocols. Currently, PE file

[Xen-devel] [PATCH v15 06/10] x86: change default load address from 1 MiB to 2 MiB

Subsequent patches introducing relocatable early boot code play with page tables using 2 MiB huge pages. If load address is not aligned at 2 MiB then code touching such page tables must have special cases for start and end of Xen image memory region. So, let's make life easier and move default

[Xen-devel] [PATCH v15 02/10] x86: add multiboot2 protocol support

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 Reviewed-by: Jan Beulich

[Xen-devel] [PATCH v15 04/10] efi: create new early memory allocator

There is a problem with place_string() which is used as early memory allocator. It gets memory chunks starting from start symbol and goes down. Sadly this does not work when Xen is loaded using multiboot2 protocol because then the start lives on 1 MiB address and we should not allocate a memory

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

Hi, I am sending fifteenth version of multiboot2 protocol support for legacy BIOS and EFI platforms. This patch series release contains fixes for all known/confirmed issues. The final goal is xen.efi binary file which could be loaded by EFI loader, multiboot (v1) protocol (only on legacy BIOS

Re: [Xen-devel] STAO spec in xen.git

On Tue, 14 Feb 2017, Olaf Hering wrote: > On Tue, Jan 17, Stefano Stabellini wrote: > > > On Tue, 17 Jan 2017, Olaf Hering wrote: > > > On Fri, Jan 13, Julien Grall wrote: > > > > > > > Regarding the format. Does ODT will allow git to do proper diff? > > > > > > There is flat ODT, "Safe as ..."

Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document

On Tue, 14 Feb 2017, Julien Grall wrote: > Hi Stefano, > > On 02/13/2017 07:59 PM, Stefano Stabellini wrote: > > On Mon, 13 Feb 2017, Julien Grall wrote: > >> Hi Stefano, > >> > >> On 10/02/17 01:01, Stefano Stabellini wrote: > >>> On Fri, 3 Feb 2017, Edgar E. Iglesias wrote: > A possible

Re: [Xen-devel] [ARM] SMC (and HVC) handling in hypervisor

Hi, On 02/13/2017 10:14 PM, Stefano Stabellini wrote: On Mon, 13 Feb 2017, Tamas K Lengyel wrote: On Mon, Feb 13, 2017 at 2:54 PM, Stefano Stabellini wrote: On Mon, 13 Feb 2017, Tamas K Lengyel wrote: On Mon, Feb 13, 2017 at 2:13 PM, Stefano Stabellini

Re: [Xen-devel] [PATCH v2] x86/shadow: Correct guest behaviour when creating PTEs above maxphysaddr

On 14/02/17 17:45, Andrew Cooper wrote: > On 14/02/17 17:42, George Dunlap wrote: >> On 13/02/17 11:00, Andrew Cooper wrote: >>> XSA-173 (c/s 8b1764833) introduces gfn_bits, and an upper limit which might >>> be >>> lower than the real maxphysaddr, to avoid overflowing the superpage shadow >>>

Re: [Xen-devel] [PATCH v2] x86/shadow: Correct guest behaviour when creating PTEs above maxphysaddr

On 14/02/17 17:49, George Dunlap wrote: > On 14/02/17 17:45, Andrew Cooper wrote: >> On 14/02/17 17:42, George Dunlap wrote: >>> On 13/02/17 11:00, Andrew Cooper wrote: XSA-173 (c/s 8b1764833) introduces gfn_bits, and an upper limit which might be lower than the real maxphysaddr,

Re: [Xen-devel] [PATCH v2] x86/shadow: Correct guest behaviour when creating PTEs above maxphysaddr

On 14/02/17 17:42, George Dunlap wrote: > On 13/02/17 11:00, Andrew Cooper wrote: >> XSA-173 (c/s 8b1764833) introduces gfn_bits, and an upper limit which might >> be >> lower than the real maxphysaddr, to avoid overflowing the superpage shadow >> backpointer. >> >> However, plenty of hardware

Re: [Xen-devel] [linux-linus test] 104684: regressions - FAIL

On Tue, Feb 14, 2017 at 02:57:42PM +, Julien Grall wrote: > Hi, > > On 01/26/2017 09:11 PM, Julien Grall wrote: > > Hi, > > > > On 26/01/2017 19:01, Boris Ostrovsky wrote: > > > On 01/26/2017 12:18 PM, Ian Jackson wrote: > > > > Boris Ostrovsky writes ("Re: [Xen-devel] [linux-linus test]

Re: [Xen-devel] [PATCH v2] x86/shadow: Correct guest behaviour when creating PTEs above maxphysaddr

On 13/02/17 11:00, Andrew Cooper wrote: > XSA-173 (c/s 8b1764833) introduces gfn_bits, and an upper limit which might be > lower than the real maxphysaddr, to avoid overflowing the superpage shadow > backpointer. > > However, plenty of hardware has a physical address width less that 44 bits, >

Re: [Xen-devel] [PATCH] x86/VMX: sanitize VM86 TSS handling

At 06:37 -0700 on 13 Feb (1486967832), Jan Beulich wrote: > >>> On 13.02.17 at 14:19, wrote: > > -tss = mem_alloc(128, 128); > > -memset(tss, 0, 128); > > +tss = mem_alloc(TSS_SIZE, TSS_SIZE); > > tss = mem_alloc(TSS_SIZE, 128); > > is sufficient here, as I've

Re: [Xen-devel] [PATCH] x86/VMX: sanitize VM86 TSS handling

Hi, At 06:19 -0700 on 13 Feb (1486966797), Jan Beulich wrote: > The present way of setting this up is flawed: Leaving the I/O bitmap > pointer at zero means that the interrupt redirection bitmap lives > outside (ahead of) the allocated space of the TSS. Similarly setting a > TSS limit of 255 when

[Xen-devel] RFC v2: Scope of Vulnerabilities for which XSAs are issued

Here is version two, with minor revisions based on comments from version 1. Please give any feedback by 28 February. Thanks! Issuing advisories has a cost: It costs the security team significant amounts of time to craft and send the advisories; it costs many of our downstreams time to apply,

Re: [Xen-devel] [PATCH v3 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP

On 02/13/2017 12:03 PM, Paul Durrant wrote: > Recently a new dm_op[1] hypercall was added to Xen to provide a mechanism > for restricting device emulators (such as QEMU) to a limited set of > hypervisor operations, and being able to audit those operations in the > kernel of the domain in which

Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document

Hi Stefano, On 02/13/2017 07:59 PM, Stefano Stabellini wrote: > On Mon, 13 Feb 2017, Julien Grall wrote: >> Hi Stefano, >> >> On 10/02/17 01:01, Stefano Stabellini wrote: >>> On Fri, 3 Feb 2017, Edgar E. Iglesias wrote: A possible hack could be to allocate a chunk of DDR dedicated for PCI

Re: [Xen-devel] [PATCH 1/2] tools/libxc: Introduce XC_CPUPOOL_POOLID_ANY

These two patches don't apply anymore. Please rebase. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 2/4] build/printf: fix incorrect format specifiers

On Tue, Feb 14, 2017 at 12:30:55PM +, Roger Pau Monne wrote: > The following incorrect format specifiers and incorrect number of parameters > passed to printf like functions are reported by clang: > > mce.c:601:18: error: data argument not used by format string >

Re: [Xen-devel] [PATCH 0/2] ocaml: Start on fixing brokenness when no ocamlopt

Hi, Ping? As Ian mentioned earlier, without this series it is not possible to build Xen tools for ARM64 in osstest. Cheers, On 02/08/2017 07:50 PM, Julien Grall wrote: Hi, On 24/01/17 22:19, David Scott wrote: On 24 Jan 2017, at 11:35, Ian Jackson wrote: Ian

Re: [Xen-devel] [PATCH v2] x86/shadow: Correct guest behaviour when creating PTEs above maxphysaddr

At 16:04 + on 14 Feb (1487088291), Andrew Cooper wrote: > Hmm ok. With the other bugfix of not dropping the first line, this hunk > is now simply: > > @@ -504,7 +505,7 @@ void recalculate_cpuid_policy(struct domain *d) > > p->extd.maxphysaddr = min(p->extd.maxphysaddr,

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

flight 105792 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/105792/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 5

Re: [Xen-devel] [PATCH biosdevname]: handle dom0 on AMD systems

Hello, and ping. Olaf On Wed, Aug 17, Olaf Hering wrote: > Starting with xen-4.7 cpuid() will return with the hypervisor bit set > in a dom0 when running on an AMD system. As a result biosdevname > thinks it runs in a guest and does nothing. Detect a dom0 by looking > into xenfs. This works

Re: [Xen-devel] STAO spec in xen.git

On Tue, Jan 17, Stefano Stabellini wrote: > On Tue, 17 Jan 2017, Olaf Hering wrote: > > On Fri, Jan 13, Julien Grall wrote: > > > > > Regarding the format. Does ODT will allow git to do proper diff? > > > > There is flat ODT, "Safe as ..." and pick the better format from the > > pulldown menu.

[Xen-devel] [PATCH 2/4] docs: convert XENV from odt to fodt

Fixes c33b5f013d ("Add XENV to docs/misc") Signed-off-by: Olaf Hering --- docs/misc/xen-env-table-spec.fodt | 852 ++ 1 file changed, 852 insertions(+) diff --git a/docs/misc/xen-env-table-spec.fodt b/docs/misc/xen-env-table-spec.fodt new

[Xen-devel] [PATCH 1/4] docs: convert STAO from odt to fodt

Fixes 140b31a8de ("Add STAO spec to docs/misc") Signed-off-by: Olaf Hering --- docs/misc/status-override-table-spec.fodt | 707 ++ 1 file changed, 707 insertions(+) diff --git a/docs/misc/status-override-table-spec.fodt

[Xen-devel] [PATCH 4/4] docs: remove odt variant of XENV

Signed-off-by: Olaf Hering --- docs/misc/xen-env-table-spec.odt | Bin 19204 -> 0 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/docs/misc/xen-env-table-spec.odt b/docs/misc/xen-env-table-spec.odt deleted file mode 100644 index

[Xen-devel] [PATCH 3/4] docs: remove odt variant of STAO

Signed-off-by: Olaf Hering --- docs/misc/status-override-table-spec.odt | Bin 20206 -> 0 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/docs/misc/status-override-table-spec.odt b/docs/misc/status-override-table-spec.odt deleted file mode 100644 index

[Xen-devel] [PATCH 0/4] docs: convert from binary to ASCII

The odt files should have been saved as Flat XML via 'Save as ...'. git send-email warns about lines longer than 998 chars. Hopefully all involved mail services have no silly limits. Olaf Olaf Hering (4): docs: convert STAO from odt to fodt docs: convert XENV from odt to fodt docs: remove

Re: [Xen-devel] [ARM] SMC (and HVC) handling in hypervisor

On 13/02/17 16:59, Tamas K Lengyel wrote: On Mon, Feb 13, 2017 at 9:37 AM, Julien Grall wrote: Hi Tamas, On 13/02/17 16:20, Tamas K Lengyel wrote: On Fri, Feb 10, 2017 at 5:14 PM, Volodymyr Babchuk wrote: Hello, This e-mail is sort of

Re: [Xen-devel] [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function

On 14/02/17 14:46, Waiman Long wrote: > On 02/14/2017 04:39 AM, Peter Zijlstra wrote: >> On Mon, Feb 13, 2017 at 05:34:01PM -0500, Waiman Long wrote: >>> It is the address of _time that will exceed the 32-bit limit. >> That seems extremely unlikely. That would mean we have more than 4G >> worth of

Re: [Xen-devel] [PATCH v2] x86/shadow: Correct guest behaviour when creating PTEs above maxphysaddr

On 13/02/17 12:36, Jan Beulich wrote: On 13.02.17 at 12:00, wrote: >> @@ -502,11 +503,9 @@ void recalculate_cpuid_policy(struct domain *d) >> >> cpuid_featureset_to_policy(fs, p); >> >> -p->extd.maxphysaddr = min(p->extd.maxphysaddr,

Re: [Xen-devel] [ARM] SMC (and HVC) handling in hypervisor

Hi Tamas, On 13/02/17 16:20, Tamas K Lengyel wrote: On Fri, Feb 10, 2017 at 5:14 PM, Volodymyr Babchuk wrote: Hello, This e-mail is sort of follow-up to the two threads: [1] (my thread about TEE interaction) and [2] (Edgar's thread regarding handling SMC calls in

Re: [Xen-devel] [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function

On Tue, Feb 14, 2017 at 09:46:17AM -0500, Waiman Long wrote: > On 02/14/2017 04:39 AM, Peter Zijlstra wrote: > > On Mon, Feb 13, 2017 at 05:34:01PM -0500, Waiman Long wrote: > >> It is the address of _time that will exceed the 32-bit limit. > > That seems extremely unlikely. That would mean we

Re: [Xen-devel] [PATCH] Make it compiler under Xen 4.7.

> -Original Message- [snip] > > Thank you. Keep in mind that it will likely break against > > older Xen versions (Xen 4.4?) as there is no xenctrl_compat.h > > I'm not sure you actually need to include that directly. I was going to try > just > adding the 'want compat' defines and seeing

Re: [Xen-devel] [PATCH v7 04/24] x86: refactor psr: implement CPU init and free flow.

On Mon, Feb 13, 2017 at 02:32:16PM +0800, Yi Sun wrote: > This patch implements the CPU init and free flow including L3 CAT > initialization and feature list free. > > Signed-off-by: Yi Sun > --- > v7: > - initialize 'l3_cat'. > - fix typo. > - correct

Re: [Xen-devel] [PATCH] x86/mm: Alter is_xen_fixed_mfn() to use mfn_t

Hi Andrew, On 02/07/2017 06:57 PM, Andrew Cooper wrote: The predicate is common between x86 and ARM, and is unlikley to be different/ NIT: s/unlikley/unlikely/ on other architectures. Drop the arch declarations and introduce a common static inline in xen/mm.h instead. Signed-off-by:

Re: [Xen-devel] [PATCH v7 01/24] docs: create Cache Allocation Technology (CAT) and Code and Data Prioritization (CDP) feature document

On Mon, Feb 13, 2017 at 02:32:13PM +0800, Yi Sun wrote: > This patch creates CAT and CDP feature document in doc/features/. It describes > key points to implement L3 CAT/CDP and L2 CAT which is described in details in > Intel SDM "INTEL® RESOURCE DIRECTOR TECHNOLOGY (INTEL® RDT) ALLOCATION >

Re: [Xen-devel] [PATCH] x86/VMX: sanitize VM86 TSS handling

On 14/02/17 08:55, Jan Beulich wrote: On 13.02.17 at 19:26, wrote: >> On 13/02/17 13:19, Jan Beulich wrote: >>> --- >>> TBD: Do we really want to re-init the TSS every time we are about to >>> use it? This can happen quite often during boot, especially while

Re: [Xen-devel] [PATCH] X86/vmx: Dump PIR and vIRR before ASSERT()

Hi Jan, On 02/14/2017 10:51 AM, Jan Beulich wrote: On 07.02.17 at 00:32, wrote: Commit c7bdecae42 ("x86/apicv: fix RTC periodic timer and apicv issue") has added a assertion that intack.vector is the highest priority vector. But according to the osstest, the assertion

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

flight 105786 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/105786/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail REGR. vs.

Re: [Xen-devel] [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)

On Tue, Feb 14, 2017 at 03:39:00PM +, Paul Durrant wrote: > > -Original Message- > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] > > Sent: 14 February 2017 15:32 > > To: Paul Durrant > > Cc: xen-de...@lists.xenproject.org > > Subject: Re:

Re: [Xen-devel] [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)

> -Original Message- > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] > Sent: 14 February 2017 15:32 > To: Paul Durrant > Cc: xen-de...@lists.xenproject.org > Subject: Re: [PATCH v1] Make demu.git compiler under Xen 4.7 (and later) > > On Tue, Feb

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

flight 105787 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/105787/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 105781

Re: [Xen-devel] [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)

On Tue, Feb 14, 2017 at 03:26:34PM +, Paul Durrant wrote: > > -Original Message- > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] > > Sent: 14 February 2017 15:16 > > To: Paul Durrant > > Cc: xen-de...@lists.xenproject.org > > Subject: Re:

Re: [Xen-devel] [PATCH 2/2] x86: package up context switch hook pointers

On 14/02/17 10:29, Jan Beulich wrote: > They're all solely dependent on guest type, so we don't need to repeat > all the same four pointers in every vCPU control structure. Instead use > static const structures, and store pointers to them in the domain > control structure. > > Since touching it

  1   2   >