Re: [Xen-devel] [PATCH v7 00/15] Load BIOS via toolstack instead of been embedded in hvmloader.

On 07/28/2016 06:49 AM, Anthony PERARD wrote: Hi all, Changes in V7: - There is one new patch at the end to fix the doc. - Patch 6 as been change. that's it. There is just a few missing ackes: 6 xen: Move the hvm_start_info C representation from libxc to public/xen.h 8

[Xen-devel] [qemu-upstream-4.4-testing test] 99724: tolerable FAIL - PUSHED

flight 99724 qemu-upstream-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/99724/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 95501 Tests which did

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

On 07/29/16 00:25, Julien Grall wrote: > > > On 28/07/2016 22:05, Tamas K Lengyel wrote: >> On Thu, Jul 28, 2016 at 3:01 PM, Julien Grall >> wrote: >> That's not how we do it with vm_event. Even on x86 we only selectively >> set registers using the

[Xen-devel] [xen-4.6-testing test] 99720: regressions - FAIL

flight 99720 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/99720/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-amd 9 redhat-install fail REGR. vs. 96031 Regressions

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

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

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

flight 99719 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/99719/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-pair15 debian-install/dst_host fail REGR. vs. 97664 Regressions which

[Xen-devel] [PATCH] x86/vMsi-x: check whether the msixtbl_list has been initialized or not when accessing it

MSI-x tables' initialization had been detered in the commit 74c6dc2d0ac4dcab0c6243cdf6ed550c1532b798. If an assigned device does not support MSI-x, the msixtbl_list won't be initialized. Howerver, both of following paths XEN_DOMCTL_bind_pt_irq pt_irq_create_bind

Re: [Xen-devel] [PATCH v2 00/15] xen/arm: P2M clean-up fixes

Committed, thanks On Thu, 28 Jul 2016, Julien Grall wrote: > Hello all, > > This patch series contains a bunch of clean-up and fixes for the P2M code on > ARM. The major changes are: > - Deduce the memory attributes from the p2m type > - Switch to read-write lock to improve performance >

Re: [Xen-devel] [PATCH v2 11/15] xen/arm: p2m: Rework the context switch to another VTTBR in flush_tlb_domain

On Thu, 28 Jul 2016, Julien Grall wrote: > The current implementation of flush_tlb_domain is relying on the domain > to have a single p2m. With the upcoming feature altp2m, a single domain > may have different p2m. So we would need to switch to the correct p2m in > order to flush the TLBs. > >

Re: [Xen-devel] [PATCH v2 09/15] xen/arm: p2m: Move the vttbr field from arch_domain to p2m_domain

On Thu, 28 Jul 2016, Julien Grall wrote: > The field vttbr holds the base address of the translation table for > guest. Its value will depends on how the p2m has been initialized and > will only be used by the P2M code. > > So move the field from arch_domain to p2m_domain. This will also ease >

Re: [Xen-devel] [PATCH v2 02/15] xen/arm: p2m: Use a whitelist rather than blacklist in get_page_from_gfn

On Thu, 28 Jul 2016, Julien Grall wrote: > Currently, the check in get_page_from_gfn is using a blacklist. This is > very fragile because we may forgot to update the check when a new p2m > type is added. > > To avoid any possible issue, use a whitelist. All type backed by a RAM > page can could

[Xen-devel] [linux-3.18 test] 99718: regressions - FAIL

flight 99718 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/99718/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-amd64-pvgrub 6 xen-boot fail REGR. vs. 96188

Re: [Xen-devel] [PATCH] mem_access: Use monitor_traps instead of mem_access_send_req

On Thu, Jul 28, 2016 at 2:38 PM, Julien Grall wrote: > Hello Tamas, > > > On 28/07/2016 20:35, Tamas K Lengyel wrote: >> >> The two functions monitor_traps and mem_access_send_req duplicate >> some of the same functionality. The mem_access_send_req however leaves a >> lot of

Re: [Xen-devel] [PATCH] mem_access: Use monitor_traps instead of mem_access_send_req

On Thu, Jul 28, 2016 at 2:54 PM, Andrew Cooper wrote: > On 28/07/2016 20:35, Tamas K Lengyel wrote: >> The two functions monitor_traps and mem_access_send_req duplicate >> some of the same functionality. The mem_access_send_req however leaves a >> lot of the standard

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

On Thu, Jul 28, 2016 at 4:03 PM, Julien Grall wrote: > > > On 28/07/2016 22:33, Tamas K Lengyel wrote: >> >> On Jul 28, 2016 15:25, "Julien Grall" > > wrote: >>> >>> >>> >>> >>> On 28/07/2016 22:05, Tamas K Lengyel wrote:

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

On 28/07/2016 22:33, Tamas K Lengyel wrote: On Jul 28, 2016 15:25, "Julien Grall" > wrote: On 28/07/2016 22:05, Tamas K Lengyel wrote: On Thu, Jul 28, 2016 at 3:01 PM, Julien Grall >

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

On Jul 28, 2016 15:25, "Julien Grall" wrote: > > > > On 28/07/2016 22:05, Tamas K Lengyel wrote: >> >> On Thu, Jul 28, 2016 at 3:01 PM, Julien Grall wrote: >> That's not how we do it with vm_event. Even on x86 we only selectively >> set registers using

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

On 28/07/2016 22:05, Tamas K Lengyel wrote: On Thu, Jul 28, 2016 at 3:01 PM, Julien Grall wrote: That's not how we do it with vm_event. Even on x86 we only selectively set registers using the VM_EVENT_FLAG_SET_REGISTERS flag (albeit it not being documented in the

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

On Thu, Jul 28, 2016 at 3:01 PM, Julien Grall wrote: > > > On 28/07/2016 21:48, Tamas K Lengyel wrote: >> >> On Thu, Jul 28, 2016 at 2:41 PM, Andrew Cooper >> wrote: >>> >>> On 28/07/2016 21:36, Tamas K Lengyel wrote: On Thu, Jul 28,

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

On 28/07/2016 21:48, Tamas K Lengyel wrote: On Thu, Jul 28, 2016 at 2:41 PM, Andrew Cooper wrote: On 28/07/2016 21:36, Tamas K Lengyel wrote: On Thu, Jul 28, 2016 at 2:26 PM, Andrew Cooper wrote: On 28/07/2016 21:05, Tamas K Lengyel

Re: [Xen-devel] [PATCH] mem_access: Use monitor_traps instead of mem_access_send_req

On 28/07/2016 20:35, Tamas K Lengyel wrote: > The two functions monitor_traps and mem_access_send_req duplicate > some of the same functionality. The mem_access_send_req however leaves a > lot of the standard vm_event fields to be filled by other functions. > > Since mem_access events go on the

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

On Thu, Jul 28, 2016 at 2:41 PM, Andrew Cooper wrote: > On 28/07/2016 21:36, Tamas K Lengyel wrote: >> On Thu, Jul 28, 2016 at 2:26 PM, Andrew Cooper >> wrote: >>> On 28/07/2016 21:05, Tamas K Lengyel wrote: Add support for

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

On 28/07/2016 21:36, Tamas K Lengyel wrote: > On Thu, Jul 28, 2016 at 2:26 PM, Andrew Cooper > wrote: >> On 28/07/2016 21:05, Tamas K Lengyel wrote: >>> Add support for getting/setting registers through vm_event on ARM. >>> The set of registers can be expanded in the

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

On Thu, Jul 28, 2016 at 2:38 PM, Julien Grall wrote: > > > On 28/07/2016 21:36, Tamas K Lengyel wrote: >> >> On Thu, Jul 28, 2016 at 2:26 PM, Andrew Cooper >> wrote: >>> >>> On 28/07/2016 21:05, Tamas K Lengyel wrote: Add support for

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

On 28/07/2016 21:36, Tamas K Lengyel wrote: On Thu, Jul 28, 2016 at 2:26 PM, Andrew Cooper wrote: On 28/07/2016 21:05, Tamas K Lengyel wrote: Add support for getting/setting registers through vm_event on ARM. The set of registers can be expanded in the future to

Re: [Xen-devel] [PATCH] mem_access: Use monitor_traps instead of mem_access_send_req

Hello Tamas, On 28/07/2016 20:35, Tamas K Lengyel wrote: The two functions monitor_traps and mem_access_send_req duplicate some of the same functionality. The mem_access_send_req however leaves a lot of the standard vm_event fields to be filled by other functions. Since mem_access events go on

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

On Thu, Jul 28, 2016 at 2:26 PM, Andrew Cooper wrote: > On 28/07/2016 21:05, Tamas K Lengyel wrote: >> Add support for getting/setting registers through vm_event on ARM. >> The set of registers can be expanded in the future to include other registers >> as well if

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

On 28/07/2016 21:05, Tamas K Lengyel wrote: > Add support for getting/setting registers through vm_event on ARM. > The set of registers can be expanded in the future to include other registers > as well if necessary but for now it is limited to TTB/CR/R0/R1, PC and CPSR. > > Signed-off-by: Tamas K

[Xen-devel] [PATCH] arm/vm_event: get/set registers

Add support for getting/setting registers through vm_event on ARM. The set of registers can be expanded in the future to include other registers as well if necessary but for now it is limited to TTB/CR/R0/R1, PC and CPSR. Signed-off-by: Tamas K Lengyel --- Cc: Stefano

[Xen-devel] [ovmf baseline-only test] 66856: trouble: blocked/broken/pass

This run is configured for baseline tests only. flight 66856 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66856/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm3

Re: [Xen-devel] OVMF very slow on AMD

On 07/28/2016 03:44 PM, Andrew Cooper wrote: As far as Intel vs AMD implementation in Xen, we have vmx_handle_cd() but no corresponding SVM code. Could it be that we need to set gPAT, for example? >>> A better approach would be to find out why ovmf insists on disabling >>> caches at

Re: [Xen-devel] OVMF very slow on AMD

On 28/07/16 20:25, Boris Ostrovsky wrote: > On 07/28/2016 11:51 AM, Andrew Cooper wrote: >> On 28/07/16 16:17, Boris Ostrovsky wrote: >>> On 07/28/2016 06:54 AM, Andrew Cooper wrote: On 28/07/16 11:43, George Dunlap wrote: > On Thu, Jul 28, 2016 at 11:18 AM, Anthony PERARD >

Re: [Xen-devel] [PATCH v2 3/6] xen/arm: Use check_workaround to handle the erratum 766422

On Wed, 27 Jul 2016, Julien Grall wrote: > Currently, Xen is accessing the stored MIDR everytime it has to check > whether the processor is affected by the erratum 766422. > > This could take advantage of the new capability bitfields to detect > whether the processor is affected at boot time. >

Re: [Xen-devel] [PATCH v2 2/6] xen/arm: Provide macros to help creating workaround helpers

On Wed, 27 Jul 2016, Julien Grall wrote: > Workarounds may require to execute a different path when the platform > is affected by the associated erratum. Furthermore, this may need to > be called in the common code. > > To avoid too much intrusion/overhead, the workaround helpers need to > be a

Re: [Xen-devel] [PATCH v2 1/6] xen/arm: traps: Simplify the switch in do_trap_*_abort_guest

On Wed, 27 Jul 2016, Julien Grall wrote: > The fault status we care are in the form xx where xx is the lookup > level that gave the fault. We can simplify the code by masking the 2 least > significant bits. > > Signed-off-by: Julien Grall Reviewed-by: Stefano

[Xen-devel] [PATCH] mem_access: Use monitor_traps instead of mem_access_send_req

The two functions monitor_traps and mem_access_send_req duplicate some of the same functionality. The mem_access_send_req however leaves a lot of the standard vm_event fields to be filled by other functions. Since mem_access events go on the monitor ring in this patch we consolidate all paths to

Re: [Xen-devel] OVMF very slow on AMD

On 07/28/2016 11:51 AM, Andrew Cooper wrote: > On 28/07/16 16:17, Boris Ostrovsky wrote: >> On 07/28/2016 06:54 AM, Andrew Cooper wrote: >>> On 28/07/16 11:43, George Dunlap wrote: On Thu, Jul 28, 2016 at 11:18 AM, Anthony PERARD wrote: > On Wed, Jul 27,

Re: [Xen-devel] [RFC PATCHv1] xen/privcmd: add IOCTL_PRIVCMD_RESTRICT_DOMID

On 07/28/2016 12:13 PM, David Vrabel wrote: > > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c > index df2e6f7..513d1c5 100644 > --- a/drivers/xen/privcmd.c > +++ b/drivers/xen/privcmd.c > @@ -43,6 +43,18 @@ MODULE_LICENSE("GPL"); > > #define PRIV_VMA_LOCKED ((void *)1) > >

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

On Thu, Jul 28, 2016 at 11:25:42AM -0700, li...@ssl-mail.com wrote: > > Hmmm Could you provide full console dump from Xen and Linux kernel? > > Will serial console output with these options > > kernel: earlyprintk=xen,keep debug loglevel=8 > hypervisor: loglvl=all

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

On 07/28/2016 11:25 AM, li...@ssl-mail.com wrote:> > Hmmm Could you provide full console dump from Xen and Linux kernel? > > Will serial console output with these options > > kernel: earlyprintk=xen,keep debug loglevel=8 > hypervisor: loglvl=all guest_loglvl=all sync_console

Re: [Xen-devel] [DRAFT v3] XenSock protocol design document

On Thu, 28 Jul 2016, Sander Eikelenboom wrote: > Thursday, July 28, 2016, 8:11:53 PM, you wrote: > > > ping > > Hi Stefano, > > JFYI: > Since this doesn't seem to be checked with the upstream kernel yet, > I don't know if you are aware of the opinions expressed upstream > about the proposed

Re: [Xen-devel] [DRAFT v3] XenSock protocol design document

Thursday, July 28, 2016, 8:11:53 PM, you wrote: > ping Hi Stefano, JFYI: Since this doesn't seem to be checked with the upstream kernel yet, I don't know if you are aware of the opinions expressed upstream about the proposed Hyper-V socket patches:

[Xen-devel] [xen-4.3-testing test] 99717: trouble: blocked/broken/fail/pass

flight 99717 xen-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/99717/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-i386-pvgrub 3 host-install(3) broken REGR. vs.

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

> Hmmm Could you provide full console dump from Xen and Linux kernel? Will serial console output with these options kernel: earlyprintk=xen,keep debug loglevel=8 hypervisor: loglvl=all guest_loglvl=all sync_console console_to_ring do?

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

On Wed, Jul 27, 2016 at 09:09:52PM -0400, Konrad Rzeszutek Wilk wrote: > > > > Sadly not. The debug symbols need to be specific to the exact binary > > > > you booted. > > > > > > > > Any change in the compilation will result in the translation being > > > > useless. What addr2line is doing is

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

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

Re: [Xen-devel] [DRAFT v3] XenSock protocol design document

ping On Wed, 20 Jul 2016, Stefano Stabellini wrote: > Hi all, > > This is the design document of the XenSock protocol. You can find > prototypes of the Linux frontend and backend drivers here: > > git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git xensock-3 > > To use them, make

Re: [Xen-devel] [RFC 13/22] xen/arm: p2m: Replace all usage of __p2m_lookup with p2m_get_entry

Hello Tamas, On 28/07/2016 18:29, Tamas K Lengyel wrote: On Thu, Jul 28, 2016 at 8:51 AM, Julien Grall wrote: [...] --- xen/arch/arm/p2m.c | 18 -- 1 file changed, 4 insertions(+), 14 deletions(-) diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c

Re: [Xen-devel] [RFC 00/22] xen/arm: Rework the P2M code to follow break-before-make sequence

Hi Julien, > I sent this patch series as an RFC because there are still some TODOs > in the code (mostly sanity check and possible optimization) and I have > done limited testing. However, I think it is a good shape to start reviewing, > get more feedback and have wider testing on different

Re: [Xen-devel] [RFC 13/22] xen/arm: p2m: Replace all usage of __p2m_lookup with p2m_get_entry

On Thu, Jul 28, 2016 at 11:29 AM, Tamas K Lengyel wrote: > On Thu, Jul 28, 2016 at 8:51 AM, Julien Grall wrote: >> __p2m_lookup is just a wrapper to p2m_get_entry. >> >> Signed-off-by: Julien Grall >> Cc: Razvan Cojocaru

Re: [Xen-devel] [RFC 13/22] xen/arm: p2m: Replace all usage of __p2m_lookup with p2m_get_entry

On Thu, Jul 28, 2016 at 8:51 AM, Julien Grall wrote: > __p2m_lookup is just a wrapper to p2m_get_entry. > > Signed-off-by: Julien Grall > Cc: Razvan Cojocaru > Cc: Tamas K Lengyel > > --- > It might

Re: [Xen-devel] [PATCH v2 1/2] xen: fix a (latent) cpupool-related race during domain destroy

On Mon, 2016-07-18 at 16:09 +0200, Juergen Gross wrote: > Acked-by: Juergen Gross > > for this patch then. > George, Ping about this series. It's not terribly urgent, but it should be easy enough, so I guess there is a chance that you can have a quick look. If you can't,

Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support

Re: [Xen-devel] [RFC 21/22] xen/arm: p2m: Re-implement p2m_set_mem_access using p2m_{set, get}_entry

On Thu, Jul 28, 2016 at 8:51 AM, Julien Grall wrote: > The function p2m_set_mem_access can be re-implemented using the generic > functions p2m_get_entry and __p2m_set_entry. > > Note that because of the implementation of p2m_get_entry, a TLB > invalidation instruction will

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

anyone need any addl info from my end to help ? ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH linux] xen: change the type of xen_vcpu_id to uint32_t

On 28/07/16 17:24, Vitaly Kuznetsov wrote: > We pass xen_vcpu_id mapping information to hypercalls which require > uint32_t type so it would be cleaner to have it as uint32_t. The > initializer to -1 can be dropped as we always do the mapping before using > it and we never check the 'not set'

[Xen-devel] XenProject/XenServer QEMU working group, Friday 8th July, 2016, 15:00.

XenProject/XenServer QEMU working group, Friday 8th July, 2016, 15:00. Date and Attendees == XenProject/XenServer QEMU working group, held on Friday the 8th of July, 2016 at 15:00. The Following were present: Ian Jackson [platform team] David Vrabel [ring0] Andrew Cooper

[Xen-devel] [PATCH linux] xen: change the type of xen_vcpu_id to uint32_t

We pass xen_vcpu_id mapping information to hypercalls which require uint32_t type so it would be cleaner to have it as uint32_t. The initializer to -1 can be dropped as we always do the mapping before using it and we never check the 'not set' value anyway. Signed-off-by: Vitaly Kuznetsov

[Xen-devel] [RFC PATCHv1] xen/privcmd: add IOCTL_PRIVCMD_RESTRICT_DOMID

This restricts the file descriptor to only being able map foreign memory belonging to a specific domain. Once a file descriptor has been restricted its restriction cannot be removed or changed. A device model (e.g., QEMU) or similar can make use of this before dropping privileges to prevent the

Re: [Xen-devel] [PATCH 2/2] x86/mm: Annotate gfn_get_* helpers as requiring non-NULL parameters

On 28/07/16 16:58, George Dunlap wrote: > On 27/07/16 19:08, Andrew Cooper wrote: >> Introduce and use the nonnull attribute to help the compiler catch NULL >> parameters being passed to function which require their parameters not to be >> NULL. Experimentally, GCC 4.9 on Debian Jessie only warns

[Xen-devel] [xen-4.4-testing test] 99711: trouble: blocked/broken/fail/pass

flight 99711 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/99711/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-raw3 host-install(3) broken REGR. vs.

Re: [Xen-devel] [PATCH 2/2] x86/mm: Annotate gfn_get_* helpers as requiring non-NULL parameters

On 27/07/16 19:08, Andrew Cooper wrote: > Introduce and use the nonnull attribute to help the compiler catch NULL > parameters being passed to function which require their parameters not to be > NULL. Experimentally, GCC 4.9 on Debian Jessie only warns of non-NULL-ness > from immediate callers,

Re: [Xen-devel] [PATCH 1/2] x86/mm: Avoid NULL dereference when checking altp2m's for shareability

On 27/07/16 19:08, Andrew Cooper wrote: > Coverity identifies that __get_gfn_type_access() unconditionally writes to its > type parameter under a number of circumstances. > > Signed-off-by: Andrew Cooper Reviewed-by: George Dunlap > --- >

Re: [Xen-devel] OVMF very slow on AMD

On 28/07/16 16:17, Boris Ostrovsky wrote: > On 07/28/2016 06:54 AM, Andrew Cooper wrote: >> On 28/07/16 11:43, George Dunlap wrote: >>> On Thu, Jul 28, 2016 at 11:18 AM, Anthony PERARD >>> wrote: On Wed, Jul 27, 2016 at 03:45:23PM -0400, Boris Ostrovsky wrote:

[Xen-devel] nocera1 boot order fixed (was Re: [xen-4.7-testing test] 99713: regressions - trouble: blocked/broken/fail/pass)

Ian Jackson writes ("nocera1 boot order fixed (was Re: [xen-4.7-testing test] 99713: regressions - trouble: blocked/broken/fail/pass)"): > Ian Jackson writes ("Re: [xen-4.7-testing test] 99713: regressions - trouble: > blocked/broken/fail/pass"): > > osstest service owner writes

Re: [Xen-devel] [RFC 21/22] xen/arm: p2m: Re-implement p2m_set_mem_access using p2m_{set, get}_entry

On 28/07/16 16:04, Razvan Cojocaru wrote: On 07/28/2016 05:51 PM, Julien Grall wrote: The function p2m_set_mem_access can be re-implemented using the generic functions p2m_get_entry and __p2m_set_entry. Note that because of the implementation of p2m_get_entry, a TLB invalidation instruction

Re: [Xen-devel] OVMF very slow on AMD

On 07/28/2016 06:54 AM, Andrew Cooper wrote: > On 28/07/16 11:43, George Dunlap wrote: >> On Thu, Jul 28, 2016 at 11:18 AM, Anthony PERARD >> wrote: >>> On Wed, Jul 27, 2016 at 03:45:23PM -0400, Boris Ostrovsky wrote: On 07/27/2016 07:35 AM, Anthony PERARD wrote:

[Xen-devel] nocera1 boot order fixed (was Re: [xen-4.7-testing test] 99713: regressions - trouble: blocked/broken/fail/pass)

Ian Jackson writes ("Re: [xen-4.7-testing test] 99713: regressions - trouble: blocked/broken/fail/pass"): > osstest service owner writes ("[xen-4.7-testing test] 99713: regressions - > trouble: blocked/broken/fail/pass"): > > test-amd64-i386-freebsd10-i386 3 host-install(3) broken REGR. vs.

Re: [Xen-devel] [RFC 21/22] xen/arm: p2m: Re-implement p2m_set_mem_access using p2m_{set, get}_entry

On 07/28/2016 05:51 PM, Julien Grall wrote: > The function p2m_set_mem_access can be re-implemented using the generic > functions p2m_get_entry and __p2m_set_entry. > > Note that because of the implementation of p2m_get_entry, a TLB > invalidation instruction will be issued for each 4KB page.

Re: [Xen-devel] [xen-4.7-testing test] 99713: regressions - trouble: blocked/broken/fail/pass

osstest service owner writes ("[xen-4.7-testing test] 99713: regressions - trouble: blocked/broken/fail/pass"): > test-amd64-i386-freebsd10-i386 3 host-install(3) broken REGR. vs. 96660 Lots of these. Something is wrong with nocera1. I am investigating. Ian.

[Xen-devel] [RFC 16/22] xen/arm: p2m: Make p2m_{valid, table, mapping} helpers inline

Those helpers are very small and often used. Let know the compiler they can be inlined. Signed-off-by: Julien Grall --- xen/arch/arm/p2m.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c index

[Xen-devel] [RFC 13/22] xen/arm: p2m: Replace all usage of __p2m_lookup with p2m_get_entry

__p2m_lookup is just a wrapper to p2m_get_entry. Signed-off-by: Julien Grall Cc: Razvan Cojocaru Cc: Tamas K Lengyel --- It might be possible to rework the memaccess code to take advantage of all the parameters. I

[Xen-devel] [RFC 22/22] xen/arm: p2m: Do not handle shattering in p2m_create_table

The helper p2m_create_table is only called to create a brand new table. Signed-off-by: Julien Grall --- xen/arch/arm/p2m.c | 51 ++- 1 file changed, 6 insertions(+), 45 deletions(-) diff --git a/xen/arch/arm/p2m.c

[Xen-devel] [RFC 18/22] xen/arm: p2m: Introduce p2m_set_entry and __p2m_set_entry

The ARM architecture mandates to use of a break-before-make sequence when changing translation entries if the page table is shared between multiple CPUs whenever a valid entry is replaced by another valid entry (see D4.7.1 in ARM DDI 0487A.j for more details). The break-before-make sequence can

[Xen-devel] [RFC 21/22] xen/arm: p2m: Re-implement p2m_set_mem_access using p2m_{set, get}_entry

The function p2m_set_mem_access can be re-implemented using the generic functions p2m_get_entry and __p2m_set_entry. Note that because of the implementation of p2m_get_entry, a TLB invalidation instruction will be issued for each 4KB page. Therefore the performance of memaccess will be impacted,

[Xen-devel] [RFC 20/22] xen/arm: p2m: Re-implement p2m_insert_mapping using p2m_set_entry

The function p2m_insert_mapping can be re-implemented using the generic function p2m_set_entry. Note that the mapping is not reverted anymore if Xen fails to insert a mapping. This was added to ensure the MMIO are not kept half-mapped in case of failure and to follow the x86 counterpart. This was

[Xen-devel] [RFC 11/22] xen/arm: p2m: Introduce p2m_get_root_pointer and use it in __p2m_lookup

Mapping the root table is always done the same way. To avoid duplicating the code in a later patch, move the code in a separate helper. Signed-off-by: Julien Grall --- xen/arch/arm/p2m.c | 53 +++-- 1 file changed, 35

[Xen-devel] [RFC 07/22] xen/arm: p2m: Rework p2m_put_l3_page

Modify the prototype to directly pass the mfn and the type in parameters. This will be useful later when we do not have the entry in hand. Signed-off-by: Julien Grall --- xen/arch/arm/p2m.c | 17 +++-- 1 file changed, 7 insertions(+), 10 deletions(-) diff

[Xen-devel] [RFC 19/22] xen/arm: p2m: Re-implement p2m_remove_using using p2m_set_entry

The function p2m_insert_mapping can be re-implemented using the generic function p2m_set_entry. Also drop the operation REMOVE in apply_* as nobody is using it anymore. Note that the functions could have been dropped in one go at the end, however I find easier to drop the operations one by one

[Xen-devel] [RFC 14/22] xen/arm: p2m: Re-implement p2m_cache_flush using p2m_get_entry

The function p2m_cache_flush can be re-implemented using the generic function p2m_get_entry by iterating over the range and using the mapping order given by the callee. As the current implementation, no preemption is implemented, although the comment in the current code claimed it. As the

[Xen-devel] [RFC 17/22] xen/arm: p2m: Introduce a helper to check if an entry is a superpage

Use the level and the entry to know whether an entry is a superpage. A superpage can only happen below level 3. Signed-off-by: Julien Grall --- xen/arch/arm/p2m.c | 5 + 1 file changed, 5 insertions(+) diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c index

[Xen-devel] [RFC 15/22] xen/arm: p2m: Re-implement relinquish_p2m_mapping using p2m_get_entry

The current implementation of relinquish_p2m_mapping is modifying the page table to erase the entry one by one. However, this is not necessary because the domain is not running anymore and therefore will speed up the domain destruction. The function relinquish_p2m_mapping can be re-implemented

[Xen-devel] [RFC 08/22] xen/arm: p2m: Invalidate the TLBs when write unlocking the p2m

Sometimes the invalidation of the TLBs can be deferred until the p2m is unlocked. This is for instance the case when multiple mappings are removed. In other case, such as shattering a superpage, an immediate flush is required. Keep track whether a flush is needed directly in the p2m_domain

[Xen-devel] [RFC 00/22] xen/arm: Rework the P2M code to follow break-before-make sequence

Hello all, The ARM architecture mandates the use of a break-before-make sequence when changing translation entries if the page table is shared between multiple CPUs whenever a valid entry is replaced by another valid entry (see D4.7.1 in ARM DDI 0487A.j for more details). The current P2M code

[Xen-devel] [RFC 05/22] xen/arm: traps: Move MMIO emulation code in a separate helper

Currently, a stage-2 fault translation will likely access an emulated region. All the checks are pre-sanitity check for MMIO emulation. A follow-up patch will handle a new case that could lead to a stage-2 translation. To improve the clarity of the code and the changes, the current implementation

[Xen-devel] [RFC 04/22] xen/arm: p2m: Use typesafe gfn in p2m_mem_access_radix_set

p2m_mem_access_radix_set is expecting a gfn in a parameter. Rename the parameter 'pfn' to 'gfn' to match its content and use the typesafe gfn to avoid possible misusage. Also rename the parameter to gfn to match its content. Signed-off-by: Julien Grall ---

[Xen-devel] [RFC 12/22] xen/arm: p2m: Introduce p2m_get_entry and use it to implement __p2m_lookup

Currently, for a given GFN, the function __p2m_lookup will only return the associated MFN and the p2m type of the mapping. In some case we need the order of the mapping and the memaccess permission. Rather than providing separate function for this purpose, it is better to implement a generic

[Xen-devel] [RFC 06/22] xen/arm: traps: Check the P2M before injecting a data/instruction abort

A data/instruction abort may have occurred if another CPU was playing with the stage-2 page table when following the break-before-make sequence (see D4.7.1 in ARM DDI 0487A.j). Rather than injecting directly the fault to the guest, we need to check whether the mapping exists. If it exists, return

[Xen-devel] [RFC 02/22] xen/arm: p2m: Store in p2m_domain whether we need to clean the entry

Each entry in the page table has to table clean when the IOMMU does not support coherent walk. Rather than querying every time the page table is updated, it is possible to do it only once when the p2m is initialized. This is because this value can never change, Xen would be in big trouble

[Xen-devel] [RFC 09/22] xen/arm: p2m: Change the type of level_shifts from paddr_t to unsigned int

The level shift can be encoded with 32-bit. So it is not necessary to use paddr_t (i.e 64-bit). Signed-off-by: Julien Grall --- xen/arch/arm/p2m.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c index

[Xen-devel] [RFC 03/22] xen/arm: p2m: Rename parameter in p2m_{remove, write}_pte...

to make clear of the usage. I.e it is used to inform whether Xen needs to clean the entry after writing in the page table. Signed-off-by: Julien Grall --- xen/arch/arm/p2m.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/xen/arch/arm/p2m.c

[Xen-devel] [RFC 01/22] xen/arm: do_trap_instr_abort_guest: Move the IPA computation out of the switch

A follow-up patch will add more case to the switch that will require the IPA. So move the computation out of the switch. Signed-off-by: Julien Grall --- xen/arch/arm/traps.c | 36 ++-- 1 file changed, 18 insertions(+), 18 deletions(-) diff

[Xen-devel] [RFC 10/22] xen/arm: p2m: Move the lookup helpers at the top of the file

This will be used later in functions that will be defined earlier in the file. Signed-off-by: Julien Grall --- xen/arch/arm/p2m.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c index

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

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

Re: [Xen-devel] [PATCH v4] xen/arm: Add a clock property

On 28.07.2016 13:17, Julien Grall wrote: Hi Dirk, On 27/07/16 06:05, Dirk Behme wrote: Hi Michael, Stefano and Julien, On 22.07.2016 03:16, Stefano Stabellini wrote: On Thu, 21 Jul 2016, Michael Turquette wrote: Quoting Stefano Stabellini (2016-07-14 03:38:04) On Thu, 14 Jul 2016, Dirk

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

On Thu, Jul 28, 2016, at 07:09 AM, Vitaly Kuznetsov wrote: > While I see that you're running linux-4.7 could you please double-check > that it has the following: > > commit 55f1ea15216a5a14c96738bd5284100a00ffa9dc > Author: Vitaly Kuznetsov > Date: Tue May 31 11:23:43

[Xen-devel] [PATCH v2 05/15] xen/arm: p2m: Remove unnecessary locking

The p2m is not yet in use when p2m_init and p2m_allocate_table are called. Furthermore the p2m is not used anymore when p2m_teardown is called. So taking the p2m lock is not necessary. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini ---

[Xen-devel] [PATCH v2 03/15] xen/arm: p2m: Differentiate cacheable vs non-cacheable MMIO

Currently, the p2m type p2m_mmio_direct is used to map in stage-2 cacheable MMIO (via map_regions_rw_cache) and non-cacheable one (via map_mmio_regions). The p2m code is relying on the caller to give the correct memory attribute. In a follow-up patch, the p2m code will rely on the p2m type to

[Xen-devel] [PATCH v2 13/15] xen/arm: Don't export flush_tlb_domain

The function flush_tlb_domain is not used outside of the file where it has been declared. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini --- Changes in v2: - Add Stefano's reviewed-by --- xen/arch/arm/p2m.c | 2

[Xen-devel] [PATCH v2 14/15] xen/arm: p2m: Replace flush_tlb_domain by p2m_flush_tlb

The function to flush the TLBs for a given p2m does not need to know about the domain. So pass directly the p2m in parameter. At the same time rename the function to p2m_flush_tlb to match the parameter change. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini

  1   2   >