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

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

Re: [Xen-devel] Added 5 additional Design sessions to Developer Summit Schedule

Thanks for pointing out, Yi. Our names may be confusing. :-) And yes, I will have a discussion session on 5 level paging enabling with Juergen. B.R. Yu > -Original Message- > From: Yi Sun [mailto:yi.y@linux.intel.com] > Sent: Friday, May 12, 2017 10:25 AM > To: Lars Kurth > Cc:

[Xen-devel] [linux-4.9 test] 109317: regressions - FAIL

flight 109317 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/109317/ 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 Tests which are

Re: [Xen-devel] Added 5 additional Design sessions to Developer Summit Schedule

Hi, Lars, Thank you very much! One correction below. On 17-05-11 18:17:41, Lars Kurth wrote: > Hi everyone, > > I added the following sessions to the Design Part of the Summit: you can see > them via >

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

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

Re: [Xen-devel] [PATCH v2] xen-netfront: avoid crashing on resume after a failure in talk_to_netback()

From: Vitaly Kuznetsov Date: Thu, 11 May 2017 13:58:06 +0200 > Unavoidable crashes in netfront_resume() and netback_changed() after a > previous fail in talk_to_netback() (e.g. when we fail to read MAC from > xenstore) were discovered. The failure path in talk_to_netback()

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

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

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

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

[Xen-devel] Building Xen 4.9 for UEFI boot

Hi I gather that with 4.9, UEFI secure boot of Xen should be possible. Is this true? If so, what are the options for utilizing UEFI secure boot? Do I need a MSFT-signed shim or grub? Any special changes required for Xen kernel (signing?) or has that been done? Thanks -Bill

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

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

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

flight 109309 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/109309/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 17 guest-start/win.repeat fail REGR. vs. 109136

Re: [Xen-devel] [PATCH v5 2/2] xtf/vpmu: MSR read/write tests for VPMU

On 04/05/17 22:33, Mohit Gambhir wrote: > This patch tests VPMU functionality in the hypervisor on Intel machines. > The tests write to all valid bits in the MSRs that get exposed to the guests > when VPMU is enabled. The tests also write invalid values to the bits > that should be masked and

Re: [Xen-devel] [PATCH v1 07/10] iommu/arm: Add alloc_page_table platform callback

On Thu, May 11, 2017 at 9:06 PM, Julien Grall wrote: > Hi Oleksandr, Hi Julien > > > On 11/05/17 15:00, Oleksandr Tyshchenko wrote: >> >> On Thu, May 11, 2017 at 2:38 PM, Julien Grall >> wrote: >>> >>> Hi Oleksandr, >> >> Hi, Julien >> >>> >>> On

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

Stefano, >> We, here at EPAM, viewed EL0 apps primarily as a way to extend >> hypervisor. Because when it comes to embedded and automotive, there >> arise some ugly things, that are needed at hypervisor level: >> TEE mediators (OP-TEE is a good TEE, but for example there is TI's >> MSHIELD with

Re: [Xen-devel] [PATCH v9 01/28] ARM: GICv3: setup number of LPI bits for a GICv3 guest

Hi Andre, On 11/05/17 18:53, Andre Przywara wrote: diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h index bd974fb..033dcee 100644 --- a/xen/include/public/arch-arm.h +++ b/xen/include/public/arch-arm.h @@ -400,6 +400,10 @@ typedef uint64_t xen_callback_t; #define

Re: [Xen-devel] [PATCH v9 00/28] arm64: Dom0 ITS emulation

Hi, On 11/05/17 18:53, Andre Przywara wrote: The code can also be found on the its/v9 branch here: git://linux-arm.org/xen-ap.git http://www.linux-arm.org/git?p=xen-ap.git;a=shortlog;h=refs/heads/its/v9 This branch does not exist :/ Cheers, -- Julien Grall

[Xen-devel] arm64: incorrect pa setup cause dom0 boot failure

Ian: Just a quick question regarding the table below in xen/arch/arm/p2m.c @@ -1479,7 +1487,7 @@ void __init setup_virt_paging(void) [0] = { 32, 32/*32*/, 0, 1 }, [1] = { 36, 28/*28*/, 0, 1 }, [2] = { 40, 24/*24*/, 1, 1 }, -

[Xen-devel] xl list command hangs

Hi All, I am working with latest xen code base ( Unstable branch ). Tried with no changes / commit from my end, and was facing the hang issue while running xl list command. I tried doing make world and installing the packages, but still the problem persists. There we not any specific logs in xl

Re: [Xen-devel] [PATCH v1 05/10] iommu/arm: Re-define iommu_use_hap_pt(d) as iommu_hap_pt_share

On Thu, May 11, 2017 at 8:58 PM, Julien Grall wrote: > > > On 11/05/17 15:38, Oleksandr Tyshchenko wrote: >> >> On Thu, May 11, 2017 at 2:28 PM, Julien Grall >> wrote: >>> >>> Hi Oleksandr, >> >> Hi Julien > > > Hi Oleksandr, > > >>> >>> On 10/05/17

Re: [Xen-devel] [PATCH v1 10/10] xen/arm: domain_build: Don't expose the "iommus" property to the guest

On 11/05/17 19:19, Oleksandr Tyshchenko wrote: On Thu, May 11, 2017 at 9:07 PM, Julien Grall wrote: This property is used to translate an RID into a Master ID (see the documentation in bindings/pci/pci-iommu.txt). So, these two should be skipped too: - iommu-map -

Re: [Xen-devel] [PATCH v1 10/10] xen/arm: domain_build: Don't expose the "iommus" property to the guest

On Thu, May 11, 2017 at 9:07 PM, Julien Grall wrote: > > > On 11/05/17 15:15, Oleksandr Tyshchenko wrote: >> >> On Thu, May 11, 2017 at 2:58 PM, Julien Grall >> wrote: >>> >>> Hi Oleksandr, >> >> Hi Julien > > > Hi, > > >>> >>> On 10/05/17 15:03,

[Xen-devel] [ovmf baseline-only test] 71291: regressions - FAIL

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

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

George, On 11 May 2017 at 20:14, George Dunlap wrote: >>> We, here at EPAM, viewed EL0 apps primarily as a way to extend >>> hypervisor. Because when it comes to embedded and automotive, there >>> arise some ugly things, that are needed at hypervisor level: >>> TEE

Re: [Xen-devel] [PATCH v1 10/10] xen/arm: domain_build: Don't expose the "iommus" property to the guest

On 11/05/17 15:15, Oleksandr Tyshchenko wrote: On Thu, May 11, 2017 at 2:58 PM, Julien Grall wrote: Hi Oleksandr, Hi Julien Hi, On 10/05/17 15:03, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko We don't passthrough IOMMU

Re: [Xen-devel] [PATCH v1 07/10] iommu/arm: Add alloc_page_table platform callback

Hi Oleksandr, On 11/05/17 15:00, Oleksandr Tyshchenko wrote: On Thu, May 11, 2017 at 2:38 PM, Julien Grall wrote: Hi Oleksandr, Hi, Julien On 10/05/17 15:03, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko The

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

On 11/05/17 16:19, Volodymyr Babchuk wrote: > Hi Stefano, > > On 10 May 2017 at 21:24, Stefano Stabellini wrote: > > I just want to point out that the comparision with tasklets is not > > helpful. Tasklets involve the idle vcpu, which we are trying to step away > > from

Re: [Xen-devel] [PATCH v1 05/10] iommu/arm: Re-define iommu_use_hap_pt(d) as iommu_hap_pt_share

On 11/05/17 15:38, Oleksandr Tyshchenko wrote: On Thu, May 11, 2017 at 2:28 PM, Julien Grall wrote: Hi Oleksandr, Hi Julien Hi Oleksandr, On 10/05/17 15:03, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko Not every

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

> On 11 May 2017, at 18:20, George Dunlap wrote: > > On Thu, May 11, 2017 at 6:14 PM, Volodymyr Babchuk > wrote: >> Hi George, >> >> On 11 May 2017 at 19:35, George Dunlap wrote: >>> Even better would be to skip the

Re: [Xen-devel] [PATCH v8 05/27] ARM: GICv3: forward pending LPIs to guests

Hi Julien, On 10/05/17 18:17, Julien Grall wrote: > > > On 05/10/2017 06:14 PM, Andre Przywara wrote: >> Hi, >> >> On 10/05/17 12:07, Julien Grall wrote: >>> >>> >>> On 05/10/2017 11:47 AM, Andre Przywara wrote: Hi, >>> >>> Hi Andre, >>> On 12/04/17 11:44, Julien Grall wrote: > On

[Xen-devel] [PATCH v9 10/28] 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 v9 17/28] 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 | 47

[Xen-devel] [PATCH v9 23/28] 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 | 24

[Xen-devel] [PATCH v9 07/28] 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

Re: [Xen-devel] [PATCH v8 07/27] ARM: vGICv3: handle virtual LPI pending and property tables

Hi, On 12/04/17 14:13, Julien Grall wrote: > > > On 12/04/17 14:12, Andre Przywara wrote: >> Hi, > > Hi, > >> >> On 12/04/17 11:55, Julien Grall wrote: >>> Hi Andre, >>> >>> On 12/04/17 01:44, Andre Przywara wrote: Allow a guest to provide the address and size for the memory regions

[Xen-devel] [PATCH v9 00/28] arm64: Dom0 ITS emulation

Hi, this is a reworked version, addressing comments on v8. After some discussions we came to the conclusion that for properly addressing all the issues we found we need some more serious rework of the VGIC: * Protecting a struct pending_irq with the VGIC VCPU lock will not be sufficient, instead

[Xen-devel] [PATCH v9 19/28] 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 v9 03/28] 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 v9 02/28] 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. The proper answer to the issue of preventing stale pointers is ref-counting, which requires more rework and will be introduced with a later rework. For

[Xen-devel] [PATCH v9 11/28] 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 v9 27/28] 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 v9 16/28] 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 v9 24/28] 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 v9 21/28] 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 v9 06/28] ARM: GICv3: enable ITS and LPIs on the host

Now that the host part of the ITS code is in place, we can enable the ITS and also 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

[Xen-devel] [PATCH v9 26/28] 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 v9 20/28] 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 v9 04/28] 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 v9 15/28] 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 v9 14/28] 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 v9 25/28] 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 v9 28/28] 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 v9 22/28] 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 v9 18/28] 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 v9 13/28] 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 v9 08/28] 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 v9 12/28] 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

Re: [Xen-devel] [PATCH for-4.9] xl: don't ignore return value from libxl_device_events_handler

Hi Wei, On 11/05/17 13:57, Wei Liu wrote: That function can return a whole slew of error codes. Translate them to EXIT_FAILURE. Signed-off-by: Wei Liu Release-acked-by: Julien Grall Cheers, --- Cc: Ian Jackson Cc:

[Xen-devel] [PATCH v9 05/28] 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 v9 01/28] 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 a fixed limited number for now. We may want to revisit this when we get

[Xen-devel] [PATCH v9 09/28] 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

Re: [Xen-devel] [Patch] Fix broken package config file xenlight.pc.in

Hi Wei, On 11/05/17 17:30, Wei Liu wrote: On Thu, May 11, 2017 at 10:29:42AM -0600, Charles Arnold wrote: The Requires line in this config file uses the wrong names for two dependencies. The package config file for xenctrl is called 'xencontrol' and for blktapctl is called 'xenblktapctl'.

Re: [Xen-devel] [PATCH V4] x86/ioreq_server: Make p2m_finish_type_change actually work

Hi, On 11/05/17 12:12, Jan Beulich wrote: On 12.05.17 at 04:42, wrote: Commit 6d774a951696 ("x86/ioreq server: synchronously reset outstanding p2m_ioreq_server entries when an ioreq server unmaps") introduced p2m_finish_type_change(), which was meant to synchronously

Re: [Xen-devel] Hypercall Inquiries

On 11/05/17 15:22, Rapidash wrote: > Greetings, > My co-worker and I are looking into Xen Hypervisor. By any chance, do > you or any of your colleagues have technical material/ papers/ > presentations detailing how the hypercall interacts with the hypervisor?

[Xen-devel] [resend PATCH] xen: common: rbtree: ported updates from linux tree

The patch contains the updated version of rbtree implementation from linux kernel tree containing the fixes so far handled. Signed-off-by: Praveen Kumar --- xen/common/rbtree.c| 748 + xen/include/xen/compiler.h

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

On Thu, May 11, 2017 at 6:14 PM, Volodymyr Babchuk wrote: > Hi George, > > On 11 May 2017 at 19:35, George Dunlap wrote: >> Even better would be to skip the module-loading step entirely, and just >> compile proprietary code directly into your Xen

[Xen-devel] Added 5 additional Design sessions to Developer Summit Schedule

Hi everyone, I added the following sessions to the Design Part of the Summit: you can see them via https://xendeveloperanddesignsummit2017.sched.com/overview/type/Interactive+Design+%26+Problem+Solving+Session (just showing Design sessions) Please also make use of the "Add to my Sched(ule)"

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

On Thu, May 11, 2017 at 6:14 PM, George Dunlap wrote: > yourself at a risk of meeting a guy like Patrick McHardy[1], a private > individual with copyright on the Linux kernel This should be "copyright on *code in the* Linux Kernel". Obviously he doesn't own a copyright

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

Hi George, On 11 May 2017 at 19:35, George Dunlap wrote: > Even better would be to skip the module-loading step entirely, and just > compile proprietary code directly into your Xen binary. > > Both solutions, unfortunately, are illegal.* Look, I don't saying we want to

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

On 11/05/17 16:35, Julien Grall wrote: > Renaming the subject + adding more people in the conversation as this is > not related to only ARM anymore. > > On 11/05/17 16:19, Volodymyr Babchuk wrote: >> Hi Stefano, >> >> On 10 May 2017 at 21:24, Stefano Stabellini >> wrote:

[Xen-devel] [PATCH for-4.9] x86/mm: Mark pages as dirty after (rather than before) writing to them

Otherwise a logdirty client can race with observing the page becoming dirty, and copy the frame before the write is complete and end up with a stale version. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Julien Grall

Re: [Xen-devel] [PATCH v3 4/9] mm: Scrub memory from idle loop

On 05/11/2017 11:48 AM, Dario Faggioli wrote: > On Thu, 2017-05-11 at 10:19 -0400, Boris Ostrovsky wrote: diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 90e2b1f..a5f62b5 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -118,7 +118,8 @@

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

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

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

On 11/05/17 16:35, Julien Grall wrote: > On 11/05/17 16:19, Volodymyr Babchuk wrote: >> Hi Stefano, >> >> On 10 May 2017 at 21:24, Stefano Stabellini >> wrote: >>> I just want to point out that the comparision with tasklets is not >>> helpful. Tasklets involve the idle

Re: [Xen-devel] [Patch] Fix broken package config file xenlight.pc.in

On Thu, May 11, 2017 at 10:29:42AM -0600, Charles Arnold wrote: > The Requires line in this config file uses the wrong names for two > dependencies. > > The package config file for xenctrl is called 'xencontrol' and for blktapctl > is > called 'xenblktapctl'. Running a command like 'pkg-config

[Xen-devel] [Patch] Fix broken package config file xenlight.pc.in

The Requires line in this config file uses the wrong names for two dependencies. The package config file for xenctrl is called 'xencontrol' and for blktapctl is called 'xenblktapctl'. Running a command like 'pkg-config --exists xenlight' will fail without this fix. Signed-off-by: Charles Arnold

Re: [Xen-devel] [PATCH for-4.9] xl: don't ignore return value from libxl_device_events_handler

Wei Liu writes ("[PATCH for-4.9] xl: don't ignore return value from libxl_device_events_handler"): > That function can return a whole slew of error codes. Translate them > to EXIT_FAILURE. Acked-by: Ian Jackson ___

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

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

Re: [Xen-devel] [PATCH v3 4/9] mm: Scrub memory from idle loop

On Thu, 2017-05-11 at 10:19 -0400, Boris Ostrovsky wrote: > > > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c > > > index 90e2b1f..a5f62b5 100644 > > > --- a/xen/arch/x86/domain.c > > > +++ b/xen/arch/x86/domain.c > > > @@ -118,7 +118,8 @@ static void idle_loop(void) > > >  { > >

[Xen-devel] [ovmf baseline-only test] 71289: tolerable FAIL

This run is configured for baseline tests only. flight 71289 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71289/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-amd64-libvirt 5 libvirt-build

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

Renaming the subject + adding more people in the conversation as this is not related to only ARM anymore. On 11/05/17 16:19, Volodymyr Babchuk wrote: Hi Stefano, On 10 May 2017 at 21:24, Stefano Stabellini wrote: I just want to point out that the comparision with

[Xen-devel] [PATCH] block: xen-blkback: add null check to avoid null pointer dereference

Add null check before calling xen_blkif_put() to avoid potential null pointer dereference. Addresses-Coverity-ID: 1350942 Cc: Juergen Gross Signed-off-by: Gustavo A. R. Silva --- drivers/block/xen-blkback/xenbus.c | 8 +--- 1 file changed, 5

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

Hi Stefano, On 10 May 2017 at 21:24, Stefano Stabellini wrote: > I just want to point out that the comparision with tasklets is not > helpful. Tasklets involve the idle vcpu, which we are trying to step away > from because it increases irq latency. Tasklets don't provide

Re: [Xen-devel] [block-xen-blkback] question about pontential null pointer dereference

Hi Juergen, Quoting Juergen Gross : On 10/05/17 18:49, Gustavo A. R. Silva wrote: Hello everybody, While looking into Coverity ID 1350942 I ran into the following piece of code at drivers/block/xen-blkback/xenbus.c:490: 490static int xen_blkbk_remove(struct xenbus_device

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

flight 109301 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/109301/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 109246 test-armhf-armhf-libvirt 13

Re: [Xen-devel] Proposal to drop Windows XP tests from Xen Project CI

Ian Jackson writes ("Proposal to drop Windows XP tests from Xen Project CI"): > Recently, the tests of Windows XP SP3 that are run by osstest, as part > of the Xen Project's test suite, have started failing a lot more. > > It is not clear what has caused this. The failures are causing >

Re: [Xen-devel] [PATCH v1 05/10] iommu/arm: Re-define iommu_use_hap_pt(d) as iommu_hap_pt_share

On Thu, May 11, 2017 at 2:28 PM, Julien Grall wrote: > Hi Oleksandr, Hi Julien > > On 10/05/17 15:03, Oleksandr Tyshchenko wrote: >> >> From: Oleksandr Tyshchenko >> >> Not every integrated into ARM SoCs IOMMU can share page tables >> with

[Xen-devel] Hypercall Inquiries

Greetings, My co-worker and I are looking into Xen Hypervisor. By any chance, do you or any of your colleagues have technical material/ papers/ presentations detailing how the hypercall interacts with the hypervisor? Thank you in advance for any assistance, - Rapidash Some specific questions:

Re: [Xen-devel] [PATCH v7 2/3] * util/grub.d/20_linux_xen.in: Add xen_boot command support for aarch64

Hi Vladimir, On 11 May 2017 at 06:01, Vladimir 'phcoder' Serbinenko wrote: > > > On Tue, May 9, 2017, 11:02 Fu Wei wrote: >> >> Hi Vladimir >> >> On 9 May 2017 at 14:59, Vladimir 'phcoder' Serbinenko >> wrote: >> > >> > >> > Le Tue, May

[Xen-devel] [PATCH 4.9 099/103] xen: Revert commits da72ff5bfcb0 and 72a9b186292d

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Boris Ostrovsky commit 84d582d236dc1f9085e741affc72e9ba061a67c2 upstream. Recent discussion (http://marc.info/?l=xen-devel=149192184523741) established that commit

Re: [Xen-devel] [PATCH v3 4/9] mm: Scrub memory from idle loop

>> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c >> index 90e2b1f..a5f62b5 100644 >> --- a/xen/arch/x86/domain.c >> +++ b/xen/arch/x86/domain.c >> @@ -118,7 +118,8 @@ static void idle_loop(void) >> { >> if ( cpu_is_offline(smp_processor_id()) ) >>

Re: [Xen-devel] [PATCH v1 04/10] xen/arm: p2m: Update IOMMU mapping whenever possible if page table is not shared

On Thu, May 11, 2017 at 2:24 PM, Julien Grall wrote: > Hi Oleksandr, Hi Julien > > On 10/05/17 15:03, Oleksandr Tyshchenko wrote: >> >> From: Oleksandr Tyshchenko >> >> Update IOMMU mapping if the IOMMU doesn't share page table with the CPU.

[Xen-devel] [PATCH 4.10 125/129] xen: Revert commits da72ff5bfcb0 and 72a9b186292d

4.10-stable review patch. If anyone has any objections, please let me know. -- From: Boris Ostrovsky commit 84d582d236dc1f9085e741affc72e9ba061a67c2 upstream. Recent discussion (http://marc.info/?l=xen-devel=149192184523741) established that commit

Re: [Xen-devel] [PATCH v1 10/10] xen/arm: domain_build: Don't expose the "iommus" property to the guest

On Thu, May 11, 2017 at 2:58 PM, Julien Grall wrote: > Hi Oleksandr, Hi Julien > > On 10/05/17 15:03, Oleksandr Tyshchenko wrote: >> >> From: Oleksandr Tyshchenko >> >> We don't passthrough IOMMU device to DOM0 even if it is not used by >>

Re: [Xen-devel] [PATCH for-4.9] xl: don't ignore return value from libxl_device_events_handler

On Thu, May 11, 2017 at 01:57:19PM +0100, Wei Liu wrote: > That function can return a whole slew of error codes. Translate them > to EXIT_FAILURE. > > Signed-off-by: Wei Liu Acked-by: Roger Pau Monné ___

[Xen-devel] [PATCH 4.11 27/28] xen: Revert commits da72ff5bfcb0 and 72a9b186292d

4.11-stable review patch. If anyone has any objections, please let me know. -- From: Boris Ostrovsky commit 84d582d236dc1f9085e741affc72e9ba061a67c2 upstream. Recent discussion (http://marc.info/?l=xen-devel=149192184523741) established that commit

Re: [Xen-devel] [PATCH v1 09/10] xen/arm: Add use_iommu flag to xen_arch_domainconfig

On Thu, May 11, 2017 at 2:42 PM, Julien Grall wrote: > Hi Oleksandr, Hi Julien > > > On 10/05/17 15:03, Oleksandr Tyshchenko wrote: >> >> From: Oleksandr Tyshchenko >> >> This flag is intended to let Xen know that the guest has devices >>

[Xen-devel] [linux-4.9 test] 109296: regressions - FAIL

flight 109296 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/109296/ 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 Tests which are

Re: [Xen-devel] [PATCH v1 07/10] iommu/arm: Add alloc_page_table platform callback

On Thu, May 11, 2017 at 2:38 PM, Julien Grall wrote: > Hi Oleksandr, Hi, Julien > > On 10/05/17 15:03, Oleksandr Tyshchenko wrote: >> >> From: Oleksandr Tyshchenko >> >> The alloc_page_table callback is a mandatory thing >> for the IOMMUs

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

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

Re: [Xen-devel] [PATCH] public/elfnote: document non-alignment of relocated init-P2M

On 09/05/17 16:23, Jan Beulich wrote: On 09.05.17 at 17:10, wrote: >> On 09/05/17 15:23, Jan Beulich wrote: >>> Since PV kernels can't use large pages anywa, when the init-P2M support >> anyway > Already fixed after Alan pointed this out. Do I need to send v2 >

  1   2   >