Re: [Xen-devel] [PATCH] xen/arm64: config: correct VMAP_VIRT_END

Hi Julien, On Tue, May 31, 2016 at 12:07:58PM +0100, Julien Grall wrote: >Hi Peng, > >On 27/05/16 11:23, Peng Fan wrote: >>To ARM64, we should use '(VMAP_VIRT_START + GB(1))' as VMAP_VIRT_END, > >s/To/For/ Fix in V2. > >>but not '(VMAP_VIRT_START + GB(1) - 1)'. >> >>Seeing 'vm_end[type] = PFN_DO

Re: [Xen-devel] [PATCH] xen/arm: setup: initialize xenheap mappings after boot pages avaiable

Hi Julien, On Tue, May 31, 2016 at 06:08:38PM +0100, Julien Grall wrote: >Hi Peng, > >On 31/05/16 10:58, Peng Fan wrote: >>> So, need to make sure boot pages are ready before setup xenheap mappings. >>> >>>init_boot_pages is using mfn_to_virt (see bootmem_region_add), which cannot >>>work unti

Re: [Xen-devel] [PATCH RESEND 1/4] libs, gnttab, libxc: Interface for grant copy operation

On Tue, 2016-05-31 at 10:25 +0100, David Vrabel wrote: > > On 31/05/2016 05:44, Paulina Szubarczyk wrote: > > Implentation of interface to grant copy operation called through > > libxc. An ioctl(gntdev, IOCTL_GNTDEV_GRANT_COPY, ..) system call is > > invoked for linux. In the mini-os the operation

Re: [Xen-devel] [RFC v2] dma-mapping: Use unsigned long for dma_attrs

On Wed, Jun 01, 2016 at 07:36:42AM +0200, Krzysztof Kozlowski wrote: > > No really for this patch, but I would much prefer to document them next > > to the code in the long run. Also I really think these BIT() macros > > are a distraction compared to the (1 << N) notation. > > Not much difference

[Xen-devel] [PATCH V2] xen/arm64: config: Correctly define VMAP_VIRT_END

The vmap initialization code (vm_init_type) will round down the end of the region to a page-aligned address. On ARM64, the default vmap region is located between 1G and 2G. Based on the initialization code, the end address is excluded of the region. Therefore the current definition of VMAP_VIRT_E

Re: [Xen-devel] [PATCH RESEND 3/4] qdisk, hw/block/xen_disk: Perform grant copy instead of grant map.

On Tue, 2016-05-31 at 10:37 +0100, David Vrabel wrote: > On 31/05/2016 05:44, Paulina Szubarczyk wrote: > > Grant copy operation is divided into two phases different for > > 'read' and 'write' operation. > > > > For a 'read' operation the flow is as follow: > > 1. allocate local buffers for al

Re: [Xen-devel] [PATCH v3 2/3] svm: iommu: Only call guest_iommu_init() after initialized HVM domain

>>> On 31.05.16 at 23:11, wrote: > On 5/26/2016 10:44 AM, Jan Beulich wrote: > Suravee Suthikulanit 05/25/16 9:01 PM >>> >>> On 5/23/2016 6:54 AM, Jan Beulich wrote: >>> On 22.05.16 at 01:42, wrote: > From: Suravee Suthikulpanit > > The guest_iommu_init() is currently called

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

flight 95089 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/95089/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail REGR. vs. 94856 test-amd64-a

[Xen-devel] [RFC] PV guest kernel address randomization

All, Linux, at least for some arches, has been doing this for a while, yet the way it's implemented means kernels running in PV Xen guests can't leverage that functionality. Obviously the whole relocation process could be carried out in the guest, but it seems like Xen (for Dom0) or libxc (for Dom

Re: [Xen-devel] [PATCH for-4.7] libxl: keep PoD target adjustment by memory fudge after reload_domain_config()

George Dunlap writes: > On Tue, May 31, 2016 at 6:42 PM, Wei Liu wrote: >> From: Vitaly Kuznetsov >> >> Commit 56fb5fd623 ("libxl: adjust PoD target by memory fudge, too") >> introduced target_memkb adjustment for HVM PoD domains on create. The >> adjustment is however being reset on reload_dom

Re: [Xen-devel] [PATCH v4 5/8] arm/vm_event: get/set registers

>>> On 31.05.16 at 18:28, wrote: > On May 31, 2016 01:48, "Jan Beulich" wrote: >> >> >>> On 30.05.16 at 21:47, wrote: >> > On Mon, May 30, 2016 at 5:50 AM, Jan Beulich wrote: >> > On 30.05.16 at 00:37, wrote: >> >>> +struct vm_event_regs_arm32 { >> >>> +uint32_t r0_usr; >> >>> +uin

Re: [Xen-devel] [PATCH for-4.7] libxl: keep PoD target adjustment by memory fudge after reload_domain_config()

On Wed, Jun 01, 2016 at 10:29:36AM +0200, Vitaly Kuznetsov wrote: > George Dunlap writes: > > > On Tue, May 31, 2016 at 6:42 PM, Wei Liu wrote: > >> From: Vitaly Kuznetsov > >> > >> Commit 56fb5fd623 ("libxl: adjust PoD target by memory fudge, too") > >> introduced target_memkb adjustment for H

Re: [Xen-devel] [PATCH] x86/cpuid: fix dom0 crash on skylake machine

>>> On 01.06.16 at 07:54, wrote: > On Wed, 2016-06-01 at 12:58 +0800, Luwei Kang wrote: >> CPUID.0XD.0X0.EAX is from machine value for dom0, and dom0 kernel will xsetbv >> with xfeatures_mask that is from CPUID.0XD.0X0.EAX, but handle_xsetbv has >> ingored XSTATE_PKRU with hardware protection faul

Re: [Xen-devel] [PATCH] x86/cpuid: fix dom0 crash on skylake machine

On Wed, 2016-06-01 at 02:49 -0600, Jan Beulich wrote: > >>> On 01.06.16 at 07:54, wrote: > > On Wed, 2016-06-01 at 12:58 +0800, Luwei Kang wrote: > >> CPUID.0XD.0X0.EAX is from machine value for dom0, and dom0 kernel will > >> xsetbv > >> with xfeatures_mask that is from CPUID.0XD.0X0.EAX, but ha

Re: [Xen-devel] [PATCH] x86/cpuid: fix dom0 crash on skylake machine

On 01/06/16 05:58, Luwei Kang wrote: > CPUID.0XD.0X0.EAX is from machine value for dom0, and dom0 kernel will xsetbv > with xfeatures_mask that is from CPUID.0XD.0X0.EAX, but handle_xsetbv has > ingored XSTATE_PKRU with hardware protection fault emulation, so dom0 kernel > will crash on skylake mac

Re: [Xen-devel] [PATCH] x86/cpuid: fix dom0 crash on skylake machine

>>> On 01.06.16 at 06:58, wrote: > CPUID.0XD.0X0.EAX is from machine value for dom0, and dom0 kernel will xsetbv > with xfeatures_mask that is from CPUID.0XD.0X0.EAX, but handle_xsetbv has > ingored XSTATE_PKRU with hardware protection fault emulation, so dom0 kernel > will crash on skylake machin

[Xen-devel] [Patch v11 3/3] vt-d: fix vt-d Device-TLB flush timeout issue

From: Quan Xu If Device-TLB flush timed out, we hide the target ATS device immediately and crash the domain owning this ATS device. If impacted domain is hardware domain, just throw out a warning. By hiding the device, we make sure it can't be assigned to any domain any longer (see device_assign

[Xen-devel] [Patch v11 0/3] VT-d Device-TLB flush issue

From: Quan Xu This patches fix current timeout concern and also allow limited ATS support: 1. add a timeout parameter for device IOTLB invalidation The parameter 'iommu_dev_iotlb_timeout' specifies the timeout of the device IOTLB invalidation in milliseconds. By default, the timeout is 1ms, w

[Xen-devel] [Patch v11 1/3] IOMMU: add a timeout parameter for device IOTLB invalidation

From: Quan Xu The parameter 'iommu_dev_iotlb_timeout' specifies the timeout of the device IOTLB invalidation in milliseconds. By default, the timeout is 1ms, which can be boot-time changed. Add a __must_check annotation. The followup patch titled 'VT-d IOTLB/Context/IEC flush issue' addresses th

[Xen-devel] [Patch v11 2/3] vt-d: synchronize for Device-TLB flush one by one

From: Quan Xu Today we do Device-TLB flush synchronization after issuing flush requests for all ATS devices belonging to a VM. Doing so however imposes a limitation, i.e. that we can not figure out which flush request is blocked in the flush queue list, based on VT-d spec. To prepare correct Dev

Re: [Xen-devel] Patch for qemu-trad build with recent gnutls not present/working for RELEASE-4.6.1 on Ubuntu 16.04?

CC Ian Jackson (stable tree and qemu-trad maintainer) On Tue, May 31, 2016 at 12:17:10PM -0400, John McDermott wrote: > Xen Developers, > > On Ubuntu 16.04, when I clone from Xenbits and then checkout RELEASE-4.6.1, > ‘make world’ breaks > when it gets to qemu-xen-traditional, with the error sho

Re: [Xen-devel] [PATCH] x86/cpuid: fix dom0 crash on skylake machine

>>> On 01.06.16 at 11:03, wrote: > While this does work, it undoes some of the work I started with my cpuid > improvements in 4.7 > > Does the attached patch also resolve your issue? While that's much better than the original, I don't think it's quite enough. The rest of the domain policy should

Re: [Xen-devel] [PATCH] x86/cpuid: fix dom0 crash on skylake machine

Y, I think it works well, and more better. to Luwei: you can test if the problem is solved. On Wed, 2016-06-01 at 10:03 +0100, Andrew Cooper wrote: > On 01/06/16 05:58, Luwei Kang wrote: > > CPUID.0XD.0X0.EAX is from machine value for dom0, and dom0 kernel will > > xsetbv > > with xfeatures_mas

Re: [Xen-devel] [PATCH] x86/cpuid: fix dom0 crash on skylake machine

On Wed, Jun 01, 2016 at 10:03:44AM +0100, Andrew Cooper wrote: > > static void __init calculate_hvm_featureset(void) > @@ -179,7 +206,7 @@ static void __init calculate_hvm_featureset(void) > __clear_bit(X86_FEATURE_PCOMMIT, hvm_featureset); > } > > -sanitise_featureset(hv

Re: [Xen-devel] [PATCH for-4.7] docs: Feature Levelling feature document

>>> On 31.05.16 at 19:05, wrote: > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich with one spelling correction: > +# Overview > + > +On native hardware, a kernel will boot, detect features, typically optimise > +certain codepaths based on the available features, and expect the features

Re: [Xen-devel] [PATCH v4 0/4] xen/arm: arm64: Widen register access to mpidr to 64-bits

Hi Wei Liu, Julien, this series is a bug fix. I think it should go in Xen 4.7, do you agree? On Tue, 31 May 2016, Wei Chen wrote: > bits are expanded to 64-bits. But Xen 64-bit ARM code treats this it > as 32-bit register. > We have to provide correct accessing to this register to avoid > unexpe

Re: [Xen-devel] [PATCH] x86/cpuid: fix dom0 crash on skylake machine

On 01/06/16 10:17, Jan Beulich wrote: On 01.06.16 at 11:03, wrote: >> While this does work, it undoes some of the work I started with my cpuid >> improvements in 4.7 >> >> Does the attached patch also resolve your issue? > While that's much better than the original, I don't think it's quite >

Re: [Xen-devel] [PATCH v4 0/4] xen/arm: arm64: Widen register access to mpidr to 64-bits

On Wed, Jun 01, 2016 at 10:29:56AM +0100, Stefano Stabellini wrote: > Hi Wei Liu, Julien, > > this series is a bug fix. I think it should go in Xen 4.7, do you agree? > Yes Release-acked-by: Wei Liu > > On Tue, 31 May 2016, Wei Chen wrote: > > bits are expanded to 64-bits. But Xen 64-bit ARM

Re: [Xen-devel] [PATCH V3] arm/gic-v3: Fix ACPI probe fail on GICv4 hardware

On Tue, 31 May 2016, Julien Grall wrote: > Hi Shanker, > > On 27/05/16 19:32, Shanker Donthineni wrote: > > The current driver ACPI probe fails on hardware which has GICv4 > > version, even though it is fully compatible to GICv3. This patch > > fixed the issue by registering the same probe functio

Re: [Xen-devel] [PATCH for-4.7] docs: Feature Levelling feature document

Release-acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/cpuid: fix dom0 crash on skylake machine

>>> On 01.06.16 at 11:34, wrote: > On 01/06/16 10:17, Jan Beulich wrote: > On 01.06.16 at 11:03, wrote: >>> While this does work, it undoes some of the work I started with my cpuid >>> improvements in 4.7 >>> >>> Does the attached patch also resolve your issue? >> While that's much better tha

Re: [Xen-devel] [PATCH] x86/cpuid: fix dom0 crash on skylake machine

On 01/06/16 10:30, Wei Liu wrote: > On Wed, Jun 01, 2016 at 10:03:44AM +0100, Andrew Cooper wrote: >> >> static void __init calculate_hvm_featureset(void) >> @@ -179,7 +206,7 @@ static void __init calculate_hvm_featureset(void) >> __clear_bit(X86_FEATURE_PCOMMIT, hvm_featureset); >>

Re: [Xen-devel] [PATCH v2 10/15] xen/arm: Detect silicon revision and set cap bits accordingly

On Tue, 31 May 2016, Julien Grall wrote: > > > > > +is_affected_midr_range(const struct arm_cpu_capabilities *entry) > > > > > +{ > > > > > +return MIDR_IS_CPU_MODEL_RANGE(boot_cpu_data.midr.bits, > > > > > entry->midr_model, > > > > > + entry->midr_range_min,

Re: [Xen-devel] 4.7 qemu regression: HVM guests fail to boot from xvda

On Tue, May 31, 2016 at 01:00:45PM +0100, George Dunlap wrote: > On Tue, May 31, 2016 at 12:41 PM, Olaf Hering wrote: > > On Tue, May 31, George Dunlap wrote: > > > >> Sorry, can you expand on this a bit? Are you saying that on SuSE, if > >> you specify "vdev=xvda" in your config file, that you'l

Re: [Xen-devel] [Patch v6 01/11] IOMMU: handle IOMMU mapping and unmapping failures

>>> On 31.05.16 at 15:57, wrote: > From: Quan Xu > > Treat IOMMU mapping and unmapping failures as a fatal to the DomU > If IOMMU mapping and unmapping failed, crash the DomU and propagate > the error up to the call trees. > > No spamming of the log can occur. For DomU, we avoid logging any > m

Re: [Xen-devel] [PATCH] arm/acpi: Fix the deadlock in function vgic_lock_rank()

On Tue, 31 May 2016, Julien Grall wrote: > Hi Stefano, > > On 31/05/16 10:40, Stefano Stabellini wrote: > > On Mon, 30 May 2016, Julien Grall wrote: > > > ACPI can only be enabled in expert mode and will be a tech-preview for Xen > > > 4.7. So I would revert the patch. SPIs will not be routed, bu

Re: [Xen-devel] [Patch v6 02/11] IOMMU/MMU: enhance the call trees of IOMMU unmapping and mapping

>>> On 31.05.16 at 15:57, wrote: > --- a/xen/arch/x86/mm/p2m-pt.c > +++ b/xen/arch/x86/mm/p2m-pt.c > @@ -673,6 +673,8 @@ p2m_pt_set_entry(struct p2m_domain *p2m, unsigned long > gfn, mfn_t mfn, > if ( iommu_enabled && need_iommu(p2m->domain) && > (iommu_old_flags != iommu_pte_flags

Re: [Xen-devel] [PATCH 1/1] tools/xsplice: cleanup unnecessary "j = ARRAY_SIZE(action_options); "

On Tue, May 31, 2016 at 05:02:50PM -0400, Konrad Rzeszutek Wilk wrote: > On Mon, May 30, 2016 at 09:46:02AM +0800, Dongli Zhang wrote: > > Local variable "j" would be used only when "i == ARRAY_SIZE(main_options)" > > is true. Thus, it is not necessary to update "j" when "i == > > ARRAY_SIZE(main_o

[Xen-devel] [PATCH for-4.7] xen/arm: warn the user that we cannout route SPIs to Dom0

as a consequence of 9d77b3c01d1261ce17c10097a1b393f2893ca657 being reverted. Signed-off-by: Stefano Stabellini diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c index ee35683..babc822 100644 --- a/xen/arch/arm/vgic.c +++ b/xen/arch/arm/vgic.c @@ -25,6 +25,8 @@ #include #include #includ

Re: [Xen-devel] [Patch v6 04/11] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU mapping (top level ones)

>>> On 31.05.16 at 15:57, wrote: > --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c > +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c > @@ -295,12 +297,22 @@ static void __hwdom_init amd_iommu_hwdom_init(struct > domain *d) > * a pfn_valid() check would seem desirable here. >

[Xen-devel] [xen-unstable-coverity test] 95123: all pass - PUSHED

flight 95123 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/95123/ Perfect :-) All tests in this flight passed version targeted for testing: xen bbfd2d6ccb31a3aeea49c8f9c7884792ddc26e3b baseline version: xen 5ff371e9d87f468bf7

Re: [Xen-devel] [PATCH for-4.7] docs: Feature Levelling feature document

Andrew Cooper writes ("[PATCH for-4.7] docs: Feature Levelling feature document"): > +N.B. `xl`, being inherently a single-host toolstack, doesn't make use of > these > +levelling improvements. These features are of interest to higher level > +toolstacks such as `libvirt` or `XAPI`. I don't thi

Re: [Xen-devel] [PATCH] kexec: allow relaxed placement specification via command line

On Mon, May 30, 2016 at 07:48:26AM -0600, Jan Beulich wrote: > Rather than just allowing a fixed address or fully automatic placement, > also allow for specifying an upper bound. Especially on EFI systems, > where firmware memory use is commonly less predictable than on legacy > BIOS ones, this mak

Re: [Xen-devel] [PATCH v4 0/4] xen/arm: arm64: Widen register access to mpidr to 64-bits

On 01/06/16 10:29, Stefano Stabellini wrote: Hi Wei Liu, Julien, Hi Stefano, this series is a bug fix. I think it should go in Xen 4.7, do you agree? Some changes in this series impact the emulation of PSCI for guest (see target_affinity_mask in vpsci.c). Looking at the code again, they

Re: [Xen-devel] [Patch v6 07/11] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU suspending (top level ones)

>>> On 31.05.16 at 15:57, wrote: > static int device_power_down(void) > { > -console_suspend(); > +if ( console_suspend() ) > +return SAVED_NONE; > > -time_suspend(); > +if ( time_suspend() ) > +return SAVED_CONSOLE; > > -i8259A_suspend(); > +if ( i825

Re: [Xen-devel] [PATCH V9] vm_event: Allow subscribing to write events for specific MSR-s

Razvan Cojocaru writes ("Re: [PATCH V9] vm_event: Allow subscribing to write events for specific MSR-s"): > On 05/13/2016 02:35 PM, Jan Beulich wrote: > On 06.05.16 at 16:33, wrote: > >> Previously, subscribing to MSR write events was an all-or-none > >> approach, with special cases for intr

Re: [Xen-devel] [PATCH] kexec: allow relaxed placement specification via command line

>>> On 01.06.16 at 12:26, wrote: > On Mon, May 30, 2016 at 07:48:26AM -0600, Jan Beulich wrote: >> Rather than just allowing a fixed address or fully automatic placement, >> also allow for specifying an upper bound. Especially on EFI systems, >> where firmware memory use is commonly less predictab

Re: [Xen-devel] [PATCH V9] vm_event: Allow subscribing to write events for specific MSR-s

On Wed, Jun 01, 2016 at 11:39:40AM +0100, Ian Jackson wrote: > Razvan Cojocaru writes ("Re: [PATCH V9] vm_event: Allow subscribing to write > events for specific MSR-s"): > > On 05/13/2016 02:35 PM, Jan Beulich wrote: > > On 06.05.16 at 16:33, wrote: > > >> Previously, subscribing to MSR wri

Re: [Xen-devel] [PATCH for-4.7] xen/arm: warn the user that we cannout route SPIs to Dom0

Hi Stefano, Title: s/cannout/cannot/ I would add ACPI in the title to avoid people been scared by "we cannot route SPIs to DOM0" :). On 01/06/16 11:19, Stefano Stabellini wrote: as a consequence of 9d77b3c01d1261ce17c10097a1b393f2893ca657 being reverted. Signed-off-by: Stefano Stabellini d

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

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

Re: [Xen-devel] [PATCH for-4.7] xen/arm: warn the user that we cannout route SPIs to Dom0

On Wed, Jun 01, 2016 at 11:45:51AM +0100, Julien Grall wrote: > Hi Stefano, > > Title: s/cannout/cannot/ > > I would add ACPI in the title to avoid people been scared by "we cannot > route SPIs to DOM0" :). > > On 01/06/16 11:19, Stefano Stabellini wrote: > >as a consequence of 9d77b3c01d1261ce1

Re: [Xen-devel] [PATCH] arm/acpi: Fix the deadlock in function vgic_lock_rank()

Hi Stefano, On 01/06/16 10:54, Stefano Stabellini wrote: spin_is_locked does not work as you expect. The function will not tell you if the lock was taken by the current CPU, but if the lock was taken by *a* CPU. It would be possible to have CPU A calling this function and have CPU B with the lo

Re: [Xen-devel] [PATCH] x86/cpuid: fix dom0 crash on skylake machine

Thank you Andrew Cooper, this patch indeed resolve my issue and two point need modify. The code need move ahead of "break;" @@ -1101,6 +1101,9 @@ void pv_cpuid(struct cpu_user_regs *regs) if ( !is_control_domain(currd) && !is_hardware_domain(currd) ) cpuid_count(l

Re: [Xen-devel] [PATCH] x86/cpuid: fix dom0 crash on skylake machine

On 01/06/16 11:54, Kang, Luwei wrote: > Thank you Andrew Cooper, this patch indeed resolve my issue and two point > need modify. > > The code need move ahead of "break;" > @@ -1101,6 +1101,9 @@ void pv_cpuid(struct cpu_user_regs *regs) > if ( !is_control_domain(currd) && !is_hardwa

Re: [Xen-devel] [PATCH 1/2] libfsimage: replace deprecated readdir_r() with readdir()

Chris Patterson writes ("Re: [Xen-devel] [PATCH 1/2] libfsimage: replace deprecated readdir_r() with readdir()"): > I'm far from the expert here, but it would appear that both NetBSD's > and FreeBSD's libc readdir()/readdir_r() implementations are > consistent in their locking mechanisms [1,2]. A

Re: [Xen-devel] [PATCH] xen/arm: setup: initialize xenheap mappings after boot pages avaiable

Hello Peng, On 01/06/16 08:40, Peng Fan wrote: On Tue, May 31, 2016 at 06:08:38PM +0100, Julien Grall wrote: On 31/05/16 10:58, Peng Fan wrote: So, need to make sure boot pages are ready before setup xenheap mappings. init_boot_pages is using mfn_to_virt (see bootmem_region_add), which can

Re: [Xen-devel] [PATCH RESEND 3/4] qdisk, hw/block/xen_disk: Perform grant copy instead of grant map.

On 01/06/16 08:52, Paulina Szubarczyk wrote: > On Tue, 2016-05-31 at 10:37 +0100, David Vrabel wrote: >> On 31/05/2016 05:44, Paulina Szubarczyk wrote: >>> Grant copy operation is divided into two phases different for >>> 'read' and 'write' operation. >>> >>> For a 'read' operation the flow is as f

[Xen-devel] [qemu-upstream-4.3-testing test] 95119: trouble: blocked/broken

flight 95119 qemu-upstream-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/95119/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 3 host-install(3) broken REG

Re: [Xen-devel] [PATCH RESEND 1/4] libs, gnttab, libxc: Interface for grant copy operation

On 01/06/16 08:45, Paulina Szubarczyk wrote: > On Tue, 2016-05-31 at 10:25 +0100, David Vrabel wrote: >> >> On 31/05/2016 05:44, Paulina Szubarczyk wrote: >>> >>> Notification is yet not implemented. >> >> I'm not sure what you mean by "notifcation" here. > There is notify interface for grant m

Re: [Xen-devel] [PATCH v4 5/8] arm/vm_event: get/set registers

Hi, On 01/06/16 09:41, Jan Beulich wrote: On 31.05.16 at 18:28, wrote: On May 31, 2016 01:48, "Jan Beulich" wrote: On 30.05.16 at 21:47, wrote: On Mon, May 30, 2016 at 5:50 AM, Jan Beulich wrote: On 30.05.16 at 00:37, wrote: +struct vm_event_regs_arm32 { +uint32_t r0_usr; +ui

Re: [Xen-devel] [PATCH] x86/cpuid: fix dom0 crash on skylake machine

On 01/06/16 10:43, Jan Beulich wrote: On 01.06.16 at 11:34, wrote: >> On 01/06/16 10:17, Jan Beulich wrote: >> On 01.06.16 at 11:03, wrote: While this does work, it undoes some of the work I started with my cpuid improvements in 4.7 Does the attached patch also resolv

Re: [Xen-devel] [PATCH V9] vm_event: Allow subscribing to write events for specific MSR-s

On 06/01/2016 01:39 PM, Ian Jackson wrote: > Razvan Cojocaru writes ("Re: [PATCH V9] vm_event: Allow subscribing to write > events for specific MSR-s"): >> On 05/13/2016 02:35 PM, Jan Beulich wrote: >> On 06.05.16 at 16:33, wrote: Previously, subscribing to MSR write events was an all-or

Re: [Xen-devel] [PATCH v4 4/8] monitor: ARM SMC events

Hi Tamas, On 29/05/16 23:37, Tamas K Lengyel wrote: Add support for monitoring ARM SMC events. This patch only adds the required bits to enable/disable monitoring and forwarding the event through vm_event. Couple of questions: - How the vm-event app will differentiate a SMC64 vs a SMC32 call?

Re: [Xen-devel] [PATCH] x86/cpuid: fix dom0 crash on skylake machine

>>> On 01.06.16 at 13:27, wrote: > On 01/06/16 10:43, Jan Beulich wrote: > On 01.06.16 at 11:34, wrote: >>> On 01/06/16 10:17, Jan Beulich wrote: >>> On 01.06.16 at 11:03, wrote: > While this does work, it undoes some of the work I started with my cpuid > improvements in 4.7

Re: [Xen-devel] [PATCH RESEND 1/4] libs, gnttab, libxc: Interface for grant copy operation

On Wed, 2016-06-01 at 12:22 +0100, David Vrabel wrote: > On 01/06/16 08:45, Paulina Szubarczyk wrote: > > On Tue, 2016-05-31 at 10:25 +0100, David Vrabel wrote: > >> > >> On 31/05/2016 05:44, Paulina Szubarczyk wrote: > >>> > >>> Notification is yet not implemented. > >> > >> I'm not sure what

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

flight 95092 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/95092/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 94748 test-amd64-amd64-

Re: [Xen-devel] [PATCH] x86/cpuid: fix dom0 crash on skylake machine

On 01/06/16 12:38, Jan Beulich wrote: On 01.06.16 at 13:27, wrote: >> On 01/06/16 10:43, Jan Beulich wrote: >> On 01.06.16 at 11:34, wrote: On 01/06/16 10:17, Jan Beulich wrote: On 01.06.16 at 11:03, wrote: >> While this does work, it undoes some of the work I started

Re: [Xen-devel] [PATCH] x86/cpuid: fix dom0 crash on skylake machine

>>> On 01.06.16 at 13:45, wrote: > On 01/06/16 12:38, Jan Beulich wrote: > On 01.06.16 at 13:27, wrote: >>> On 01/06/16 10:43, Jan Beulich wrote: >>> On 01.06.16 at 11:34, wrote: > On 01/06/16 10:17, Jan Beulich wrote: > On 01.06.16 at 11:03, wrote: >>> While this does w

Re: [Xen-devel] [PATCH 1/2] libfsimage: replace deprecated readdir_r() with readdir()

Ian Jackson writes ("Re: [Xen-devel] [PATCH 1/2] libfsimage: replace deprecated readdir_r() with readdir()"): > 2. There may be good reasons to deviate from a formal specification. > Formal specifications can be wrong (for example, they can differ from > established practice, or unuseable, or inco

Re: [Xen-devel] [PATCH for-4.7] docs: Feature Levelling feature document

On 01/06/16 11:25, Ian Jackson wrote: > Andrew Cooper writes ("[PATCH for-4.7] docs: Feature Levelling feature > document"): >> +N.B. `xl`, being inherently a single-host toolstack, doesn't make use of >> these >> +levelling improvements. These features are of interest to higher level >> +toolst

Re: [Xen-devel] [PATCH 1/2] libfsimage: replace deprecated readdir_r() with readdir()

Ian Jackson writes ("Re: [Xen-devel] [PATCH 1/2] libfsimage: replace deprecated readdir_r() with readdir()"): > Ian Jackson writes ("Re: [Xen-devel] [PATCH 1/2] libfsimage: replace > deprecated readdir_r() with readdir()"): > > 2. There may be good reasons to deviate from a formal specification.

Re: [Xen-devel] [PATCH for-4.7] docs: Feature Levelling feature document

Andrew Cooper writes ("Re: [PATCH for-4.7] docs: Feature Levelling feature document"): > On 01/06/16 11:25, Ian Jackson wrote: > > I would prefer a wording which was more encouraging to future > > improvements. Shall I suggest something ? > > I guess there are two different issues here. (Note:

Re: [Xen-devel] [PATCH v2] arm/acpi: Add Server Base System Architecture UART support

Hi Wui, On 06/01/2016 01:47 AM, Wei Chen wrote: > Hi Shanker, > > On 31 May 2016 at 22:02, Shanker Donthineni wrote: >> The ARM Server Base System Architecture describes a generic UART >> interface. It doesn't support clock control registers, modem >> control, DMA and hardware flow control featur

Re: [Xen-devel] [PATCH 00/14] Xen ARM DomU ACPI support

Hi Boris, On 31/05/16 21:51, Boris Ostrovsky wrote: On 05/31/2016 03:42 PM, Konrad Rzeszutek Wilk wrote: On Tue, May 31, 2016 at 12:43:22PM +0800, Shannon Zhao wrote: From: Shannon Zhao The design of this feature is described as below. Firstly, the toolstack (libxl) generates the ACPI tables

Re: [Xen-devel] [PATCH v2 10/15] xen/arm: Detect silicon revision and set cap bits accordingly

Hi Stefano, On 01/06/16 10:46, Stefano Stabellini wrote: On Tue, 31 May 2016, Julien Grall wrote: +is_affected_midr_range(const struct arm_cpu_capabilities *entry) +{ +return MIDR_IS_CPU_MODEL_RANGE(boot_cpu_data.midr.bits, entry->midr_model, + entry->midr_

Re: [Xen-devel] Patch for qemu-trad build with recent gnutls not present/working for RELEASE-4.6.1 on Ubuntu 16.04?

> On May 31, 2016, at 4:22 PM, Mark Pryor wrote: > > John M. said: > > > > On Ubuntu 16.04, when I clone from Xenbits and then checkout > RELEASE-4.6.1, > ‘make world’ breaks > when it gets to qemu-xen-traditional, with

Re: [Xen-devel] [PATCH 00/14] Xen ARM DomU ACPI support

On 06/01/2016 08:42 AM, Julien Grall wrote: > Hi Boris, > > On 31/05/16 21:51, Boris Ostrovsky wrote: >> On 05/31/2016 03:42 PM, Konrad Rzeszutek Wilk wrote: >>> On Tue, May 31, 2016 at 12:43:22PM +0800, Shannon Zhao wrote: From: Shannon Zhao The design of this feature is described

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

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

Re: [Xen-devel] [PATCH] x86/cpuid: fix dom0 crash on skylake machine

On 01/06/16 13:01, Jan Beulich wrote: >> I want to adjust the representation of cpuid information in struct domain. The current loop in domain_cpuid() causes an O(N) overhead for every query, which is very poor for actions which really should be a single bit test at a fixed offs

Re: [Xen-devel] [PATCH for-4.7] docs: Feature Levelling feature document

On 01/06/16 13:14, Ian Jackson wrote: > Andrew Cooper writes ("Re: [PATCH for-4.7] docs: Feature Levelling feature > document"): >> On 01/06/16 11:25, Ian Jackson wrote: >>> I would prefer a wording which was more encouraging to future >>> improvements. Shall I suggest something ? >> I guess ther

Re: [Xen-devel] 4.7 qemu regression: HVM guests fail to boot from xvda

On Tue, May 31, Olaf Hering wrote: > On Tue, May 31, George Dunlap wrote: > > > Do you have a concrete proposal? > > I have to give it some more thought what the impact really is, what > config variants are affected. Here is a list. Essentially it means that upgrading dom0 to xen-4.7 might brea

Re: [Xen-devel] [PATCH 00/14] Xen ARM DomU ACPI support

On 01/06/16 13:59, Boris Ostrovsky wrote: On 06/01/2016 08:42 AM, Julien Grall wrote: On 31/05/16 21:51, Boris Ostrovsky wrote: On 05/31/2016 03:42 PM, Konrad Rzeszutek Wilk wrote: On Tue, May 31, 2016 at 12:43:22PM +0800, Shannon Zhao wrote: From: Shannon Zhao The design of this feature

Re: [Xen-devel] [PATCH] x86/cpuid: fix dom0 crash on skylake machine

>>> On 01.06.16 at 15:03, wrote: > On 01/06/16 13:01, Jan Beulich wrote: >>> > I want to adjust the representation of cpuid information in struct > domain. The current loop in domain_cpuid() causes an O(N) overhead for > every query, which is very poor for actions which really should b

Re: [Xen-devel] 4.7 qemu regression: HVM guests fail to boot from xvda

On Wed, Jun 01, Wei Liu wrote: > So I think the safest option now is to revert the said patch and figure > out what to do next. What did OSStest report when c0c099d got into the tree? Do these test domU.cfg files contain vdev=hd instead of vdev=xvd, so the boot breakage was not noticed? What are

Re: [Xen-devel] [PATCH v3 16/16] x86: add multiboot2 protocol support for relocatable images

On Wed, May 25, 2016 at 05:03:20AM -0600, Jan Beulich wrote: > >>> On 15.04.16 at 14:33, wrote: > > Add multiboot2 protocol support for relocatable images. Only GRUB2 with > > "multiboot2: Add support for relocatable images" patch understands > > that feature. Older multiboot protocol (regardless

Re: [Xen-devel] [PATCH 00/14] Xen ARM DomU ACPI support

On 06/01/2016 09:21 AM, Julien Grall wrote: > > > On 01/06/16 13:59, Boris Ostrovsky wrote: >> On 06/01/2016 08:42 AM, Julien Grall wrote: >>> On 31/05/16 21:51, Boris Ostrovsky wrote: On 05/31/2016 03:42 PM, Konrad Rzeszutek Wilk wrote: > On Tue, May 31, 2016 at 12:43:22PM +0800, Shannon

Re: [Xen-devel] [PATCH v2] arm/acpi: Add Server Base System Architecture UART support

Hello Shanker, On 31/05/16 15:02, Shanker Donthineni wrote: The ARM Server Base System Architecture describes a generic UART interface. It doesn't support clock control registers, modem control, DMA and hardware flow control features. So, extend the driver probe() to handle SBSA interface and sk

Re: [Xen-devel] [PATCH 00/14] Xen ARM DomU ACPI support

On 2016年06月01日 21:21, Julien Grall wrote: > > > On 01/06/16 13:59, Boris Ostrovsky wrote: >> On 06/01/2016 08:42 AM, Julien Grall wrote: >>> On 31/05/16 21:51, Boris Ostrovsky wrote: On 05/31/2016 03:42 PM, Konrad Rzeszutek Wilk wrote: > On Tue, May 31, 2016 at 12:43:22PM +0800, Shannon

Re: [Xen-devel] [PATCH 1/2] libfsimage: replace deprecated readdir_r() with readdir()

On Wed, Jun 1, 2016 at 8:06 AM, Ian Jackson wrote: > Ian Jackson writes ("Re: [Xen-devel] [PATCH 1/2] libfsimage: replace > deprecated readdir_r() with readdir()"): >> Ian Jackson writes ("Re: [Xen-devel] [PATCH 1/2] libfsimage: replace >> deprecated readdir_r() with readdir()"): >> > 2. There m

Re: [Xen-devel] [PATCH] arm/acpi: Fix the deadlock in function vgic_lock_rank()

On 2016年06月01日 18:49, Julien Grall wrote: > Hi Stefano, > > On 01/06/16 10:54, Stefano Stabellini wrote: >>> spin_is_locked does not work as you expect. The function will not >>> tell you if >>> the lock was taken by the current CPU, but if the lock was taken by >>> *a* CPU. >>> >>> It would be po

[Xen-devel] XSA-180 follow-up: repurpose xenconsoled for logging

Hi all During the discussion of XSA-180 Ian came up with the idea that we repurpose xenconsoled to handle logging. I've done some research (and some coding as well!). In my reply to George the other day: > I just read the code of virtlogd and xenconsoled. > > I think xenconsoled is missing at l

Re: [Xen-devel] [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0

On Tue, May 31, 2016 at 05:04:42PM +0300, Oleksandr Dmytryshyn wrote: > On Fri, May 20, 2016 at 7:05 PM, Edgar E. Iglesias > wrote: > > Hi, > > > > We have similar needs (not exactly the same) in some of our setups. > > We need to map certain OCMs (On Chip Memories) to dom0. Among other things, >

Re: [Xen-devel] 4.7 qemu regression: HVM guests fail to boot from xvda

On Wed, Jun 01, 2016 at 03:34:08PM +0200, Olaf Hering wrote: > On Wed, Jun 01, Wei Liu wrote: > > > So I think the safest option now is to revert the said patch and figure > > out what to do next. > > What did OSStest report when c0c099d got into the tree? Do these test > domU.cfg files contain v

[Xen-devel] [PATCH v2] xen: xen-pciback: Remove create_workqueue

System workqueues have been able to handle high level of concurrency for a long time now and there's no reason to use dedicated workqueues just to gain concurrency. Replace dedicated xen_pcibk_wq with the use of system_wq. Unlike a dedicated per-cpu workqueue created with create_workqueue(), syst

Re: [Xen-devel] [PATCH v4 0/4] xen/arm: arm64: Widen register access to mpidr to 64-bits

On Wed, Jun 01, 2016 at 11:37:55AM +0100, Julien Grall wrote: > > > On 01/06/16 10:29, Stefano Stabellini wrote: > >Hi Wei Liu, Julien, > > Hi Stefano, > > > > >this series is a bug fix. I think it should go in Xen 4.7, do you agree? > > Some changes in this series impact the emulation of PSCI

Re: [Xen-devel] 4.7 qemu regression: HVM guests fail to boot from xvda

On Wed, Jun 01, Wei Liu wrote: > > Konrad mentioned Solaris, no idea if its frontend driver uses the vdev > > string. BSD should be checked as well. > > > > So you are fine with documenting without reverting the patch? I think yes, If Solaris and BSD domU are not affected by the change. Given t

Re: [Xen-devel] [PATCH 00/14] Xen ARM DomU ACPI support

On 06/01/2016 09:53 AM, Shannon Zhao wrote: > > Actually I think there are two tables can be reused: RSDP and XSDT(while > which are smaller codes, I don't think it needs to be mixed with > others). The other tables are arch specific because the contents are > totally different. So if we want to ad

[Xen-devel] [PATCH v2] xen/arm: warn the user that we cannot route SPIs to Dom0 on ACPI

as a consequence of 9d77b3c01d1261ce17c10097a1b393f2893ca657 being reverted. Signed-off-by: Stefano Stabellini --- Changes in v2: - fix typo - add log_once --- xen/arch/arm/vgic.c | 15 +++ 1 file changed, 15 insertions(+) diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c index

Re: [Xen-devel] [PATCH v3 16/16] x86: add multiboot2 protocol support for relocatable images

>>> On 01.06.16 at 15:35, wrote: > On Wed, May 25, 2016 at 05:03:20AM -0600, Jan Beulich wrote: >> >>> On 15.04.16 at 14:33, wrote: >> > --- a/xen/arch/x86/boot/head.S >> > +++ b/xen/arch/x86/boot/head.S >> > @@ -79,6 +79,13 @@ multiboot2_header_start: >> > /* Align modules at page bound

Re: [Xen-devel] [PATCH v2] xen/arm: warn the user that we cannot route SPIs to Dom0 on ACPI

On 01/06/16 15:38, Stefano Stabellini wrote: as a consequence of 9d77b3c01d1261ce17c10097a1b393f2893ca657 being reverted. Signed-off-by: Stefano Stabellini Reviewed-by: Julien Grall --- Changes in v2: - fix typo - add log_once --- xen/arch/arm/vgic.c | 15 +++ 1 file chang

  1   2   >