Re: [Xen-devel] [PATCH v10 10/25] x86: refactor psr: L3 CAT: set value: assemble features value array.

On 17-04-11 09:11:20, Jan Beulich wrote: > >>> On 01.04.17 at 15:53, wrote: > > @@ -593,7 +616,21 @@ int psr_get_val(struct domain *d, unsigned int socket, > > /* Set value functions */ > > static unsigned int get_cos_num(const struct psr_socket_info *info) > > { > >

Re: [Xen-devel] [PATCH v10 09/25] x86: refactor psr: L3 CAT: set value: implement framework.

On 17-04-11 09:01:53, Jan Beulich wrote: > >>> On 01.04.17 at 15:53, wrote: > > --- a/xen/arch/x86/psr.c > > +++ b/xen/arch/x86/psr.c > > @@ -157,10 +157,26 @@ static void free_socket_resources(unsigned int socket) > > { > > unsigned int i; > > struct

[Xen-devel] [xtf test] 107372: all pass - PUSHED

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

[Xen-devel] valgrind support for xen4.7+

Hi there Has anyone seen or been working on patches for valgrind for recent versions of xen? I was trying 3.13 from SVN against xen 4.7.2 and see that support for that version is not present. Per https://blog.xenproject.org/2013/01/18/using-valgrind-to-debug-xen-toolstacks/ A starter

[Xen-devel] linux-next: manual merge of the xen-tip tree with the tip tree

Hi all, Today's linux-next merge of the xen-tip tree got a conflict in: arch/x86/xen/enlighten.c between commit: 687d77a5f7b2 ("x86/xen: Update e820 table handling to the new core x86 E820 code") from the tip tree and commit: ca7b75377014 ("x86/xen: split off enlighten_pvh.c") from

Re: [Xen-devel] [RFC PATCH] hvm/vpt: fix inconsistent views of vIOAPIC in vmx_intr_assist()

On Wed, Apr 12, 2017 at 02:45:36AM +, Xuquan (Quan Xu) wrote: >On April 07, 2017 11:24 AM, Chao Gao wrote: >>When injecting periodic timer interrupt in vmx_intr_assist(), multiple read >>operation is operated during one event delivery and incur to inconsistent >>views of vIOAPIC. For example,

Re: [Xen-devel] [Qemu-devel] [PATCH v4 09/13] qobject: Use simpler QDict/QList scalar insertion macros

On 04/11/2017 03:50 PM, Eric Blake wrote: We now have macros in place to make it less verbose to add a scalar to QDict and QList, so use them. To make this patch smaller to review, a couple of subdirectories were done in earlier patches. Patch created mechanically via: spatch --sp-file

[Xen-devel] linux-next: manual merge of the xen-tip tree with the tip tree

Hi all, Today's linux-next merge of the xen-tip tree got a conflict in: arch/x86/xen/mmu.c between commit: 66441bd3cfdc ("x86/boot/e820: Move asm/e820.h to asm/e820/api.h") from the tip tree and commit: 5159dc315db8 ("x86/xen: split off mmu_pv.c") from the xen-tip tree. The code

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

flight 107367 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/107367/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-cubietruck 11 guest-start fail REGR. vs. 59254

Re: [Xen-devel] [RFC PATCH] hvm/vpt: fix inconsistent views of vIOAPIC in vmx_intr_assist()

On Wed, Apr 12, 2017 at 02:45:36AM +, Xuquan (Quan Xu) wrote: >On April 07, 2017 11:24 AM, Chao Gao wrote: >>When injecting periodic timer interrupt in vmx_intr_assist(), multiple read >>operation is operated during one event delivery and incur to inconsistent >>views of vIOAPIC. For example,

Re: [Xen-devel] [RFC PATCH] hvm/vpt: fix inconsistent views of vIOAPIC in vmx_intr_assist()

On April 07, 2017 11:24 AM, Chao Gao wrote: >When injecting periodic timer interrupt in vmx_intr_assist(), multiple read >operation is operated during one event delivery and incur to inconsistent >views of vIOAPIC. For example, if a periodic timer interrupt is from PIT, when >set the corresponding

[Xen-devel] [PATCH] tools:misc:xenpm: set max freq to all cpu with default cpuid

User can set max freq to specific cpu by "xenpm set-scaling-maxfreq " or set max freq to all cpu with default cpuid by "xenpm set-scaling-maxfreq ". Set max freq with defaule cpuid will cause segmentation fault after commit id d4906b5d05. This patch will fix this issue and add ability to set max

[Xen-devel] [PATCH v8 19/27] ARM: vITS: handle MAPTI command

The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU pair and actually instantiates LPI interrupts. We connect the already allocated host LPI to this virtual LPI, so that any triggering LPI on the host can be quickly forwarded to a guest. Beside entering the VCPU and the virtual

[Xen-devel] [PATCH v8 21/27] 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 the host LPI structure and in our virtual ITTE. Signed-off-by: Andre Przywara ---

[Xen-devel] [PATCH v8 11/27] ARM: VGIC: add 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 v8 26/27] 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 v8 24/27] 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 v8 20/27] 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 v8 16/27] 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 --- xen/arch/arm/vgic-v3-its.c | 21 + 1 file changed, 21 insertions(+) diff --git

[Xen-devel] [PATCH v8 15/27] 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 v8 03/27] 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 handle with irq_to_pending() returning a NULL pointer. We just do nothing in this case or clean up the LR if the virtual

[Xen-devel] [PATCH v8 25/27] 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 --- xen/arch/arm/vgic-v3-its.c | 15 +++

[Xen-devel] [PATCH v8 17/27] 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 --- xen/arch/arm/vgic-v3-its.c | 41

[Xen-devel] [PATCH v8 07/27] 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 v8 00/27] arm64: Dom0 ITS emulation

Hi, this is a reworked version of the second part of the ITS emulation series, where the first part has been merged already. It extends the concept of letting Xen deal with irq_to_pending() potentially returning NULL, by making sure the retrieval and usage of the pending_irq pointer is always

[Xen-devel] [PATCH v8 27/27] 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 v8 10/27] ARM: GIC: export vgic_init_pending_irq()

For LPIs we later want to dynamically allocate struct pending_irqs. Let's export the vgic_init_pending_irq() to be able to reuse it. Signed-off-by: Andre Przywara Acked-by: Julien Grall --- xen/arch/arm/vgic.c| 2 +-

[Xen-devel] [PATCH v8 04/27] 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 v8 12/27] 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 the host has initialized at least one ITS. This removes a "TBD" comment, as we now populate the processor

[Xen-devel] [PATCH v8 23/27] 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 v8 22/27] 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 --- xen/arch/arm/vgic-v3-its.c | 30

[Xen-devel] [PATCH v8 02/27] ARM: VGIC: move irq_to_pending() calls under the VGIC VCPU lock

So far irq_to_pending() is just a convenience function to lookup in statically allocated arrays. This will change with LPIs, which are more dynamic. So move the irq_to_pending() call under the VGIC VCPU lock, so we only use this pointer while holding the lock. Signed-off-by: Andre Przywara

[Xen-devel] [PATCH v8 18/27] 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 v8 09/27] 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 v8 05/27] 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 this information quickly when the host takes an LPI. Call the existing injection function to let the GIC emulation deal with this interrupt.

[Xen-devel] [PATCH v8 13/27] 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 v8 08/27] 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 v8 14/27] 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 v8 01/27] ARM: GICv3: propagate number of host LPIs to 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). Signed-off-by: Andre Przywara --- xen/arch/arm/gic-v3.c

Re: [Xen-devel] [PATCH] blkfront: add uevent for size change

On Tue, Apr 11, 2017 at 04:04:59PM -0400, Konrad Rzeszutek Wilk wrote: > On Tue, Apr 11, 2017 at 12:24:09PM -0700, Marc Olson wrote: > > When a blkfront device is resized from dom0, emit a KOBJ_CHANGE uevent to > > notify the guest about the change. This allows for custom udev rules, such > > as

Re: [Xen-devel] null domains after xl destroy

On 12/04/17 10:23, Andrew Cooper wrote: On 11/04/2017 23:13, Glenn Enright wrote: On 11/04/17 21:49, Dietmar Hahn wrote: Am Dienstag, 11. April 2017, 20:03:14 schrieb Glenn Enright: On 11/04/17 17:59, Juergen Gross wrote: On 11/04/17 07:25, Glenn Enright wrote: Hi all We are seeing an odd

Re: [Xen-devel] [Qemu-devel] [RFC/BUG] xen-mapcache: buggy invalidate map cache?

On Tue, 11 Apr 2017, hrg wrote: > On Tue, Apr 11, 2017 at 3:50 AM, Stefano Stabellini > wrote: > > On Mon, 10 Apr 2017, Stefano Stabellini wrote: > >> On Mon, 10 Apr 2017, hrg wrote: > >> > On Sun, Apr 9, 2017 at 11:55 PM, hrg wrote: > >> > > On Sun,

Re: [Xen-devel] null domains after xl destroy

On 11/04/2017 23:13, Glenn Enright wrote: > On 11/04/17 21:49, Dietmar Hahn wrote: >> Am Dienstag, 11. April 2017, 20:03:14 schrieb Glenn Enright: >>> On 11/04/17 17:59, Juergen Gross wrote: On 11/04/17 07:25, Glenn Enright wrote: > Hi all > > We are seeing an odd issue with domu

[Xen-devel] [ovmf baseline-only test] 71173: all pass

This run is configured for baseline tests only. flight 71173 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71173/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf f8c1facf34a1f65082fa22fdbc20a6e0ab8887b4 baseline

[Xen-devel] [xen-4.4-testing test] 107365: regressions - FAIL

flight 107365 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/107365/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xend-qemut-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs. 106822 Tests

Re: [Xen-devel] null domains after xl destroy

On 11/04/17 21:49, Dietmar Hahn wrote: Am Dienstag, 11. April 2017, 20:03:14 schrieb Glenn Enright: On 11/04/17 17:59, Juergen Gross wrote: On 11/04/17 07:25, Glenn Enright wrote: Hi all We are seeing an odd issue with domu domains from xl destroy, under recent 4.9 kernels a (null) domain is

Re: [Xen-devel] [PATCH 02/11] xen/arm: vpl011: Add new hvm params in Xen for ring buffer/event setup

On Tue, 11 Apr 2017, Bhupinder Thakur wrote: > Hi, > > Kindly let me know if my understanding is correct. > > Using a domctl API will allow us to keep the vUART configuration > flexible. Currently, we can operate on one ring-buf PFN and an event > channel port only for a single vUART but if we

[Xen-devel] [libvirt test] 107362: tolerable FAIL - PUSHED

flight 107362 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/107362/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 107325 test-armhf-armhf-libvirt-xsm 13

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

On Fri, 7 Apr 2017, Stefano Stabellini wrote: > On Fri, 7 Apr 2017, Volodymyr Babchuk wrote: > > >> Native application is an another domain type. It has own vCPU (only one > > >> at this > > >> moment) Native app is loaded as any other kernel, using ELF loader. > > >> It looks like another

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

flight 107360 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/107360/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-xsm 9 debian-install fail REGR. vs. 107219 Regressions

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

flight 107358 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/107358/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-arndale 2 hosts-allocate broken in 107313 pass in 107358 test-armhf-armhf-xl-multivcpu 15

[Xen-devel] [xen-4.6-testing baseline-only test] 71172: regressions - FAIL

This run is configured for baseline tests only. flight 71172 xen-4.6-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71172/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu 15

Re: [Xen-devel] [PATCH] blkfront: add uevent for size change

On Tue, Apr 11, 2017 at 12:24:09PM -0700, Marc Olson wrote: > When a blkfront device is resized from dom0, emit a KOBJ_CHANGE uevent to > notify the guest about the change. This allows for custom udev rules, such > as automatically resizing a filesystem, when an event occurs. Looks pretty

[Xen-devel] [PATCH] blkfront: add uevent for size change

When a blkfront device is resized from dom0, emit a KOBJ_CHANGE uevent to notify the guest about the change. This allows for custom udev rules, such as automatically resizing a filesystem, when an event occurs. Signed-off-by: Marc Olson --- drivers/block/xen-blkfront.c | 3

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

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

[Xen-devel] [PATCH v4 09/13] qobject: Use simpler QDict/QList scalar insertion macros

We now have macros in place to make it less verbose to add a scalar to QDict and QList, so use them. To make this patch smaller to review, a couple of subdirectories were done in earlier patches. Patch created mechanically via: spatch --sp-file scripts/coccinelle/qobject.cocci \

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

flight 107359 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/107359/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-vhd 15 guest-start.2fail REGR. vs. 107247 Regressions which

[Xen-devel] [PATCH] xen: credit2: cleanup patch for type betterness

The patch actually doesn't impact the functionality as such. This only replaces bool_t with bool in credit2. Signed-off-by: Praveen Kumar --- xen/common/sched_credit2.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git

Re: [Xen-devel] [RFC XEN PATCH v2 00/15] Add vNVDIMM support to HVM domains

On Tue, Apr 04, 2017 at 11:59:03AM -0700, Dan Williams wrote: > >> I don't think KVM has the same issue, but honestly I don't have the > >> full mental model of how KVM supports mmap. I've at least been able to > >> run a guest where the "pmem" is just dynamic page cache on the host > >> side so

Re: [Xen-devel] [Qemu-devel] [PATCH v3 09/13] qobject: Use simpler QDict/QList scalar insertion macros

On 04/11/2017 12:12 PM, Markus Armbruster wrote: > Eric Blake writes: > >> We now have macros in place to make it less verbose to add a scalar >> to QDict and QList, so use them. To make this patch smaller to >> review, a couple of subdirectories were done in earlier patches.

Re: [Xen-devel] [PATCH v2] xen, kdump: handle pv domain in paddr_vmcoreinfo_note()

On Tue, Apr 11, 2017 at 04:59:16PM +0200, Petr Tesarik wrote: > On Tue, 11 Apr 2017 15:00:58 +0200 > Daniel Kiper wrote: > > > On Tue, Apr 11, 2017 at 02:45:43PM +0200, Juergen Gross wrote: > > > On 03/04/17 14:42, Daniel Kiper wrote: > > > > On Fri, Mar 31, 2017 at

Re: [Xen-devel] [Qemu-devel] [PATCH v3 09/13] qobject: Use simpler QDict/QList scalar insertion macros

Eric Blake writes: > We now have macros in place to make it less verbose to add a scalar > to QDict and QList, so use them. To make this patch smaller to > review, a couple of subdirectories were done in earlier patches. > > Patch created mechanically via: > spatch

[Xen-devel] [linux-arm-xen test] 107296: trouble: broken/pass

flight 107296 linux-arm-xen real [real] http://logs.test-lab.xenproject.org/osstest/logs/107296/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-arndale 2 hosts-allocate broken REGR. vs.

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

On 11/04/17 17:15, 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: Praveen Kumar

[Xen-devel] ITS emulation: case for checking pending_irq against NULL

Hello, this is trying to make the point that having NULL pointer entries in the radix tree and letting Xen handle that is a valid case. To some degree this serves as a tag (LPI has been unmapped), so should semantically come close to what we are discussing. It has the big advantage of being able

Re: [Xen-devel] [PATCH v2] x86emul: add "unblock NMI" retire flag

On 11/04/17 16:36, Jan Beulich wrote: > No matter that we emulate IRET for (guest) real more only right now, we > should get its effect on (virtual) NMI delivery right. > > Signed-off-by: Jan Beulich > --- > v2: Adjust x86_emulate_wrapper() accordingly. > > ---

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

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: Praveen Kumar Reviewed-by: Dario Faggioli

[Xen-devel] [PATCH v3] xen, kdump: handle pv domain in paddr_vmcoreinfo_note()

For kdump to work correctly it needs the physical address of vmcoreinfo_note. When running as dom0 this means the virtual address has to be translated to the related machine address. paddr_vmcoreinfo_note() is meant to do the translation via __pa_symbol() only, but being attributed "weak" it can

Re: [Xen-devel] [PATCH v5 23/30] ARM: vITS: handle MAPTI command

Hi, On 06/04/17 01:45, Stefano Stabellini wrote: > On Thu, 6 Apr 2017, Andre Przywara wrote: >> The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU >> pair and actually instantiates LPI interrupts. >> We connect the already allocated host LPI to this virtual LPI, so that >> any

Re: [Xen-devel] [PATCH v10 17/25] x86: refactor psr: CDP: implement set value callback functions.

>>> On 01.04.17 at 15:53, wrote: > @@ -94,6 +102,13 @@ struct feat_node { > unsigned int cos_max; > unsigned int cbm_len; > > +/* > + * An array to save all 'enum cbm_type' values of the feature. It is > + * used with cos_num

Re: [Xen-devel] [PATCH v6 24/36] ARM: vITS: add command handling stub and MMIO emulation

Hi, On 09/04/17 21:16, Julien Grall wrote: > Hi Andre, > > On 04/07/2017 06:32 PM, Andre Przywara wrote: >> 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). >> >>

Re: [Xen-devel] [PATCH v10 16/25] x86: refactor psr: CDP: implement get value flow.

>>> On 01.04.17 at 15:53, wrote: > @@ -755,7 +765,7 @@ static int gather_val_array(uint32_t val[], > cos = 0; > > /* Value getting order is same as feature array. */ > -feat->props->get_val(feat, cos, [0]); > +

[Xen-devel] [PATCH v2] x86emul: add "unblock NMI" retire flag

No matter that we emulate IRET for (guest) real more only right now, we should get its effect on (virtual) NMI delivery right. Signed-off-by: Jan Beulich --- v2: Adjust x86_emulate_wrapper() accordingly. --- a/xen/arch/x86/hvm/emulate.c +++ b/xen/arch/x86/hvm/emulate.c @@

Re: [Xen-devel] [PATCH v10 13/25] x86: refactor psr: L3 CAT: set value: implement write msr flow.

>>> On 01.04.17 at 15:53, wrote: > +static void do_write_psr_msr(void *data) > +{ > +struct cos_write_info *info = data; > +unsigned int cos= info->cos; > +struct feat_node *feat = info->feature; > + > +if ( cos > feat->props->cos_max ) >

Re: [Xen-devel] [PATCH v10 12/25] x86: refactor psr: L3 CAT: set value: implement cos id picking flow.

>>> On 01.04.17 at 15:53, wrote: > --- a/xen/arch/x86/psr.c > +++ b/xen/arch/x86/psr.c > @@ -800,15 +800,82 @@ static int find_cos(const uint32_t val[], unsigned int > array_len, > return -ENOENT; > } > > +static bool fits_cos_max(const uint32_t val[], > +

Re: [Xen-devel] [PATCH v10 11/25] x86: refactor psr: L3 CAT: set value: implement cos finding flow.

>>> On 01.04.17 at 15:53, wrote: > --- a/xen/arch/x86/psr.c > +++ b/xen/arch/x86/psr.c > @@ -720,8 +720,83 @@ static int find_cos(const uint32_t val[], unsigned int > array_len, > const struct psr_socket_info *info, > spinlock_t

Re: [Xen-devel] [PATCH v10 10/25] x86: refactor psr: L3 CAT: set value: assemble features value array.

>>> On 01.04.17 at 15:53, wrote: > @@ -593,7 +616,21 @@ int psr_get_val(struct domain *d, unsigned int socket, > /* Set value functions */ > static unsigned int get_cos_num(const struct psr_socket_info *info) > { > -return 0; > +unsigned int num = 0, i; > + >

Re: [Xen-devel] [PATCH v10 09/25] x86: refactor psr: L3 CAT: set value: implement framework.

>>> On 01.04.17 at 15:53, wrote: > --- a/xen/arch/x86/psr.c > +++ b/xen/arch/x86/psr.c > @@ -157,10 +157,26 @@ static void free_socket_resources(unsigned int socket) > { > unsigned int i; > struct psr_socket_info *info = socket_info + socket; > +struct

Re: [Xen-devel] [PATCH v2] xen, kdump: handle pv domain in paddr_vmcoreinfo_note()

On Tue, 11 Apr 2017 15:00:58 +0200 Daniel Kiper wrote: > On Tue, Apr 11, 2017 at 02:45:43PM +0200, Juergen Gross wrote: > > On 03/04/17 14:42, Daniel Kiper wrote: > > > On Fri, Mar 31, 2017 at 12:14:38PM +0200, Juergen Gross wrote: > > >> For kdump to work correctly it

Re: [Xen-devel] Please apply "partially revert "xen: Remove event channel..."

On 11/04/17 16:42, Raslan, KarimAllah wrote: > >> On Apr 11, 2017, at 4:10 PM, Boris Ostrovsky >> wrote: >> >> >> I think the right thing is indeed to revert 72a9b186292 (and therefore da72ff5bfcb02). Any objections? >>> >>> For the end result:

Re: [Xen-devel] Please apply "partially revert "xen: Remove event channel..."

> On Apr 11, 2017, at 4:10 PM, Boris Ostrovsky > wrote: > > > >>> >>> I think the right thing is indeed to revert 72a9b186292 (and >>> therefore da72ff5bfcb02). Any objections? >> >> For the end result: depends. Is there a real error or not? >> KarimAllah wrote

Re: [Xen-devel] [PATCH 02/11] xen/arm: vpl011: Add new hvm params in Xen for ring buffer/event setup

Hi, Kindly let me know if my understanding is correct. Using a domctl API will allow us to keep the vUART configuration flexible. Currently, we can operate on one ring-buf PFN and an event channel port only for a single vUART but if we use DOMCTL interface, then we can effectively get/set

Re: [Xen-devel] Please apply "partially revert "xen: Remove event channel..."

> On Apr 11, 2017, at 10:57 AM, Juergen Gross wrote: > > On 10/04/17 17:32, Raslan, KarimAllah wrote: >> >> Ahmed, Karim Allah >> karah...@amazon.de >> >> >> >>> On Apr 10, 2017, at 3:57 PM, Juergen Gross wrote: >>> >>> On 10/04/17 15:47, Boris Ostrovsky

Re: [Xen-devel] Please apply "partially revert "xen: Remove event channel..."

I think the right thing is indeed to revert 72a9b186292 (and therefore da72ff5bfcb02). Any objections? For the end result: depends. Is there a real error or not? KarimAllah wrote that his concerns are of a theoretical nature as xen_strict_xenbus_quirk() would mask the problem. OTOH he

Re: [Xen-devel] Please apply "partially revert "xen: Remove event channel..."

On 11/04/17 15:22, Boris Ostrovsky wrote: > > > On 04/11/2017 05:53 AM, Andrew Cooper wrote: >> On 10/04/17 19:48, Boris Ostrovsky wrote: > The following is meant as a real question without any > prejudice: > > How old a Xen version do we want to support in the Linux >

Re: [Xen-devel] [Outreachy] Interested in Xen Code Review Dashboard

On Mon, 2017-04-10 at 14:50 -0700, Candida Haynes wrote: > Hi, > > I apologize to anyone who receives this twice - I received an > error/bounce message. I am writing because I am interested in > applying to Outreachy and contributing to the Xen Code Review > Dashboard. My most formal experience

[Xen-devel] [distros-debian-snapshot test] 71171: regressions - trouble: blocked/broken/fail/pass

flight 71171 distros-debian-snapshot real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71171/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-i386-daily-netboot-pvgrub 9 debian-di-install fail REGR. vs. 71146

Re: [Xen-devel] Please apply "partially revert "xen: Remove event channel..."

On 04/11/2017 05:53 AM, Andrew Cooper wrote: On 10/04/17 19:48, Boris Ostrovsky wrote: The following is meant as a real question without any prejudice: How old a Xen version do we want to support in the Linux kernel? - Only those being still maintained (meaning getting security fixes)

[Xen-devel] [xen-4.8-testing test] 107357: regressions - FAIL

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

Re: [Xen-devel] [PATCH for-4.9] docs: fix configuration syntax in xl.cfg manpage

Hi Wei, On 11/04/17 12:03, Wei Liu wrote: No quote is required when a string is provided as part of a spec string. Reported-by: Doug Freed Signed-off-by: Wei Liu Documentation will always improve the release :). Unless there is a commit moratorium,

Re: [Xen-devel] [PATCH v2] xen, kdump: handle pv domain in paddr_vmcoreinfo_note()

On Tue, Apr 11, 2017 at 02:45:43PM +0200, Juergen Gross wrote: > On 03/04/17 14:42, Daniel Kiper wrote: > > On Fri, Mar 31, 2017 at 12:14:38PM +0200, Juergen Gross wrote: > >> For kdump to work correctly it needs the physical address of > >> vmcoreinfo_note. When running as dom0 this means the

Re: [Xen-devel] [PATCH v2] xen, kdump: handle pv domain in paddr_vmcoreinfo_note()

On 03/04/17 14:42, Daniel Kiper wrote: > On Fri, Mar 31, 2017 at 12:14:38PM +0200, Juergen Gross wrote: >> For kdump to work correctly it needs the physical address of >> vmcoreinfo_note. When running as dom0 this means the virtual address >> has to be translated to the related machine address. >>

Re: [Xen-devel] [PATCH] kexec: Add spinlock for the whole hypercall

On Tue, Apr 11, 2017 at 06:31:36AM -0600, Jan Beulich wrote: > >>> On 11.04.17 at 13:24, wrote: > > On Tue, Apr 11, 2017 at 01:46:37AM -0600, Jan Beulich wrote: > >> >>> On 10.04.17 at 21:44, wrote: > >> wouldn't it be better to handle this with

Re: [Xen-devel] [PATCH] kexec: Add spinlock for the whole hypercall

>>> On 11.04.17 at 13:24, wrote: > On Tue, Apr 11, 2017 at 01:46:37AM -0600, Jan Beulich wrote: >> >>> On 10.04.17 at 21:44, wrote: >> wouldn't it be better to handle this with a static state variable, >> which gets checked/set atomically, and

[Xen-devel] [PATCH v3] xen, input: add xen-kbdfront module parameter for setting resolution

Add a parameter for setting the resolution of xen-kbdfront in order to be able to cope with a (virtual) frame buffer of arbitrary resolution. While at it remove the pointless second reading of parameters from Xenstore in the device connection phase: all parameters are available during device

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

Hi Andre, On Sat, Apr 8, 2017 at 3:37 AM, Andre Przywara wrote: > Hi, > > an only slightly modified repost of the last version. > I added the Reviewed-by: and Acked-by: tags from Stefano and Julien > and rebased on top of the latest staging tree: > commit

Re: [Xen-devel] [Outreachy] Interested in contribution: Code Standards Checking using clang-format

Ishani, > On 11 Apr 2017, at 12:21, Ishani wrote: > > Hello, > > I have created a clang-format file for specifications of format for Xen > hypervisor and incorporated all of the support which present clang-format > could provide. I have seen all the options

Re: [Xen-devel] [PATCH] kexec: Add spinlock for the whole hypercall

On Tue, Apr 11, 2017 at 01:46:37AM -0600, Jan Beulich wrote: > >>> On 10.04.17 at 21:44, wrote: > > Please don't forget Cc-ing the maintainer(s) of the code being modified. > > > @@ -1187,12 +1182,22 @@ static int do_kexec_op_internal(unsigned long op, > >

Re: [Xen-devel] [Outreachy] Interested in contribution: Code Standards Checking using clang-format

Hello, I have created a clang-format file for specifications of format for Xen hypervisor and incorporated all of the support which present clang-format could provide. I have seen all the options provided by clang-format and have some discrepancies regarding some of format specifications which

Re: [Xen-devel] ITS emulation race conditions

On 11/04/17 10:24, Julien Grall wrote: Hi Stefano, On 04/11/2017 12:01 AM, Stefano Stabellini wrote: On Mon, 10 Apr 2017, Andre Przywara wrote: Hi, On 10/04/17 00:12, André Przywara wrote: Hi, I wanted to run some ideas on how to prevent the race conditions we are facing with the ITS

  1   2   >