[Xen-devel] [PATCH v4] xen/arm32: Introduce alternative runtime patching

This patch is based on the implementation of ARM64, it introduces alternative runtime patching to ARM32. This allows to patch assembly instruction at runtime to either fix hardware bugs or optimize for certain hardware features on ARM32 platform. Xen hypervisor is using ARM execution state only on

Re: [Xen-devel] [RFC PATCH v3 1/2] xen: credit2: enable per cpu runqueue creation

Hello Praveen, On Fri, 2017-03-31 at 00:58 +0530, Praveen Kumar wrote: > The patch introduces a new command line option 'cpu' that when used > will > create runqueue per logical pCPU. > I'd add a quick note about why we think it's a good idea to have this. Something like: "This may be useful for

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

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

Re: [Xen-devel] [PATCH v3 1/9] x86/mce: handle LMCE locally

>>> On 31.03.17 at 04:34, wrote: > On 03/30/17 08:35 -0600, Jan Beulich wrote: >> >>> On 30.03.17 at 08:19, wrote: >> > --- a/xen/arch/x86/cpu/mcheck/mce.c >> > +++ b/xen/arch/x86/cpu/mcheck/mce.c >> > @@ -42,6 +42,13 @@ DEFINE_PER_CPU_READ_MOSTLY(struct mca_banks *, >> > poll_bankmask); >> > D

Re: [Xen-devel] [PATCH v2] x86/emul: Poision the stubs with debug traps

>>> On 30.03.17 at 19:09, wrote: > If you do have an external debugger attached, you don't need embedded > int3's to start with, and you'd still hit the debugger_trap_*() calls > before dying. Well, my experience (on other OSes with a better debugger) is different - there are occasions where it i

Re: [Xen-devel] [PATCH RFC] x86/emulate: implement hvmemul_cmpxchg() with an actual CMPXCHG

>>> On 31.03.17 at 08:17, wrote: > On 03/30/2017 06:47 PM, Jan Beulich wrote: >>> Speaking of emulated MMIO, I've got this when the guest was crashing >>> immediately (pre RETRY loop): >>> >>> MMIO emulation failed: d3v8 32bit @ 0008:82679f3c -> f0 0f ba 30 00 72 >>> 07 8b cb e8 da 4b ff ff 8b 45

Re: [Xen-devel] [PATCH for-4.9 2/4] tools/libxc: Avoid generating inappropriate zero-content records

>>> On 30.03.17 at 18:32, wrote: > --- a/tools/libxc/xc_sr_save_x86_hvm.c > +++ b/tools/libxc/xc_sr_save_x86_hvm.c > @@ -112,6 +112,10 @@ static int write_hvm_params(struct xc_sr_context *ctx) > } > } > > +/* No params? Skip this record. */ > +if ( hdr.count == 0 ) > +

Re: [Xen-devel] [PATCH v2] x86: suppress duplicate symbol warnings for CONFIG_GCOV

On 03/30/2017 05:12 PM, Jan Beulich wrote: There are quite a few of these, and as the option is a development one only, duplicate symbol names should not be an issue there. In other environments allow the user to control this, unless Live patching is enabled. Signed-off-by: Jan Beulich Review

Re: [Xen-devel] [PATCH for-4.9 4/4] docs: Clarify the expected behaviour of zero-content records

>>> On 30.03.17 at 18:32, wrote: > @@ -631,6 +631,11 @@ The set of valid records depends on the guest > architecture and type. No > assumptions should be made about the ordering or interleaving of > independent records. Record dependencies are noted below. > > +Some records are used for sig

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

On 30/03/17 17:05, Jan Beulich wrote: On 30.03.17 at 16:18, wrote: >> @@ -2903,3 +2906,13 @@ int xen_unmap_domain_gfn_range(struct vm_area_struct >> *vma, >> return -EINVAL; >> } >> EXPORT_SYMBOL_GPL(xen_unmap_domain_gfn_range); >> + >> +#ifdef CONFIG_KEXEC_CORE >> +phys_addr_t paddr_

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

On 30/03/17 16:51, Boris Ostrovsky wrote: > On 03/30/2017 10:18 AM, 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. >> >> paddr_vmcore

Re: [Xen-devel] Legacy PCI interrupt {de}assertion count

On Fri, Mar 31, 2017 at 05:05:44AM +, Tian, Kevin wrote: > > From: Jan Beulich [mailto:jbeul...@suse.com] > > Sent: Monday, March 27, 2017 4:00 PM > > > > >>> On 24.03.17 at 17:54, wrote: > > > As I understand it, for level triggered legacy PCI interrupts Xen sets > > > up a timer in order to

Re: [Xen-devel] [PATCH v11 2/6] VT-d: Introduce new fields in msi_desc to track binding with guest interrupt

>>> On 31.03.17 at 01:01, wrote: > On Fri, Mar 31, 2017 at 01:46:33PM +0800, Tian, Kevin wrote: >>> From: Gao, Chao >>> Sent: Wednesday, March 29, 2017 1:12 PM >>> --- a/xen/drivers/passthrough/io.c >>> +++ b/xen/drivers/passthrough/io.c >>> @@ -618,6 +618,8 @@ int pt_irq_destroy_bind( >>>

Re: [Xen-devel] arm64: dma_to_phys/phys_to_dma need to be properly implemented

Hi, Stefano Unfortunately I had to switch to other tasks, but I'll get back to this issue asap Thank you On 03/30/2017 01:36 AM, Stefano Stabellini wrote: On Wed, 29 Mar 2017, Oleksandr Andrushchenko wrote: Hi, Stefano! Ok, probably I need to put more details into the use-case so it is cle

Re: [Xen-devel] [PATCH v11 2/6] VT-d: Introduce new fields in msi_desc to track binding with guest interrupt

On Fri, Mar 31, 2017 at 02:11:08AM -0600, Jan Beulich wrote: On 31.03.17 at 01:01, wrote: >> On Fri, Mar 31, 2017 at 01:46:33PM +0800, Tian, Kevin wrote: From: Gao, Chao Sent: Wednesday, March 29, 2017 1:12 PM --- a/xen/drivers/passthrough/io.c +++ b/xen/drivers/passthroug

Re: [Xen-devel] [PATCH v3] xen/arm: alternative: Register re-mapped Xen area as a temporary virtual region

On 03/31/2017 07:47 AM, Jan Beulich wrote: On 29.03.17 at 16:23, wrote: On 27/03/17 09:40, Wei Chen wrote: @@ -154,8 +155,12 @@ static int __apply_alternatives_multi_stop(void *unused) int ret; struct alt_region region; mfn_t xen_mfn = _mfn(virt_to_mfn(_start)); -

Re: [Xen-devel] [PATCH v7 2/4] xen: introduce a C99 headers check

>>> On 30.03.17 at 23:04, wrote: > --- a/.gitignore > +++ b/.gitignore > @@ -274,6 +274,7 @@ xen/arch/*/efi/compat.c > xen/arch/*/efi/efi.h > xen/arch/*/efi/runtime.c > xen/include/headers.chk > +xen/include/headers99.chk > xen/include/headers++.chk I'm sorry for not having noticed on the pre

Re: [Xen-devel] [PATCH v7 4/4] Introduce the pvcalls header

>>> On 30.03.17 at 23:04, wrote: > Define the ring and request and response structs according to the > specification. Use the new DEFINE_XEN_FLEX_RING macro. > > Add the header to the C99 check. > > Signed-off-by: Stefano Stabellini > CC: jbeul...@suse.com > CC: konrad.w...@oracle.com > --- >

Re: [Xen-devel] [RFC PATCH v3 2/2] xen: credit2: provide custom option to create

On Fri, 2017-03-31 at 00:58 +0530, Praveen Kumar wrote: > The patch introduces a new command line option 'custom' that when used will > create runqueue based upon the pCPU subset provide during bootup. > "introduces a new, very flexible, way of arranging runqueues in Credit2. It allows to specify

Re: [Xen-devel] [PATCH v2 02/19] xen/arm: Remove vwfi while setting HCR_EL2 in init_traps

Hi Stefano, On 03/30/2017 11:29 PM, Stefano Stabellini wrote: I tried on different boards, and it gets stuck when initializing stage-2 page table configuration on each CPU (see setup_virt_paging). The secondary CPUs don't receive the SGI. Reading a bit more the ARM ARM (D7.2.33 in ARM DDI 0487A

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

flight 107016 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/107016/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt 5 libvirt-buildfail REGR. vs. 106829 Tests which did not suc

Re: [Xen-devel] [PATCH v2 04/19] xen/arm: Restore HCR_EL2 register

Hi Wei, On 03/31/2017 03:10 AM, Wei Chen wrote: Hi Julien and Stefano, On 2017/3/31 6:03, Stefano Stabellini wrote: On Thu, 30 Mar 2017, Julien Grall wrote: Hi Wei, On 30/03/17 10:13, Wei Chen wrote: diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index de59e5f..8af22

[Xen-devel] [distros-debian-jessie test] 71130: tolerable trouble: blocked/broken/pass

flight 71130 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71130/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-armhf-pvops 3 host-install(3) broken like 68668 build-armhf

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

>>> On 30.03.17 at 14:10, wrote: > On 17-03-30 05:55:52, Jan Beulich wrote: >> >>> On 30.03.17 at 03:37, wrote: >> > On 17-03-29 03:57:52, Jan Beulich wrote: >> >> >>> On 29.03.17 at 03:36, wrote: >> >> > On 17-03-29 09:20:21, Yi Sun wrote: >> >> >> On 17-03-28 06:20:48, Jan Beulich wrote: >> >>

Re: [Xen-devel] [PATCH v2 09/19] xen/arm: Introduce a initcall to update cpu_hwcaps by serror_op

Hi Stefano, On 03/30/2017 10:28 PM, Stefano Stabellini wrote: On Thu, 30 Mar 2017, Julien Grall wrote: On 30/03/17 10:13, Wei Chen wrote: In the later patches of this series, we want to use the alternative patching framework to avoid checking serror_op in every entries. So we define a new cpu

[Xen-devel] Outreachy Project

Hello! My name is Nazira and I am interested in the project called "Xen Hypervisor". This mail is displayed as a contact information, so I wanted to ask how to connect to a mentor of the project? ___ Xen-devel mailing list Xen-devel@lists.xen.org https:/

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

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

Re: [Xen-devel] [PATCH v2 04/19] xen/arm: Restore HCR_EL2 register

On 2017/3/31 16:39, Julien Grall wrote: > Hi Wei, > > On 03/31/2017 03:10 AM, Wei Chen wrote: >> Hi Julien and Stefano, >> >> On 2017/3/31 6:03, Stefano Stabellini wrote: >>> On Thu, 30 Mar 2017, Julien Grall wrote: Hi Wei, On 30/03/17 10:13, Wei Chen wrote: > diff --git a/xen/ar

Re: [Xen-devel] [PATCH v2 1/2] ACPICA: ACPI 6.0: Add support for IORT table.

>>> On 31.03.17 at 01:00, wrote: > --- a/xen/include/acpi/actbl2.h > +++ b/xen/include/acpi/actbl2.h > @@ -69,6 +69,7 @@ > #define ACPI_SIG_HPET "HPET" /* High Precision Event Timer > table */ > #define ACPI_SIG_IBFT "IBFT" /* i_sCSI Boot Firmware Table */ > #de

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

On 17-03-31 02:47:25, Jan Beulich wrote: > >>> On 30.03.17 at 14:10, wrote: > > On 17-03-30 05:55:52, Jan Beulich wrote: > >> >>> On 30.03.17 at 03:37, wrote: > >> > On 17-03-29 03:57:52, Jan Beulich wrote: > >> >> >>> On 29.03.17 at 03:36, wrote: > >> >> > On 17-03-29 09:20:21, Yi Sun wrote: >

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

On 17-03-31 17:12:36, Yi Sun wrote: > On 17-03-31 02:47:25, Jan Beulich wrote: > > >>> On 30.03.17 at 14:10, wrote: > > > On 17-03-30 05:55:52, Jan Beulich wrote: > > >> >>> On 30.03.17 at 03:37, wrote: > > >> > On 17-03-29 03:57:52, Jan Beulich wrote: > > >> >> >>> On 29.03.17 at 03:36, wrote:

Re: [Xen-devel] [PATCH v11 1/6] passthrough: don't migrate pirq when it is delivered through VT-d PI

>>> On 29.03.17 at 07:11, wrote: > @@ -442,17 +397,24 @@ int pt_irq_create_bind( > dest_vcpu_id = hvm_girq_dest_2_vcpu_id(d, dest, dest_mode); > pirq_dpci->gmsi.dest_vcpu_id = dest_vcpu_id; > spin_unlock(&d->event_lock); > + > +pirq_dpci->gmsi.posted = false; > +

Re: [Xen-devel] [PATCH] setup vwfi correctly on cpu0

Hi Stefano, On 03/30/2017 11:35 PM, Stefano Stabellini wrote: parse_vwfi runs after init_traps on cpu0, potentially resulting in the wrong HCR_EL2 for it. Secondary cpus boot after parse_vwfi, so in their case init_traps will write the correct set of flags to HCR_EL2. For cpu0, fix the issue by

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

Hello Sir, I am Ishani Chugh, a fourth year undergraduate student of Electronics and Communications Engineering at International Institute of Information Technology, Hyderabad. I am passionate about Open Source Development. I am interested to contribute to your organization Xen Project as an Ou

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

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

Re: [Xen-devel] [PATCH v11 1/6] passthrough: don't migrate pirq when it is delivered through VT-d PI

On Fri, Mar 31, 2017 at 03:31:47AM -0600, Jan Beulich wrote: On 29.03.17 at 07:11, wrote: >> @@ -442,17 +397,24 @@ int pt_irq_create_bind( >> dest_vcpu_id = hvm_girq_dest_2_vcpu_id(d, dest, dest_mode); >> pirq_dpci->gmsi.dest_vcpu_id = dest_vcpu_id; >> spin_unlock(&

Re: [Xen-devel] [PATCH v11 2/6] VT-d: Introduce new fields in msi_desc to track binding with guest interrupt

>>> On 29.03.17 at 07:11, wrote: > v11: > - Commit message changes. > - Add code to clear the two new fields introduced in this patch. The latter appears to contradict ... > --- a/xen/arch/x86/msi.c > +++ b/xen/arch/x86/msi.c > @@ -578,6 +578,7 @@ static struct msi_desc *alloc_msi_entry(unsigned

Re: [Xen-devel] [PATCH RFC] x86/emulate: implement hvmemul_cmpxchg() with an actual CMPXCHG

On 03/31/2017 10:34 AM, Jan Beulich wrote: On 31.03.17 at 08:17, wrote: >> On 03/30/2017 06:47 PM, Jan Beulich wrote: Speaking of emulated MMIO, I've got this when the guest was crashing immediately (pre RETRY loop): MMIO emulation failed: d3v8 32bit @ 0008:82679f3c -> f0

[Xen-devel] [qemu-mainline test] 107011: tolerable FAIL - PUSHED

flight 107011 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/107011/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106999 test-armhf-armhf-libvirt-r

Re: [Xen-devel] [PATCH v11 5/6] VT-d: introduce update_irte to update irte safely

>>> On 29.03.17 at 07:11, wrote: > We used structure assignment to update irte which was non-atomic when the > whole IRTE was to be updated. It is unsafe when a interrupt happened during > update. Furthermore, no bug or warning would be reported when this happened. > > This patch introduces two v

Re: [Xen-devel] [PATCH v11 1/6] passthrough: don't migrate pirq when it is delivered through VT-d PI

>>> On 31.03.17 at 04:42, wrote: > On Fri, Mar 31, 2017 at 03:31:47AM -0600, Jan Beulich wrote: > On 29.03.17 at 07:11, wrote: >>> @@ -442,17 +397,24 @@ int pt_irq_create_bind( >>> dest_vcpu_id = hvm_girq_dest_2_vcpu_id(d, dest, dest_mode); >>> pirq_dpci->gmsi.dest_vcpu_id =

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

On 03/30/2017 09:17 PM, Volodymyr Babchuk wrote: Hi Julien, Hi Volodymyr, On 30 March 2017 at 22:57, Julien Grall wrote: Hi Volodymyr On 30/03/2017 20:19, Volodymyr Babchuk wrote: On 30 March 2017 at 21:52, Stefano Stabellini wrote: On Thu, 30 Mar 2017, Volodymyr Babchuk wrote: And

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

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

[Xen-devel] [PATCH v2] 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 b

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

>>> On 31.03.17 at 11:12, wrote: > On 17-03-31 02:47:25, Jan Beulich wrote: >> >>> On 30.03.17 at 14:10, wrote: >> > On 17-03-30 05:55:52, Jan Beulich wrote: >> >> >>> On 30.03.17 at 03:37, wrote: >> >> > On 17-03-29 03:57:52, Jan Beulich wrote: >> >> >> >>> On 29.03.17 at 03:36, wrote: >> >> >

Re: [Xen-devel] [PATCH] xl: Add 'pvh' config option

On Thu, Mar 30, 2017 at 07:06:15PM -0400, Boris Ostrovsky wrote: > In addition to 'device_model_version="none"' config option users can > also use 'pvh=1' in xl configuration file when creating a PVH guest. I'm not sure, but I think the plan was to remove device_model_version="none" and instead ju

[Xen-devel] [For Xen-4.10 RFC PATCH 0/3] Reduce unnecessary icache maintenance operations

Hi, Although icache maintenance operations are required when changing page table mappings, in certain situations they are being called far more frequently than necessary. As icache maintenance has a performance penalty, one that increases with the number of cores in the system, this RFC attempts

[Xen-devel] [For Xen-4.10 RFC PATCH 3/3] Prevent redundant icache flushes in populate_physmap()

populate_physmap() calls alloc_heap_pages() per requested extent. As alloc_heap_pages() performs icache maintenance operations affecting the entire instruction cache, this leads to redundant cache flushes when allocating multiple extents in populate_physmap(). To alleviate this problem, introduce

[Xen-devel] [For Xen-4.10 RFC PATCH 2/3] arm: p2m: Prevent redundant icache flushes

When toolstack requests flushing the caches, flush_page_to_ram() is called for each page of the requested domain. This needs to unnecessary icache invalidation operations. Let's take the responsibility of performing icache operations and use the recently introduced flag to prevent redundant icache

[Xen-devel] [For Xen-4.10 RFC PATCH 1/3] Allow control of icache invalidations when calling flush_page_to_ram()

flush_page_to_ram() unconditionally drops the icache. In certain situations this leads to execessive icache flushes when flush_page_to_ram() ends up being repeatedly called in a loop. Introduce a parameter to allow callers of flush_page_to_ram() to take responsibility of synchronising the icache.

Re: [Xen-devel] [PATCH v11 1/6] passthrough: don't migrate pirq when it is delivered through VT-d PI

>>> On 31.03.17 at 01:10, wrote: > On Fri, Mar 31, 2017 at 01:28:02PM +0800, Tian, Kevin wrote: >>> From: Chao Gao >>> Sent: Wednesday, March 29, 2017 1:12 PM >>> --- a/xen/arch/x86/hvm/hvm.c >>> +++ b/xen/arch/x86/hvm/hvm.c >>> @@ -438,6 +438,9 @@ static int hvm_migrate_pirq(struct domain *d, str

Re: [Xen-devel] [PATCH v11 1/6] passthrough: don't migrate pirq when it is delivered through VT-d PI

On Fri, Mar 31, 2017 at 04:06:27AM -0600, Jan Beulich wrote: On 31.03.17 at 04:42, wrote: >> On Fri, Mar 31, 2017 at 03:31:47AM -0600, Jan Beulich wrote: >> On 29.03.17 at 07:11, wrote: @@ -442,17 +397,24 @@ int pt_irq_create_bind( dest_vcpu_id = hvm_girq_dest_2_vcpu_i

Re: [Xen-devel] [PATCH v11 1/6] passthrough: don't migrate pirq when it is delivered through VT-d PI

>>> On 31.03.17 at 05:27, wrote: > On Fri, Mar 31, 2017 at 04:06:27AM -0600, Jan Beulich wrote: > On 31.03.17 at 04:42, wrote: >>> On Fri, Mar 31, 2017 at 03:31:47AM -0600, Jan Beulich wrote: >>> On 29.03.17 at 07:11, wrote: > @@ -442,17 +397,24 @@ int pt_irq_create_bind( >

Re: [Xen-devel] Legacy PCI interrupt {de}assertion count

>>> On 31.03.17 at 10:07, wrote: > On Fri, Mar 31, 2017 at 05:05:44AM +, Tian, Kevin wrote: >> > From: Jan Beulich [mailto:jbeul...@suse.com] >> > Sent: Monday, March 27, 2017 4:00 PM >> > >> > >>> On 24.03.17 at 17:54, wrote: >> > > As I understand it, for level triggered legacy PCI interru

Re: [Xen-devel] Outreachy Project

Nazira, please check https://wiki.xenproject.org/wiki/2017-Summer-Internships and then https://wiki.xenproject.org/wiki/Outreach_Program_Projects , which contains a list of pos

Re: [Xen-devel] [PATCH] Enable compiling with gcc tracing

2017-03-30 17:46 GMT+02:00 Wei Liu : > Cool. I think Xen should boot with this. > > You've successfully finished what I asked for. Now you can divert your > energy to polish your application. :-) > > On Thu, Mar 30, 2017 at 05:39:56PM +0200, Felix Schmoll wrote: > > Make minimal adjustments in ord

Re: [Xen-devel] [PATCH v2 16/19] xen/arm: Introduce a helper to synchronize SError

Hi Julien, On 2017/3/31 2:38, Julien Grall wrote: > > > On 30/03/17 19:32, Julien Grall wrote: >> On 30/03/17 19:28, Julien Grall wrote: >>> Hi Wei, >>> >>> On 30/03/17 10:13, Wei Chen wrote: +void synchronize_serror(void) >>> >>> Sorry for been late in the party. Looking at the way you use t

Re: [Xen-devel] [PATCH v4 3/4] xenstore: rework of transaction handling

On Thu, Mar 30, 2017 at 06:41:11PM +0200, Juergen Gross wrote: [...] > > > >>node->generation = generation++; > >> - return; > >> + if (conn && !conn->transaction) > >> + wrl_apply_debit_direct(conn); > >> + } > >> + > >> + if (!conn || !conn->trans

Re: [Xen-devel] Outreachy project - Xen Code Review Dashboard

Hi, > On 31 Mar 2017, at 02:48, Vaishnavi Ramesh Jayaraman > wrote: > > Hi, > I am Vaishnavi, interested in contributing to the Xen Project as part of the > Outreachy Program. I am particularly interested in working on the Xen Code > Review Dashboard. > > I have worked on the ElasticSearch -

Re: [Xen-devel] [PATCH v4 3/4] xenstore: rework of transaction handling

On 31/03/17 13:00, Wei Liu wrote: > On Thu, Mar 30, 2017 at 06:41:11PM +0200, Juergen Gross wrote: > [...] >>> node->generation = generation++; - return; + if (conn && !conn->transaction) + wrl_apply_debit_direct(conn); + } >>>

Re: [Xen-devel] [PATCH v2 16/19] xen/arm: Introduce a helper to synchronize SError

On 31/03/17 11:55, Wei Chen wrote: Hi Julien, Hi Wei, On 2017/3/31 2:38, Julien Grall wrote: On 30/03/17 19:32, Julien Grall wrote: On 30/03/17 19:28, Julien Grall wrote: Hi Wei, On 30/03/17 10:13, Wei Chen wrote: +void synchronize_serror(void) Sorry for been late in the party. Loo

Re: [Xen-devel] [PATCH v2 16/19] xen/arm: Introduce a helper to synchronize SError

On 2017/3/31 19:06, Julien Grall wrote: > > > On 31/03/17 11:55, Wei Chen wrote: >> Hi Julien, > > Hi Wei, > >> On 2017/3/31 2:38, Julien Grall wrote: >>> >>> >>> On 30/03/17 19:32, Julien Grall wrote: On 30/03/17 19:28, Julien Grall wrote: > Hi Wei, > > On 30/03/17 10:13, Wei Chen

Re: [Xen-devel] [PATCH v3 8/9] tools/libxc: add support of injecting MC# to specified CPUs

On Thu, Mar 30, 2017 at 02:20:02PM +0800, Haozhong Zhang wrote: > Though XEN_MC_inject_v2 allows injecting MC# to specified CPUs, the > current xc_mca_op() does not use this feature and not provide an > interface to callers. This commit add a new xc_mca_op_inject_v2() that > receives a cpumap provi

Re: [Xen-devel] [PATCH v4] dm_op: Add xendevicemodel_modified_memory_bulk.

On Wed, Mar 29, 2017 at 05:03:04PM +, Jennifer Herbert wrote: > From: Jennifer Herbert > > This new lib devicemodel call allows multiple extents of pages to be > marked as modified in a single call. This is something needed for a > usecase I'm working on. > > The xen side of the modified_me

[Xen-devel] [PATCH 1/2] xen: correct error handling in xen-acpi-processor

Error handling in upload_pm_data() is rather questionable: possible errno values from called functions are or'ed together resulting in strange return values: -EINVAL and -ENOMEM would e.g. result in returning -EXDEV. Fix this by bailing out early after the first error. Cc: sta...@vger.kernel.org

[Xen-devel] [PATCH 0/2] xen: fix and cleanup of xen-acpi-processor

Juergen Gross (2): xen: correct error handling in xen-acpi-processor xen: make functions in xen-acpi-processor return void drivers/xen/xen-acpi-processor.c | 18 -- 1 file changed, 8 insertions(+), 10 deletions(-) -- 2.10.2 ___ X

[Xen-devel] [PATCH 2/2] xen: make functions in xen-acpi-processor return void

The return value of xen_copy_pct_data() is always 0 and never checked. xen_copy_psd_data() returns always 0, too, so checking the value is kind of pointless. Make the functions return void. Signed-off-by: Juergen Gross --- drivers/xen/xen-acpi-processor.c | 14 ++ 1 file changed, 6

Re: [Xen-devel] [PATCH] xl: Add 'pvh' config option

On Fri, Mar 31, 2017 at 11:23:04AM +0100, Roger Pau Monné wrote: > On Thu, Mar 30, 2017 at 07:06:15PM -0400, Boris Ostrovsky wrote: > > In addition to 'device_model_version="none"' config option users can > > also use 'pvh=1' in xl configuration file when creating a PVH guest. > > I'm not sure, bu

[Xen-devel] [PATCH v5 3/4] xenstore: rework of transaction handling

The handling of transactions in xenstored is rather clumsy today: - Each transaction in progress is keeping a local copy of the complete xenstore data base - A transaction will fail as soon as any node is being modified outside the transaction This is leading to a very bad behavior in case of

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

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

Re: [Xen-devel] [For Xen-4.10 RFC PATCH 3/3] Prevent redundant icache flushes in populate_physmap()

On Fri, Mar 31, 2017 at 11:24:24AM +0100, Punit Agrawal wrote: > populate_physmap() calls alloc_heap_pages() per requested extent. As > alloc_heap_pages() performs icache maintenance operations affecting the > entire instruction cache, this leads to redundant cache flushes when > allocating multipl

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

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

Re: [Xen-devel] [PATCH v5 3/4] xenstore: rework of transaction handling

Another stupid question below. On Fri, Mar 31, 2017 at 01:29:19PM +0200, Juergen Gross wrote: > > -struct changed_node > +/* > + * Some notes regarding detection and handling of transaction conflicts: > + * > + * Basic source of reference is the 'generation' count. Each writing access > + * (eit

Re: [Xen-devel] [PATCH v5 3/4] xenstore: rework of transaction handling

On 31/03/17 14:03, Wei Liu wrote: > Another stupid question below. > > On Fri, Mar 31, 2017 at 01:29:19PM +0200, Juergen Gross wrote: >> >> -struct changed_node >> +/* >> + * Some notes regarding detection and handling of transaction conflicts: >> + * >> + * Basic source of reference is the 'gen

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

On 17-03-31 04:19:49, Jan Beulich wrote: > >>> On 31.03.17 at 11:12, wrote: > > On 17-03-31 02:47:25, Jan Beulich wrote: > >> >>> On 30.03.17 at 14:10, wrote: > >> > On 17-03-30 05:55:52, Jan Beulich wrote: > >> >> >>> On 30.03.17 at 03:37, wrote: > >> >> > On 17-03-29 03:57:52, Jan Beulich wrot

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

>>> On 31.03.17 at 14:40, wrote: > On 17-03-31 04:19:49, Jan Beulich wrote: >> >>> On 31.03.17 at 11:12, wrote: >> > On 17-03-31 02:47:25, Jan Beulich wrote: >> >> >>> On 30.03.17 at 14:10, wrote: >> >> > I think you can check v9 codes here: >> >> > https://github.com/yisun-git/xen/tree/l2_cat_v

Re: [Xen-devel] [PATCH v5 3/4] xenstore: rework of transaction handling

On Fri, Mar 31, 2017 at 02:11:46PM +0200, Juergen Gross wrote: > On 31/03/17 14:03, Wei Liu wrote: > > Another stupid question below. > > > > On Fri, Mar 31, 2017 at 01:29:19PM +0200, Juergen Gross wrote: > >> > >> -struct changed_node > >> +/* > >> + * Some notes regarding detection and handlin

[Xen-devel] [PATCH v3 00/19] Provide a command line option to choose how to handle SErrors

From XSA-201, we know that, a guest could trigger SErrors when accessing memory mapped HW in a non-conventional way. In the patches for XSA-201, we crash the guest when we captured such asynchronous aborts to avoid data corruption. In order to distinguish guest-generated SErrors from hypervisor-ge

[Xen-devel] [PATCH v3 05/19] xen/arm: Save HCR_EL2 when a guest took the SError

The HCR_EL2.VSE (HCR.VA for aarch32) bit can be used to generate a virtual abort to guest. The HCR_EL2.VSE bit has a peculiar feature of getting cleared when the guest has taken the abort (this is the only bit that behaves as such in HCR_EL2 register). This means that if we set the HCR_EL2.VSE bit

[Xen-devel] [PATCH v3 04/19] xen/arm: Avoid setting/clearing HCR_RW at every context switch

The HCR_EL2 flags for 64-bit and 32-bit domains are different. But when we initialized the HCR_EL2 for vcpu0 of Dom0 and all vcpus of DomU in vcpu_initialise, we didn't know the domain's address size information. We had to use compatible flags to initialize HCR_EL2, and set HCR_RW for 64-bit domain

[Xen-devel] [PATCH v3 01/19] xen/arm: Save ESR_EL2 to avoid using mismatched value in syndrome check

Xen will do exception syndrome check while some types of exception take place in EL2. The syndrome check code read the ESR_EL2 register directly, but in some situation this register maybe overridden by nested exception. For example, if we re-enable IRQ before reading ESR_EL2 which means Xen may en

[Xen-devel] [PATCH v3 02/19] xen/arm: Introduce a helper to get default HCR_EL2 flags

We want to add HCR_EL2 register to Xen context switch. And each copy of HCR_EL2 in vcpu structure will be initialized with the same set of trap flags as the HCR_EL2 register. We introduce a helper here to represent these flags to be reused easily. Signed-off-by: Wei Chen --- xen/arch/arm/traps.c

[Xen-devel] [PATCH v3 03/19] xen/arm: Set and restore HCR_EL2 register for each vCPU separately

Different domains may have different HCR_EL2 flags. For example, the 64-bit domain needs HCR_RW flag but the 32-bit does not need it. So we give each domain a default HCR_EL2 value and save it in the vCPU's context. HCR_EL2 register has only one bit can be updated automatically without explicit wr

[Xen-devel] [PATCH v3 08/19] xen/arm: Introduce a initcall to update cpu_hwcaps by serror_op

In the later patches of this series, we want to use the alternative patching framework to avoid checking serror_op in every entries. So we define a new cpu feature "SKIP_CHECK_PENDING_VSERROR" for serror_op. When serror_op is not equal to SERROR_DIVERSE, this feature will be set to cpu_hwcaps. Cur

[Xen-devel] [PATCH v3 09/19] xen/arm64: Use alternative to skip the check of pending serrors

We have provided an option to administrator to determine how to handle the SErrors. In order to skip the check of pending SError, in conventional way, we have to read the option every time before we try to check the pending SError. This will add overhead to check the option at every trap. The ARM6

[Xen-devel] [PATCH v3 13/19] xen/arm: Replace do_trap_guest_serror with new helpers

We have introduced two helpers to handle the guest/hyp SErrors: do_trap_guest_serror and do_trap_guest_hyp_serror. These handlers can take the role of do_trap_guest_serror and reduce the assembly code in the same time. So we use these two helpers to replace it and drop it now. Signed-off-by: Wei C

[Xen-devel] [PATCH v3 11/19] xen/arm: Move macro VABORT_GEN_BY_GUEST to common header

We want to move part of SErrors checking code from hyp_error assembly code to a function. This new function will use this macro to distinguish the guest SErrors from hypervisor SErrors. So we have to move this macro to common header. The VABORT_GEN_BY_GUEST macro uses the symbols abort_guest_exit_

[Xen-devel] [PATCH v3 06/19] xen/arm: Introduce a virtual abort injection helper

When guest triggers async aborts, in most platform, such aborts will be routed to hypervisor. But we don't want the hypervisor to handle such aborts, so we have to route such aborts back to the guest. This helper is using the HCR_EL2.VSE (HCR.VA for aarch32) bit to route such aborts back to the gu

[Xen-devel] [PATCH v3 12/19] xen/arm: Introduce new helpers to handle guest/hyp SErrors

Currently, ARM32 and ARM64 has different SError exception handlers. These handlers include lots of code to check SError handle options and code to distinguish guest-generated SErrors from hypervisor SErrors. The new helpers: do_trap_guest_serror and do_trap_hyp_serror are wrappers of __do_trap_ser

[Xen-devel] [PATCH v3 07/19] xen/arm: Introduce a command line parameter for SErrors/Aborts

In order to distinguish guest-generated SErrors from hypervisor-generated SErrors we have to place SError checking code in every EL1 <-> EL2 paths. That will cause overhead on entries and exits due to dsb/isb. However, not all platforms want to categorize SErrors. For example, a host that is runni

[Xen-devel] [PATCH v3 14/19] xen/arm: Unmask the Abort/SError bit in the exception entries

Currently, we masked the Abort/SError bit in Xen exception entries. So Xen could not capture any Abort/SError while it's running. Now, Xen has the ability to handle the Abort/SError, we should unmask the Abort/SError bit by default to let Xen capture Abort/SError while it's running. But in order t

[Xen-devel] [PATCH v3 18/19] xen/arm: Prevent slipping hypervisor SError to guest

If there is a pending SError while we're returning from trap. If the SError handle option is "DIVERSE", we have to prevent slipping this hypervisor SError to guest. So we have to use the dsb/isb to guarantee that the pending hypervisor SError would be caught in hypervisor before return to guest. I

[Xen-devel] [PATCH v3 10/19] xen/arm32: Use alternative to skip the check of pending serrors

We have provided an option to administrator to determine how to handle the SErrors. In order to skip the check of pending SError, in conventional way, we have to read the option every time before we try to check the pending SError. This will add overhead to check the option at every trap. The ARM3

[Xen-devel] [PATCH v3 19/19] xen/arm: Handle guest external abort as guest SError

The guest generated external data/instruction aborts can be treated as guest SErrors. We already have a handler to handle the SErrors, so we can reuse this handler to handle guest external aborts. Signed-off-by: Wei Chen Reviewed-by: Stefano Stabellini --- xen/arch/arm/traps.c | 14 ++--

[Xen-devel] [PATCH v3 15/19] xen/arm: Introduce a helper to check local abort is enabled

In previous patch, we have umasked the Abort/SError bit for Xen in most of its running time. So in some use-cases, we have to check whether the abort is enabled in current context. For example, while we want to synchronize SErrors, we have to confirm the abort is enabled. Otherwise synchronize SErr

[Xen-devel] [PATCH v3 17/19] xen/arm: Isolate the SError between the context switch of 2 vCPUs

If there is a pending SError while we are doing context switch, if the SError handle option is "FORWARD", We have to guranatee this serror to be caught by current vCPU, otherwise it will be caught by next vCPU and be forwarded to this wrong vCPU. So we have to synchronize SError before switch to n

[Xen-devel] [PATCH v3 16/19] xen/arm: Introduce a macro to synchronize SError

In previous patches, we have provided the ability to synchronize SErrors in exception entries. But we haven't synchronized SErrors while returning to guest and doing context switch. So we still have two risks: 1. Slipping hypervisor SErrors to guest. For example, hypervisor triggers a SError wh

[Xen-devel] [xen-4.8-testing test] 107019: tolerable FAIL - PUSHED

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

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

On 17-03-31 06:51:07, Jan Beulich wrote: > >>> On 31.03.17 at 14:40, wrote: > > On 17-03-31 04:19:49, Jan Beulich wrote: > >> >>> On 31.03.17 at 11:12, wrote: > >> > On 17-03-31 02:47:25, Jan Beulich wrote: > >> >> >>> On 30.03.17 at 14:10, wrote: > >> >> > I think you can check v9 codes here: >

Re: [Xen-devel] [PATCH] xl: Add 'pvh' config option

On 03/31/2017 06:23 AM, Roger Pau Monné wrote: > On Thu, Mar 30, 2017 at 07:06:15PM -0400, Boris Ostrovsky wrote: >> In addition to 'device_model_version="none"' config option users can >> also use 'pvh=1' in xl configuration file when creating a PVH guest. > I'm not sure, but I think the plan was

  1   2   3   >