Re: [Xen-devel] [PATCH] arm: clean up build variables

On Wed, 2016-01-27 at 15:24 +, Ian Campbell wrote: > On Wed, 2016-01-27 at 09:11 -0600, Doug Goldstein wrote: > > On 1/27/16 9:05 AM, Ian Campbell wrote: > > > Indeed, I was referring to the change from: > > > > > > -ifeq (arm64,$(XEN_TARGET_ARCH)) > > > > > > to > > > > > > +ifdef

Re: [Xen-devel] [PATCH 2/4] x86: adjust xsave structure attributes

On 29/01/16 10:27, Jan Beulich wrote: > The packed attribute was pointlessly used here - there are no > misaligned fields, and hence even if the attribute took effect, it > would at best lead to the compiler generating worse code. > > At the same time specify the required alignment of the fpu_sse

Re: [Xen-devel] Retiring http://bugzilla.xensource.com/bugzilla/

On 1/29/16 4:36 AM, Lars Kurth wrote: > Hi everyone, > > as part of the review of Xen Project infrastructure, we are looking at some > old services that we want to retire. I had an action, to verify whether > anyone is still using http://bugzilla.xensource.com/bugzilla ... I believe > that the

[Xen-devel] [xen-unstable test] 79379: tolerable FAIL - PUSHED

flight 79379 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/79379/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt-qcow2 3 host-install(3) broken in 79328 pass in 79379 test-armhf-armhf-xl-credit2 6

Re: [Xen-devel] [PATCH 1/4] x86/xstate: fix xcomp_bv initialization

On 29/01/16 10:26, Jan Beulich wrote: > We must not clear the compaction bit when using XSAVES/XRSTORS. And > we need to guarantee that xcomp_bv never has any bits clear which > are set in xstate_bv (which requires partly undoing commit 83ae0bb226 > ["x86/xsave: simplify xcomp_bv

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Thu, 28 Jan 2016, Leonid Yegoshin wrote: > In http://patchwork.linux-mips.org/patch/10505/ the very last mesg exchange > is: [...] > ... and that stops forever... Thanks for the reminder -- last June was very hectic, I travelled a lot and I lost the discussion from my radar. Apologies for

Re: [Xen-devel] hap_invlpg() vs INVLPGA

On 29/01/16 14:57, Egger, Christoph wrote: > On 29/01/16 14:24, Jan Beulich wrote: >> Christoph, >> >> in commit dd6de3ab99 ("Implement Nested-on-Nested") you added >> code to hap_invlpg() supposedly emulating INVLPGA. I've been >> stumbling across this a number of times in the past, not being

Re: [Xen-devel] [RFC] support more qdisk types

On 1/27/16 8:37 PM, Jim Fehlig wrote: > On 01/27/2016 01:25 PM, Doug Goldstein wrote: >> On 1/27/16 12:32 PM, Konrad Rzeszutek Wilk wrote: >>> On Mon, Jan 25, 2016 at 05:25:02PM -0700, Jim Fehlig wrote: I would like to hear the community's opinion on supporting more qdisk types in

[Xen-devel] hap_invlpg() vs INVLPGA

Christoph, in commit dd6de3ab99 ("Implement Nested-on-Nested") you added code to hap_invlpg() supposedly emulating INVLPGA. I've been stumbling across this a number of times in the past, not being able to make the connection between (a) VMX/EPT and INVLPGA and (b) SVM's INVLPGA intercept and this

Re: [Xen-devel] hap_invlpg() vs INVLPGA

On 29/01/16 14:24, Jan Beulich wrote: > Christoph, > > in commit dd6de3ab99 ("Implement Nested-on-Nested") you added > code to hap_invlpg() supposedly emulating INVLPGA. I've been > stumbling across this a number of times in the past, not being able > to make the connection between (a) VMX/EPT

Re: [Xen-devel] [RFC] support more qdisk types

On Wed, Jan 27, 2016 at 07:42:49PM -0700, Jim Fehlig wrote: > On 01/27/2016 02:09 PM, Konrad Rzeszutek Wilk wrote: > > On Wed, Jan 27, 2016 at 02:25:51PM -0600, Doug Goldstein wrote: > >> On 1/27/16 12:32 PM, Konrad Rzeszutek Wilk wrote: > >>> On Mon, Jan 25, 2016 at 05:25:02PM -0700, Jim Fehlig

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

On Fri, 2016-01-29 at 00:52 +, osstest service owner wrote: > flight 79328 xen-unstable real [real] > http://logs.test-lab.xenproject.org/osstest/logs/79328/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: >  

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

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

[Xen-devel] [PATCH v12 0/3] Refactor ioreq server for better performance.

XenGT leverages ioreq server to track and forward the accesses to GPU I/O resources, e.g. the PPGTT(per-process graphic translation tables). Currently, ioreq server uses rangeset to track the BDF/ PIO/MMIO ranges to be emulated. To select an ioreq server, the rangeset is searched to see if the

Re: [Xen-devel] [PATCH v5 00/10] virtio DMA API, yet again

On Thu, 2016-01-28 at 18:31 -0800, Andy Lutomirski wrote: > > To everyone else: we've waffled on this for way too long.  I think > we should to get DMA API implementation in with a conservative > policy like this rather than waiting until we achieve perfection. > I'm tired of carrying these

Re: [Xen-devel] [linux-3.16 test] 79367: regressions - FAIL

On Fri, 2016-01-29 at 10:03 +, osstest service owner wrote: > flight 79367 linux-3.16 real [real] > http://logs.test-lab.xenproject.org/osstest/logs/79367/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: >  

Re: [Xen-devel] [PATCH v2 1/2] altp2m: Merge p2m_set_altp2m_mem_access and p2m_set_mem_access

>>> On 28.01.16 at 21:58, wrote: > --- a/xen/arch/x86/mm/p2m.c > +++ b/xen/arch/x86/mm/p2m.c > @@ -1777,14 +1777,57 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned > long gla, > return (p2ma == p2m_access_n2rwx); > } > > +static int

[Xen-devel] Retiring http://bugzilla.xensource.com/bugzilla/

Hi everyone, as part of the review of Xen Project infrastructure, we are looking at some old services that we want to retire. I had an action, to verify whether anyone is still using http://bugzilla.xensource.com/bugzilla ... I believe that the service can be retired, as it has been replaced

Re: [Xen-devel] [PATCH] xen: recalculate per-cpupool credits when updating timeslice

>>> On 29.01.16 at 11:21, wrote: > --- a/xen/common/sched_credit.c > +++ b/xen/common/sched_credit.c > @@ -1086,12 +1086,19 @@ csched_dom_cntl( > static inline void > __csched_set_tslice(struct csched_private *prv, unsigned timeslice) > { > +unsigned long flags; > + > +

[Xen-devel] [PATCH v12 2/3] Differentiate IO/mem resources tracked by ioreq server

Currently in ioreq server, guest write-protected ram pages are tracked in the same rangeset with device mmio resources. Yet unlike device mmio, which can be in big chunks, the guest write- protected pages may be discrete ranges with 4K bytes each. This patch uses a seperate rangeset for the guest

[Xen-devel] [PATCH v12 1/3] Refactor rangeset structure for better performance.

This patch refactors struct rangeset to base it on the red-black tree structure, instead of on the current doubly linked list. By now, ioreq leverages rangeset to keep track of the IO/memory resources to be emulated. Yet when number of ranges inside one ioreq server is very high, traversing a

[Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

A new parameter - max_wp_ram_ranges is added to set the upper limit of write-protected ram ranges to be tracked inside one ioreq server rangeset. Ioreq server uses a group of rangesets to track the I/O or memory resources to be emulated. Default limit of ranges that one rangeset can allocate is

Re: [Xen-devel] [PATCH v5 09/10] vring: Use the DMA API on Xen

On 29/01/16 02:31, Andy Lutomirski wrote: > Signed-off-by: Andy Lutomirski > --- > drivers/virtio/virtio_ring.c | 12 > 1 file changed, 12 insertions(+) > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > index c169c6444637..305c05cc249a

Re: [Xen-devel] Xen Project Infrastructure Maintenance: xenbits (Jan 28), qemu-bitslave & mail & downloads.xenproject.org (Feb 1), lists & etherpad (Feb 4th)

Hi all, this is a quick note to let you note that we are deferring the upgrades that were originally planned on Feb 1 and 4th. We ran into some issues with the Jan 28th upgrade, which would occur again. We are working with Rackspace to find a solution that avoids the issues we have seen on the

Re: [Xen-devel] [PATCH] xen: recalculate per-cpupool credits when updating timeslice

On 29/01/16 11:46, Jan Beulich wrote: On 29.01.16 at 11:21, wrote: >> --- a/xen/common/sched_credit.c >> +++ b/xen/common/sched_credit.c >> @@ -1086,12 +1086,19 @@ csched_dom_cntl( >> static inline void >> __csched_set_tslice(struct csched_private *prv, unsigned timeslice)

[Xen-devel] [distros-debian-jessie test] 38713: tolerable all pass

flight 38713 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38713/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-armhf-jessie-netboot-pygrub 12 saverestore-support-check fail never pass

[Xen-devel] [qemu-mainline baseline-only test] 38712: regressions - FAIL

This run is configured for baseline tests only. flight 38712 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38712/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 14

Re: [Xen-devel] [PATCH v11 1/2] vmx: VT-d posted-interrupt core logic handling

>>> On 29.01.16 at 02:53, wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: Friday, January 29, 2016 12:38 AM >> >>> On 28.01.16 at 06:12, wrote: >> > --- a/xen/arch/x86/hvm/vmx/vmx.c >> > +++ b/xen/arch/x86/hvm/vmx/vmx.c >> > @@ -83,7 +83,140

[Xen-devel] [linux-linus bisection] complete test-armhf-armhf-xl-credit2

branch xen-unstable xenbranch xen-unstable job test-armhf-armhf-xl-credit2 testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen

[Xen-devel] [PATCH 1/4] x86/xstate: fix xcomp_bv initialization

We must not clear the compaction bit when using XSAVES/XRSTORS. And we need to guarantee that xcomp_bv never has any bits clear which are set in xstate_bv (which requires partly undoing commit 83ae0bb226 ["x86/xsave: simplify xcomp_bv initialization"]). Split initialization of xcomp_bv from the

[Xen-devel] [PATCH v7 5/5] PCI: ACPI: Add a generic ACPI based host controller

Add a simple ACPI based PCI host controller under config option ACPI_PCI_HOST_GENERIC. This is done by providing an implementation of pci_acpi_scan_root(). The pci_mmcfg_list handling is done by the ACPI code, so we keep a reference to the pci_mmcfg_region in sysdata. The ECAM region will be

[Xen-devel] [PATCH v7 1/5] APCI: MCFG: Move mmcfg_list management to drivers/acpi

Move pci_mmcfg_list handling to a drivers/acpi/pci_mcfg.c. This is to share the API and code with ARM64 later. The corresponding declarations are moved from asm/pci_x86.h to linux/pci-acpi.h As a part of this we introduce three functions that can be implemented by the arch code:

[Xen-devel] [PATCH v7 3/5] PCI: Handle ACPI companion and domain number

pci_create_root_bus is called with NULL as parent in ACPI. This ends up calling pci_bus_assign_domain_nr with a NULL parent, which crashes when dereferencing parent. Fix this by providing a way to set the ACPI domain number and ACPI companion in PCI code. We define pci_acpi_set_companion() to set

[Xen-devel] [PATCH v7 0/5] ACPI based PCI support for arm64

Here is another update to this patchset. This patchset provides a generic ACPI based PCI host controller implementation and uses it on arm64. The first patch moves the common code to handle MCFG ACPI table from arch/x86 to drivers/acpi/pci_mcfg.c. The last patch in the patchset provides the

[Xen-devel] [PATCH v7 4/5] arm64: pci: Add ACPI support

Add functions needed for ACPI support and prepare arm64 for using CONFIG_ACPI_PCI_HOST_GENERIC for the ACPI based PCI controller. pci_acpi_scan_root(), raw_pci_read() and raw_pci_write() are marked as weak so that they can be implemented by the generic ACPI PCI driver. pcibios_enable_device()

[Xen-devel] [PATCH v7 2/5] ACPI: PCI: Support platforms that need pci_remap_iospace

On some platforms (in this case ARM64), the PCI iospace needs to be mapped with pci_remap_iospace and the resources have to be adjusted for the iospace physical address. This has to be done before acpi_pci_root_validate_resources() checks and removes resource windows. Handle this by adding a

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

flight 79367 linux-3.16 real [real] http://logs.test-lab.xenproject.org/osstest/logs/79367/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-rumpuserxen6 xen-build fail REGR. vs. 77819

Re: [Xen-devel] Error booting Xen

>>> On 28.01.16 at 20:17, wrote: > Latest set looks good. No boot issues. No resets. > Full log at http://paste2.org/NxHNW4vn Thanks! > Sorry I don't know much about source of last few > lines. I was just tracing in xen when these came. > I was unable to create them

[Xen-devel] [PATCH 4/4] x86/xstate: extend validation to cover full header

Since we never hand out compacted state, at least for now we're also not going to accept such. Reported-by: Harmandeep Kaur Signed-off-by: Jan Beulich --- a/xen/arch/x86/domctl.c +++ b/xen/arch/x86/domctl.c @@ -964,7 +964,7 @@ long arch_do_domctl(

[Xen-devel] [PATCH 3/4] x86/xstate: fix fault behavior on XRSTORS

XRSTORS unconditionally faults when xcomp_bv has bit 63 clear. Instead of just fixing this issue, overhaul the fault recovery code, which - one of the many mistakes made when xstate support got introduced - was blindly mirroring that accompanying FXRSTOR, neglecting the fact that XRSTOR{,S} aren't

[Xen-devel] [PATCH 2/4] x86: adjust xsave structure attributes

The packed attribute was pointlessly used here - there are no misaligned fields, and hence even if the attribute took effect, it would at best lead to the compiler generating worse code. At the same time specify the required alignment of the fpu_sse sub- structure, such that the various typeof()

[Xen-devel] [PATCH V2] vm_event: make sure the domain is paused in key domctls

This patch pauses the domain for all writes through the 'ad' pointer in monitor_domctl(), defers a domain_unpause() call until after the CRs are updated for the MONITOR_EVENT_WRITE_CTRLREG case, and makes sure that the domain is paused for both vm_event enable and disable cases in

[Xen-devel] [PATCH 0/4] x86: xsave{c,s} fixes and adjustments

1: xstate: fix xcomp_bv initialization 2: adjust xsave structure attributes 3: xstate: fix fault behavior on XRSTORS 4: xstate: extend validation to cover full header Reported-by: Harmandeep Kaur Signed-off-by: Jan Beulich

[Xen-devel] [PATCH] xen: recalculate per-cpupool credits when updating timeslice

When modifying the timeslice of the credit scheduler in a cpupool the cpupool global credit value (n_cpus * credits_per_tslice) isn't recalculated. This will lead to wrong scheduling decisions later. Do the recalculation when updating the timeslice. Signed-off-by: Juergen Gross

[Xen-devel] X86 arch_domain ginormous, sizeof(struct domain) already == PAGE_SIZE

I'm trying to refactor some arch-specific code into common code and was surprised to find out that the x86 domain structure already occupies PAGE_SIZE bytes, couldn't even add an unsigned short field in it w/o causing a compile-time error. I'm using the master branch of

Re: [Xen-devel] [COVERITY ACCESS] for Doug Goldstein

On Fri, Jan 29, 2016 at 10:16:04AM -0600, Doug Goldstein wrote: > Hi all, > > I agree to the conditions in the Xen Project Security [1] and Coverity > [2] Contribution guidelines. > > I have been a Gentoo Linux developer since 2001 and involved with > downstream packaging of virtualization

Re: [Xen-devel] [PATCH v2 1/2] altp2m: Merge p2m_set_altp2m_mem_access and p2m_set_mem_access

>>> On 29.01.16 at 17:32, wrote: > On Fri, Jan 29, 2016 at 9:19 AM, Jan Beulich wrote: >> >>> On 29.01.16 at 17:12, wrote: >> > On Fri, Jan 29, 2016 at 4:03 AM, Jan Beulich wrote: >> >> >>> On 28.01.16 at 21:58,

Re: [Xen-devel] X86 arch_domain ginormous, sizeof(struct domain) already == PAGE_SIZE

> by leaving there only the x86-specific part, i.e.: > struct { > uint8_t mov_to_msr_enabled : 1; > uint8_t mov_to_msr_extended : 1; > } monitor; > > and moving the rest directly into the domain structure, i.e. add @ the end > of struct domain [@

Re: [Xen-devel] [PATCH 3/4] x86/xstate: fix fault behavior on XRSTORS

>>> On 29.01.16 at 17:48, wrote: > On 29/01/16 10:29, Jan Beulich wrote: >> --- a/xen/arch/x86/xstate.c >> +++ b/xen/arch/x86/xstate.c >> @@ -29,6 +29,8 @@ unsigned int *__read_mostly xstate_sizes >> static unsigned int __read_mostly xstate_features; >> static

Re: [Xen-devel] [PATCH V7 1/5] x86/hvm: pkeys, disable pkeys for guests in non-paging mode

>>> On 27.01.16 at 09:30, wrote: > Changes in v7: > no changes. > > > This patch disables pkeys for guest in non-paging mode, However XEN always > uses > paging mode to emulate guest non-paging mode, To emulate this behavior, pkeys > needs to be manually disabled

Re: [Xen-devel] [PATCH v7 06/18] tools/libxl: introduce enum type libxl_checkpointed_stream

On Fri, Jan 29, 2016 at 01:27:22PM +0800, Wen Congyang wrote: > Introduce enum type libxl_checkpointed_stream in IDL. > rename the last argument of migrate_receive from "remus" to > "checkpointed" since the semantics of this parameter has > changed. > > NOTE: > libxl_domain_restore_params and

Re: [Xen-devel] [PATCH v7 07/18] migration/save: pass checkpointed_stream from libxl to libxc

On Fri, Jan 29, 2016 at 01:27:23PM +0800, Wen Congyang wrote: > Pass checkpointed_stream from libxl to libxc. > It won't affact legacy migration because legacy migration > won't use this param. > > Signed-off-by: Yang Hongyang > Signed-off-by: Wen Congyang

[Xen-devel] [PATCH RFC] xen/libxl/libxl: RIP PV superpage.

The last bastion of users is moving away from needing this. Please note that there was an partial removal by c/s 9b3c6b13e0c085ceb53210f8e682a073096b94fa "libxc: remove superpages option for pv domains" so an user could not even run PV guests with superpage. HVM guests are not affected - they

[Xen-devel] [PATCH RFC] Remove PV superpage support (v1).

Hey, This patchset removes the opt_allow_superpage parameter and also the code around it. I've tested (migration, bootup, etc) with normal PV and HVM guests and all works. I haven't yet tested kernels that had PV superpage support in (UEK2, UEK3, classic Xen kernels) but looking at the code

Re: [Xen-devel] [PATCH v2 1/2] altp2m: Merge p2m_set_altp2m_mem_access and p2m_set_mem_access

On Fri, Jan 29, 2016 at 9:19 AM, Jan Beulich wrote: > >>> On 29.01.16 at 17:12, wrote: > > On Fri, Jan 29, 2016 at 4:03 AM, Jan Beulich wrote: > >> >>> On 28.01.16 at 21:58, wrote: > >> > ---

Re: [Xen-devel] [PATCH v7 08/18] tools/libxl: introduce libxl__domain_restore_device_model to load qemu state

On Fri, Jan 29, 2016 at 01:27:24PM +0800, Wen Congyang wrote: > In normal migration, the qemu state is passed to qemu as a parameter. > With COLO, secondary vm is running. So we will do the following steps > at every checkpoint: > 1. suspend both primary vm and secondary vm > 2. sync the state >

Re: [Xen-devel] [PATCH v7 09/18] tools/libxl: introduce libxl__domain_common_switch_qemu_logdirty()

On Fri, Jan 29, 2016 at 01:27:25PM +0800, Wen Congyang wrote: > Secondary vm is running in COLO mode, we need to send secondary > vm's dirty page information to primary host at checkpoint, so we > have to enable qemu logdirty on secondary. > > libxl__domain_suspend_common_switch_qemu_logdirty()

Re: [Xen-devel] [PATCH v7 12/18] tools/libx{l, c}: add back channel to libxc

On Fri, Jan 29, 2016 at 01:27:28PM +0800, Wen Congyang wrote: > In COLO mode, both VMs are running, and are considered in sync if the > visible network traffic is identical. After some time, they fall out of > sync. > > At this point, the two VMs have definitely diverged. Lets call the >

Re: [Xen-devel] [PATCH v2 1/2] altp2m: Merge p2m_set_altp2m_mem_access and p2m_set_mem_access

On Fri, Jan 29, 2016 at 4:03 AM, Jan Beulich wrote: > >>> On 28.01.16 at 21:58, wrote: > > --- a/xen/arch/x86/mm/p2m.c > > +++ b/xen/arch/x86/mm/p2m.c > > @@ -1777,14 +1777,57 @@ bool_t p2m_mem_access_check(paddr_t gpa, > unsigned long gla, > >

Re: [Xen-devel] schedulers and topology exposing questions

On Thu, Jan 28, 2016 at 09:46:46AM +, Dario Faggioli wrote: > On Wed, 2016-01-27 at 11:03 -0500, Elena Ufimtseva wrote: > > On Wed, Jan 27, 2016 at 10:27:01AM -0500, Konrad Rzeszutek Wilk > > wrote: > > > On Wed, Jan 27, 2016 at 03:10:01PM +, George Dunlap wrote: > > > > On 27/01/16 14:33,

Re: [Xen-devel] [PATCH v7 14/18] tools/libxl: fix backword compatibility after the automatic renaming

On Fri, Jan 29, 2016 at 01:27:30PM +0800, Wen Congyang wrote: > The error code ERROR_REMUS_XXX was introduced in Xen 4.5, and > changed to ERROR_CHECKPOINT_XXX after previous renaming. > The patch fix the backword compatibility. > > Signed-off-by: Yang Hongyang >

Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

>>> On 29.01.16 at 11:45, wrote: > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -940,6 +940,8 @@ static int hvm_ioreq_server_alloc_rangesets(struct > hvm_ioreq_server *s, > { > unsigned int i; > int rc; > +unsigned int

Re: [Xen-devel] [PATCH RFC] Remove PV superpage support (v1).

>>> On 29.01.16 at 17:26, wrote: > On Fri, Jan 29, 2016 at 09:00:15AM -0700, Jan Beulich wrote: >> >>> On 29.01.16 at 16:30, wrote: >> > I am hoping the maintainers can guide me in how they would like: >> > - Deal with documentation? I removed the

Re: [Xen-devel] hap_invlpg() vs INVLPGA

>>> On 29.01.16 at 15:02, wrote: > On 29/01/16 14:57, Egger, Christoph wrote: >> On 29/01/16 14:24, Jan Beulich wrote: >>> Christoph, >>> >>> in commit dd6de3ab99 ("Implement Nested-on-Nested") you added >>> code to hap_invlpg() supposedly emulating INVLPGA. I've been >>>

Re: [Xen-devel] [PATCH v2 1/2] altp2m: Merge p2m_set_altp2m_mem_access and p2m_set_mem_access

>>> On 29.01.16 at 17:12, wrote: > On Fri, Jan 29, 2016 at 4:03 AM, Jan Beulich wrote: >> >>> On 28.01.16 at 21:58, wrote: >> > --- a/xen/arch/x86/mm/p2m.c >> > +++ b/xen/arch/x86/mm/p2m.c >> > @@ -1777,14 +1777,57 @@ bool_t

Re: [Xen-devel] [PATCH v7 02/18] tools/libxl: move remus code into libxl_remus.c

On Fri, Jan 29, 2016 at 01:27:18PM +0800, Wen Congyang wrote: > After previous refactoring, we are now able to move all remus code > into a separate file libxl_remus.c. > > Export following functions for internal use: > - Remus callbacks > * libxl__remus_domain_suspend_callback > *

Re: [Xen-devel] [PATCH v7 04/18] libxl/save: Refactor libxl__domain_suspend_state

On Fri, Jan 29, 2016 at 01:27:20PM +0800, Wen Congyang wrote: > Currently struct libxl__domain_suspend_state contains 2 type of states, > one is save state, another is suspend state. This patch separates those > two out. > The motivation of this is that COLO will need to do suspend/resume >

Re: [Xen-devel] [PATCH v7 05/18] tools/libxc: support to resume uncooperative HVM guests

On Fri, Jan 29, 2016 at 01:27:21PM +0800, Wen Congyang wrote: > Before this patch: > 1. suspend > a. PVHVM and PV: we use the same way to suspend the guest (send the suspend >request to the guest). If the guest doesn't support evtchn, the xenstore >variant will be used, suspending the

Re: [Xen-devel] [PATCH v7 03/18] tools/libxl: move save/restore code into libxl_dom_save.c

On Fri, Jan 29, 2016 at 01:27:19PM +0800, Wen Congyang wrote: > This is purely code motion. > > Signed-off-by: Yang Hongyang > Signed-off-by: Wen Congyang > CC: Ian Jackson > CC: Wei Liu >

Re: [Xen-devel] [PATCH 3/4] x86/xstate: fix fault behavior on XRSTORS

On 29/01/16 10:29, Jan Beulich wrote: > XRSTORS unconditionally faults when xcomp_bv has bit 63 clear. Instead > of just fixing this issue, overhaul the fault recovery code, which - > one of the many mistakes made when xstate support got introduced - was > blindly mirroring that accompanying

Re: [Xen-devel] [PATCH RFC] Remove PV superpage support (v1).

>>> On 29.01.16 at 16:30, wrote: > I am hoping the maintainers can guide me in how they would like: > - Deal with documentation? I removed the allowsuperpage from documentation >but perhaps it should just mention deprecated? Since you delete the option, deleting it

[Xen-devel] [COVERITY ACCESS] for Doug Goldstein

Hi all, I agree to the conditions in the Xen Project Security [1] and Coverity [2] Contribution guidelines. I have been a Gentoo Linux developer since 2001 and involved with downstream packaging of virtualization products in Gentoo for at least 8 years with a specific focus on QEMU, libvirt, KVM

Re: [Xen-devel] [PATCH RFC] xen/libxl/libxl: RIP PV superpage.

>>> On 29.01.16 at 16:30, wrote: > @@ -985,20 +968,7 @@ get_page_from_l2e( > return rc; > } > > -if ( !opt_allow_superpage ) > -{ > -MEM_LOG("Attempt to map superpage without allowsuperpage " > -"flag in hypervisor"); > -

Re: [Xen-devel] [PATCH RFC] Remove PV superpage support (v1).

On Fri, Jan 29, 2016 at 09:00:15AM -0700, Jan Beulich wrote: > >>> On 29.01.16 at 16:30, wrote: > > I am hoping the maintainers can guide me in how they would like: > > - Deal with documentation? I removed the allowsuperpage from documentation > >but perhaps it should

Re: [Xen-devel] [PATCH v7 00/18] Prerequisite patches for COLO

On Fri, Jan 29, 2016 at 01:27:16PM +0800, Wen Congyang wrote: > This patchset is Prerequisite for COLO feature. Refer to: > http://wiki.xen.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping > > Patch status: > 1. Acked patches: patch 2, 3, 4, 9, 10, 15, 16, 18 > 2. Reviewd patches: patch 1, 10, 13, 15,

Re: [Xen-devel] [PATCH 4/4] x86/xstate: extend validation to cover full header

On 29/01/16 10:30, Jan Beulich wrote: > Since we never hand out compacted state, at least for now we're also > not going to accept such. > > Reported-by: Harmandeep Kaur > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper

Re: [Xen-devel] X86 arch_domain ginormous, sizeof(struct domain) already == PAGE_SIZE

>>> On 29.01.16 at 17:24, wrote: > To investigate I compiled the unaltered domain.c & used the pahole tool > (part of dwarves package) to obtain the complete layout of the domain > structure (& its members). > What I obtained: > * sizeof(struct domain) is already =

Re: [Xen-devel] [COVERITY ACCESS] for Doug Goldstein

On 29/01/16 16:16, Doug Goldstein wrote: > Hi all, > > I agree to the conditions in the Xen Project Security [1] and Coverity > [2] Contribution guidelines. > > I have been a Gentoo Linux developer since 2001 and involved with > downstream packaging of virtualization products in Gentoo for at

[Xen-devel] [PATCH] x86: Convert shadow-paging to Kconfig

Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Doug Goldstein CC: Tim Deegan CC: George Dunlap v2: * Expand text. Use more-common makefile syntax --- xen/arch/x86/Kconfig

Re: [Xen-devel] [PATCH V2] vm_event: make sure the domain is paused in key domctls

On 29/01/16 08:55, Razvan Cojocaru wrote: > This patch pauses the domain for all writes through the 'ad' > pointer in monitor_domctl(), defers a domain_unpause() call until > after the CRs are updated for the MONITOR_EVENT_WRITE_CTRLREG > case, and makes sure that the domain is paused for both

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

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

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

flight 79424 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/79424/ 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] hap_invlpg() vs INVLPGA

On 29/01/16 16:53, Jan Beulich wrote: On 29.01.16 at 15:02, wrote: >> On 29/01/16 14:57, Egger, Christoph wrote: >>> On 29/01/16 14:24, Jan Beulich wrote: Christoph, in commit dd6de3ab99 ("Implement Nested-on-Nested") you added code to hap_invlpg()

Re: [Xen-devel] [PATCH V2] vm_event: make sure the domain is paused in key domctls

On Fri, Jan 29, 2016 at 10:15 AM, Andrew Cooper wrote: > On 29/01/16 08:55, Razvan Cojocaru wrote: > > This patch pauses the domain for all writes through the 'ad' > > pointer in monitor_domctl(), defers a domain_unpause() call until > > after the CRs are updated for

Re: [Xen-devel] [RFC] support more qdisk types

Konrad Rzeszutek Wilk wrote: > On Wed, Jan 27, 2016 at 07:42:49PM -0700, Jim Fehlig wrote: >> On 01/27/2016 02:09 PM, Konrad Rzeszutek Wilk wrote: >>> On Wed, Jan 27, 2016 at 02:25:51PM -0600, Doug Goldstein wrote: On 1/27/16 12:32 PM, Konrad Rzeszutek Wilk wrote: > On Mon, Jan 25, 2016

Re: [Xen-devel] [RFC] support more qdisk types

On Fri, Jan 29, 2016 at 10:18:01AM -0700, Jim Fehlig wrote: > Konrad Rzeszutek Wilk wrote: > > On Wed, Jan 27, 2016 at 07:42:49PM -0700, Jim Fehlig wrote: > >> On 01/27/2016 02:09 PM, Konrad Rzeszutek Wilk wrote: > >>> On Wed, Jan 27, 2016 at 02:25:51PM -0600, Doug Goldstein wrote: > On

Re: [Xen-devel] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks

On Fri, 2016-01-29 at 08:09 +0100, Gerd Hoffmann wrote: >   Hi, >  > > 1) The OpRegion MemoryRegion is mapped into system_memory through > > programming of the 0xFC config space register. > >  a) vfio-pci could pick an address to do this as it is realized. > >  b) SeaBIOS/OVMF could program this.

Re: [Xen-devel] X86 arch_domain ginormous, sizeof(struct domain) already == PAGE_SIZE

On 29/01/16 17:09, Jan Beulich wrote: On 29.01.16 at 17:24, wrote: >> To investigate I compiled the unaltered domain.c & used the pahole tool >> (part of dwarves package) to obtain the complete layout of the domain >> structure (& its members). >> What I obtained: >>

Re: [Xen-devel] [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks

> -Original Message- > From: iGVT-g [mailto:igvt-g-boun...@lists.01.org] On Behalf Of Alex > Williamson > Sent: Friday, January 29, 2016 10:00 AM > To: Gerd Hoffmann > Cc: igv...@ml01.01.org; xen-de...@lists.xensource.com; Eduardo Habkost; > Stefano Stabellini; qemu-de...@nongnu.org; Cao

Re: [Xen-devel] pre Sandy bridge IOMMU support (gm45)

On Tue, Jan 26, 2016 at 04:37:05AM -0700, Jan Beulich wrote: > (re-adding xen-devel) > > >>> On 26.01.16 at 12:28, wrote: > > Iommu=0 let the whole Qubes system work, without enforcing hardware > > compartimentalisation (iommu is enforced in software mode) > > > >

Re: [Xen-devel] [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks

> -Original Message- > From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Thursday, January 28, 2016 6:55 PM > To: Kay, Allen M; Gerd Hoffmann; qemu-de...@nongnu.org > Cc: igv...@ml01.01.org; xen-de...@lists.xensource.com; Eduardo Habkost; > Stefano Stabellini; Cao jin;

Re: [Xen-devel] schedulers and topology exposing questions

On Thu, Jan 28, 2016 at 09:55:45AM +, Dario Faggioli wrote: > On Wed, 2016-01-27 at 15:53 +, George Dunlap wrote: > > On 27/01/16 15:27, Konrad Rzeszutek Wilk wrote: > > >  > > > So Elena started looking at the CPU bound and seeing how Xen > > > behaves then > > > and if we can improve the

Re: [Xen-devel] [PATCH V2 1/1] Improved RTDS scheduler

On 1/26/2016 12:28 PM, Meng Xu wrote: Hi Dario and Tianyang, On Tue, Jan 26, 2016 at 9:06 AM, Dario Faggioli wrote: On Mon, 2016-01-25 at 18:00 -0500, Meng Xu wrote: On Mon, Jan 25, 2016 at 5:04 PM, Tianyang Chen wrote: I have removed some

[Xen-devel] [linux-mingo-tip-master test] 79388: regressions - FAIL

flight 79388 linux-mingo-tip-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/79388/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684

[Xen-devel] [linux-linus test] 79389: regressions - FAIL

flight 79389 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/79389/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 59254

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

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

[Xen-devel] [linux-3.14 test] 79397: regressions - FAIL

flight 79397 linux-3.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/79397/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 78986

[Xen-devel] [GIT PULL] (xen) stable/for-jens-4.5

Hey Jens, Please git pull the following branch: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-4.5 which has one bug-fix. I had it in my tree at some point and after an rebase (done months ago) lost it! It solves an migration problem where the number of queues may

Re: [Xen-devel] [BUG] pci-passthrough generates "xen:events: Failed to obtain physical IRQ" for some devices

On Wed, Jan 27, 2016 at 01:30:05PM -0500, Konrad Rzeszutek Wilk wrote: > On Sat, Jan 23, 2016 at 05:12:04PM +0100, Tommi Airikka wrote: > > Xen developers, > > > > After an upgrade of my Debian Jessie dom0 and domUs, my passthroughed > > NIC stopped working. I have very similar (the same?)

Re: [Xen-devel] X86 arch_domain ginormous, sizeof(struct domain) already == PAGE_SIZE

On 1/29/2016 6:47 PM, Lengyel, Tamas wrote: by leaving there only the x86-specific part, i.e.: struct { uint8_t mov_to_msr_enabled : 1; uint8_t mov_to_msr_extended : 1; } monitor; and moving the rest directly into the domain

  1   2   >