Re: [Xen-devel] [PATCH 1/1] x86/PVHv2: Add memory map pointer to hvm_start_info struct

On Fri, Mar 02, 2018 at 02:29:29PM -0800, Maran Wilson wrote: > On 3/2/2018 1:20 PM, Konrad Rzeszutek Wilk wrote: > >On Fri, Mar 02, 2018 at 12:54:29PM -0800, Maran Wilson wrote: > >>The start info structure that is defined as part of the x86/HVM direct boot > >>ABI and used for starting Xen PVH

Re: [Xen-devel] [PATCH] SUPPORT.md: Clarify stubdomain support

George Dunlap writes ("[PATCH] SUPPORT.md: Clarify stubdomain support"): > We don't promise to protect you against rogue stub domain binaries; > only from the running domain once the guest has come up. Acked-by: Ian Jackson

[Xen-devel] [PATCH 1/3] tests/x86emul: Helpers to save and restore FPU state

Introduce common helpers for saving and restoring FPU state. During emul_test_init(), calculate whether to use xsave or fxsave, and tweak the existing mxcsr_mask logic to avoid using another large static buffer. Signed-off-by: Andrew Cooper --- CC: Jan Beulich

[Xen-devel] [PATCH 3/3] tests/x86emul: Improve the utility of verbose mode

* Align the function call names, which aligns all subsequent data on the line. * Convert x86_segment and X86EMUL_ constants to strings rather than printing raw numbers. * Move the printing to the end of the function, and either hexdump the result or print the failure code. No change

[Xen-devel] [PATCH 2/3] tests/x86emul: Save and restore FPU state in the emulator callbacks

Currently with then native toolchain on Debian Jessie ./test_x86_emulator yeilds: Testing AVX2 256bit single native execution...okay Testing AVX2 256bit single 64-bit code sequence...[line 933] failed! The bug is that libc's memcpy() in read() uses %xmm8 (specifically, in

[Xen-devel] [PATCH v1] xen: acpi: upload _PSD info for offline CPUs too

All uploaded PM data from offline CPUs takes the info from vCPU 0 and changing only the acpi_id. For processors which P-state coordination type is HW_ALL (0xFD) it is OK to upload bogus P-state dependency information (_PSD), because Xen will ignore cpufreq domains existence. Albeit for hardware

Re: [Xen-devel] Merging 4.10.0-shim-comet-3 tag into staging-4.10

On Tue, Mar 06, 2018 at 09:14:50AM -0700, Jan Beulich wrote: > >>> On 06.03.18 at 11:56, wrote: > > Wei Liu writes ("Merging 4.10.0-shim-comet-3 tag into staging-4.10"): > >> Please check if the shape and form of this branch is OK. And please > >> indicate if anything is

Re: [Xen-devel] [PATCH 27/57] ARM: new VGIC: Add data structure definitions

Hi, On 06/03/18 17:46, Julien Grall wrote: > Hi Andre, > > On 05/03/18 16:03, Andre Przywara wrote: >> Add a new header file for the new and improved GIC implementation. >> The big change is that we now have a struct vgic_irq per IRQ instead >> of spreading all the information over various

[Xen-devel] [PATCH 0/3] tests/x86emul: Fix register corruption in the test harness

The main bugfix is in patch 2. Patch 3 is some extra debugging developed while investigating the issue. Andrew Cooper (3): tests/x86emul: Helpers to save and restore FPU state tests/x86emul: Save and restore FPU state in the emulator callbacks tests/x86emul: Improve the utility of verbose

Re: [Xen-devel] osstest planned outage consultation

Jan Beulich writes ("Re: osstest planned outage consultation"): > The most recent flights don't look too bad anymore (at least > most of the have started disappearing again), so > there's some hop for pushes soon. I hope to get around to > push another batch of backports today, in particular to

Re: [Xen-devel] [PATCH] SUPPORT.md: Clarify stubdomain support

On Tue, Mar 06, 2018 at 05:08:43PM +, George Dunlap wrote: > We don't promise to protect you against rogue stub domain binaries; > only from the running domain once the guest has come up. > > Signed-off-by: George Dunlap > --- > CC: Ian Jackson

Re: [Xen-devel] [PATCH 28/57] ARM: new VGIC: Add acccessor to new struct vgic_irq instance

Hi Andre, On 05/03/18 16:03, Andre Przywara wrote: The new VGIC implementation centers around a struct vgic_irq instance per virtual IRQ. Provide a function to retrieve the right instance for a given IRQ number and (in case of private interrupts) the right VCPU. This also includes the

[Xen-devel] [PATCH 4/3] tests/x86emul: Save and restore FPU state in the middle of emulation

Using libc functions in the middle of emulation may corrupt FPU state. Save and restore FPU state around the progress marker which is the only current libc function on the success path. Signed-off-by: Andrew Cooper --- CC: Jan Beulich ---

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

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

Re: [Xen-devel] ThunderX support in Xen

On Tue, 6 Mar 2018, Stefano Stabellini wrote: > On Wed, 31 Jan 2018, Julien Grall wrote: > > When working on getting Xen booting on rochester{0,1} (Thunder-X in > > Osstest), > > I blacklist them with this small patch. I will clean-up it and send it on > > the ML: > > > > diff --git

[Xen-devel] [seabios test] 120257: regressions - FAIL

flight 120257 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/120257/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539 Tests which did not

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

flight 120256 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/120256/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu 10 debian-install fail REGR. vs. 120140

Re: [Xen-devel] [PATCH v2] vvmx: fixes after CR4 trapping optimizations

> From: Roger Pau Monne [mailto:roger@citrix.com] > Sent: Saturday, March 3, 2018 12:19 AM > > Commit 406817 doesn't update nested VMX code in order to take into > account L1 CR4 host mask when nested guest (L2) writes to CR4, and > thus the mask written to CR4_GUEST_HOST_MASK is likely not

Re: [Xen-devel] preparations for 4.9.2 and 4.7.5

>>> On 06.03.18 at 20:24, wrote: > On Tue, 6 Mar 2018, Jan Beulich wrote: >> these stable releases should go out before the end of the month. >> Please point out backport candidates you find missing from the >> respective staging branches, but which you consider relevant.

[Xen-devel] [linux-4.9 test] 120260: tolerable FAIL - PUSHED

flight 120260 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/120260/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 120047 test-amd64-amd64-xl-qemut-win7-amd64

[Xen-devel] [PATCH] SUPPORT.md: Clarify stubdomain support

We don't promise to protect you against rogue stub domain binaries; only from the running domain once the guest has come up. Signed-off-by: George Dunlap --- CC: Ian Jackson CC: Wei Liu CC: Andrew Cooper

Re: [Xen-devel] [Xen-users] Only one CPU available to Xen? (nr_cpus : 1)

On Tue, Mar 6, 2018 at 11:15 AM, Andrew Cooper wrote: > Upgrade Grub to 2.02. > > The problem here is that Grub is starting EFI, but doesn't pass the EFI > details to Xen, and Xen therefore cannot locate the RSDP. I think my Ubuntu 17.10 system is already using GRUB

Re: [Xen-devel] [PATCH v4 1/7] xen/arm: Read the dcache line size from CTR register

Hi Stefano, On 02/03/18 19:06, Stefano Stabellini wrote: diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h index d948250..ce18f0c 100644 --- a/xen/include/asm-arm/page.h +++ b/xen/include/asm-arm/page.h @@ -134,7 +134,7 @@ /* Architectural minimum cacheline size is 4 32-bit

Re: [Xen-devel] Merging 4.10.0-shim-comet-3 tag into staging-4.10

Wei Liu writes ("Merging 4.10.0-shim-comet-3 tag into staging-4.10"): > Please check if the shape and form of this branch is OK. And please > indicate if anything is missing. The branch shape looks good to me. > Building that branch seems to produce the expected binaries. I will do > some smoke

Re: [Xen-devel] Merging 4.10.0-shim-comet-3 tag into staging-4.10

>>> On 06.03.18 at 11:41, wrote: > On Tue, Mar 06, 2018 at 01:21:52AM -0700, Jan Beulich wrote: >> >>> On 05.03.18 at 20:44, wrote: >> > I merged 4.10.0-shim-comet-3 tag into staging-4.10, went through all >> > commits since then and cherry-picked

Re: [Xen-devel] [xen-4.9-testing test] 120239: regressions - FAIL

>>> On 06.03.18 at 12:01, wrote: > Jan Beulich writes ("Re: [Xen-devel] [xen-4.9-testing test] 120239: > regressions - > FAIL"): >> (other than >> adding "async-show-all", as already suggested in the reply to that >> other flight report). > > Thanks for the reminder.

Re: [Xen-devel] [alsa-devel] [PATCH 0/2] sndif: add explicit back and front synchronization

On 03/06/2018 12:52 PM, Takashi Iwai wrote: On Mon, 05 Feb 2018 09:24:58 +0100, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Hi, all! Foreword This change is aimed to add support for explicit back and front synchronization during

Re: [Xen-devel] [PATCH v2] tools/xenstore: try to get minimum thread stack size for watch thread

On Fri, Mar 02, Wei Liu wrote: > But still, Juergen must have tested the change, so I wonder why it > doesn't work in your setup. What is your build environment? Gcc version? Unclear what the difference is between building in clean chroot and locally. This change fixes it for me: ---

Re: [Xen-devel] [PATCH] xen/arm: p2m: Prevent deadlock when using memaccess

On 06/03/18 11:06, Sergej Proskurin wrote: Hi Julien, Hi Sergej, On 02/28/2018 04:25 PM, Julien Grall wrote: Commit 7d623b358a4 "arm/mem_access: Add long-descriptor based gpt" assumed the read-write lock can be taken recursively. However, this assumption is wrong and will lead to deadlock

[Xen-devel] [PATCH] xen: xenbus: use put_device() instead of kfree()

Never directly free @dev after calling device_register(), even if it returned an error! Always use put_device() to give up the reference initialized. Signed-off-by: Arvind Yadav --- drivers/xen/xenbus/xenbus_probe.c | 5 - 1 file changed, 4 insertions(+), 1

Re: [Xen-devel] [Xen-users] Only one CPU available to Xen? (nr_cpus : 1)

On Tue, Mar 6, 2018 at 10:15 AM, Andrew Cooper wrote: > On 06/03/18 10:04, George Dunlap wrote: >> [Moving over to xen-devel, cc'ing a few people] >> >> On Tue, Mar 6, 2018 at 8:16 AM, John Naggets >> wrote: >>> Hi George, >>> >>> You will

[Xen-devel] [PATCH v3] new config option vtsc_tolerance_khz to avoid TSC emulation

Add an option to control when vTSC emulation will be activated for a domU with tsc_mode=default. Without such option each TSC access from domU will be emulated, which causes a significant perfomance drop for workloads that make use of rdtsc. Add a new domctl XEN_DOMCTL_set_vtsc_tolerance_khz to

Re: [Xen-devel] [xen-4.9-testing test] 120239: regressions - FAIL

Jan Beulich writes ("Re: [Xen-devel] [xen-4.9-testing test] 120239: regressions - FAIL"): > (other than > adding "async-show-all", as already suggested in the reply to that > other flight report). Thanks for the reminder. I'm about to push the patch below. I looked at the docs for

Re: [Xen-devel] [PATCH] xen: xenbus: use put_device() instead of kfree()

On 06/03/18 11:10, Arvind Yadav wrote: > Never directly free @dev after calling device_register(), even > if it returned an error! Always use put_device() to give up the > reference initialized. > > Signed-off-by: Arvind Yadav Reviewed-by: Juergen Gross

Re: [Xen-devel] [PATCH v1] pv_console: remove unnecessary #ifdefs

On Tue, Mar 06, 2018 at 08:51:56AM +, Sergey Dyasli wrote: > The header for PV console contains empty function definitions in case of > !CONFIG_XEN_GUEST specially to avoid #ifdefs in a code that uses them > to make the code look cleaner. > > Unfortunately, during the release of shim-comet,

Re: [Xen-devel] [PATCH v3] new config option vtsc_tolerance_khz to avoid TSC emulation

Am Tue, 6 Mar 2018 11:07:54 + schrieb Andrew Cooper : > > One option to avoid the TSC option is to run domUs with tsc_mode=native. > > This has the drawback that migrating a domU from a "2.3GHz" class host > > to a "2.4GHz" class host may change the rate at wich the

Re: [Xen-devel] [PATCH v3] new config option vtsc_tolerance_khz to avoid TSC emulation

On 06/03/18 10:41, Olaf Hering wrote: > Add an option to control when vTSC emulation will be activated for a > domU with tsc_mode=default. Without such option each TSC access from > domU will be emulated, which causes a significant perfomance drop for > workloads that make use of rdtsc. > > Add a

Re: [Xen-devel] [PATCH] xen/arm: p2m: Prevent deadlock when using memaccess

Hi Julien, On 02/28/2018 04:25 PM, Julien Grall wrote: > Commit 7d623b358a4 "arm/mem_access: Add long-descriptor based gpt" > assumed the read-write lock can be taken recursively. However, this > assumption is wrong and will lead to deadlock when the lock is > contended. > > To avoid the nested

Re: [Xen-devel] Merging 4.10.0-shim-comet-3 tag into staging-4.10

On Tue, Mar 06, 2018 at 01:21:52AM -0700, Jan Beulich wrote: > >>> On 05.03.18 at 20:44, wrote: > > I merged 4.10.0-shim-comet-3 tag into staging-4.10, went through all > > commits since then and cherry-picked relevant patches from master to > > staging-4.10. > > > > The end

Re: [Xen-devel] [alsa-devel] [PATCH 0/2] sndif: add explicit back and front synchronization

On Mon, 05 Feb 2018 09:24:58 +0100, Oleksandr Andrushchenko wrote: > > From: Oleksandr Andrushchenko > > Hi, all! > > Foreword > > > This change is aimed to add support for explicit back and front > synchronization during playback and capture in

Re: [Xen-devel] [PATCH v4 7/7] xen/arm: disable CPUs with different dcache line sizes

Hi Stefano, Something is wrong with your threading again. Patch #2-7 have "In-Reply-To" matching patch #1 and not the cover letter. On 02/03/18 19:06, Stefano Stabellini wrote: Even different cpus in big.LITTLE systems are expected to have the same dcache line size. Unless the minimum of all

Re: [Xen-devel] [Xen-users] Only one CPU available to Xen? (nr_cpus : 1)

>>> On 06.03.18 at 11:24, wrote: > On Tue, Mar 6, 2018 at 11:15 AM, Andrew Cooper > wrote: >> Alternatively, switch back to legacy boot, at which point it will all >> start working again. > > This is unfortunately not possible. This is a new

Re: [Xen-devel] Merging 4.10.0-shim-comet-3 tag into staging-4.10

On Mon, Mar 05, 2018 at 07:44:49PM +, Wei Liu wrote: > Building that branch seems to produce the expected binaries. I will do > some smoke tests tomorrow to make sure I haven't screwed things up. Travis build result is positive for both x86 and ARM (although ARM tools aren't built yet).

Re: [Xen-devel] [PATCH 10/57] ARM: VGIC: rename gic_event_needs_delivery()

Hi, On 05/03/18 16:03, Andre Przywara wrote: gic_event_needs_delivery() is not named very intuitively, especially the gic_ prefix is somewhat misleading. Rename it to vgic_pending_irq(), which makes it clear that this relates to the virtual GIC and is about interrupts. Signed-off-by: Andre

Re: [Xen-devel] [PATCH 21/57] ARM: GICv2: extend LR read/write functions to cover EOI and source

Hi Andre, On 05/03/18 16:03, Andre Przywara wrote: So far our LR read/write functions do not handle the EOI bit and the source CPUID bits in an LR, because the current VGIC implementation does not use them. Extend the gic_lr data structure to hold these bits of information as well, packing it

Re: [Xen-devel] [PATCH 17/57] ARM: Introduce kick_vcpu()

Hi Andre, On 05/03/18 16:03, Andre Przywara wrote: If we change something in a vCPU that affects its runnability or otherwise needs the vCPU's attention, we might need to tell the scheduler about it. We are using this in one place (vIRQ injection) at the moment, but will need this at more

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

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

[Xen-devel] preparations for 4.9.2 and 4.7.5

All, these stable releases should go out before the end of the month. Please point out backport candidates you find missing from the respective staging branches, but which you consider relevant. Please note that 4.7.5 is expected to be the last xenproject.org managed release from its branch. Jan

Re: [Xen-devel] [alsa-devel] [PATCH 0/2] sndif: add explicit back and front synchronization

On 03/06/2018 05:06 PM, Takashi Iwai wrote: On Tue, 06 Mar 2018 15:48:53 +0100, Oleksandr Andrushchenko wrote: And, now an open question for XEN comes: what kind of restriction should be applied to the frontend. Obviously it depends on the backend, so there must be some communication, and the

Re: [Xen-devel] [alsa-devel] [PATCH 0/2] sndif: add explicit back and front synchronization

On Tue, 06 Mar 2018 14:30:05 +0100, Oleksandr Andrushchenko wrote: > > On 03/06/2018 02:52 PM, Takashi Iwai wrote: > > On Tue, 06 Mar 2018 13:05:16 +0100, > > Oleksandr Andrushchenko wrote: > >> On 03/06/2018 01:32 PM, Takashi Iwai wrote: > >>> On Tue, 06 Mar 2018 12:25:07 +0100, > >>> Oleksandr

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

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

Re: [Xen-devel] [alsa-devel] [PATCH 0/2] sndif: add explicit back and front synchronization

On Tue, 06 Mar 2018 15:13:13 +0100, Oleksandr Andrushchenko wrote: > > On 03/06/2018 03:48 PM, Takashi Iwai wrote: > > On Tue, 06 Mar 2018 14:30:05 +0100, > > Oleksandr Andrushchenko wrote: > >> On 03/06/2018 02:52 PM, Takashi Iwai wrote: > >>> On Tue, 06 Mar 2018 13:05:16 +0100, > >>> Oleksandr

Re: [Xen-devel] [PATCH 16/57] ARM: GICv3: rename HYP interface definitions to use ICH_ prefix

Hi Andre, On 05/03/18 16:03, Andre Przywara wrote: On a GICv3 in non-compat mode the hypervisor interface is always accessed via system registers. Those register names have a "ICH_" prefix in the manual, to differentiate them from the MMIO registers. Also those registers are mostly 64-bit

Re: [Xen-devel] [PATCH 14/57] ARM: VGIC: Introduce gic_get_nr_lrs()

Hi Andre, On 05/03/18 16:03, Andre Przywara wrote: So far the number of list registers (LRs) a GIC implements is only needed in the hardware facing side of the VGIC code (gic-vgic.c). The new VGIC will need this information in more and multiple places, so export a function that returns the

Re: [Xen-devel] [PATCH v2] tools/xenstore: try to get minimum thread stack size for watch thread

Juergen Gross writes ("Re: [Xen-devel] [PATCH v2] tools/xenstore: try to get minimum thread stack size for watch thread"): > On 06/03/18 12:24, Olaf Hering wrote: > > +ifeq ($(CONFIG_Linux),y) > > +LDLIBS_libxenstore += -ldl > > +endif > > So we need to add this to xenstore.pc, right? Yes.

Re: [Xen-devel] [alsa-devel] [PATCH 0/2] sndif: add explicit back and front synchronization

On 03/06/2018 03:48 PM, Takashi Iwai wrote: On Tue, 06 Mar 2018 14:30:05 +0100, Oleksandr Andrushchenko wrote: On 03/06/2018 02:52 PM, Takashi Iwai wrote: On Tue, 06 Mar 2018 13:05:16 +0100, Oleksandr Andrushchenko wrote: On 03/06/2018 01:32 PM, Takashi Iwai wrote: On Tue, 06 Mar 2018

Re: [Xen-devel] [PATCH 15/57] ARM: GICv2: Extend and adjust register definitions

Hi Andre, On 05/03/18 16:03, Andre Przywara wrote: The new VGIC will shortly use more bits of the various GIC registers, so add the respective definitions from the manual. This series does not seem to use any of the new value you added. Did I miss anything? Note that I am not against this

Re: [Xen-devel] [RFC 06/11] fwnode xen spacific changes

On 06/03/18 10:27, Manish Jaggi wrote: On 01/19/2018 12:21 AM, Julien Grall wrote: Hi Manish, Please use scripts/get_maintainers.pl to CC relevant maintainers. I have done it for you this time. Title: s/spacific/specific/ On 02/01/18 09:28, manish.ja...@linaro.org wrote: From: Manish

Re: [Xen-devel] [alsa-devel] [PATCH 0/2] sndif: add explicit back and front synchronization

On 03/06/2018 04:27 PM, Takashi Iwai wrote: On Tue, 06 Mar 2018 15:13:13 +0100, Oleksandr Andrushchenko wrote: On 03/06/2018 03:48 PM, Takashi Iwai wrote: On Tue, 06 Mar 2018 14:30:05 +0100, Oleksandr Andrushchenko wrote: On 03/06/2018 02:52 PM, Takashi Iwai wrote: On Tue, 06 Mar 2018

Re: [Xen-devel] [RFC 06/11] fwnode xen spacific changes

On 06/03/18 13:44, Manish Jaggi wrote: Hi Julien, On 01/19/2018 12:21 AM, Julien Grall wrote: diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h index 6734ae8efd..f78482ca0c 100644 --- a/xen/include/asm-arm/device.h +++ b/xen/include/asm-arm/device.h @@ -6,6 +6,8 @@  

Re: [Xen-devel] Merging 4.10.0-shim-comet-3 tag into staging-4.10

>>> On 06.03.18 at 11:56, wrote: > Wei Liu writes ("Merging 4.10.0-shim-comet-3 tag into staging-4.10"): >> Please check if the shape and form of this branch is OK. And please >> indicate if anything is missing. > > The branch shape looks good to me. Same here - feel

[Xen-devel] [PATCH v1] pv_console: remove unnecessary #ifdefs

The header for PV console contains empty function definitions in case of !CONFIG_XEN_GUEST specially to avoid #ifdefs in a code that uses them to make the code look cleaner. Unfortunately, during the release of shim-comet, PV console functions were enclosed into unnecessary #ifdefs CONFIG_X86.

Re: [Xen-devel] [PATCH 0/5] x86: improve PDX <-> PFN and alike translations

>>> On 28.02.18 at 17:47, wrote: > On 28/02/18 13:51, Jan Beulich wrote: >> 1: remove page.h and processor.h inclusion from asm_defns.h >> 2: use PDEP for PTE flags insertion when available >> 3: use PDEP/PEXT for maddr/direct-map-offset conversion when available >> 4:

Re: [Xen-devel] osstest planned outage consultation

>>> On 02.03.18 at 17:55, wrote: > Several of the VMs in the Massachusetts Xen Project Test Lab, which > runs our community osstest instance, need to be upgraded. And we want > to sort out some oddities with the way the storage is configured. > > This will involve a long

Re: [Xen-devel] [PATCH v2] tools/xenstore: try to get minimum thread stack size for watch thread

On 06/03/18 12:24, Olaf Hering wrote: > On Fri, Mar 02, Wei Liu wrote: > >> But still, Juergen must have tested the change, so I wonder why it >> doesn't work in your setup. What is your build environment? Gcc version? > > Unclear what the difference is between building in clean chroot and

Re: [Xen-devel] [PATCH] xen/arm: p2m: Prevent deadlock when using memaccess

Hi Julien, On 03/06/2018 12:37 PM, Julien Grall wrote: > On 06/03/18 11:06, Sergej Proskurin wrote: >> Hi Julien, > > Hi Sergej, > >> >> On 02/28/2018 04:25 PM, Julien Grall wrote: >>> Commit 7d623b358a4 "arm/mem_access: Add long-descriptor based gpt" >>> assumed the read-write lock can be taken

Re: [Xen-devel] [Xen-users] Only one CPU available to Xen? (nr_cpus : 1)

On Tue, Mar 6, 2018 at 11:39 AM, Jan Beulich wrote: > As indicated in another reply, try using GrUB's "chainloader" > directive or boot xen.efi directly from the EFI shell or the EFI > boot loader. Sorry for my naive question but how do I chainload Xen with GRUB? I did not

Re: [Xen-devel] [PATCH v3] new config option vtsc_tolerance_khz to avoid TSC emulation

>>> On 06.03.18 at 12:07, wrote: > On 06/03/18 10:41, Olaf Hering wrote: >> With this option the host admin can decide how a domU should behave when >> it is migrated across systems of the same class. Since there is always >> some jitter when Xen calibrates the cpu_khz

Re: [Xen-devel] [alsa-devel] [PATCH 0/2] sndif: add explicit back and front synchronization

On 03/06/2018 02:52 PM, Takashi Iwai wrote: On Tue, 06 Mar 2018 13:05:16 +0100, Oleksandr Andrushchenko wrote: On 03/06/2018 01:32 PM, Takashi Iwai wrote: On Tue, 06 Mar 2018 12:25:07 +0100, Oleksandr Andrushchenko wrote: On 03/06/2018 12:52 PM, Takashi Iwai wrote: On Mon, 05 Feb 2018

Re: [Xen-devel] [RFC 06/11] fwnode xen spacific changes

Hi Julien, On 01/19/2018 12:21 AM, Julien Grall wrote: diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h index 6734ae8efd..f78482ca0c 100644 --- a/xen/include/asm-arm/device.h +++ b/xen/include/asm-arm/device.h @@ -6,6 +6,8 @@   enum device_type   {   DEV_DT, +   

Re: [Xen-devel] [RFC 06/11] fwnode xen spacific changes

Hi Julien, On 01/19/2018 12:21 AM, Julien Grall wrote: diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h index 6734ae8efd..f78482ca0c 100644 --- a/xen/include/asm-arm/device.h +++ b/xen/include/asm-arm/device.h @@ -6,6 +6,8 @@   enum device_type   {   DEV_DT, +   

[Xen-devel] [xen-4.10-testing test] 120244: tolerable FAIL - PUSHED

flight 120244 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/120244/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat fail REGR. vs. 119859

Re: [Xen-devel] [PATCH] xen/arm: p2m: Prevent deadlock when using memaccess

Hi Stefano, On 02/03/18 23:42, Stefano Stabellini wrote: On Wed, 28 Feb 2018, Julien Grall wrote: Commit 7d623b358a4 "arm/mem_access: Add long-descriptor based gpt" assumed the read-write lock can be taken recursively. However, this assumption is wrong and will lead to deadlock when the lock

Re: [Xen-devel] [PATCH 11/57] ARM: VGIC: change to level-IRQ compatible IRQ injection interface

Hi, On 05/03/18 16:03, Andre Przywara wrote: At the moment vgic_vcpu_inject_irq() is the interface for Xen internal code and virtual devices to inject IRQs into a guest. This interface has two shortcomings: 1) It requires a VCPU pointer, which we may not know (and don't need!) for shared

Re: [Xen-devel] [PATCH v4 06/20] x86emul: place test blobs in executable section

>>> On 06.03.18 at 12:28, wrote: > On 28/02/18 13:00, Jan Beulich wrote: >> --- unstable.orig/tools/tests/x86_emulator/Makefile >> +++ unstable/tools/tests/x86_emulator/Makefile >> @@ -91,7 +91,7 @@ $(addsuffix .h,$(TESTCASES)): %.h: %.c t >> $(MAKE) -f