[Xen-devel] [linux-linus test] 110178: regressions - trouble: blocked/broken/fail/pass

flight 110178 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/110178/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-vhd 3 host-install(3)broken REGR. vs. 110093

[Xen-devel] [linux-next test] 110177: regressions - trouble: blocked/broken/fail/pass

flight 110177 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/110177/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ws16-amd64 3 host-install(3) broken REGR. vs. 110131 test-amd64-i386-xl

[Xen-devel] Delivery Status Notification (Delay)

** Delivery incomplete ** There was a temporary problem delivering your message to curtiskwo...@gmail.com. Gmail will retry for 22 more hours. You'll be notified if the delivery fails permanently. Reporting-MTA: dns; googlemail.com Received-From-MTA: dns;

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

flight 110165 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/110165/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 110063 Tests

[Xen-devel] [xen-unstable baseline-only test] 71536: regressions - trouble: blocked/broken/fail/pass

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

[Xen-devel] [ovmf bisection] complete build-amd64

branch xen-unstable xenbranch xen-unstable job build-amd64 testid xen-build Tree: ovmf https://github.com/tianocore/edk2.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced

Re: [Xen-devel] [PATCH v4 3/8] mm: Scrub pages in alloc_heap_pages() if needed

On 06/09/2017 11:22 AM, Jan Beulich wrote: On 19.05.17 at 17:50, wrote: >> @@ -734,8 +735,15 @@ static struct page_info *get_free_buddy(unsigned int >> zone_lo, >> >> /* Find smallest order which can satisfy the request. */ >> for ( j

[Xen-devel] [xen-unstable-smoke test] 110201: tolerable trouble: broken/pass - PUSHED

flight 110201 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/110201/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 12

Re: [Xen-devel] [PATCH v4 1/8] mm: Place unscrubbed pages at the end of pagelist

On 06/09/2017 10:50 AM, Jan Beulich wrote: On 19.05.17 at 17:50, wrote: >> --- a/xen/common/page_alloc.c >> +++ b/xen/common/page_alloc.c >> @@ -383,6 +383,8 @@ typedef struct page_list_head >> heap_by_zone_and_order_t[NR_ZONES][MAX_ORDER+1]; >> static

Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

>> >> PV guests don't go through Linux x86 early boot code. They start at >> xen_start_kernel() (well, xen-head.S:startup_xen(), really) and merge >> with baremetal path at x86_64_start_reservations() (for 64-bit). >> > > Ok, I don't think anything needs to be done then. The sme_me_mask is set >

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

flight 110161 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/110161/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qcow210 guest-start fail REGR. vs. 109975

Re: [Xen-devel] [PATCH v10 25/32] ARM: vITS: handle MAPTI/MAPI command

On Fri, 9 Jun 2017, Andre Przywara wrote: > On 02/06/17 18:12, Julien Grall wrote: > > Hi Andre, > > > > On 05/26/2017 06:35 PM, Andre Przywara wrote: > >> The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU > >> pair and actually instantiates LPI interrupts. MAPI is just a

Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

On 6/9/2017 1:43 PM, Boris Ostrovsky wrote: On 06/09/2017 02:36 PM, Tom Lendacky wrote: On 6/8/2017 5:01 PM, Andrew Cooper wrote: On 08/06/2017 22:17, Boris Ostrovsky wrote: On 06/08/2017 05:02 PM, Tom Lendacky wrote: On 6/8/2017 3:51 PM, Boris Ostrovsky wrote: What may be needed is making

Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

On 09/06/17 19:43, Boris Ostrovsky wrote: > On 06/09/2017 02:36 PM, Tom Lendacky wrote: >>> basis, although (as far as I am aware) Xen as a whole would be able to >>> encompass itself and all of its PV guests inside one single SME >>> instance. >> Yes, that is correct. Thinking more about this,

Re: [Xen-devel] [PATCH 2/2] x86: consolidate atomic build_*() macros

On 09/06/17 13:44, Jan Beulich wrote: > Use a single macro to define both read and write inline functions. > Avoid redundant inputs (including quotes - use stringification > instead). Generalize "add" to ease eventual addition of other > artihmetic operations. > > At once correct the artihmetic

Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

On 06/09/2017 02:36 PM, Tom Lendacky wrote: > On 6/8/2017 5:01 PM, Andrew Cooper wrote: >> On 08/06/2017 22:17, Boris Ostrovsky wrote: >>> On 06/08/2017 05:02 PM, Tom Lendacky wrote: On 6/8/2017 3:51 PM, Boris Ostrovsky wrote: >>> What may be needed is making sure X86_FEATURE_SME is not

Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

On 6/8/2017 5:01 PM, Andrew Cooper wrote: On 08/06/2017 22:17, Boris Ostrovsky wrote: On 06/08/2017 05:02 PM, Tom Lendacky wrote: On 6/8/2017 3:51 PM, Boris Ostrovsky wrote: What may be needed is making sure X86_FEATURE_SME is not set for PV guests. And that may be something that Xen will

Re: [Xen-devel] [PATCH 06/14 v4] xen/arm: vpl011: Add a new domctl API to initialize vpl011

On Fri, 9 Jun 2017, Julien Grall wrote: > Hi Stefano, > > On 07/06/17 00:26, Stefano Stabellini wrote: > > > diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c > > > index 00909ad4..a8efd5e 100644 > > > --- a/tools/libxc/xc_domain.c > > > +++ b/tools/libxc/xc_domain.c > > > @@ -343,6

Re: [Xen-devel] [PATCH 1/2] x86: drop unused barrier parameter from build_{read, write}_atomic()

On 09/06/17 13:43, Jan Beulich wrote: > Also take the opportunity and make an attempt at making the macro > definitions readable. Drop pointless casts while doing so. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper , although as I've said

[Xen-devel] [libvirt test] 110162: regressions - FAIL

flight 110162 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/110162/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt 11 guest-start fail REGR. vs. 110107 Tests which did not

Re: [Xen-devel] [PATCH 03/14 v4] xen/arm: vpl011: Add pl011 uart emulation in Xen

On Fri, 9 Jun 2017, Julien Grall wrote: > Hi, > > On 07/06/17 00:02, Stefano Stabellini wrote: > > On Tue, 6 Jun 2017, Bhupinder Thakur wrote: > > > +static uint8_t vpl011_read_data(struct domain *d) > > > +{ > > > +unsigned long flags; > > > +uint8_t data = 0; > > > +struct vpl011

Re: [Xen-devel] [PATCH] x86emul: minor cleanup

On 08/06/17 16:49, Jan Beulich wrote: > Drop a redundant input constraint, correct a comment, and (re)move > fix.insn_bytes adjustments (these aren't needed for custom stub > invocations when the instruction placed in the stub can't raise #XF) I'm not sure these are wise to remove. Even if we

Re: [Xen-devel] [xen-unstable test] 110009: regressions - FAIL

On Fri, 9 Jun 2017, Jan Beulich wrote: > >>> On 07.06.17 at 10:12, wrote: > On 06.06.17 at 21:19, wrote: > >> On Tue, 6 Jun 2017, Jan Beulich wrote: > >>> >>> On 06.06.17 at 16:00, wrote: > >>> > Looking at the serial

[Xen-devel] [PATCH v11 29/34] ARM: vITS: handle DISCARD command

The DISCARD command drops the connection between a DeviceID/EventID and an LPI/collection pair. We mark the respective structure entries as not allocated and make sure that any queued IRQs are removed. Signed-off-by: Andre Przywara Acked-by: Julien Grall

[Xen-devel] [PATCH v11 34/34] ARM: vITS: create ITS subnodes for Dom0 DT

Dom0 expects all ITSes in the system to be propagated to be able to use MSIs. Create Dom0 DT nodes for each hardware ITS, keeping the register frame address the same, as the doorbell address that the Dom0 drivers program into the BARs has to match the hardware. Signed-off-by: Andre Przywara

[Xen-devel] [PATCH v11 32/34] ARM: vITS: increase mmio_count for each ITS

Increase the count of MMIO regions needed by one for each ITS Dom0 has to emulate. We emulate the ITSes 1:1 from the hardware, so the number is the number of host ITSes. Signed-off-by: Andre Przywara Acked-by: Julien Grall ---

[Xen-devel] [PATCH v11 31/34] ARM: vITS: handle INVALL command

The INVALL command instructs an ITS to invalidate the configuration data for all LPIs associated with a given redistributor (read: VCPU). This is nasty to emulate exactly with our architecture, so we just iterate over all mapped LPIs and filter for those from that particular VCPU. Signed-off-by:

[Xen-devel] [PATCH v11 33/34] ARM: vITS: create and initialize virtual ITSes for Dom0

For each hardware ITS create and initialize a virtual ITS for Dom0. We use the same memory mapped address to keep the doorbell working. This introduces a function to initialize a virtual ITS. We maintain a list of virtual ITSes, at the moment for the only purpose of later being able to free them

[Xen-devel] [PATCH v11 30/34] ARM: vITS: handle INV command

The INV command instructs the ITS to update the configuration data for a given LPI by re-reading its entry from the property table. We don't need to care so much about the priority value, but enabling or disabling an LPI has some effect: We remove or push virtual LPIs to their VCPUs, also check

[Xen-devel] [PATCH v11 27/34] ARM: vITS: handle MAPTI/MAPI command

The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU pair and actually instantiates LPI interrupts. MAPI is just a variant of this comment, where the LPI ID is the same as the event ID. We connect the already allocated host LPI to this virtual LPI, so that any triggering LPI on the

[Xen-devel] [PATCH v11 16/34] ARM: introduce vgic_access_guest_memory()

From: Vijaya Kumar K This function allows to copy a chunk of data from and to guest physical memory. It looks up the associated page from the guest's p2m tree and maps this page temporarily for the time of the access. This function was originally written by

[Xen-devel] [PATCH v11 26/34] ARM: GICv3: handle unmapped LPIs

When LPIs get unmapped by a guest, they might still be in some LR of some VCPU. Nevertheless we remove the corresponding pending_irq (possibly freeing it), and detect this case (irq_to_pending() returns NULL) when the LR gets cleaned up later. However a *new* LPI may get mapped with the same

[Xen-devel] [PATCH v11 12/34] ARM: vGIC: add LPI VCPU ID to struct pending_irq

The target CPU for an LPI is encoded in the interrupt translation table entry, so can't be easily derived from just an LPI number (short of walking *all* tables and find the matching LPI). To avoid this in case we need to know the VCPU (for the INVALL command, for instance), put the VCPU ID in the

[Xen-devel] [PATCH v11 22/34] ARM: vITS: handle INT command

The INT command sets a given LPI identified by a DeviceID/EventID pair as pending and thus triggers it to be injected. Signed-off-by: Andre Przywara Reviewed-by: Julien Grall --- xen/arch/arm/vgic-v3-its.c | 29 +++-- 1 file

[Xen-devel] [PATCH v11 13/34] ARM: GIC: ITS: remove no longer needed VCPU ID in host LPI entry

To get easy access to the VCPU a forwareded LPI interrupt should be injected to, so far we stored the VCPU ID in the host LPI entry. However this creates a redundancy, since we keep the target VCPU in the struct pending_irq already, which we can easily look up given the domain and the virtual LPI

[Xen-devel] [PATCH v11 24/34] ARM: vITS: handle CLEAR command

This introduces the ITS command handler for the CLEAR command, which clears the pending state of an LPI. This removes a not-yet injected, but already queued IRQ from a VCPU. As read_itte() is now eventually used, we add the static keyword. Signed-off-by: Andre Przywara

[Xen-devel] [PATCH v11 28/34] ARM: vITS: handle MOVI command

The MOVI command moves the interrupt affinity from one redistributor (read: VCPU) to another. For now migration of "live" LPIs is not yet implemented, but we store the changed affinity in our virtual ITTE and the pending_irq. Signed-off-by: Andre Przywara ---

[Xen-devel] [PATCH v11 25/34] ARM: vITS: handle MAPD command

The MAPD command maps a device by associating a memory region for storing ITEs with a certain device ID. Since it features a valid bit, MAPD also covers the "unmap" functionality, which we also cover here. We store the given guest physical address in the device table, and, if this command comes

[Xen-devel] [PATCH v11 23/34] ARM: vITS: handle MAPC command

The MAPC command associates a given collection ID with a given redistributor, thus mapping collections to VCPUs. We just store the vcpu_id in the collection table for that. Signed-off-by: Andre Przywara Acked-by: Julien Grall ---

[Xen-devel] [PATCH v11 14/34] ARM: GICv3: forward pending LPIs to guests

Upon receiving an LPI on the host, we need to find the right VCPU and virtual IRQ number to get this IRQ injected. Iterate our two-level LPI table to find the domain ID and the virtual LPI number quickly when the host takes an LPI. We then look up the right VCPU in the struct pending_irq. We use

[Xen-devel] [PATCH v11 20/34] ARM: vITS: introduce translation table walks

The ITS stores the target (v)CPU and the (virtual) LPI number in tables. Introduce functions to walk those tables and translate an device ID - event ID pair into a pair of virtual LPI and vCPU. We map those tables on demand - which is cheap on arm64 - and copy the respective entries before using

[Xen-devel] [PATCH v11 21/34] ARM: vITS: provide access to struct pending_irq

For each device we allocate one struct pending_irq for each virtual event (MSI). Provide a helper function which returns the pointer to the appropriate struct, to be able to find the right struct when given a virtual deviceID/eventID pair. Signed-off-by: Andre Przywara

[Xen-devel] [PATCH v11 18/34] ARM: vGIC: advertise LPI support

To let a guest know about the availability of virtual LPIs, set the respective bits in the virtual GIC registers and let a guest control the LPI enable bit. Only report the LPI capability if there is at least one ITS emulated for that guest (which depends on the host having an ITS at the moment).

[Xen-devel] [PATCH v11 19/34] ARM: vITS: add command handling stub and MMIO emulation

Emulate the memory mapped ITS registers and provide a stub to introduce the ITS command handling framework (but without actually emulating any commands at this time). This fixes a misnomer in our virtual ITS structure, where the spec is confusingly using ID_bits in GITS_TYPER to denote the number

[Xen-devel] [PATCH v11 17/34] ARM: vGICv3: re-use vgic_reg64_check_access

vgic_reg64_check_access() checks for a valid access width of a 64-bit MMIO register, which is useful beyond the current GICv3 emulation only. Move this function to the vgic-emul.h to be easily reusable. Signed-off-by: Andre Przywara Acked-by: Julien Grall

[Xen-devel] [PATCH v11 15/34] ARM: vGICv3: handle virtual LPI pending and property tables

Allow a guest to provide the address and size for the memory regions it has reserved for the GICv3 pending and property tables. We sanitise the various fields of the respective redistributor registers. The MMIO read and write accesses are protected by locks, to avoid any changing of the property

[Xen-devel] [PATCH v11 05/34] ARM: vGIC: rework gic_remove_from_queues()

The function name gic_remove_from_queues() was a bit of a misnomer, since it just removes an IRQ from the pending queue, not both queues. Rename the function to make this more clear, also give it a pointer to a struct pending_irq directly and rely on the VGIC VCPU lock to be already taken, so this

[Xen-devel] [PATCH v11 10/34] ARM: GIC: export and extend vgic_init_pending_irq()

For LPIs we later want to dynamically allocate struct pending_irqs. So beside needing to initialize the struct from there we also need to clean it up and re-initialize it later on. Export vgic_init_pending_irq() and extend it to be reusable. Signed-off-by: Andre Przywara

[Xen-devel] [PATCH v11 11/34] ARM: vGIC: cache virtual LPI priority in struct pending_irq

We enhance struct pending_irq to cache the priority information for LPIs. Reading the information from there is faster than accessing the property table from guest memory. Also it use some padding area in the struct, so does not require more memory. This introduces the function to retrieve the LPI

[Xen-devel] [PATCH v11 06/34] ARM: vGIC: move irq_to_pending() calls under the VGIC VCPU lock

So far irq_to_pending() is just a convenience function to lookup statically allocated arrays. This will change with LPIs, which are more dynamic, so the memory for their struct pending_irq might go away. The proper answer to the issue of preventing stale pointers is ref-counting, which requires

[Xen-devel] [PATCH v11 08/34] ARM: GIC: Add checks for NULL pointer pending_irq's

For LPIs the struct pending_irq's are dynamically allocated and the pointers will be stored in a radix tree. Since an LPI can be "unmapped" at any time, teach the VGIC how to deal with irq_to_pending() returning a NULL pointer. We just do nothing in this case or clean up the LR if the virtual LPI

[Xen-devel] [PATCH v11 09/34] ARM: GICv3: introduce separate pending_irq structs for LPIs

For the same reason that allocating a struct irq_desc for each possible LPI is not an option, having a struct pending_irq for each LPI is also not feasible. We only care about mapped LPIs, so we can get away with having struct pending_irq's only for them. Maintain a radix tree per domain where we

[Xen-devel] [PATCH v11 04/34] ARM: GICv3: setup number of LPI bits for a GICv3 guest

The host supports a certain number of LPI identifiers, as stored in the GICD_TYPER register. Store this number from the hardware register in vgic_v3_hw to allow injecting the very same number into a guest (Dom0). DomUs get the legacy number of 10 bits here, since for now it only sees SPIs, so it

[Xen-devel] [PATCH v11 07/34] ARM: vGIC: introduce gic_remove_irq()

To avoid code duplication in a later patch, introduce a generic function to remove a virtual IRQ from the VGIC. Call that function instead of the open-coded version in vgic_migrate_irq(). Signed-off-by: Andre Przywara --- xen/arch/arm/gic.c| 9 +

[Xen-devel] [PATCH v11 03/34] ARM: GICv3: enable LPIs on the host

Now that the host part of the ITS code is in place, we can enable the LPIs on each redistributor to get the show rolling. At this point there would be no LPIs mapped, as guests don't know about the ITS yet. Signed-off-by: Andre Przywara Acked-by: Stefano Stabellini

[Xen-devel] [PATCH v11 00/34] arm64: Dom0 ITS emulation

Hi, fixes to v10, with their number getting eventually smaller ;-) The same restriction as for the previous versions still apply: the locking is considered somewhat insufficient and will be fixed by an upcoming rework. Patch 01/34 was reworked to properly synchronize access to the priority in a

[Xen-devel] [PATCH v11 02/34] ARM: GICv3: enable ITS on the host

Even though the ITS emulation is not yet in place, the host ITS already gets initialized and Xen tries to map the host collections. However for commands to be processed we need to *enable* the ITS, which will be done in a later patch not yet merged. So those MAPC commands are not processed and run

[Xen-devel] [PATCH v11 01/34] ARM: vGIC: avoid rank lock when reading priority

When reading the priority value of a virtual interrupt, we were taking the respective rank lock so far. However for forwarded interrupts (Dom0 only so far) this may lead to a deadlock with the following call chain: - MMIO access to change the IRQ affinity, calling the ITARGETSR handler - this

Re: [Xen-devel] [PATCH] x86/mm: drop further relics of translated PV domains

On 08/06/17 16:30, Jan Beulich wrote: > For PV domains paging_mode_{refcounts,translate}() are always false as > of commits 4045953527 ("x86/paging: Enforce PG_external == PG_translate > == PG_refcounts") and 92942fd3d4 ("x86/mm: drop > guest_{map,get_eff}_l1e() hooks"). > > Signed-off-by: Jan

Re: [Xen-devel] [PATCH] x86: get_page_from_gfn() should not return misleading type

On 08/06/17 16:21, Jan Beulich wrote: > It is not impossible that the page owner is dom_io. While no current > caller cares about this case, let's nevertheless return an appropriate > type even in that case. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper

[Xen-devel] [linux-4.9 test] 110151: regressions - trouble: broken/fail/pass

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

Re: [Xen-devel] [PATCH for v4.9] livepatch: Wrong usage of spinlock on debug console.

On 06/09/2017 10:16 AM, Konrad Rzeszutek Wilk wrote: > If we have a large amount of livepatches and want to print them > on the console using 'xl debug-keys x' we eventually hit > the preemption check: > > if ( i && !(i % 64) ) > { > spin_unlock(_lock); >

Re: [Xen-devel] [PATCH LIVEPATCH-BUILD-TOOLS 2/2] Remove section alignment requirement

On Fri, Jun 09, 2017 at 06:00:35PM +0100, Andrew Cooper wrote: > On 09/06/17 17:38, Konrad Rzeszutek Wilk wrote: > > On Fri, Jun 09, 2017 at 05:03:36PM +0100, Ross Lagerwall wrote: > >> Remove the requirement that section twins have the same alignment. The > >> section alignment of the patched

Re: [Xen-devel] [PATCH LIVEPATCH-BUILD-TOOLS 2/2] Remove section alignment requirement

On 09/06/17 17:38, Konrad Rzeszutek Wilk wrote: > On Fri, Jun 09, 2017 at 05:03:36PM +0100, Ross Lagerwall wrote: >> Remove the requirement that section twins have the same alignment. The >> section alignment of the patched section is respected by the loader in >> Xen so it shouldn't matter if the

[Xen-devel] [PATCH 2/2] x86/altp2m: Add a hvmop for setting the suppress #VE bit

Introduce a new hvmop, HVMOP_altp2m_set_suppress_ve, which allows a privileged domain to change the value of the #VE suppress bit for a page. Add a libxc wrapper for invoking this hvmop. Signed-off-by: Adrian Pop --- tools/libxc/include/xenctrl.h | 2 ++

[Xen-devel] [PATCH 0/2] x86: Add a hvmop for setting the #VE suppress bit

As the code stands right now, after DomU has enabled #VE using HVMOP_altp2m_vcpu_enable_notify, all its pages have the #VE suppress bit cleared, generating #VEs for any EPT violation. There is currently no way to change the value of the #VE suppress bit for a page from a domain; it can only be

[Xen-devel] [PATCH 1/2] x86/mm: Change default value for suppress #VE in set_mem_access()

From: Vlad Ioan Topan The default value for the "suppress #VE" bit set by set_mem_access() currently depends on whether the call is made from the same domain (the bit is set when called from another domain and cleared if called from the same domain). This patch changes

Re: [Xen-devel] [PATCH] xen: credit2: enable per cpu runqueue creation

On Tue, 2017-04-11 at 21:45 +0530, Praveen Kumar wrote: > The patch introduces a new command line option 'cpu' that when used > will create > runqueue per logical pCPU. This may be useful for small systems, and > also for > development, performance evalution and comparison. > > Signed-off-by:

Re: [Xen-devel] [RFC PATCH v4] xen: credit2: provide custom option to create runqueue

Hey Praveen, Here we are, sorry for the delay. On Wed, 2017-04-19 at 23:15 +0530, Praveen Kumar wrote: > index 33e54aef63..f2ee4ad972 100644 > --- a/docs/misc/xen-command-line.markdown > +++ b/docs/misc/xen-command-line.markdown > @@ -525,7 +525,7 @@ also slow in responding to load changes. >  

Re: [Xen-devel] [PATCH LIVEPATCH-BUILD-TOOLS 2/2] Remove section alignment requirement

On Fri, Jun 09, 2017 at 05:03:36PM +0100, Ross Lagerwall wrote: > Remove the requirement that section twins have the same alignment. The > section alignment of the patched section is respected by the loader in > Xen so it shouldn't matter if the original section alignment was > different. Why

Re: [Xen-devel] [PATCH LIVEPATCH-BUILD-TOOLS 1/2] Ignore .discard sections

On Fri, Jun 09, 2017 at 05:03:35PM +0100, Ross Lagerwall wrote: > Ignore differences in discard sections. They are not included in the final xen > binary so there is no need to include them in the live patch. > > Signed-off-by: Ross Lagerwall Reviewed-by: Konrad

Re: [Xen-devel] [PATCH LIVEPATCH-BUILD-TOOLS 2/2] Remove section alignment requirement

On 09/06/17 17:03, Ross Lagerwall wrote: > Remove the requirement that section twins have the same alignment. The > section alignment of the patched section is respected by the loader in > Xen so it shouldn't matter if the original section alignment was > different. > > Signed-off-by: Ross

Re: [Xen-devel] [PATCH LIVEPATCH-BUILD-TOOLS 1/2] Ignore .discard sections

On 09/06/17 17:03, Ross Lagerwall wrote: > Ignore differences in discard sections. They are not included in the final xen > binary so there is no need to include them in the live patch. > > Signed-off-by: Ross Lagerwall Reviewed-by: Andrew Cooper

Re: [Xen-devel] xsa213 and live patching

On 06/09/2017 08:22 AM, Sarah Newman wrote: Has anyone tried to generate a live patch for xsa213 against 4.8? When I try to do so I get errors for common/compat/compat/multicall.o and xen/common/multicall.o stating that 'changed section .discard not selected for inclusion'. I think, but could

[Xen-devel] [qemu-mainline bisection] complete test-amd64-amd64-libvirt-vhd

branch xen-unstable xenbranch xen-unstable job test-amd64-amd64-libvirt-vhd testid guest-start Tree: libvirt git://xenbits.xen.org/libvirt.git Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git Tree: linux

[Xen-devel] [GIT PULL] xen: fix for 4.12 rc5

Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.12b-rc5-tag xen: fix for 4.12 rc5 It contains a fix for Xen on ARM when dealing with 64kB page size of a guest. Thanks. Juergen drivers/xen/privcmd.c | 4 ++-- 1 file changed,

[Xen-devel] [PATCH LIVEPATCH-BUILD-TOOLS 2/2] Remove section alignment requirement

Remove the requirement that section twins have the same alignment. The section alignment of the patched section is respected by the loader in Xen so it shouldn't matter if the original section alignment was different. Signed-off-by: Ross Lagerwall ---

[Xen-devel] [PATCH LIVEPATCH-BUILD-TOOLS 1/2] Ignore .discard sections

Ignore differences in discard sections. They are not included in the final xen binary so there is no need to include them in the live patch. Signed-off-by: Ross Lagerwall --- create-diff-object.c | 8 1 file changed, 8 insertions(+) diff --git

Re: [Xen-devel] debian stretch dom0 + xen 4.9 fails to boot

>>> On 09.06.17 at 17:47, wrote: > I'll go have a look and the linux edd code. I'm also trying a BIOS update > (which is proving to be trickier than I thought as it seems to have killed > networking in some weird way). Speaks for the quality of what that vendor

Re: [Xen-devel] debian stretch dom0 + xen 4.9 fails to boot

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 09 June 2017 16:41 > To: Paul Durrant > Cc: Julien Grall (julien.gr...@arm.com) ; Andrew > Cooper ; xen-devel(xen- >

Re: [Xen-devel] debian stretch dom0 + xen 4.9 fails to boot

>>> On 09.06.17 at 17:14, wrote: > I've characterised the issue some more and it appears to be an overflow > inside the int13 handler if es:bx is less than 512 bytes below a 4k boundary. > I modified the code to use a hardcoded segment, which I set at 0x6000, and > all

Re: [Xen-devel] [PATCH v4 3/8] mm: Scrub pages in alloc_heap_pages() if needed

>>> On 19.05.17 at 17:50, wrote: > @@ -734,8 +735,15 @@ static struct page_info *get_free_buddy(unsigned int > zone_lo, > > /* Find smallest order which can satisfy the request. */ > for ( j = order; j <= MAX_ORDER; j++ ) > +{ >

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

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

Re: [Xen-devel] debian stretch dom0 + xen 4.9 fails to boot

> -Original Message- > From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] > Sent: 09 June 2017 14:52 > To: Jan Beulich ; Paul Durrant > > Cc: Julien Grall (julien.gr...@arm.com) ; Andrew > Cooper

Re: [Xen-devel] [PATCH v4 2/8] mm: Extract allocation loop from alloc_heap_pages()

>>> On 19.05.17 at 17:50, wrote: > --- a/xen/common/page_alloc.c > +++ b/xen/common/page_alloc.c > @@ -694,22 +694,15 @@ static void page_list_add_scrub(struct page_info *pg, > unsigned int node, > page_list_add(pg, (node, zone, order)); > } > > -/*

Re: [Xen-devel] [PATCH for v4.9] livepatch: Wrong usage of spinlock on debug console.

On 06/09/2017 03:16 PM, Konrad Rzeszutek Wilk wrote: If we have a large amount of livepatches and want to print them on the console using 'xl debug-keys x' we eventually hit the preemption check: if ( i && !(i % 64) ) { spin_unlock(_lock); process_pending_softirqs();

Re: [Xen-devel] [PATCH for v4.9] livepatch: Wrong usage of spinlock on debug console.

>>> On 09.06.17 at 16:16, wrote: > If we have a large amount of livepatches and want to print them > on the console using 'xl debug-keys x' we eventually hit > the preemption check: > > if ( i && !(i % 64) ) > { > spin_unlock(_lock); >

Re: [Xen-devel] [PATCH v4 1/8] mm: Place unscrubbed pages at the end of pagelist

>>> On 19.05.17 at 17:50, wrote: > --- a/xen/common/page_alloc.c > +++ b/xen/common/page_alloc.c > @@ -383,6 +383,8 @@ typedef struct page_list_head > heap_by_zone_and_order_t[NR_ZONES][MAX_ORDER+1]; > static heap_by_zone_and_order_t *_heap[MAX_NUMNODES]; > #define

[Xen-devel] [xen-unstable-smoke test] 110187: tolerable trouble: broken/pass - PUSHED

flight 110187 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/110187/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 12

Re: [Xen-devel] [OSSTEST PATCH v4 00/11] livepatch test support

Konrad Rzeszutek Wilk writes ("Re: [OSSTEST PATCH v4 00/11] livepatch test support"): > Done. I am satisfied with them. Great, thanks. I have pushed this to osstest pretest. I think it should go through without regressions; the new tests will fail, of course, on Xen branches that don't have

Re: [Xen-devel] [PATCH v3] SVM: clean up svm_vmcb_isvalid()

On 06/09/2017 08:44 AM, Jan Beulich wrote: > - correct CR3, CR4, and EFER checks > - delete bogus nested paging check > - add vcpu parameter (to include in log messages) and constify vmcb one > - use bool/true/false > - use accessors (and local variables to improve code readability) > - adjust

Re: [Xen-devel] [PATCH for-4.9 0/4] Makefiles: Provide way to ship livepatch tests

Julien Grall writes ("Re: [PATCH for-4.9 0/4] Makefiles: Provide way to ship livepatch tests"): > Release-acked-by: Julien Grall Thanks. I have pushed this to staging and will wait for an osstest test report to check I didn't break the build, before applying the same

Re: [Xen-devel] preparations 4.7.3 and 4.6.6

On 09/06/17 13:47, Jan Beulich wrote: > >> The prereq revert is fine for backport to 4.7 (which was when the change >> was introduced. > You mean - other than I've indicated - without the follow-up > also backported? The two patches are logically independent. They were presented as a series

Re: [Xen-devel] [PATCH 2/3] x86/altp2m: Add a hvmop for setting the suppress #VE bit

On Thu, Jun 08, 2017 at 08:08:56AM -0600, Jan Beulich wrote: > >>> On 08.06.17 at 15:49, wrote: > > On Tue, Jun 06, 2017 at 07:08:43AM -0600, Jan Beulich wrote: > >> >>> On 06.06.17 at 15:00, wrote: > >> > On Mon, May 29, 2017 at 08:38:33AM -0600, Jan

[Xen-devel] [PATCH for v4.9] livepatch: Wrong usage of spinlock on debug console.

If we have a large amount of livepatches and want to print them on the console using 'xl debug-keys x' we eventually hit the preemption check: if ( i && !(i % 64) ) { spin_unlock(_lock); process_pending_softirqs(); if ( spin_trylock(_lock) ) return

Re: [Xen-devel] [PATCH 06/14 v4] xen/arm: vpl011: Add a new domctl API to initialize vpl011

Hi Bhupinder, On 06/06/17 18:25, Bhupinder Thakur wrote: diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h index 1629f41..77425dd 100644 --- a/tools/libxc/include/xenctrl.h +++ b/tools/libxc/include/xenctrl.h @@ -884,6 +884,23 @@ int xc_vcpu_getcontext(xc_interface

Re: [Xen-devel] [PATCH 06/14 v4] xen/arm: vpl011: Add a new domctl API to initialize vpl011

Hi Stefano, On 07/06/17 00:26, Stefano Stabellini wrote: diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c index 00909ad4..a8efd5e 100644 --- a/tools/libxc/xc_domain.c +++ b/tools/libxc/xc_domain.c @@ -343,6 +343,29 @@ int xc_domain_get_guest_width(xc_interface *xch, uint32_t

[Xen-devel] [PATCH v2] public: there's no MMUEXT_SET_FOREIGNDOM

Correct respective comments. Signed-off-by: Jan Beulich --- v2: Also mention XENMAPSPACE_gmfn_foreign for DOMID_XEN. --- a/xen/include/public/xen.h +++ b/xen/include/public/xen.h @@ -550,16 +550,21 @@ DEFINE_XEN_GUEST_HANDLE(mmuext_op_t); * is useful to ensure that no

Re: [Xen-devel] [PATCH 00/14 v4] PL011 emulation support in Xen

Hi Bhupinder, On 06/06/17 18:25, Bhupinder Thakur wrote: The vpl011 changes available at the following repo: url: ssh://g...@git.linaro.org:/people/bhupinder.thakur/xen.git This address can only be access by Linaro employee/assignee. Please provide an URL accessible by everyone so we can

Re: [Xen-devel] [PATCH 03/14 v4] xen/arm: vpl011: Add pl011 uart emulation in Xen

Hi Bhupinder, On 06/06/17 18:25, Bhupinder Thakur wrote: Add emulation code to emulate read/write access to pl011 registers and pl011 interrupts: - Emulate DR read/write by reading and writing from/to the IN and OUT ring buffers and raising an event to the backend when there is

  1   2   >