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

On 15/12/16 19:41, Dario Faggioli wrote: > On Thu, 2016-12-08 at 11:38 +0100, Juergen Gross wrote: >> So you really solved the following problem in credit2? >> >> You have three domains with 2 vcpus each and different weights. Run >> them >> on 3 physical cpus with following pinning: >> >> dom1:

Re: [Xen-devel] arm64: Approach for DT based NUMA and issues

On Tue, Nov 29, 2016 at 12:29 AM, Julien Grall wrote: > > > On 26/11/16 06:59, Vijay Kilari wrote: >> >> Hi, > > > Hi Vijay, > > This mail is mixing two distinct problems: > 1) Making Xen NUMA-aware > 2) Make DOM0 NUMA-aware > > As mentioned in another part

[Xen-devel] [xen-4.4-testing baseline-only test] 68226: regressions - FAIL

This run is configured for baseline tests only. flight 68226 xen-4.4-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68226/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-320

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On 15/12/16 18:36, Borislav Petkov wrote: > On Thu, Dec 15, 2016 at 12:27:49PM -0500, Boris Ostrovsky wrote: >> It will probably fix it but I don't think we want this: it's a >> build-time solution. Most kernels have XEN on even though they are >> booted bare-metal. > > Lemme tell you want I

Re: [Xen-devel] [PATCH v2] x86/emul: Simplfy L{ES, DS, SS, FS, GS} handling

>>> On 15.12.16 at 18:10, wrote: > %ss, %fs and %gs can be calculated by directly masking the opcode. %es and > %ds cant, but the calculation isn't hard. > > Use seg rather than dst.val for storing the calculated segment, which is > appropriately typed. Drop the sel

[Xen-devel] [XEN VMID RESEND v5 2/2] xen/arm: Add support for 16 bit VMIDs

VMID space is increased to 16-bits from 8-bits in ARMv8 8.1 revision. This allows more than 256 VMs to be supported by Xen. This change adds support for 16-bit VMIDs in Xen based on whether the architecture supports it. Signed-off-by: Bhupinder Thakur ---

[Xen-devel] [XEN VMID RESEND v5 1/2] xen/arm: Move p2m_vmid_allocator_init() inside setup_virt_paging()

Since VMIDs are related to 2nd stage address translation, it makes more sense to move the call to p2m_vmid_allocator_init(), which initializes the vmid allocation bitmap, inside setup_virt_paging(), where 2nd stage address translation is set up. Signed-off-by: Bhupinder Thakur

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

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

[Xen-devel] [linux-4.1 bisection] complete test-amd64-amd64-qemuu-nested-intel

branch xen-unstable xenbranch xen-unstable job test-amd64-amd64-qemuu-nested-intel testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu

[Xen-devel] [xen-unstable-smoke test] 103439: regressions - FAIL

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

[Xen-devel] [ovmf baseline-only test] 68227: all pass

This run is configured for baseline tests only. flight 68227 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68227/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf aaa61995af9e0b65c37bdad6796867760fa1d5fe baseline

[Xen-devel] RFC: p2m type change draft

Yu Zhang, As we discussed, attached is the draft of the change to the p2m_change_entry_type changes I was working on. Currently, Xen keeps track of what certain types “should” be, via a list of logdirty ranges as well as mmio ranges. This patch series attempts to do the opposite: to make

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

> On Dec 16, 2016, at 12:43 AM, Jan Beulich wrote: > On 09.12.16 at 16:44, wrote: >> + * - Any loop needs to be accompanied by calls to elf_iter_ok (or >> + *elf_iter_ok_counted). >> + * >> + *Rationale: the image must not be able

Re: [Xen-devel] [PATCH RFC] tools/xenlight: Create xenlight Makefile

On Fri, Dec 16, 2016 at 7:20 AM, Ronald Rojas wrote: > Create a basic Makefile to build and install libxenlight Golang > bindings. Also add a template. What's this template again? > > --- > > Eventually this patch will contain the actual bindings package; for > now it just

Re: [Xen-devel] [PATCH RFC] tools/xenlight: Create xenlight Makefile

> On Dec 16, 2016, at 11:20 AM, Doug Goldstein wrote: > > On 12/15/16 5:20 PM, Ronald Rojas wrote: >> Create a basic Makefile to build and install libxenlight Golang >> bindings. Also add a template. >> >> --- >> >> Eventually this patch will contain the actual bindings

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On Fri, 16 Dec 2016, Borislav Petkov wrote: > What for? We don't want to run the microcode loader on xen at all. Or under KVM, or any other hypervisor, really. -- Henrique Holschuh ___ Xen-devel mailing list Xen-devel@lists.xen.org

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On 12/15/2016 06:04 PM, Borislav Petkov wrote: On Thu, Dec 15, 2016 at 05:56:44PM -0500, Boris Ostrovsky wrote: With CONFIG_PARAVIRT (which I suspect you don't have on) cpuid() is a call via a pointer, you can see it, for example, if you disassemble load_ucode_amd_bsp(). And we don't have

Re: [Xen-devel] [PATCH RFC] tools/xenlight: Create xenlight Makefile

On 12/15/16 5:20 PM, Ronald Rojas wrote: > Create a basic Makefile to build and install libxenlight Golang > bindings. Also add a template. > > --- > > Eventually this patch will contain the actual bindings package; for > now it just includes a stub package. > So I'm curious why the interest

[Xen-devel] [xen-unstable-smoke test] 103429: regressions - FAIL

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

[Xen-devel] [xen-4.4-testing test] 103365: regressions - FAIL

flight 103365 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/103365/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-3 20 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 102521

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

On Wed, 2016-12-14 at 03:39 +0100, George Dunlap wrote: > > On Dec 10, 2016, at 4:18 AM, Stefano Stabellini > .org> wrote: > > > > The issue with spreading interrupts migrations over time is > > > > that it makes > > > > interrupt latency less deterministic. It is OK, in the

Re: [Xen-devel] [PATCH v2] xen: sched: removal of redundant check in Credit

On Thu, 2016-12-15 at 23:39 +0530, Praveen Kumar wrote: > The patch gets rid of a redundant check in csched_vcpu_acct. In fact, > the function is only called from csched_tick, which already checks > that current is not the idle vcpu. The patch also adds an ASSERT to > the same effect, in order to

Re: [Xen-devel] [PATCH] xen/arm: fix rank/vgic locks inversion bug

On Thu, 15 Dec 2016, Julien Grall wrote: > Hi Stefano, > > On 15/12/2016 01:04, Stefano Stabellini wrote: > > The locking order is: first rank lock, then vgic lock. The order is > > respected everywhere, except for gic_update_one_lr. > > > > gic_update_one_lr is called with the vgic lock held,

[Xen-devel] [xen-unstable-smoke test] 103422: regressions - FAIL

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

[Xen-devel] [PATCH RFC] tools/xenlight: Create xenlight Makefile

Create a basic Makefile to build and install libxenlight Golang bindings. Also add a template. --- Eventually this patch will contain the actual bindings package; for now it just includes a stub package. To Do: - Have configure detect golang bindings properly CC: xen-devel

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On Thu, Dec 15, 2016 at 05:56:44PM -0500, Boris Ostrovsky wrote: > With CONFIG_PARAVIRT (which I suspect you don't have on) cpuid() is a > call via a pointer, you can see it, for example, if you disassemble > load_ucode_amd_bsp(). And we don't have paging on yet when we call > load_ucode_amd_bsp

Re: [Xen-devel] [PATCH] xen/arm: fix rank/vgic locks inversion bug

Hi Stefano, On 15/12/2016 01:04, Stefano Stabellini wrote: The locking order is: first rank lock, then vgic lock. The order is respected everywhere, except for gic_update_one_lr. gic_update_one_lr is called with the vgic lock held, but it calls vgic_get_target_vcpu, which tries to obtain the

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On 12/15/2016 03:03 PM, Borislav Petkov wrote: > On Thu, Dec 15, 2016 at 02:36:46PM -0500, Boris Ostrovsky wrote: >> We are calling find_proper_container(..., _id) and determine result >> based on eq_id not being zero. If find_proper_container() doesn't find >> anything it will not modify eq_id

Re: [Xen-devel] [XEN VMID PATCH v5 2/2] xen/arm: Add support for 16 bit VMIDs

On 15/12/2016 17:35, Bhupinder Thakur wrote: Hi Julien, Hi Bhupinder, Thanks for the clarification. One more confirmation: When the reviewer asks you to add the reviewed-by tag to one of the patch in the series then also the whole series should be resent with just the reviewed-by tag added

[Xen-devel] [xen-unstable-smoke test] 103417: regressions - FAIL

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

[Xen-devel] [xen-unstable baseline-only test] 68224: regressions - FAIL

This run is configured for baseline tests only. flight 68224 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68224/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-win7-amd64 9

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On Thu, Dec 15, 2016 at 02:36:46PM -0500, Boris Ostrovsky wrote: > We are calling find_proper_container(..., _id) and determine result > based on eq_id not being zero. If find_proper_container() doesn't find > anything it will not modify eq_id and so you get back whatever you > passed in. The

[Xen-devel] [xen-4.7-testing test] 103351: regressions - FAIL

flight 103351 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/103351/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 103163

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On 12/15/2016 02:23 PM, Borislav Petkov wrote: > On Thu, Dec 15, 2016 at 02:08:50PM -0500, Boris Ostrovsky wrote: >> This fixes my PV boot problem. I am still failing to boot HVM, will >> need to look at this some more. > No, no more stabbing in the dark and no more brown paper bags. This fixes a

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On Thu, Dec 15, 2016 at 02:08:50PM -0500, Boris Ostrovsky wrote: > This fixes my PV boot problem. I am still failing to boot HVM, will > need to look at this some more. No, no more stabbing in the dark and no more brown paper bags. Please check whether CPUID(4) works that early in any xen guest

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On 12/15/2016 12:36 PM, Borislav Petkov wrote: > On Thu, Dec 15, 2016 at 12:27:49PM -0500, Boris Ostrovsky wrote: >> It will probably fix it but I don't think we want this: it's a >> build-time solution. Most kernels have XEN on even though they are >> booted bare-metal. > Lemme tell you want I

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

On Thu, 2016-12-08 at 11:38 +0100, Juergen Gross wrote: > So you really solved the following problem in credit2? > > You have three domains with 2 vcpus each and different weights. Run > them > on 3 physical cpus with following pinning: > > dom1: pcpu 1 and 2 > dom2: pcpu 2 and 3 > dom3: pcpu 1

[Xen-devel] [PATCH v2] xen: sched: removal of redundant check in Credit

The patch gets rid of a redundant check in csched_vcpu_acct. In fact, the function is only called from csched_tick, which already checks that current is not the idle vcpu. The patch also adds an ASSERT to the same effect, in order to make assumption ( i.e., no calling this on idle vcpus) even more

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

On Fri, Dec 9, 2016 at 10:24 AM, Andy Lutomirski wrote: > *** 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. > Ping?

[Xen-devel] [xen-unstable-smoke test] 103412: regressions - FAIL

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

Re: [Xen-devel] [XEN VMID PATCH v5 2/2] xen/arm: Add support for 16 bit VMIDs

Hi Julien, Thanks for the clarification. One more confirmation: When the reviewer asks you to add the reviewed-by tag to one of the patch in the series then also the whole series should be resent with just the reviewed-by tag added to that single patch. Regards, Bhupinder On 15 December 2016

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On Thu, Dec 15, 2016 at 12:27:49PM -0500, Boris Ostrovsky wrote: > It will probably fix it but I don't think we want this: it's a > build-time solution. Most kernels have XEN on even though they are > booted bare-metal. Lemme tell you want I want: a way to detect I'm running on xen. Does CPUID(4)

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On 12/15/2016 12:17 PM, Borislav Petkov wrote: > On Thu, Dec 15, 2016 at 12:00:22PM -0500, Boris Ostrovsky wrote: >> There is an error on AMD as well. We end up being called at >> load_microcode_amd() with size=0 and crash soon after. > Does that fix it? > > diff --git a/arch/x86/Kconfig

Re: [Xen-devel] [XEN VMID PATCH v5 2/2] xen/arm: Add support for 16 bit VMIDs

On 15/12/2016 17:14, Bhupinder Thakur wrote: Hi Julien, Hi Bhupinder, I did not send the 1st patch in the series as there is no change in the first patch since the last one I sent. I understood from your last mail that I need not send the patch again if there is no change. You

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On Thu, Dec 15, 2016 at 12:00:22PM -0500, Boris Ostrovsky wrote: > There is an error on AMD as well. We end up being called at > load_microcode_amd() with size=0 and crash soon after. Does that fix it? diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index dd47e60aabf5..e238119b5dff 100644 ---

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On Thu, Dec 15, 2016 at 04:59:49PM +, Andrew Cooper wrote: > Xen has the same logic as Linux does to look for an uncompressed > microcode blob in the initrd and apply it early in boot. > > If dom0 goes looking, it should see the same microcode version as it has > in its initrd. So it sounds

Re: [Xen-devel] [XEN VMID PATCH v5 2/2] xen/arm: Add support for 16 bit VMIDs

Hi Julien, I did not send the 1st patch in the series as there is no change in the first patch since the last one I sent. I understood from your last mail that I need not send the patch again if there is no change. Should I send it again after updating the version as 5? Should I add the

[Xen-devel] [PATCH v2] x86/emul: Simplfy L{ES, DS, SS, FS, GS} handling

%ss, %fs and %gs can be calculated by directly masking the opcode. %es and %ds cant, but the calculation isn't hard. Use seg rather than dst.val for storing the calculated segment, which is appropriately typed. Drop the sel local variable entirely and use dst.val instead. The mode_64bit()

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On 15/12/16 17:46, Borislav Petkov wrote: > On Thu, Dec 15, 2016 at 05:12:04PM +0100, Juergen Gross wrote: >> with today's kernel the system isn't coming up when booted as Xen dom0: > > Remind me again pls, is dom0 even supposed to load microcode? Isn't the > hypervisor supposed to apply

Re: [Xen-devel] [XEN VMID PATCH v5 2/2] xen/arm: Add support for 16 bit VMIDs

Hi, The patch indicates "2/2" but I can't find the first patch. Is it a mistake? Cheers, On 15/12/2016 16:55, Bhupinder Thakur wrote: VMID space is increased to 16-bits from 8-bits in ARMv8 8.1 revision. This allows more than 256 VMs to be supported by Xen. This change adds support for

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On 15/12/16 16:53, Jan Beulich wrote: On 15.12.16 at 17:46, wrote: >> On Thu, Dec 15, 2016 at 05:12:04PM +0100, Juergen Gross wrote: >>> with today's kernel the system isn't coming up when booted as Xen dom0: >> Remind me again pls, is dom0 even supposed to load microcode?

[Xen-devel] [XEN VMID PATCH v5 2/2] xen/arm: Add support for 16 bit VMIDs

VMID space is increased to 16-bits from 8-bits in ARMv8 8.1 revision. This allows more than 256 VMs to be supported by Xen. This change adds support for 16-bit VMIDs in Xen based on whether the architecture supports it. Signed-off-by: Bhupinder Thakur ---

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On 12/15/2016 11:46 AM, Borislav Petkov wrote: > On Thu, Dec 15, 2016 at 05:12:04PM +0100, Juergen Gross wrote: >> with today's kernel the system isn't coming up when booted as Xen dom0: > Remind me again pls, is dom0 even supposed to load microcode? Isn't the > hypervisor supposed to apply

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

ok thank you very much On Tuesday, December 13, 2016, Konrad Rzeszutek Wilk wrote: > On Tue, Dec 13, 2016 at 10:58:53AM +0530, George John wrote: > > no, I meant some embedded platform like say for example minnowboard. Any > > other boards like minnowboard? > > Based n

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

>>> On 15.12.16 at 17:46, wrote: > On Thu, Dec 15, 2016 at 05:12:04PM +0100, Juergen Gross wrote: >> with today's kernel the system isn't coming up when booted as Xen dom0: > > Remind me again pls, is dom0 even supposed to load microcode? Isn't the > hypervisor supposed to apply

Re: [Xen-devel] FATAL TRAP on __do_update_va_mapping when booting Xen 4.8

>>> On 15.12.16 at 17:33, wrote: > We're getting a FATAL TRAP when booting Xen 4.8 on 2 different servers (Xeon > L5640 and Xeon L5520). The same xen binary boots fine on a third server with a > Xeon E5-2650 v2 CPU, and the 3 servers boot fine when Xen is built with -01

Re: [Xen-devel] [PATCH 2/2] cpufreq: Remove cpu hotplug callbacks only if they were initialized

On Thu, 15 Dec 2016, Boris Ostrovsky wrote: > Since cpu hotplug callbacks are requested for CPUHP_AP_ONLINE_DYN state, > successful callback initialization will result in cpuhp_setup_state() > returning a positive value. Therefore acpi_cpufreq_online being zero > indicates that callbacks have not

Re: [Xen-devel] FATAL TRAP on __do_update_va_mapping when booting Xen 4.8

On 15/12/16 16:33, Vincent Legout wrote: > Hello, > > We're getting a FATAL TRAP when booting Xen 4.8 on 2 different servers (Xeon > L5640 and Xeon L5520). The same xen binary boots fine on a third server with a > Xeon E5-2650 v2 CPU, and the 3 servers boot fine when Xen is built with -01 >

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On Thu, Dec 15, 2016 at 05:12:04PM +0100, Juergen Gross wrote: > with today's kernel the system isn't coming up when booted as Xen dom0: Remind me again pls, is dom0 even supposed to load microcode? Isn't the hypervisor supposed to apply microcode? > Looking into the state of cpu 1 I find the

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

>>> On 09.12.16 at 16:44, wrote: > +/* > + * DESIGN PRINCIPLES FOR THE SAFETY OF LIBELF > + * > + * libelf is a complex piece of code on a security boundary: when > + * built as part of the tools, it parses guest kernels and loads them > + * into guest memory. Bugs in

[Xen-devel] FATAL TRAP on __do_update_va_mapping when booting Xen 4.8

Hello, We're getting a FATAL TRAP when booting Xen 4.8 on 2 different servers (Xeon L5640 and Xeon L5520). The same xen binary boots fine on a third server with a Xeon E5-2650 v2 CPU, and the 3 servers boot fine when Xen is built with -01 instead of -02 (gcc 4.9.2-10 from Debian jessie). I've

Re: [Xen-devel] [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages] [and 1 more messages]

On Thu, Dec 15, 2016 at 9:53 AM, Ian Jackson wrote: > I don't think "set max_pred_locks_per_transaction generously" is a > practical thing to write in the documentation, because the application > programmer, or admin, has no sensible way to calculate what a >

Re: [Xen-devel] [PATCH v2 7/8] dm_op: convert HVMOP_inject_trap and HVMOP_inject_msi

> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan > Beulich > Sent: 15 December 2016 16:23 > To: Paul Durrant > Cc: Andrew Cooper ; Daniel De Graaf > ; Wei Liu

Re: [Xen-devel] [PATCH v2 5/8] dm_op: convert HVMOP_modified_memory

> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan > Beulich > Sent: 15 December 2016 16:06 > To: Paul Durrant > Cc: Andrew Cooper ; Daniel De Graaf > ; Wei Liu

Re: [Xen-devel] [PATCH v2 3/8] dm_op: convert HVMOP_track_dirty_vram

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 15 December 2016 15:45 > To: Paul Durrant > Cc: Andrew Cooper ; Wei Liu > ; George Dunlap ; Ian > Jackson

Re: [Xen-devel] [PATCH v2 7/8] dm_op: convert HVMOP_inject_trap and HVMOP_inject_msi

>>> On 06.12.16 at 14:46, wrote: > +struct xen_dm_op_inject_trap { > +/* IN - index of vCPU */ > +uint32_t vcpuid; > +/* IN - interrupt vector */ > +uint8_t vector; > +/* IN - trap type (DMOP_TRAP_* ) */ > +uint8_t type; > +/* NB. This enumeration

Re: [Xen-devel] SMBIOS UUID

On 12/12/16 19:05, Dejan Markic wrote: > Hello all, > > sorry, as this might be a stupid question for some of you, but I > wonder why here: > > https://github.com/mirage/xen/blob/master/tools/firmware/hvmloader/smbios.c#L438 > > > You allow almost everything to be overwritten in SMBIOS type 1

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

Hi George, On 15/12/16 04:54, George Dunlap wrote: On Wed, Dec 14, 2016 at 8:05 PM, Julien Grall wrote: Note that ARM does not provide any hardware instruction to translate an IPA (guest physical address) to a PA. So we have a walker there. We also a walk for debugging

[Xen-devel] Can't boot as Xen dom0 due to commit fe055896

Boris, with today's kernel the system isn't coming up when booted as Xen dom0: [ 33.575326] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [swapper/0:1] [ 33.589795] Modules linked in: [ 33.596015] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-pv+ #687 [ 33.608844] Hardware

Re: [Xen-devel] [PATCH v2 6/8] dm_op: convert HVMOP_set_mem_type

>>> On 06.12.16 at 14:46, wrote: > --- a/xen/arch/x86/hvm/dm.c > +++ b/xen/arch/x86/hvm/dm.c > @@ -199,6 +199,87 @@ static int modified_memory(struct domain *d, xen_pfn_t > *first_pfn, > return rc; > } > > +static bool allow_p2m_type_change(p2m_type_t old,

Re: [Xen-devel] [PATCH v2 5/8] dm_op: convert HVMOP_modified_memory

>>> On 06.12.16 at 14:46, wrote: > @@ -142,18 +143,77 @@ static int set_isa_irq_level(struct domain *d, uint8_t > isa_irq, > return 0; > } > > +static int modified_memory(struct domain *d, xen_pfn_t *first_pfn, > + unsigned int *nr) > +{

Re: [Xen-devel] [PATCH v2] VT-d: correct dma_msi_set_affinity()

On 15/12/16 15:53, Jan Beulich wrote: > Commit 83cd2038fe ("VT-d: use msi_compose_msg()) together with > 15aa6c6748 ("amd iommu: use base platform MSI implementation"), > introducing the use of a per-CPU scratch CPU mask, went too far: > dma_msi_set_affinity() may, at least in theory, be called in

Re: [Xen-devel] [PATCH v2 1/8] public / x86: Introduce __HYPERCALL_dm_op...

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 15 December 2016 15:23 > To: Paul Durrant > Cc: Andrew Cooper ; Ian Jackson > ; Jennifer Herbert ; > Wei Liu

[Xen-devel] [ovmf test] 103347: all pass - PUSHED

flight 103347 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/103347/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf aaa61995af9e0b65c37bdad6796867760fa1d5fe baseline version: ovmf

Re: [Xen-devel] [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages] [and 1 more messages]

Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages] [and 1 more messages]"): > On Thu, Dec 15, 2016 at 6:09 AM, Ian Jackson > wrote: > > [...] Are there other reasons, > > besides previously

[Xen-devel] [PATCH v2] VT-d: correct dma_msi_set_affinity()

Commit 83cd2038fe ("VT-d: use msi_compose_msg()) together with 15aa6c6748 ("amd iommu: use base platform MSI implementation"), introducing the use of a per-CPU scratch CPU mask, went too far: dma_msi_set_affinity() may, at least in theory, be called in interrupt context, and hence the use of that

Re: [Xen-devel] [PATCH] x86: streamline copying to/from user memory

On 06/12/16 11:25, Jan Beulich wrote: > Their size parameters being "unsigned", there's neither a point for > them returning "unsigned long", nor for any of their (assembly) > arithmetic to involved 64-bit operations on other than addresses. > > Take the opportunity and fold __do_clear_user() into

Re: [Xen-devel] [PATCH v2 4/8] dm_op: convert HVMOP_set_pci_intx_level, HVMOP_set_isa_irq_level, and...

>>> On 06.12.16 at 14:46, wrote: > --- a/xen/include/public/hvm/dm_op.h > +++ b/xen/include/public/hvm/dm_op.h > @@ -191,6 +191,49 @@ struct xen_dm_op_track_dirty_vram { > uint64_aligned_t first_pfn; > }; > > +/* > + * XEN_DMOP_set_pci_intx_level: Set the logical

Re: [Xen-devel] [PATCH v2 3/8] dm_op: convert HVMOP_track_dirty_vram

>>> On 06.12.16 at 14:46, wrote: > @@ -68,6 +70,35 @@ static int > copy_buf_to_guest(XEN_GUEST_HANDLE_PARAM(xen_dm_op_buf_t) bufs, > return copy_to_guest(buf.h, src, size) ? -EFAULT : 0; > } > > +static int track_dirty_vram(struct domain *d, > +

[Xen-devel] [xen-unstable-smoke test] 103406: regressions - FAIL

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

Re: [Xen-devel] Ping: Re: [PATCH 2/3] VT-d: correct dma_msi_set_affinity()

On 15/12/16 14:16, Jan Beulich wrote: On 15.12.16 at 13:52, wrote: >> On 15/12/16 09:54, Jan Beulich wrote: >> On 09.12.16 at 09:47, wrote: >>> On 08.12.16 at 18:33, wrote: > On 08/12/16 16:01, Jan Beulich

Re: [Xen-devel] [PATCH 3/3] x86: introduce and use scratch CPU mask

On 15/12/16 14:59, Jan Beulich wrote: On 15.12.16 at 15:15, wrote: >> On 09/12/16 08:59, Jan Beulich wrote: >> On 08.12.16 at 18:51, wrote: On 08/12/16 16:02, Jan Beulich wrote: > variable. With an IRQ happening at the

Re: [Xen-devel] [PATCH v2 2/8] dm_op: convert HVMOP_*ioreq_server*

>>> On 06.12.16 at 14:46, wrote: > switch ( op.op ) > { > +case XEN_DMOP_create_ioreq_server: > +{ > +struct domain *curr_d = current->domain; > +struct xen_dm_op_create_ioreq_server *data = > +_ioreq_server; > + > +rc

Re: [Xen-devel] [PATCH v2 1/8] public / x86: Introduce __HYPERCALL_dm_op...

>>> On 06.12.16 at 14:46, wrote: > ...as a set of hypercalls to be used by a device model. > > As stated in the new docs/designs/dm_op.markdown: > > "The aim of DMOP is to prevent a compromised device model from > compromising domains other then the one it is associated

[Xen-devel] [xtf test] 103339: all pass - PUSHED

flight 103339 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/103339/ Perfect :-) All tests in this flight passed as required version targeted for testing: xtf 5f54a923b496210af833b902afcc56b1982818a4 baseline version: xtf

Re: [Xen-devel] [xen-4.5-testing test] 103161: regressions - FAIL [and 1 more messages]

Ian Jackson writes ("Re: [xen-4.5-testing test] 103161: regressions - FAIL"): > Andrew Cooper writes ("Re: [xen-4.5-testing test] 103161: regressions - > FAIL"): > > These leak check failures are because the XSA-195 PoC is somehow causing > > qemu to segfault. I cant explain why, because qemu

Re: [Xen-devel] Ping: [PATCH v2 RESEND] x86/time: correctly honor late clearing of TSC related feature flags

>>> On 15.12.16 at 12:04, wrote: > On 15/12/16 09:49, Jan Beulich wrote: > On 06.12.16 at 11:51, wrote: >>> As such clearing of flags may have an impact on the selected rendezvous >>> function, handle such in a central place. >>> >>> But don't

[Xen-devel] [PATCH 1/2] cpu/hotplug: Clarify description of __cpuhp_setup_state() return value

When ivoked with CPUHP_AP_ONLINE_DYN state __cpuhp_setup_state() is expected to return positive value which is the hotplug state that the routine assigns. Signed-off-by: Boris Ostrovsky --- kernel/cpu.c |6 +- 1 files changed, 5 insertions(+), 1 deletions(-)

[Xen-devel] [PATCH 2/2] cpufreq: Remove cpu hotplug callbacks only if they were initialized

Since cpu hotplug callbacks are requested for CPUHP_AP_ONLINE_DYN state, successful callback initialization will result in cpuhp_setup_state() returning a positive value. Therefore acpi_cpufreq_online being zero indicates that callbacks have not been installed. This means that

Re: [Xen-devel] Ping: Re: [PATCH 2/2] x86: drop cpu_has_sse{,2}

>>> On 15.12.16 at 13:03, wrote: > On 15/12/16 09:57, Jan Beulich wrote: > On 09.12.16 at 16:27, wrote: >> On 09.12.16 at 16:19, wrote: >>> On 09.12.16 at 15:56, wrote: > It is a

Re: [Xen-devel] [PATCH 3/3] x86: introduce and use scratch CPU mask

>>> On 15.12.16 at 15:15, wrote: > On 09/12/16 08:59, Jan Beulich wrote: > On 08.12.16 at 18:51, wrote: >>> On 08/12/16 16:02, Jan Beulich wrote: variable. With an IRQ happening at the deepest point of the stack, and with

[Xen-devel] [PATCH 0/2] __cpuhp_setup_state() returns positive value for dynamic state

The first patch corrects description of __cpuhp_setup_state()'s possible return values and the second fixes a bug (which causes Xen guests to crash). As a follow-up question for the first patch --- should we allow calling __cpuhp_setup_state() with state in [CPUHP_AP_ONLINE_DYN + 1 ..

Re: [Xen-devel] Ping: Re: [PATCH 2/3] VT-d: correct dma_msi_set_affinity()

>>> On 15.12.16 at 13:52, wrote: > On 15/12/16 09:54, Jan Beulich wrote: > On 09.12.16 at 09:47, wrote: >> On 08.12.16 at 18:33, wrote: On 08/12/16 16:01, Jan Beulich wrote: > That commit ("VT-d: use

Re: [Xen-devel] [PATCH 3/3] x86: introduce and use scratch CPU mask

On 09/12/16 08:59, Jan Beulich wrote: On 08.12.16 at 18:51, wrote: >> On 08/12/16 16:02, Jan Beulich wrote: >>> variable. With an IRQ happening at the deepest point of the stack, and >>> with send_guest_pirq() being called from there (leading to vcpu_kick() >>> ->

Re: [Xen-devel] [PATCH] x86/boot: fix build with certain older gcc versions

On 15/12/16 14:04, Jan Beulich wrote: > Despite all attempts so far (ending in commit fecf584294 ["Config.mk: > fix comment for debug option"] adjusting the respective comment), > Config.mk's debug= setting still affects the hypervisor build: CFLAGS > gets -g added there. > >

[Xen-devel] [PATCH] x86/boot: fix build with certain older gcc versions

Despite all attempts so far (ending in commit fecf584294 ["Config.mk: fix comment for debug option"] adjusting the respective comment), Config.mk's debug= setting still affects the hypervisor build: CFLAGS gets -g added there. xen/arch/x86/boot/build32.mk includes that file, and hence inherits

[Xen-devel] [xen-4.6-testing test] 103323: regressions - FAIL

flight 103323 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/103323/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-xsm 11 guest-start fail REGR. vs. 103209

Re: [Xen-devel] [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages] [and 1 more messages]

On Thu, Dec 15, 2016 at 6:09 AM, Ian Jackson wrote: > However, in that example, as you seem to allude to, there is still a > complete serialisation of all the transactions, even the failed T3: > T1,T2,T3. The database has detected the problem before returning data >

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

On 14/12/16 21:18, Edgar E. Iglesias wrote: On Wed, Dec 14, 2016 at 03:59:00PM +0100, Dario Faggioli wrote: On Tue, 2016-12-13 at 19:00 +, Julien Grall wrote: Hi all, Stefano suggested to move the call at 5pm and I haven't seen any disagreement. So the call will be tomorrow (Wednesday

[Xen-devel] [xen-unstable-smoke test] 103401: regressions - FAIL

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

  1   2   >