Re: [Xen-devel] Xen Project and Xvisor.

Please look at "http://xhypervisor.org/pdf/Embedded_Hypervisor_Xvisor_A_comparative_analysis.pdf;. On Friday, December 9, 2016 11:30 AM, Konrad Rzeszutek Wilk wrote: On Fri, Dec 09, 2016 at 06:50:03PM +, Jason Long wrote: > Hello. > I like to see Xen developer

Re: [Xen-devel] Xen Project and Xvisor.

I see "http://www.xvisor-x86.org/wiki/Main_Page; and they want move it to x86. On Friday, December 9, 2016 11:30 AM, Konrad Rzeszutek Wilk wrote: On Fri, Dec 09, 2016 at 06:50:03PM +, Jason Long wrote: > Hello. > I like to see Xen developer ideas and concerns

[Xen-devel] [xen-4.6-testing baseline-only test] 68188: trouble: blocked/broken

This run is configured for baseline tests only. flight 68188 xen-4.6-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68188/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvops

Re: [Xen-devel] [PATCH] x86/smpboot: Make logical package management more robust

On 12/09/2016 06:00 PM, Thomas Gleixner wrote: On Fri, 9 Dec 2016, Boris Ostrovsky wrote: On 12/09/2016 05:06 PM, Thomas Gleixner wrote: On Thu, 8 Dec 2016, Thomas Gleixner wrote: Boris, can you please verify if that makes the topology_update_package_map() call which you placed into the Xen

Re: [Xen-devel] [PATCH] x86/smpboot: Make logical package management more robust

On 12/09/2016 06:02 PM, Boris Ostrovsky wrote: On 12/09/2016 05:06 PM, Thomas Gleixner wrote: On Thu, 8 Dec 2016, Thomas Gleixner wrote: Boris, can you please verify if that makes the topology_update_package_map() call which you placed into the Xen cpu starting code obsolete ? Will do. I

[Xen-devel] [PATCH] remove dead code from arm/decode.c

The rt variable can only be 0 or 7, no need to check if it's 15. Coverity-ID: 1381835 Signed-off-by: Stefano Stabellini diff --git a/xen/arch/arm/decode.c b/xen/arch/arm/decode.c index c6f49a5..decd9dd 100644 --- a/xen/arch/arm/decode.c +++ b/xen/arch/arm/decode.c @@

Re: [Xen-devel] [PATCH v2] fix potential int overflow in efi/boot

Forgot to CC Jan again. On Fri, 9 Dec 2016, Stefano Stabellini wrote: > HorizontalResolution and VerticalResolution are 32bit, while size is > 64bit. As it stands multiplications are evaluated with 32bit arithmetic, > which could overflow. Cast HorizontalResolution to 64bit to avoid that. > >

Re: [Xen-devel] Question about porting IPMMU-VMSA Linux driver to XEN

On Thu, 8 Dec 2016, Oleksandr Tyshchenko wrote: > On Thu, Dec 8, 2016 at 9:39 PM, Julien Grall wrote: > > > > > > On 08/12/16 17:06, Oleksandr Tyshchenko wrote: > >> > >> Hi Julien, > > > > > > Hi Oleksandr, > Hi Julien, > > thank you for sharing your opinion. > > > > > As

[Xen-devel] [xen-4.8-testing test] 103103: regressions - FAIL

flight 103103 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/103103/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-debianhvm-amd64 14 guest-saverestore.2 fail REGR. vs. 103036

Re: [Xen-devel] [RFC PATCH 21/24] ARM: vITS: handle INVALL command

On Fri, 9 Dec 2016, Andre Przywara wrote: > >> I've been spending some time thinking about this, and I think we can in > >> fact get away without ever propagating command from domains to the host. > >> > >> I made a list of all commands that possible require host ITS command > >> propagation.

Re: [Xen-devel] [RFC XEN PATCH 05/16] xen/x86: release pmem pages at domain destroy

On Mon, Oct 10, 2016 at 08:32:24AM +0800, Haozhong Zhang wrote: > The host pmem pages mapped to a domain are unassigned at domain destroy > so as to be used by other domains in future. > > Signed-off-by: Haozhong Zhang > --- > Cc: Jan Beulich > Cc:

Re: [Xen-devel] [RFC XEN PATCH 04/16] xen/x86: add XENMEM_populate_pmemmap to map host pmem pages to guest

On Mon, Oct 10, 2016 at 08:32:23AM +0800, Haozhong Zhang wrote: > XENMEM_populate_pmemmap is used by toolstack to map given host pmem pages > to given guest pages. Only pages in the data area of a pmem region are > allowed to be mapped to guest. > > Signed-off-by: Haozhong Zhang

Re: [Xen-devel] [RFC XEN PATCH 03/16] xen/x86: add a hypercall XENPF_pmem_add to report host pmem regions

On Mon, Oct 10, 2016 at 08:32:22AM +0800, Haozhong Zhang wrote: > Xen hypervisor does not include a pmem driver. Instead, it relies on the > pmem driver in Dom0 to report the PFN ranges of the entire pmem region, > its reserved area and data area via XENPF_pmem_add. The reserved area is > used by

[Xen-devel] [linux-4.1 test] 103089: regressions - FAIL

flight 103089 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/103089/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-winxpsp3 6 xen-boot fail REGR. vs. 101737 test-amd64-amd64-xl

Re: [Xen-devel] [RFC XEN PATCH 02/16] x86_64/mm: explicitly specify the location to place the M2P table

On Mon, Oct 10, 2016 at 08:32:21AM +0800, Haozhong Zhang wrote: > A reserved area on each pmem region is used to place the M2P table. > However, it's not at the beginning of the pmem region, so we need to > specify the location explicitly when creating the M2P table. > > Signed-off-by: Haozhong

Re: [Xen-devel] [RFC XEN PATCH 01/16] x86_64/mm: explicitly specify the location to place the frame table

On Mon, Oct 10, 2016 at 08:32:20AM +0800, Haozhong Zhang wrote: > A reserved area on each pmem region is used to place the frame table. > However, it's not at the beginning of the pmem region, so we need to > specify the location explicitly when extending the frame table. > > Signed-off-by:

Re: [Xen-devel] [PATCH] xen/setup: Don't relocate p2m/initrd over existing one

On 12/09/2016 10:50 AM, Ross Lagerwall wrote: > When relocating the p2m/initrd, take special care not to relocate it so > that is overlaps with the current location of the p2m/initrd. This is > needed since the full extent of the current location is not marked as a > reserved region in the e820

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

flight 103102 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/103102/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-arndale 6 xen-boot fail REGR. vs. 102942 Regressions which

Re: [Xen-devel] [RFC PATCH 21/24] ARM: vITS: handle INVALL command

On Fri, 9 Dec 2016, Andre Przywara wrote: > On 07/12/16 20:20, Stefano Stabellini wrote: > > On Tue, 6 Dec 2016, Julien Grall wrote: > >> On 06/12/2016 22:01, Stefano Stabellini wrote: > >>> On Tue, 6 Dec 2016, Stefano Stabellini wrote: > moving a vCPU with interrupts assigned to it is slower

Re: [Xen-devel] [RFC PATCH 21/24] ARM: vITS: handle INVALL command

On Fri, 9 Dec 2016, Julien Grall wrote: > Hi Stefano, > > On 07/12/16 20:20, Stefano Stabellini wrote: > > On Tue, 6 Dec 2016, Julien Grall wrote: > > > On 06/12/2016 22:01, Stefano Stabellini wrote: > > > > On Tue, 6 Dec 2016, Stefano Stabellini wrote: > > > > > moving a vCPU with interrupts

[Xen-devel] [PATCH v2 2/2] p2m: split mem_access into separate files

This patch relocates mem_access components that are currently mixed with p2m code into separate files. This better aligns the code with similar subsystems, such as mem_sharing and mem_paging, which are already in separate files. There are no code-changes introduced, the patch is mechanical code

[Xen-devel] [PATCH v2 1/2] arm/mem_access: adjust check_and_get_page to not rely on current

The only caller of this function is get_page_from_gva which already takes a vcpu pointer as input. Pass this along to make the function in-line with its intended use-case. Signed-off-by: Tamas K Lengyel --- Cc: Stefano Stabellini Cc: Julien

Re: [Xen-devel] [PATCH v1] arm/irq: Reorder check in route_irq_to_guest() to avoid 4 layers of "if"

On Fri, 9 Dec 2016, Julien Grall wrote: > Hi Oleksandr, > > Thank you for the patch. > > On 06/12/16 17:53, Oleksandr Tyshchenko wrote: > > From: Oleksandr Tyshchenko > > > > Remove one layer of "if" by reordering the check > > in route_irq_to_guest() to make

Re: [Xen-devel] AMD VMMCALL and VM86 mode

On 09/12/16 19:55, Boris Ostrovsky wrote: > On 12/09/2016 02:01 PM, Andrew Cooper wrote: >> Hello, >> >> While working on XSA-192, I found a curious thing. On AMD hardware, the >> VMMCALL instruction appears to behave like a nop if executed in VM86 >> mode. All other processor modes work fine.

Re: [Xen-devel] AMD VMMCALL and VM86 mode

On 12/09/2016 02:01 PM, Andrew Cooper wrote: > Hello, > > While working on XSA-192, I found a curious thing. On AMD hardware, the > VMMCALL instruction appears to behave like a nop if executed in VM86 > mode. All other processor modes work fine. > > The documentation suggests it should be valid

Re: [Xen-devel] Future support of 5-level paging in Xen:wq

On 09/12/16 19:31, Stefano Stabellini wrote: > On Fri, 9 Dec 2016, Juergen Gross wrote: >> On 09/12/16 00:50, Stefano Stabellini wrote: >>> On Thu, 8 Dec 2016, Andrew Cooper wrote: On 08/12/2016 19:18, Stefano Stabellini wrote: > On Thu, 8 Dec 2016, Andrew Cooper wrote: >> On 08/12/16

[Xen-devel] [PATCH v2] fix potential int overflow in efi/boot

HorizontalResolution and VerticalResolution are 32bit, while size is 64bit. As it stands multiplications are evaluated with 32bit arithmetic, which could overflow. Cast HorizontalResolution to 64bit to avoid that. Coverity-ID: 1381858 Signed-off-by: Stefano Stabellini

[Xen-devel] [PATCH v2] fix potential pa_range_info out of bound access

pa_range_info has only 8 elements and is accessed using pa_range as index. pa_range is initialized to 16, potentially causing out of bound access errors. Fix the issue by checking that pa_range is not greater than the size of the array. Coverity-ID: 1381865 Signed-off-by: Stefano Stabellini

Re: [Xen-devel] [PATCH] fix potential pa_range_info out of bound access

On Fri, 9 Dec 2016, Julien Grall wrote: > Hi Stefano, > > On 09/12/16 01:40, Stefano Stabellini wrote: > > On Thu, 8 Dec 2016, Stefano Stabellini wrote: > > > pa_range_info has only 8 elements and is accessed using pa_range as > > > index. pa_range is initialized to 16, potentially causing out of

Re: [Xen-devel] [PATCH] missing vgic_unlock_rank in gic_remove_irq_from_guest

On Fri, 9 Dec 2016, Artem Mygaiev wrote: > Hi Stefano > > On 09.12.16 02:59, Stefano Stabellini wrote: > > Add missing vgic_unlock_rank on the error path in > > gic_remove_irq_from_guest. > > > > CID: 1381843 > > > > Signed-off-by: Stefano Stabellini > > > > diff --git

Re: [Xen-devel] Future support of 5-level paging in Xen:wq

On Fri, 9 Dec 2016, Juergen Gross wrote: > On 09/12/16 00:50, Stefano Stabellini wrote: > > On Thu, 8 Dec 2016, Andrew Cooper wrote: > >> On 08/12/2016 19:18, Stefano Stabellini wrote: > >>> On Thu, 8 Dec 2016, Andrew Cooper wrote: > On 08/12/16 16:46, Juergen Gross wrote: > > The first

Re: [Xen-devel] Issue while bringing up libvirtd.service

On Fri, 2016-12-09 at 14:07 +0100, Dario Faggioli wrote: > > Thanks Dario and Wei Liu. I am able to create VMs using XL toolstack and removing old xen and libvirt packages. I think you both were right, I had double environment problem. Thanks once again for your suggestions. > On Thu,

Re: [Xen-devel] Xen Project and Xvisor.

On Fri, Dec 09, 2016 at 06:50:03PM +, Jason Long wrote: > Hello. > I like to see Xen developer ideas and concerns about "Xvisor" hypervisor. Any > experiences and compares? Um (https://github.com/xvisor/xvisor/blob/master/HOSTS), this: M: x86_64 Generic A: x86 64-bit C:

Re: [Xen-devel] [DOC RFC] Heterogeneous Multi Processing Support in Xen

On Fri, 9 Dec 2016, Jan Beulich wrote: > >>> On 09.12.16 at 09:29, wrote: > > On Fri, 2016-12-09 at 01:13 -0700, Jan Beulich wrote: > >> > > > On 08.12.16 at 22:54, wrote: > >> > Yeah, that was what was puzzling me too. Keeping them ordered

Re: [Xen-devel] Xen 4.9 Development Update

On 09/12/16 19:01, Stefano Stabellini wrote: > On Fri, 9 Dec 2016, Oleksandr Andrushchenko wrote: >> On 12/09/2016 03:57 PM, Pasi Kärkkäinen wrote: >>> On Fri, Dec 09, 2016 at 02:57:04PM +0200, Oleksandr Andrushchenko wrote: >> Should we have a section on new PV drivers? If so, I suggest to

Re: [Xen-devel] Xen 4.9 Development Update

On Fri, 9 Dec 2016, Oleksandr Andrushchenko wrote: > On 12/09/2016 03:57 PM, Pasi Kärkkäinen wrote: > > On Fri, Dec 09, 2016 at 02:57:04PM +0200, Oleksandr Andrushchenko wrote: > > > > > Should we have a section on new PV drivers? If so, I suggest to add: > > > > > - Xen transport for 9pfs > > > >

[Xen-devel] AMD VMMCALL and VM86 mode

Hello, While working on XSA-192, I found a curious thing. On AMD hardware, the VMMCALL instruction appears to behave like a nop if executed in VM86 mode. All other processor modes work fine. The documentation suggests it should be valid in any situation, but I never get a #VMEXIT from it.

Re: [Xen-devel] [RFC PATCH 21/24] ARM: vITS: handle INVALL command

On 03/12/16 00:46, Stefano Stabellini wrote: > On Fri, 2 Dec 2016, Andre Przywara wrote: >> Hi, Hi Stefano, I started to answer this email some days ago, but then spend some time on actually implementing what I suggested, hence the delay ... >> >> sorry for chiming in late >> >> I've been

[Xen-devel] Xen Project and Xvisor.

Hello. I like to see Xen developer ideas and concerns about "Xvisor" hypervisor. Any experiences and compares? Thank you. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/3] x86/HVM: support (emulate) UMIP

On 08/12/16 12:20, Jan Beulich wrote: > >> However, it would also require only enabling the SVM GP intercept in the >> hvm_update_guest_vendor() path (which should be renamed to something >> slightly more generic like hvm_cpuid_policy_updated()). > Why that? We always need it intercepted as long

Re: [Xen-devel] [PATCH] p2m: split mem_access into separate files

On Fri, Dec 9, 2016 at 2:27 AM, Jan Beulich wrote: On 08.12.16 at 23:57, wrote: >> --- a/xen/arch/x86/mm/Makefile >> +++ b/xen/arch/x86/mm/Makefile >> @@ -9,6 +9,7 @@ obj-y += guest_walk_3.o >> obj-y += guest_walk_4.o >> obj-y += mem_paging.o

[Xen-devel] [OSSTEST PATCH 1/1] PostgreSQL db: Retry transactions on constraint failures

This is unfortunate but appears to be necessary. Signed-off-by: Ian Jackson CC: pgsql-hack...@postgresql.org --- Osstest/JobDB/Executive.pm | 45 - tcl/JobDB-Executive.tcl| 6 -- 2 files changed, 48 insertions(+), 3

[Xen-devel] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation

Hi. This message is going to xen-devel (because that's where the osstest project is) and to pgsql-hackers (because I hope they may be able to advise about the scope of the PostgreSQL SERIALIZABLE constraint problem). In summary: PostgreSQL only provides transaction serialisability for successful

Re: [Xen-devel] [PATCH v2 1/4] x86/vpmu: Move vpmu_do_cpuid() handling into {pv, hvm}_cpuid()

On 12/09/2016 01:15 PM, Andrew Cooper wrote: > On 06/12/16 11:11, Andrew Cooper wrote: >> On 05/12/16 20:59, Boris Ostrovsky wrote: >>> On 12/05/2016 01:24 PM, Andrew Cooper wrote: @@ -3516,6 +3516,17 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, unsigned int *ebx,

[Xen-devel] [PATCH v4 4/4] x86/asm: Rewrite sync_core() to use IRET-to-self

Aside from being excessively slow, CPUID is problematic: Linux runs on a handful of CPUs that don't have CPUID. Use IRET-to-self instead. IRET-to-self works everywhere, so it makes testing easy. For reference, On my laptop, IRET-to-self is ~110ns, CPUID(eax=1, ecx=0) is ~83ns on native and very

[Xen-devel] [PATCH v4 1/4] x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels

We support various non-Intel CPUs that don't have the CPUID instruction, so the M486 test was wrong. For now, fix it with a big hammer: handle missing CPUID on all 32-bit CPUs. Reported-by: One Thousand Gnomes Signed-off-by: Andy Lutomirski ---

[Xen-devel] [PATCH v4 2/4] Revert "x86/boot: Fail the boot if !M486 and CPUID is missing"

This reverts commit ed68d7e9b9cfb64f3045ffbcb108df03c09a0f98. The patch wasn't quite correct -- there are non-Intel (and hence non-486) CPUs that we support that don't have CPUID. Since we no longer require CPUID for sync_core(), just revert the patch. I think the relevant CPUs are Geode and

[Xen-devel] [PATCH v4 3/4] x86/microcode/intel: Replace sync_core() with native_cpuid()

The Intel microcode driver is using sync_core() to mean "do CPUID with EAX=1". I want to rework sync_core(), but first the Intel microcode driver needs to stop depending on its current behavior. Reported-by: Henrique de Moraes Holschuh Acked-by: Borislav Petkov

[Xen-devel] [PATCH v4 0/4] CPUID-less CPU/sync_core fixes and improvements

*** PATCHES 1 and 2 MAY BE 4.9 MATERIAL *** Alan Cox pointed out that the 486 isn't the only supported CPU that doesn't have CPUID. Let's clean up the mess and make everything faster while we're at it. Patch 1 is intended to be an easy fix: it makes sync_core() work without CPUID on all 32-bit

Re: [Xen-devel] [PATCH] x86/hvm: don't create a default ioreq server...

On 09/12/16 17:55, Paul Durrant wrote: > ...if the domain is not under construction. > > If upstream QEMU is in use then it will explicitly create an ioreq server > rather than implicitly creating the default ioreq server, which is a > side-effect of reading HVM_PARAM_IOREQ_PFN,

[Xen-devel] [PATCH] x86/hvm: don't create a default ioreq server...

...if the domain is not under construction. If upstream QEMU is in use then it will explicitly create an ioreq server rather than implicitly creating the default ioreq server, which is a side-effect of reading HVM_PARAM_IOREQ_PFN, HVM_PARAM_BUFIOREQ_PFN, or HVM_PARAM_BUFIOREQ_EVTCHN (as is done

Re: [Xen-devel] [PATCH v2] xen/arm: Add support for 16 bit VMIDs

On 09/12/16 10:49, Bhupinder Thakur wrote: Hi Julien, Hi Bhupinder, On 6 December 2016 at 21:14, Julien Grall wrote: --- a/xen/arch/arm/setup.c +++ b/xen/arch/arm/setup.c @@ -789,7 +789,8 @@ void __init start_xen(unsigned long boot_phys_offset, gic_init();

Re: [Xen-devel] [PATCH v2 1/4] x86/vpmu: Move vpmu_do_cpuid() handling into {pv, hvm}_cpuid()

On 06/12/16 11:11, Andrew Cooper wrote: > On 05/12/16 20:59, Boris Ostrovsky wrote: >> On 12/05/2016 01:24 PM, Andrew Cooper wrote: >>> @@ -3516,6 +3516,17 @@ void hvm_cpuid(unsigned int input, unsigned int >>> *eax, unsigned int *ebx, >>> if ( !(hvm_pae_enabled(v) ||

Re: [Xen-devel] [PATCH] xen/balloon: Only mark a page as managed when it is released

On 12/09/2016 12:10 PM, Ross Lagerwall wrote: > Only mark a page as managed when it is released back to the allocator. > This ensures that the managed page count does not get falsely increased > when a VM is running. Correspondingly change it so that pages are > marked as unmanaged after getting

Re: [Xen-devel] [RFC PATCH 21/24] ARM: vITS: handle INVALL command

Hi, On 07/12/16 20:20, Stefano Stabellini wrote: > On Tue, 6 Dec 2016, Julien Grall wrote: >> On 06/12/2016 22:01, Stefano Stabellini wrote: >>> On Tue, 6 Dec 2016, Stefano Stabellini wrote: moving a vCPU with interrupts assigned to it is slower than moving a vCPU without interrupts

Re: [Xen-devel] [PATCH 1/3] make tlbflush_filter()'s first parameter a pointer

Hi Jan, On 08/12/16 16:00, Jan Beulich wrote: This brings it in line with most other functions dealing with CPU masks. Convert both implementations to inline functions at once. Signed-off-by: Jan Beulich Acked-by: Julien Grall Regards, -- Julien

Re: [Xen-devel] [PATCH v11 06/13] efi: create new early memory allocator

Hi Daniel, On 05/12/16 22:25, Daniel Kiper wrote: 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

Re: [Xen-devel] [RFC PATCH 21/24] ARM: vITS: handle INVALL command

Hi Stefano, On 07/12/16 20:20, Stefano Stabellini wrote: On Tue, 6 Dec 2016, Julien Grall wrote: On 06/12/2016 22:01, Stefano Stabellini wrote: On Tue, 6 Dec 2016, Stefano Stabellini wrote: moving a vCPU with interrupts assigned to it is slower than moving a vCPU without interrupts assigned

Re: [Xen-devel] [PATCH 1/3] Don't create default ioreq server

> -Original Message- > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] [snip] > > > > > > This bug is caused by the read side effects of > > > HVM_PARAM_IOREQ_PFN. The migration code needs a way of being > able to > > > query whether a default ioreq server exists, without

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

flight 103144 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/103144/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl

Re: [Xen-devel] [PATCH 1/3] Don't create default ioreq server

On Fri, Dec 09, 2016 at 04:43:58PM +, Paul Durrant wrote: > > -Original Message- > > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of > > Konrad Rzeszutek Wilk > > Sent: 09 December 2016 16:14 > > To: Zhang Chen ; Paul Durrant > >

Re: [Xen-devel] [PATCH 2/2] x86emul: consolidate string insn address increments

On 09/12/16 15:22, Jan Beulich wrote: > Move the looking at EFLAGS.DF into the macro, rendering all call sites > more readable. > > Signed-off-by: Jan Beulich The net change is ok; it is certainly cleaner to read in the body of x86_emulate(). However, the naming of

Re: [Xen-devel] [PATCH 1/2] x86emul: use SrcEax/DstEax where suitable for string insns

>>> On 09.12.16 at 18:06, wrote: > On 09/12/16 15:21, Jan Beulich wrote: >> LODS, SCAS, and STOS all use the accumulator as one of their operands. >> This avoids come open coding of things, but requires switching around > > Do you mean "some open coding" ? Indeed I do

[Xen-devel] [PATCH] xen/balloon: Only mark a page as managed when it is released

Only mark a page as managed when it is released back to the allocator. This ensures that the managed page count does not get falsely increased when a VM is running. Correspondingly change it so that pages are marked as unmanaged after getting them from the allocator. Signed-off-by: Ross Lagerwall

Re: [Xen-devel] [PATCH v4 12/14] x86/PVHv2: fix dom0_max_vcpus so it's capped to 128 for PVHv2 Dom0

>>> On 30.11.16 at 17:49, wrote: > @@ -176,6 +177,8 @@ unsigned int __init dom0_max_vcpus(void) > max_vcpus = opt_dom0_max_vcpus_max; > if ( max_vcpus > MAX_VIRT_CPUS ) > max_vcpus = MAX_VIRT_CPUS; > +if ( dom0_hvm ) > +max_vcpus =

Re: [Xen-devel] [PATCH 1/2] x86emul: use SrcEax/DstEax where suitable for string insns

On 09/12/16 15:21, Jan Beulich wrote: > LODS, SCAS, and STOS all use the accumulator as one of their operands. > This avoids come open coding of things, but requires switching around Do you mean "some open coding" ? > operands of SCAS. > > Signed-off-by: Jan Beulich

Re: [Xen-devel] [PATCH v4 11/14] xen/x86: parse Dom0 kernel for PVHv2

>>> On 30.11.16 at 17:49, wrote: > @@ -1930,12 +1931,148 @@ static int __init hvm_setup_p2m(struct domain *d) > #undef MB1_PAGES > } > > +static int __init hvm_copy_to_phys(struct domain *d, paddr_t paddr, void > *buf, > + int size) I

Re: [Xen-devel] [PATCH] docs: turn links to docs/* into absolute path

On Fri, Dec 09, 2016 at 01:02:10PM +0100, Cedric Bosdonnat wrote: > On Fri, 2016-12-09 at 11:25 +, Ian Jackson wrote: > > Hi, Cedric et al.  I like the idea of tidying this up.  Thanks for the > > patch, which (with some small changes) will be a good idea. > > > > Cedric Bosdonnat writes

Re: [Xen-devel] tap device name for emulated NIC too long

On Wed, Nov 30, 2016 at 06:38:45PM -0700, Jim Fehlig wrote: > Hi All, .. crickets.. > > During the last Wg-openstack meetup we briefly discussed a long-standing bug > when using Xen+libvirt+OpenStack with Neutron networking > > https://bugs.launchpad.net/nova/+bug/1450465 > > The bug was also

Re: [Xen-devel] [PATCH v1] arm/irq: Reorder check in route_irq_to_guest() to avoid 4 layers of "if"

Hi Oleksandr, Thank you for the patch. On 06/12/16 17:53, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko Remove one layer of "if" by reordering the check in route_irq_to_guest() to make code more clearer. Signed-off-by: Oleksandr Tyshchenko

Re: [Xen-devel] [PATCH] fix potential pa_range_info out of bound access

Hi Stefano, On 09/12/16 01:40, Stefano Stabellini wrote: On Thu, 8 Dec 2016, Stefano Stabellini wrote: pa_range_info has only 8 elements and is accessed using pa_range as index. pa_range is initialized to 16, potentially causing out of bound access errors. Fix the issue by initializing

Re: [Xen-devel] [PATCH 1/3] Don't create default ioreq server

> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of > Konrad Rzeszutek Wilk > Sent: 09 December 2016 16:14 > To: Zhang Chen ; Paul Durrant > > Cc: Changlong Xie ;

Re: [Xen-devel] [PATCH v4 10/14] xen/x86: populate PVHv2 Dom0 physical memory map

>>> On 30.11.16 at 17:49, wrote: > @@ -302,7 +307,8 @@ static unsigned long __init compute_dom0_nr_pages( > avail -= max_pdx >> s; > } > > -need_paging = opt_dom0_shadow || (is_pvh_domain(d) && > !iommu_hap_pt_share); > +need_paging =

[Xen-devel] nocera1 Re: [xen-unstable test] 103010: regressions - trouble: broken/fail/pass

osstest service owner writes ("[xen-unstable test] 103010: regressions - trouble: broken/fail/pass"): > flight 103010 xen-unstable real [real] > http://logs.test-lab.xenproject.org/osstest/logs/103010/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which

[Xen-devel] [PATCH 04/11] docs: convert xl-disk-configuration into a man page

Convert xl-disk-configuration.txt from plain text file to a POD file to get it as a man page. The references to it in the other man pages are also updated. Signed-off-by: Cédric Bosdonnat --- docs/INDEX | 1 - docs/man/xl-disk-configuration.pod.5

[Xen-devel] [PATCH 11/11] docs: convert tscmode.txt into man page

tscmode.txt is referenced in xl.cfg(5). Convert it into a pod formatted man page. Signed-off-by: Cédric Bosdonnat --- docs/INDEX | 1 - docs/{misc/tscmode.txt => man/tscmode.pod.7} | 109 ++-

[Xen-devel] [PATCH 08/11] docs: convert vtpmmgr into a pod man page

vtpmmgr.txt is referenced in a man page, convert it to a man page. Signed-off-by: Cédric Bosdonnat --- docs/{misc/vtpmmgr.txt => man/vtpmmgr.pod.7} | 351 --- 1 file changed, 206 insertions(+), 145 deletions(-) rename docs/{misc/vtpmmgr.txt =>

[Xen-devel] [PATCH 01/11] docs: allow writing man pages in markdown

Some of the docs/misc documents are written in markdown language. As an effort to cleanup man pages these documents will be converted into man pages. To avoid some more conversion, add rules to the docs/Makefile to generate man pages out of markdown files as well as pod ones. However, pandoc

[Xen-devel] [PATCH 05/11] docs: move vbd-interface from misc to man

Make vbd-interface a man page, section7, as this document is referenced in other man pages (xl-disk-configuration) Signed-off-by: Cédric Bosdonnat --- docs/INDEX| 1 - docs/{misc/vbd-interface.txt =>

[Xen-devel] [PATCH 00/11] Convert a few docs/misc pages into man pages

As pointed out in Ian and Andrew's emails on my recent docs improvement attempt, getting the documents from docs/misc referenced in man pages as man pages would would make these pages more visible for users. This would also not break the docs html INDEX. This series adds ability to write markdown

[Xen-devel] [PATCH 06/11] docs: move xl-numa-placement.markdown to man7

docs/misc/xl-numa-placement.markdown is referenced by xl.cfg.5 man page, move it to a man page, section 7. Signed-off-by: Cédric Bosdonnat --- .../xl-numa-placement.markdown => man/xl-numa-placement.markdown.7} | 0 docs/man/xl.cfg.pod.5.in

[Xen-devel] [PATCH 10/11] docs: move pci-device-reservations from misc to man

pci-device-reservations is references in xl.cfg(5), convert it as a man page in pod format. The name is now prefixed with 'xen-' to avoid possible name conflicts. Signed-off-by: Cédric Bosdonnat --- docs/man/xen-pci-device-reservations.pod.7 | 84

[Xen-devel] [PATCH 02/11] docs: add rules for man 7 section

Some of the docs/misc documents will need to go in man 7 section, prepare docs/Makefile for it. Signed-off-by: Cédric Bosdonnat --- .gitignore| 1 + docs/Makefile | 9 - 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/.gitignore b/.gitignore index

[Xen-devel] [PATCH 07/11] docs: move vtpm from misc to man

vtpm.txt is referenced in xl.cfg man page. Convert it to pod, move it to the man folder and update the reference. Signed-off-by: Cédric Bosdonnat --- docs/INDEX | 1 - docs/{misc/vtpm.txt => man/vtpm.pod.7} | 364

[Xen-devel] [PATCH 03/11] docs: xl-network-configuration turns into a man

Move docs/misc/xl-network-configuration.markdown to docs/man and update the references to it in the other man pages. Signed-off-by: Cédric Bosdonnat --- docs/INDEX| 1 - .../xl-network-configuration.markdown.5}

[Xen-devel] [PATCH 09/11] docs: convert misc/channel.txt into xen-pv-channel man page

channel.txt is referenced in xl.cfg(5). Move it to man pages, section 7 Signed-off-by: Cédric Bosdonnat --- .../channel.txt => man/xen-pv-channel.markdown.7}| 20 ++-- docs/man/xl.cfg.pod.5.in | 2 +- 2 files changed, 11

Re: [Xen-devel] Xen/cdrom: Ubuntu 16.04 VM read the content from CD-ROM abnormally

On Fri, Dec 09, 2016 at 04:21:02PM +0800, Ken wrote: > Hi all, > > I run the Ubuntu 16.04 server (2 vcpu/2G, Linux 4.4.0) on the Xen-4.1.2, and > installed gcc through the CDROM used by 16.04 iso file, when I installed gcc > that depends deb packages to decompress failed. But uploaded the ISO

Re: [Xen-devel] [PATCH 1/3] Don't create default ioreq server

.snip.. > > If you can be more specific about what is broken in COLO we might be > > able to devise a fix for you. > > My workmate have reported this BUG last year: > https://lists.xenproject.org/archives/html/xen-devel/2015-12/msg02850.html Paul, Andrew was asking about: This bug is

Re: [Xen-devel] [PATCH v4 09/14] xen/x86: split Dom0 build into PV and PVHv2

>>> On 30.11.16 at 17:49, wrote: > --- a/docs/misc/xen-command-line.markdown > +++ b/docs/misc/xen-command-line.markdown > @@ -656,6 +656,23 @@ affinities to prefer but be not limited to the specified > node(s). > > Pin dom0 vcpus to their respective pcpus > > +###

[Xen-devel] [PATCH 5/8] libelf: loop safety: Replace all calls to strcmp

strcmp can do singificant work, and is found in some inner loops where we search for the meaning of things we find in the image. We need to avoid doing too much work. So replace all calls to strcmp with elf_strcmp_safe. Signed-off-by: Ian Jackson ---

[Xen-devel] [PATCH 2/8] libelf: loop safety: Pass `elf' to elf_xen_parse_features

Not used yet, so no functional change. We will need this in a moment. Signed-off-by: Ian Jackson --- xen/common/libelf/libelf-dominfo.c | 5 +++-- xen/include/xen/libelf.h | 3 ++- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git

Re: [Xen-devel] Intel board support for xen

On Fri, Dec 09, 2016 at 06:40:07PM +0530, George John wrote: > Hi all, > > I am a newbie in xen. I wish to know which all intel platforms support xen > hypervisor?. All the ones that can do 64-bit mode. ___ Xen-devel mailing list

[Xen-devel] [PATCH] xen/setup: Don't relocate p2m/initrd over existing one

When relocating the p2m/initrd, take special care not to relocate it so that is overlaps with the current location of the p2m/initrd. This is needed since the full extent of the current location is not marked as a reserved region in the e820 (and it shouldn't be since it is about to be moved).

[Xen-devel] [PATCH 1/8] libelf: loop safety: Introduce elf_iter_ok and elf_strcmp_safe

This will allow us to keep track of the total amount of work we are doing. When it becomes excessive, we mark the ELF broken, and stop processing. This is a more robust way of preventing DoS problems by bad images than attempting to prove, for each of the (sometimes rather deeply nested) loops,

[Xen-devel] [PATCH 6/8] libelf: loop safety cleanup: Remove obsolete check in elf_shdr_count

All the loops which might go out of control, due to excessive shdrs, have been decorated with elf_iter_ok. So there is no need for this explicit (and rather crude) check. (Anyway, the count was a 16-bit field, so the check was redundant.) Signed-off-by: Ian Jackson

[Xen-devel] [PATCH 4/8] libelf: loop safety: Call elf_iter_ok_counted at every *mem*_unsafe

When we use elf_mem*_unsafe, we need to check that we are not doing too much work. Ensure that a call to elf_iter_ok_counted is near every call to elf_mem*_unsafe. (At one call site, just have a comment instead.) Signed-off-by: Ian Jackson ---

[Xen-devel] [PATCH 3/8] libelf: loop safety: Call elf_iter_ok[_counted] in every loop

In every `for' or `while' loop, either call elf_iter_ok, or explain why it's not necessary. This is part of comprehensive defence against out of control loops. Signed-off-by: Ian Jackson --- xen/common/libelf/libelf-dominfo.c | 22 +-

[Xen-devel] [PATCH 8/8] libelf: safety: Document safety principles in header file

Signed-off-by: Ian Jackson --- xen/include/xen/libelf.h | 92 1 file changed, 92 insertions(+) diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h index 6436bd7..8b75242 100644 ---

[Xen-devel] [PATCH 0/8] libelf: safety enhancements

We recently discovered two near-miss in libelf: * The intended method for limiting the phdr loop iteration count was not effective. But happily this turned not to be important because the count field is only 16 bits. * A recent commit accidentally introduced a division by zero

[Xen-devel] [PATCH 7/8] libelf: loop safety cleanup: Remove superseded image size copy check

Now, elf_load_image eventually calls elf_memcpy_safe, which calls elf_iter_ok_counted. So there is a work limit of 4x the image size. This is larger than the previous limit of 2x the image size, but it includes a lot of other processing too. And the purpose is to reject bad images without a

  1   2   3   >