Re: [Xen-devel] PML (Page Modification Logging) design for Xen

On 02/12/2015 03:08 PM, Tian, Kevin wrote: From: Kai Huang [mailto:kai.hu...@linux.intel.com] Sent: Thursday, February 12, 2015 2:46 PM On 02/12/2015 02:25 PM, Tian, Kevin wrote: From: Kai Huang [mailto:kai.hu...@linux.intel.com] Sent: Thursday, February 12, 2015 10:35 AM On 02/11/2015 09:13

Re: [Xen-devel] PML (Page Modification Logging) design for Xen

On 02/12/2015 03:09 PM, Tian, Kevin wrote: From: Kai Huang [mailto:kai.hu...@linux.intel.com] Sent: Thursday, February 12, 2015 2:57 PM On 02/12/2015 02:54 PM, Tian, Kevin wrote: From: Kai Huang [mailto:kai.hu...@linux.intel.com] Sent: Thursday, February 12, 2015 10:39 AM PML needs to be enab

Re: [Xen-devel] PML (Page Modification Logging) design for Xen

On 02/12/2015 03:02 PM, Tian, Kevin wrote: From: Kai Huang [mailto:kai.hu...@linux.intel.com] Sent: Thursday, February 12, 2015 10:50 AM - PML buffer flush There are two places we need to flush PML buffer. The first place is PML buffer full VMEXIT handler (apparently), and the second place is

Re: [Xen-devel] PML (Page Modification Logging) design for Xen

> From: Kai Huang [mailto:kai.hu...@linux.intel.com] > Sent: Thursday, February 12, 2015 2:57 PM > > On 02/12/2015 02:54 PM, Tian, Kevin wrote: > >> From: Kai Huang [mailto:kai.hu...@linux.intel.com] > >> Sent: Thursday, February 12, 2015 10:39 AM > PML needs to be enabled (allocate PML buffe

Re: [Xen-devel] PML (Page Modification Logging) design for Xen

> From: Kai Huang [mailto:kai.hu...@linux.intel.com] > Sent: Thursday, February 12, 2015 2:46 PM > > On 02/12/2015 02:25 PM, Tian, Kevin wrote: > >> From: Kai Huang [mailto:kai.hu...@linux.intel.com] > >> Sent: Thursday, February 12, 2015 10:35 AM > >> > >> On 02/11/2015 09:13 PM, Jan Beulich wrot

Re: [Xen-devel] [PATCH] x86 spinlock: Fix memory corruption on completing completions

On 02/11/2015 03:28 PM, Linus Torvalds wrote: > > > On Feb 11, 2015 3:15 PM, "Jeremy Fitzhardinge" > wrote: > > > > Right now it needs to be a locked operation to prevent read-reordering. > > x86 memory ordering rules state that all writes are seen in a globally > > consis

Re: [Xen-devel] PML (Page Modification Logging) design for Xen

On 02/12/2015 02:54 PM, Tian, Kevin wrote: From: Kai Huang [mailto:kai.hu...@linux.intel.com] Sent: Thursday, February 12, 2015 10:39 AM PML needs to be enabled (allocate PML buffer, initialize PML index, PML base address, turn PML on VMCS, etc) for all vcpus of the domain, as PML buffer and PM

Re: [Xen-devel] PML (Page Modification Logging) design for Xen

> From: Kai Huang [mailto:kai.hu...@linux.intel.com] > Sent: Thursday, February 12, 2015 10:50 AM > > >> - PML buffer flush > >> > >> There are two places we need to flush PML buffer. The first place is PML > >> buffer full VMEXIT handler (apparently), and the second place is in > >> paging_log_di

Re: [Xen-devel] PML (Page Modification Logging) design for Xen

> From: Kai Huang [mailto:kai.hu...@linux.intel.com] > Sent: Thursday, February 12, 2015 10:39 AM > > > >> PML needs to be enabled (allocate PML buffer, initialize PML index, > >> PML base address, turn PML on VMCS, etc) for all vcpus of the domain, > >> as PML buffer and PML index are per-vcpu, bu

Re: [Xen-devel] PML (Page Modification Logging) design for Xen

On 02/12/2015 02:25 PM, Tian, Kevin wrote: From: Kai Huang [mailto:kai.hu...@linux.intel.com] Sent: Thursday, February 12, 2015 10:35 AM On 02/11/2015 09:13 PM, Jan Beulich wrote: On 11.02.15 at 12:52, wrote: On 11/02/15 08:28, Kai Huang wrote: With PML, we don't have to use write protectio

Re: [Xen-devel] [PATCH RFC 31/35] arm : acpi map status override table to dom0

On Wed, 11 Feb 2015, Julien Grall wrote: > Hi Ian, > > On 05/02/2015 19:47, Ian Campbell wrote: > > On Thu, 2015-02-05 at 16:27 +0530, Parth Dixit wrote: > > > > > +stao->header.length = sizeof(struct acpi_table_header) + 1; > > > > > +stao->header.checksum = 0; > > > > > +ACPI_MEMCPY(

[Xen-devel] [PATCH 2/2] arm, arm64/xen: move Xen initialization earlier

From: Stefano Stabellini Currently, Xen is initialized/discovered in an initcall. This doesn't allow us to support earlyprintk or choosing the preferred console when running on Xen. The current function xen_guest_init is now split in 2 parts: - xen_early_init: Check if there is a Xen node in

[Xen-devel] [PATCH 0/2] arm/arm64: Detect Xen support earlier

Hello, This small patch series move the detection of running on Xen earlier. This is required in order to support earlyprintk via Xen and selecting the preferred console. Ard, the patch to move the call earlier (see #2) differed from the one I sent you privately mostly because it's not possible t

[Xen-devel] [PATCH 1/2] arm/xen: Correctly check if the event channel interrupt is present

The function irq_of_parse_and_map returns 0 when the IRQ is not found. Furthermore xen_events_irq is only read when the CPU is bring up, so it's not necessary to use the attribute __read_mostly. Lastly, move the check before notifying the user that we are running on Xen. Signed-off-by: Julien Gr

Re: [Xen-devel] PML (Page Modification Logging) design for Xen

> From: Kai Huang [mailto:kai.hu...@linux.intel.com] > Sent: Thursday, February 12, 2015 10:35 AM > > On 02/11/2015 09:13 PM, Jan Beulich wrote: > On 11.02.15 at 12:52, wrote: > >> On 11/02/15 08:28, Kai Huang wrote: > >>> With PML, we don't have to use write protection but just clear D-bit

[Xen-devel] [RFC v1 8/8] xen: x86: remove CONFIG_XEN dependency PARAVIRT and PARAVIRT_CLOCK

From: "Luis R. Rodriguez" Now that the respective PV modes have the specific requirements selectable just remove this from CONFIG_XEN This is as per the agreed upon Xen Kconfig changes [0]. [0] http://comments.gmane.org/gmane.comp.emulators.xen.devel/231579 Signed-off-by: Luis R. Rodriguez ---

[Xen-devel] [RFC v1 7/8] xen: unwrap XEN_BACKEND from XEN_DOM0

From: "Luis R. Rodriguez" This unwraps XEN_BACKEND from depending on XEN_DOM0, it instead makes it depend on the possible x86 backends and under what scenerios its allowed under ARM. This is as per the agreed upon Xen Kconfig changes [0]. [0] http://comments.gmane.org/gmane.comp.emulators.xen.de

[Xen-devel] [RFC v1 6/8] xen: x86: make XEN_PV* stuff depend on PARAVIRT and PARAVIRT_CLOCK

From: "Luis R. Rodriguez" This will later more easily let us unfold PARAVIRT and PARAVIRT_CLOCK from under CONFIG_XEN. All the XEN_PV* stuff is under the x86 universe. This is as per the agreed upon Xen Kconfig changes [0]. [0] http://comments.gmane.org/gmane.comp.emulators.xen.devel/231579 Sig

[Xen-devel] [RFC v1 5/8] xen: x86: add XEN_PV

From: "Luis R. Rodriguez" This lets us rip out under the general XEN config the XEN_HAVE_PVMMU dependency. This only exists on the x86 universe. This is as per the agreed upon Xen Kconfig changes [0]. [0] http://comments.gmane.org/gmane.comp.emulators.xen.devel/231579 Signed-off-by: Luis R. Rod

[Xen-devel] [RFC v1 4/8] xen: x86: make XEN_PVH select XEN_PVHVM

From: "Luis R. Rodriguez" This lets us expose XEN_PVH and set what is required for it. This only exists on the x86 universe. This is as per the agreed upon Xen Kconfig changes [0]. [0] http://comments.gmane.org/gmane.comp.emulators.xen.devel/231579 Signed-off-by: Luis R. Rodriguez --- arch/x8

Re: [Xen-devel] [PATCH] xen/arm: allow console=hvc0 to be omitted for guests

On Thu, 12 Feb 2015, Julien Grall wrote: > On 12/02/2015 12:54, Ian Campbell wrote: > > On Thu, 2015-02-12 at 04:35 +, Stefano Stabellini wrote: > > > On Tue, 10 Feb 2015, Ian Campbell wrote: > > > > On Tue, 2015-02-10 at 15:51 +0800, Ard Biesheuvel wrote: > > > > > > FWIW on x86 this doesn't d

[Xen-devel] [RFC v1 3/8] xen: drivers: add XEN_FRONTEND and fold front end drivers under them

From: "Luis R. Rodriguez" Fold Xen front end drivers under their own Kconfig entry. You may want to for example only enable domU guests with pv-drivers. While at it make HVC_XEN_FRONTEND select HVC_XEN. This is a per the agreed upon Kconfig changes for Xen [0]. [0] http://comments.gmane.org/gm

[Xen-devel] [RFC v1 2/8] xen: x86: make XEN_MAX_DOMAIN_MEMORY depend on XEN_HAVE_PVMMU

From: "Luis R. Rodriguez" Although XEN currently selects XEN_HAVE_PVMMU that will not be the case in the near future so select this requirement explicitly as per the agreed upon Kconfig changes [0]. [0] http://comments.gmane.org/gmane.comp.emulators.xen.devel/231579 Signed-off-by: Luis R. Rodri

[Xen-devel] [RFC v1 1/8] xen: make dom0 specific changes depend on XEN_DOM0

From: "Luis R. Rodriguez" These are Kconfig options which are known to only make sense with Xen dom0 support. This is as per the agreed upon changes to Xen's kconfig changes [0]. [0] http://comments.gmane.org/gmane.comp.emulators.xen.devel/231579 Signed-off-by: Luis R. Rodriguez --- arch/x86/

[Xen-devel] [RFC v1 0/8] xen: kconfig changes

From: "Luis R. Rodriguez" Here's the first shot at the Kconfig changes for Xen as discussed on the mailing list a little while ago [0]. Let me know if you spot any issues or if you'd like things split differently. I tried to make things as atomic as possible, but not being too rediculous on the a

Re: [Xen-devel] PML (Page Modification Logging) design for Xen

On 02/12/2015 10:49 AM, Kai Huang wrote: On 02/11/2015 09:06 PM, Jan Beulich wrote: On 11.02.15 at 09:28, wrote: - PML enable/disable for particular Domain PML needs to be enabled (allocate PML buffer, initialize PML index, PML base address, turn PML on VMCS, etc) for all vcpus of the doma

Re: [Xen-devel] [PATCH] xen/arm: allow console=hvc0 to be omitted for guests

On 12/02/2015 12:54, Ian Campbell wrote: On Thu, 2015-02-12 at 04:35 +, Stefano Stabellini wrote: On Tue, 10 Feb 2015, Ian Campbell wrote: On Tue, 2015-02-10 at 15:51 +0800, Ard Biesheuvel wrote: FWIW on x86 this doesn't depend on console_set_on_cmdline, does it need to here? I didn't

Re: [Xen-devel] [PATCH] xen/arm: allow console=hvc0 to be omitted for guests

On Thu, 2015-02-12 at 04:35 +, Stefano Stabellini wrote: > On Tue, 10 Feb 2015, Ian Campbell wrote: > > On Tue, 2015-02-10 at 15:51 +0800, Ard Biesheuvel wrote: > > > > FWIW on x86 this doesn't depend on console_set_on_cmdline, does it need > > > > to here? > > > > > > > > > > I didn't check t

Re: [Xen-devel] [PATCH] xen/arm: allow console=hvc0 to be omitted for guests

On Thu, 12 Feb 2015, Stefano Stabellini wrote: > On Tue, 10 Feb 2015, Ian Campbell wrote: > > On Tue, 2015-02-10 at 15:51 +0800, Ard Biesheuvel wrote: > > > > FWIW on x86 this doesn't depend on console_set_on_cmdline, does it need > > > > to here? > > > > > > > > > > I didn't check the code, but i

Re: [Xen-devel] [PATCH] xen/arm: allow console=hvc0 to be omitted for guests

On Tue, 10 Feb 2015, Ian Campbell wrote: > On Tue, 2015-02-10 at 15:51 +0800, Ard Biesheuvel wrote: > > > FWIW on x86 this doesn't depend on console_set_on_cmdline, does it need > > > to here? > > > > > > > I didn't check the code, but it seems inappropriate to add a preferred > > console implicit

Re: [Xen-devel] Xen's Linux kernel config options V2

On Fri, Feb 6, 2015 at 2:51 PM, Luis R. Rodriguez wrote: >>> >> > XEN_PLATFORM_PCI >>> > >>> > definitely x86 only >>> >>> All? >> >> only XEN_PLATFORM_PCI > > Updated. Then again commit 5fbdc10395cd500d6ff844825a918c4e6f38de37 removed this so its no longer relevant as its all folded under XEN_

Re: [Xen-devel] [PATCH OSSTEST 01/12] Add support of parsing grub which has 'submenu' primitive

On Wed, 2015-02-11 at 14:44 +, Ian Jackson wrote: > Robert Ho writes ("[PATCH OSSTEST 01/12] Add support of parsing grub which > has 'submenu' primitive"): > > From a hvm kernel build from Linux stable Kernel tree, > > the auto generated grub2 menu will have 'submenu' primitive, upon the > >

Re: [Xen-devel] [OSSTEST PATCH v2 10/10] rump kernel tests: Repeat the xenstorels test 50 times

On Wed, 2015-02-11 at 14:37 +, Ian Jackson wrote: > Ian Campbell writes ("Re: [OSSTEST PATCH 10/10] rump kernel tests: Repeat the > xenstorels test 50 times"): > > On Fri, 2015-02-06 at 19:17 +, Ian Jackson wrote: > > > Add a new step which uses repeat-ts to run > > > ts-rumpuserxen-demo-x

Re: [Xen-devel] Usage of efi_enabled - Was: Re: [PATCH RFC 33/35] arm : acpi enable efi for acpi

On Wed, 2015-02-11 at 11:22 +, Jan Beulich wrote: > > Does that also imply that some code which is using it to signal > > availability of Runtime Services should be switch to some other (new?) > > variable? > > I hope not - we already have efi_rs_enable, Good, I was just mislead by the nearby

[Xen-devel] [rumpuserxen test] 34486: regressions - FAIL

flight 34486 rumpuserxen real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34486/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-rumpuserxen6 xen-build fail REGR. vs. 33866 build-amd64-rumpuserx

Re: [Xen-devel] PML (Page Modification Logging) design for Xen

On 02/11/2015 09:06 PM, Jan Beulich wrote: On 11.02.15 at 09:28, wrote: - PML enable/disable for particular Domain PML needs to be enabled (allocate PML buffer, initialize PML index, PML base address, turn PML on VMCS, etc) for all vcpus of the domain, as PML buffer and PML index are per-vcpu

Re: [Xen-devel] PML (Page Modification Logging) design for Xen

On 02/11/2015 07:52 PM, Andrew Cooper wrote: On 11/02/15 08:28, Kai Huang wrote: Hi all, PML (Page Modification Logging) is a new feature on Intel's Boardwell server platfrom targeted to reduce overhead of dirty logging mechanism. Below is the design for Xen. Would you help to review and give

[Xen-devel] [libvirt test] 34464: tolerable all pass - PUSHED

flight 34464 libvirt real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34464/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt 10 migrate-support-checkfail never pass test-armhf-armhf-libvirt 10 migrate-sup

Re: [Xen-devel] PML (Page Modification Logging) design for Xen

On 02/11/2015 09:13 PM, Jan Beulich wrote: On 11.02.15 at 12:52, wrote: On 11/02/15 08:28, Kai Huang wrote: With PML, we don't have to use write protection but just clear D-bit of EPT entry of guest memory to do dirty logging, with an additional PML buffer full VMEXIT for 512 dirty GPAs. Theo

Re: [Xen-devel] [PATCH OSSTEST 01/12] Add support of parsing grub which has 'submenu' primitive

> -Original Message- > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com] > Sent: Wednesday, February 11, 2015 10:44 PM > To: Hu, Robert > Cc: xen-devel@lists.xen.org; jfeh...@suse.com; wei.l...@citrix.com; > ian.campb...@citrix.com; Pang, LongtaoX > Subject: Re: [PATCH OSSTEST 01/12] Ad

[Xen-devel] [linux-3.10 test] 34436: regressions - FAIL

flight 34436 linux-3.10 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34436/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 26303 Regressions which are

Re: [Xen-devel] [edk2] [PATCH] MdeModulePkg: mark completion of PCI enumeration in PciEnumeratorLight

Wei, No you cannot install gEfiPciEnumerationCompleteProtocolGuid in PciEnumeratorLight(). For a real platform, PCI BUS is fully enumerated in PciEnumerator() and later if reconnect happens, it's light enumerated in PciEnumeratorLight(). The protocol should only be installed once in PeiEnumerato

Re: [Xen-devel] [PATCH] modify the IO_TLB_SEGSIZE to io_tlb_segsize configurable as flexible requirement about SW-IOMMU.

Dear Wilk: > -Original Message- > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] > Sent: Thursday, February 12, 2015 4:49 AM > To: Wang, Xiaoming > Cc: David Vrabel; linux-m...@linux-mips.org; pebo...@tiscali.nl; Zhang, > Dongxing; lau...@codeaurora.org; d.kasat...@samsung.com

Re: [Xen-devel] [PATCH] virtual: Documentation: simplify and generalize paravirt_ops.txt

"Luis R. Rodriguez" writes: > From: "Luis R. Rodriguez" > > The general documentation we have for pv_ops is currenty present > on the IA64 docs, but since this documentation covers IA64 xen > enablement and IA64 Xen support got ripped out a while ago > through commit d52eefb47 present since v3.14

Re: [Xen-devel] [PATCH] x86 spinlock: Fix memory corruption on completing completions

On Feb 11, 2015 3:15 PM, "Jeremy Fitzhardinge" wrote: > > Right now it needs to be a locked operation to prevent read-reordering. > x86 memory ordering rules state that all writes are seen in a globally > consistent order, and are globally ordered wrt reads *on the same > addresses*, but reads to

Re: [Xen-devel] [PATCH] x86 spinlock: Fix memory corruption on completing completions

On 02/11/2015 09:24 AM, Oleg Nesterov wrote: > I agree, and I have to admit I am not sure I fully understand why > unlock uses the locked add. Except we need a barrier to avoid the race > with the enter_slowpath() users, of course. Perhaps this is the only > reason? Right now it needs to be a loc

[Xen-devel] [linux-3.16 test] 34434: regressions - FAIL

flight 34434 linux-3.16 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34434/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-credit2 15 guest-localmigrate/x10fail REGR. vs. 34167 Tests which are failin

[Xen-devel] [PATCH v2] vsprintf: Make sure argument to %pX specifier is valid

If invalid pointer (i.e. something smaller than HYPERVISOR_VIRT_START) is passed for %*ph/%pv/%ps/%pS format specifiers then print "(NULL)" Signed-off-by: Boris Ostrovsky --- xen/common/vsprintf.c | 23 --- 1 files changed, 16 insertions(+), 7 deletions(-) v2: * Print "(N

Re: [Xen-devel] [PATCH] modify the IO_TLB_SEGSIZE to io_tlb_segsize configurable as flexible requirement about SW-IOMMU.

On Wed, Feb 11, 2015 at 08:38:29AM +, Wang, Xiaoming wrote: > Dear David > > > -Original Message- > > From: David Vrabel [mailto:david.vra...@citrix.com] > > Sent: Tuesday, February 10, 2015 5:46 PM > > To: Wang, Xiaoming; Konrad Rzeszutek Wilk > > Cc: linux-m...@linux-mips.org; pebo..

[Xen-devel] [PATCH] MdeModulePkg: mark completion of PCI enumeration in PciEnumeratorLight

I had an issue when trying to boot Xen HVM guest with latest OVMF master. Guest crashed with memory violation, and the bisection pointed to 66b280df2 ("OvmfPkg: AcpiPlatformDxe: make dependency on PCI enumeration explicit"). That commit made AcpiPlatformDxe depend on PCI enumeration using gEfiPciEn

[Xen-devel] [PATCH] x86/xen: Make sure X2APIC_ENABLE bit of MSR_IA32_APICBASE is not set

Commit d524165cb8db ("x86/apic: Check x2apic early") tests X2APIC_ENABLE bit of MSR_IA32_APICBASE when CONFIG_X86_X2APIC is off and panics the kernel when this bit is set. Xen's PV guests will pass this MSR read to the hypervisor which will return its version of the MSR, where this bit might be se

[Xen-devel] [qemu-mainline test] 34427: regressions - FAIL

flight 34427 qemu-mainline real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34427/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 33480 test-amd64-i386-xl

Re: [Xen-devel] [PATCH] x86 spinlock: Fix memory corruption on completing completions

On 02/11/2015 11:08 PM, Oleg Nesterov wrote: On 02/11, Raghavendra K T wrote: On 02/10/2015 06:56 PM, Oleg Nesterov wrote: In this case __ticket_check_and_clear_slowpath() really needs to cmpxchg the whole .head_tail. Plus obviously more boring changes. This needs a separate patch even _if_ t

Re: [Xen-devel] [RFC PATCH] xen, apic: Setup our own APIC driver and validator for APIC IDs.

On Wed, Feb 11, 2015 at 09:53:26AM +, David Vrabel wrote: > On 10/02/15 20:33, Konrad Rzeszutek Wilk wrote: > > On Thu, Jan 22, 2015 at 10:00:55AM +, David Vrabel wrote: > >> On 21/01/15 21:56, Konrad Rzeszutek Wilk wrote: > >>> +static struct apic xen_apic = { > >>> + .name = "Xen", > >>>

Re: [Xen-devel] [PATCH] x86 spinlock: Fix memory corruption on completing completions

On 02/11, Raghavendra K T wrote: > > On 02/10/2015 06:56 PM, Oleg Nesterov wrote: > >> In this case __ticket_check_and_clear_slowpath() really needs to cmpxchg >> the whole .head_tail. Plus obviously more boring changes. This needs a >> separate patch even _if_ this can work. > > Correct, but apart

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

flight 34431 ovmf real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34431/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 33686 test-amd64-i386-xl-qemuu-ovm

Re: [Xen-devel] [PATCH] x86 spinlock: Fix memory corruption on completing completions

On 02/10, Jeremy Fitzhardinge wrote: > > On 02/10/2015 05:26 AM, Oleg Nesterov wrote: > > On 02/10, Raghavendra K T wrote: > >> Unfortunately xadd could result in head overflow as tail is high. > >> > >> The other option was repeated cmpxchg which is bad I believe. > >> Any suggestions? > > Stupid

Re: [Xen-devel] [PATCH 3/3] libxl: libxl__device_from_disk should retrieve backend from xenstore

Wei Liu wrote: > On Tue, Feb 10, 2015 at 11:01:46AM +, Ian Jackson wrote: > >> Wei Liu writes ("[PATCH 3/3] libxl: libxl__device_from_disk should retrieve >> backend from xenstore"): >> >>> ... if backend is not set by caller. >>> >> Acked-by: Ian Jackson >> >> as far as it goe

Re: [Xen-devel] [PATCH OSSTEST 12/12] Changes to test step of xen install

Robert Ho writes ("[PATCH OSSTEST 12/12] Changes to test step of xen install"): > This patch accomodates ts-xen-install to nested L1 xen Ah yes, here is the meat. I have run out of time today but will reply tomorrow with some design observations. Thanks, Ian. __

Re: [Xen-devel] [PATCH OSSTEST 10/12] Compose the main body of test-nested test job.

Robert Ho writes ("[PATCH OSSTEST 10/12] Compose the main body of test-nested test job."): > Compose the main body of test-nested test job. Ah, this is what I was missing earlier. You really need to order this so that things come after things which depend on them. Typically: * cleanups * de

[Xen-devel] [rumpuserxen test] 34448: regressions - FAIL

flight 34448 rumpuserxen real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34448/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-rumpuserxen6 xen-build fail REGR. vs. 33866 build-amd64-rumpuserx

Re: [Xen-devel] [PATCH OSSTEST 08/12] Add test job for nest test case

Robert Ho writes ("[PATCH OSSTEST 08/12] Add test job for nest test case"): > This patch adds creation of the nested test job; when > job creation procedure is invoked. ... > + job_create_test test-$xenarch$kern-$dom0arch-nested test-nested xl \ > + $xenarch $dom0arch \ Have

Re: [Xen-devel] [PATCH OSSTEST 09/12] Add build hvm job for nested test use

Robert Ho writes ("[PATCH OSSTEST 09/12] Add build hvm job for nested test use"): > Add build-debain-hvm build job. The $TREE_LINUX and > $REVISION_LINU can be designaged in standalone.config. What is this for ? It seems very similar to the build-$arch-pvops job. Ian. ___

Re: [Xen-devel] [PATCH v8 4/7] xen: Add vmware_port support

On 11/02/15 07:56, Jan Beulich wrote: On 10.02.15 at 20:30, wrote: >> While coding this is up I have hit issues that I need input on: >> >> As a HVM_PARAM_ item, I would assume I should be following >> what HVM_PARAM_VIRIDIAN does. It has this comment: >> >> case HVM_PARAM_VIRIDI

Re: [Xen-devel] [PATCH OSSTEST 07/12] For hvm guest configuration, config console to 'hvc0'

Robert Ho writes ("[PATCH OSSTEST 07/12] For hvm guest configuration, config console to 'hvc0'"): > --- > Osstest/TestSupport.pm | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm > index c23bbc7..864805e 100644 > --- a/O

Re: [Xen-devel] PML (Page Modification Logging) design for Xen

>>> On 11.02.15 at 17:33, wrote: > On 11/02/15 13:13, Jan Beulich wrote: > On 11.02.15 at 12:52, wrote: >>> On 11/02/15 08:28, Kai Huang wrote: We handle above two cases by flushing PML buffer at the beginning of all VMEXITs. This solves the first case above, and it also solves the

Re: [Xen-devel] PML (Page Modification Logging) design for Xen

On 11/02/15 13:13, Jan Beulich wrote: On 11.02.15 at 12:52, wrote: >> On 11/02/15 08:28, Kai Huang wrote: >>> With PML, we don't have to use write protection but just clear D-bit >>> of EPT entry of guest memory to do dirty logging, with an additional >>> PML buffer full VMEXIT for 512 dirty

Re: [Xen-devel] [PATCH v4 20/21] libxlu: introduce new APIs

Wei Liu writes ("[PATCH v4 20/21] libxlu: introduce new APIs"): > These APIs can be used to manipulate XLU_ConfigValue and XLU_ConfigList. ... > +const char *xlu_cfg_value_get_string(const XLU_ConfigValue *value) > +{ > +assert(value->type == XLU_STRING); > +return value->u.string; > +} Mo

Re: [Xen-devel] [PATCH v4 19/21] libxlu: nested list support

Wei Liu writes ("[PATCH v4 19/21] libxlu: nested list support"): > 1. Extend grammar of parser. > 2. Adjust internal functional to accept XLU_ConfigValue instead of ^functions Otherwise, Acked-by: Ian Jackson ___ Xen-devel mailin

Re: [Xen-devel] [PATCH v4 18/21] libxlu: rework internal representation of setting

Wei Liu writes ("[PATCH v4 18/21] libxlu: rework internal representation of setting"): > This patches does following things: ... > +void xlu__cfg_list_append(CfgParseContext *ctx, > + XLU_ConfigValue *list, > + char *atom) > +{ > +XLU_ConfigVal

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

flight 34426 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34426/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvh-intel 5 xen-boot fail REGR. vs. 34341 Regressions which ar

Re: [Xen-devel] [PATCH] x86: simplify non-atomic bitops

>>> On 11.02.15 at 16:14, wrote: > On 11/02/15 13:39, Jan Beulich wrote: >> @@ -55,12 +54,9 @@ static inline void set_bit(int nr, volat >> * If it's called on the same region of memory simultaneously, the effect >> * may be that only one operation succeeds. >> */ >> -static inline void __set

Re: [Xen-devel] stubdom vtpm build failure in staging

On Wed, Jan 28, Xu, Quan wrote: > Thanks, I will check and fix it tomorrow. It is 23:12 PM Pacific time now. Any progress? These typedefs are duplicated in stubdom/vtpmmgr/tcg.h and supported compilers do not cope with current staging: # for i in `grep -w typedef stubdom/vtpmmgr/tcg.h | sed -n '

[Xen-devel] Processed: Re: [RFC] Tweaking the release process for Xen 4.6

Processing commands for x...@bugs.xenproject.org: > create ^ Created new bug #48 rooted at `<20150210150424.ga32...@zion.uk.xensource.com>' Title: `Re: [RFC] Tweaking the release process for Xen 4.6' > title it Tweaking the release process for Xen 4.6 Set title for #48 to `Tweaking the release pro

Re: [Xen-devel] [PATCH] x86: simplify non-atomic bitops

On 11/02/15 13:39, Jan Beulich wrote: > - being non-atomic, their pointer arguments shouldn't be volatile- > qualified > - their (half fake) memory operands can be a single "+m" instead of > being both an output and an input > > Signed-off-by: Jan Beulich > --- > v2: Drop "+m" related sentence

Re: [Xen-devel] [PATCH v3 3/3] hvmemul_do_io: Do not retry if no ioreq server exists for this I/O.

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 11 February 2015 13:37 > To: Paul Durrant > Cc: Andrew Cooper; Ian Campbell; Wei Liu; George Dunlap; Ian Jackson; > Stefano Stabellini; xen-devel@lists.xen.org; Don Slutz; Keir (Xen.org) > Subject: Re: [PATCH v3 3/3

Re: [Xen-devel] [PATCH v2] introduce and use relaxed cpumask bitops

On 11/02/15 13:42, Jan Beulich wrote: > Using atomic (LOCKed on x86) bitops for certain of the operations on > cpumask_t is overkill when the variables aren't concurrently accessible > (e.g. local function variables, or due to explicit locking). Introduce > alternatives using non-atomic bitops and

Re: [Xen-devel] Query: Boot time allocation of irq descriptors

>>> On 11.02.15 at 16:03, wrote: > On Wed, Feb 11, 2015 at 8:25 PM, Andrew Cooper > wrote: >> On 11/02/15 14:50, Vijay Kilari wrote: >>> Hi , >>> >>> I just glaced at the x86 code, here nr_irqs are set to 1024, which > includes >>> normal irq's and MSI's. Memory for these descriptors are alloc

[Xen-devel] [PATCH v2 2/3] x86/traps: Avoid interleaved writes when updating potentially-live descriptors

Signed-off-by: Andrew Cooper CC: Jan Beulich CC: Tim Deegan --- v2: * Use _write_gate_lower() instead of opencoding write_atomic() * Drop write_atomic() in _write_gate_lower(). It doesn't appear to make a practical difference (although certainly does cause a difference to the register

Re: [Xen-devel] [PATCH OSSTEST 05/12] Add and expose some testsupport APIs

Robert Ho writes ("[PATCH OSSTEST 05/12] Add and expose some testsupport APIs"): > When install L2 guest, we will need to invoke > 'select_ether' to get guest MAC address. So here expose select_ether(). I'm not sure whether you actually need to do this. I will look at the rest of your series to

Re: [Xen-devel] [PATCH OSSTEST 03/12] Designate vif device model to e1000

Robert Ho writes ("[PATCH OSSTEST 03/12] Designate vif device model to e1000"): > Designate vif model to 'e1000', otherwise, with default > device model, the L1 eth0 interface disappear, hence xenbridge cannot work. > Maybe this limitation can be removed later after some fix it. For now, we > ha

Re: [Xen-devel] [PATCH OSSTEST 02/12] Increase boot timer to accomodate to nest test

Robert Ho writes ("[PATCH OSSTEST 02/12] Increase boot timer to accomodate to nest test"): > In nested test case, guest boot will take more time. > Increase the timer to 200 seconds. Can we make this conditional somehow ? I think it should probably be picked up from a runvar. We don't currentl

Re: [Xen-devel] Query: Boot time allocation of irq descriptors

>>> On 11.02.15 at 15:50, wrote: > I just glaced at the x86 code, here nr_irqs are set to 1024, which > includes > normal irq's and MSI's. Memory for these descriptors are allocated at boot > time. > is it correct? > > int __init init_irq_data(void) > { > > ... > for (vector = 0; vector

Re: [Xen-devel] [PATCH OSSTEST 06/12] Manipulate $ho IP assignment for nest L2 situation

Robert Ho writes ("[PATCH OSSTEST 06/12] Manipulate $ho IP assignment for nest L2 situation"): > In L2 installation context, its host (L1) IP address is not queried > from DNS, but from previous step of L1 installation, in which, L1 IP > is stored in run var. > -$ho->{IpStatic} = get_host_pr

Re: [Xen-devel] [PATCH OSSTEST 04/12] Just some indentation adustments.

Robert Ho writes ("[PATCH OSSTEST 04/12] Just some indentation adustments."): > - target_putfilecontents_root_stash > + target_putfilecontents_root_stash This seems to be just tab/space changes. I don't think we really need to bother about these. Do you fin

Re: [Xen-devel] Query: Boot time allocation of irq descriptors

On Wed, Feb 11, 2015 at 8:25 PM, Andrew Cooper wrote: > On 11/02/15 14:50, Vijay Kilari wrote: >> Hi , >> >> I just glaced at the x86 code, here nr_irqs are set to 1024, which includes >> normal irq's and MSI's. Memory for these descriptors are allocated at boot >> time. >> is it correct? >> >>

[Xen-devel] [PATCH] tools: require at least pixman 0.21.8 for qemu-xen

Avoid late build failure in openSUSE 11.4, it has just pixman-0.20: [ 211s] ERROR: pixman >= 0.21.8 not present. Your options: [ 211s] (1) Preferred: Install the pixman devel package (any recent [ 211s] distro should have packages as Xorg needs pixman too). [ 211s]

Re: [Xen-devel] Query: Boot time allocation of irq descriptors

On 11/02/15 14:50, Vijay Kilari wrote: > Hi , > > I just glaced at the x86 code, here nr_irqs are set to 1024, which includes > normal irq's and MSI's. Memory for these descriptors are allocated at boot > time. > is it correct? > > int __init init_irq_data(void) > { > > ... > for (vector = 0

[Xen-devel] Query: Boot time allocation of irq descriptors

Hi , I just glaced at the x86 code, here nr_irqs are set to 1024, which includes normal irq's and MSI's. Memory for these descriptors are allocated at boot time. is it correct? int __init init_irq_data(void) { ... for (vector = 0; vector < NR_VECTORS; ++vector) this_cpu(vector_irq)

Re: [Xen-devel] [PATCH OSSTEST 01/12] Add support of parsing grub which has 'submenu' primitive

Robert Ho writes ("[PATCH OSSTEST 01/12] Add support of parsing grub which has 'submenu' primitive"): > From a hvm kernel build from Linux stable Kernel tree, > the auto generated grub2 menu will have 'submenu' primitive, upon the > 'menuentry' items. Xen boot entries will be grouped into a sub

Re: [Xen-devel] [PATCH OSSTEST v6 9/9] mfi-common, make-flight: create XSM test jobs

Wei Liu writes ("Re: [PATCH OSSTEST v6 9/9] mfi-common, make-flight: create XSM test jobs"): > Here is the updated version: ... > Duplicate Debian PV and HVM test jobs for XSM testing. Thanks. This series (v7, then) is currently in the osstest self-push-gate. Ian. _

[Xen-devel] [OSSTEST PATCH v2 10/10] rump kernel tests: Repeat the xenstorels test 50 times

Ian Campbell writes ("Re: [OSSTEST PATCH 10/10] rump kernel tests: Repeat the xenstorels test 50 times"): > On Fri, 2015-02-06 at 19:17 +, Ian Jackson wrote: > > Add a new step which uses repeat-ts to run > > ts-rumpuserxen-demo-xenstorels many times. > > Acked-by: Ian Campbell Thanks. Aft

Re: [Xen-devel] [PATCH RFC 33/35] arm : acpi enable efi for acpi

Hi Jan, On 11/02/2015 18:31, Jan Beulich wrote: On 11.02.15 at 10:57, wrote: Hi Ian, On 05/02/2015 20:05, Ian Campbell wrote: On Thu, 2015-02-05 at 11:58 +, Jan Beulich wrote: On 05.02.15 at 06:31, wrote: --- a/xen/common/efi/runtime.c +++ b/xen/common/efi/runtime.c @@ -11,7 +11,13 @@

[Xen-devel] Xen OVMF regression

Hi Anthony and Laszlo The following commit caused Xen hvm guest failed to boot. commit 66b280df282ae82888d2eb416bfeda3f65afa386 Author: Laszlo Ersek Date: Thu Nov 20 09:58:28 2014 + OvmfPkg: AcpiPlatformDxe: make dependency on PCI enumeration explicit The ACPI payload that OVMF d

Re: [Xen-devel] [PATCH] domctl: do away with tool stack based retrying

On 11/02/15 13:47, Jan Beulich wrote: > XEN_DOMCTL_destroydomain so far is being special cased in libxc to > reinvoke the operation when getting back EAGAIN. Quite a few other > domctl-s have gained continuations, so I see no reason not to use them > here too. > > Signed-off-by: Jan Beulich In pa

[Xen-devel] [PATCH] domctl: do away with tool stack based retrying

XEN_DOMCTL_destroydomain so far is being special cased in libxc to reinvoke the operation when getting back EAGAIN. Quite a few other domctl-s have gained continuations, so I see no reason not to use them here too. Signed-off-by: Jan Beulich --- a/tools/libxc/xc_domain.c +++ b/tools/libxc/xc_dom

[Xen-devel] [PATCH v2] introduce and use relaxed cpumask bitops

Using atomic (LOCKed on x86) bitops for certain of the operations on cpumask_t is overkill when the variables aren't concurrently accessible (e.g. local function variables, or due to explicit locking). Introduce alternatives using non-atomic bitops and use them where appropriate. Note that this -

[Xen-devel] [qemu-upstream-unstable test] 34396: regressions - FAIL

flight 34396 qemu-upstream-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34396/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-i386 11 guest-localmigrate fail REGR. vs. 33488 test-amd64

[Xen-devel] [PATCH] x86: simplify non-atomic bitops

- being non-atomic, their pointer arguments shouldn't be volatile- qualified - their (half fake) memory operands can be a single "+m" instead of being both an output and an input Signed-off-by: Jan Beulich --- v2: Drop "+m" related sentence from comment at the top of the file as being wro

Re: [Xen-devel] [PATCH v3 3/3] hvmemul_do_io: Do not retry if no ioreq server exists for this I/O.

>>> On 10.02.15 at 23:52, wrote: > This saves a VMENTRY and a VMEXIT since we no longer retry the > ioport read on backing DM not handling a given ioreq. > > There are 2 case about "no ioreq server exists for this I/O": > > 1) No ioreq servers (PVH case) > 2) No ioreq servers for this I/O (non P

  1   2   >