Re: [Xen-devel] [PATCH] tools/migrate: Prevent PTE truncation from being fatal duing the live phase

On Fri, Sep 02, 2016 at 09:30:03AM +0100, Wei Liu wrote: > On Thu, Sep 01, 2016 at 10:45:03AM +0100, Andrew Cooper wrote: > > It is possible, when normalising a PV pagetable that the table has been > > freed > > and reused for something else by the guest. > > > > In such a case, data read might

Re: [Xen-devel] [PATCH v3 10/38] arm/p2m: Move hostp2m init/teardown to individual functions

Hi Julien, On 09/01/2016 07:36 PM, Julien Grall wrote: > Hello Sergej, > > On 16/08/16 23:16, Sergej Proskurin wrote: >> --- >> xen/arch/arm/p2m.c| 71 >> +-- >> xen/include/asm-arm/p2m.h | 11 >> 2 files changed, 73 insertions(+), 9

Re: [Xen-devel] [PATCH v3 08/38] arm/p2m: Free p2m entries only in the hostp2m

Hi Julien, On 09/01/2016 07:08 PM, Julien Grall wrote: > Hello Sergej, > > On 16/08/16 23:16, Sergej Proskurin wrote: >> Freeing p2m entries of arbitrary p2m's (in particular in alternate >> p2m's) will lead to unpredicted behavior as the entries might still be >> used within the host's p2m. The

[Xen-devel] [PATCH] docs: document old SUSE/Novell unplug for HVM

Signed-off-by: Olaf Hering --- docs/misc/hvm-emulated-unplug.markdown | 24 1 file changed, 24 insertions(+) diff --git a/docs/misc/hvm-emulated-unplug.markdown b/docs/misc/hvm-emulated-unplug.markdown index c6d1f9b..70fb024 100644 ---

Re: [Xen-devel] [PATCH v2] stubdom: support Mini-OS config for Mini-OS apps

On Tue, Aug 30, 2016 at 04:53:39PM +0200, Juergen Gross wrote: > Mini-OS apps need to be compiled with the appropriate config settings > of Mini-OS, as there are various dependencies on those settings in > header files included by the apps. > > Enhance stubdom Makefile to set the appropriate

Re: [Xen-devel] [PATCH v3 4/6] Pause/Unpause the domain before/after assigning PI hooks

>>> On 02.09.16 at 10:40, wrote: > >> -Original Message- >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: Friday, September 2, 2016 4:16 PM >> To: Wu, Feng >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com; >>

[Xen-devel] [PATCH] xen/arm: smpboot: drop unneeded code when identifying cpuinfo

The current_cpu_data indicates the cpuinfo for the current cpu. There is no need to fill the current_cpu_data from boot_cpu_data, because the following call to identify_cpu will override it. Signed-off-by: Peng Fan Cc: Julien Grall Cc: Stefano Stabellini

Re: [Xen-devel] [PATCH v5 15/16] x86: make Xen early boot code relocatable

On Fri, Sep 02, 2016 at 12:58:14AM -0600, Jan Beulich wrote: > >>> On 01.09.16 at 23:19, wrote: > > On Thu, Sep 01, 2016 at 01:46:24AM -0600, Jan Beulich wrote: > >> >>> On 31.08.16 at 22:50, wrote: > >> > On Wed, Aug 31, 2016 at 09:46:31AM

[Xen-devel] [PATCH v2 0/2] Xen HVM unplug changes

Update unplug in Xen HVM guests to cover more cases. Please review. Olaf changes in v2: - fix issues reported by checkpatch Olaf Hering (2): xen_platform: unplug also SCSI disks xen_platform: SUSE xenlinux unplug for emulated PCI hw/i386/xen/xen_platform.c | 35

[Xen-devel] [PATCH v2 1/2] xen_platform: unplug also SCSI disks

Using 'vdev=sd[a-o]' will create an emulated LSI controller, which can be used by the emulated BIOS to boot from disk. If the HVM domU has also PV driver the disk may appear twice in the guest. To avoid this an unplug of the emulated hardware is needed, similar to what is done for IDE and NIC

[Xen-devel] [PATCH v2 2/2] xen_platform: SUSE xenlinux unplug for emulated PCI

Implement SUSE specific unplug protocol for emulated PCI devices in PVonHVM guests. Its a simple 'outl(1, (ioaddr + 4));'. This protocol was implemented and used since Xen 3.0.4. It is used in all SUSE/SLES/openSUSE releases up to SLES11SP3 and openSUSE 12.3. Signed-off-by: Olaf Hering

Re: [Xen-devel] [PATCH v5 14/16] public/hvm/params.h: Add macros for HVM_PARAM_CALLBACK_TYPE_PPI

On 2016/9/2 14:18, Jan Beulich wrote: On 02.09.16 at 04:55, wrote: >> --- a/xen/include/public/hvm/params.h >> +++ b/xen/include/public/hvm/params.h >> @@ -30,6 +30,7 @@ >> */ >> >> #define HVM_PARAM_CALLBACK_IRQ 0 >> +#define

[Xen-devel] [PATCH] x86emul: check alignment of SSE and AVX memory operands

It only now occurred to me that there's no new hook needed to do so. Eliminate the two work item comments. Signed-off-by: Jan Beulich --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -1419,6 +1419,25 @@ decode_segment(uint8_t

Re: [Xen-devel] [PATCH v5 15/16] x86: make Xen early boot code relocatable

>>> On 01.09.16 at 23:19, wrote: > On Thu, Sep 01, 2016 at 01:46:24AM -0600, Jan Beulich wrote: >> >>> On 31.08.16 at 22:50, wrote: >> > On Wed, Aug 31, 2016 at 09:46:31AM -0600, Jan Beulich wrote: >> >> >>> On 31.08.16 at 16:59,

Re: [Xen-devel] [PATCH 3/3] mini-os: support "make config" for out-of-tree users

Juergen Gross, on Fri 02 Sep 2016 07:42:36 +0200, wrote: > I think I'll add a new make target "test" which will test different > build configurations (PARAVIRT y/n, BALLOON y/n, 32/64 bit, Xen > interface versions, all/no frontends). This can be easily added to > OSStest. Good, thanks. Samuel

Re: [Xen-devel] [PATCH v3 4/6] Pause/Unpause the domain before/after assigning PI hooks

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Friday, September 2, 2016 3:04 PM > To: Wu, Feng > Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com; > george.dun...@eu.citrix.com; Tian, Kevin ; xen- >

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

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

Re: [Xen-devel] [PATCH v5 14/16] public/hvm/params.h: Add macros for HVM_PARAM_CALLBACK_TYPE_PPI

>>> On 02.09.16 at 04:55, wrote: > --- a/xen/include/public/hvm/params.h > +++ b/xen/include/public/hvm/params.h > @@ -30,6 +30,7 @@ > */ > > #define HVM_PARAM_CALLBACK_IRQ 0 > +#define HVM_PARAM_CALLBACK_IRQ_TYPE_SHIFT 56 This covering the top 8 bits, just the

Re: [Xen-devel] [PATCH v3 4/6] Pause/Unpause the domain before/after assigning PI hooks

>>> On 02.09.16 at 03:46, wrote: > >> -Original Message- >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: Thursday, September 1, 2016 4:30 PM >> To: Wu, Feng >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com; >>

Re: [Xen-devel] [PATCH v3 6/6] VMX: Fixup PI descritpor when cpu is offline

>>> On 02.09.16 at 05:25, wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: Thursday, September 1, 2016 4:49 PM >> >>> On 31.08.16 at 05:56, wrote: >> > +new_cpu = cpumask_any(_online_map); >> > +new_lock = _cpu(vmx_pi_blocking,

Re: [Xen-devel] [PATCH 1/2] x86/shadow: More consistent printing for debug messages

At 20:21 +0100 on 01 Sep (1472761306), Andrew Cooper wrote: > * Use %pv or just d%d in preference to the multiple current ways of >presenting the same information. > * Use PRI_mfn instead of opencoding it. > * Drop all explicit use of __func__ from SHADOW_{PRINTK,DEBUG}() calls. The >

Re: [Xen-devel] fail to register IRQ for virtualization exception

>>> On 02.09.16 at 04:59, wrote: > I'm recently trying to utilize the virtualization exception (#VE) feature. > As the document says, #VE is handled by guest interrupt handler. The IRQ > number of #VE is 20. However, when I tried to register an IRQ handler for > #VE, it

Re: [Xen-devel] [PATCH 2/2] xen/trace: Turn the stub debugtrace_{dump, printk}() macros into functions

On 02/09/16 08:57, Jan Beulich wrote: On 01.09.16 at 21:21, wrote: >> --- a/xen/include/xen/lib.h >> +++ b/xen/include/xen/lib.h >> @@ -68,8 +68,10 @@ extern void debugtrace_dump(void); >> extern void debugtrace_printk(const char *fmt, ...) >> __attribute__

Re: [Xen-devel] [PATCH 2/2] xen/trace: Turn the stub debugtrace_{dump, printk}() macros into functions

>>> On 02.09.16 at 12:00, wrote: > On 02/09/16 08:57, Jan Beulich wrote: > On 01.09.16 at 21:21, wrote: >>> --- a/xen/include/xen/lib.h >>> +++ b/xen/include/xen/lib.h >>> @@ -68,8 +68,10 @@ extern void debugtrace_dump(void); >>> extern

Re: [Xen-devel] [PATCH v3 02/38] arm/p2m: Expose p2m_*lock helpers

Hi Julien, On 09/01/2016 05:48 PM, Julien Grall wrote: > Hello Sergej, > > On 16/08/16 23:16, Sergej Proskurin wrote: >> This commit exposes the "p2m_*lock" helpers, as they will be used within >> the file ./xen/arch/arm/altp2m.c, as will be shown in the following >> commits. >> >>

Re: [Xen-devel] [PATCH v3 03/38] arm/p2m: Introduce p2m_(switch|restore)_vttbr_and_(g|s)et_flags

Hi Julien, On 09/02/2016 11:57 AM, Julien Grall wrote: > > > On 02/09/16 09:40, Sergej Proskurin wrote: >> Hi Julien, > > Hello Sergej, > >> On 09/01/2016 05:51 PM, Julien Grall wrote: >>> Hello Sergej, >>> >>> On 16/08/16 23:16, Sergej Proskurin wrote: This commit introduces macros for

Re: [Xen-devel] [PATCH] x86/levelling: Fix breakage on older Intel boxes from c/s 08e7738

>>> On 01.09.16 at 20:26, wrote: > I wonder whether a better fix might be to put an explicit (int) cast in > cpufeat_mask() to yield an signed constant? That's an option, but will make us use implementation defined behavior (due to the unsigned -> signed conversion of

Re: [Xen-devel] [PATCH v3 04/38] arm/p2m: Add first altp2m HVMOP stubs

Hi Julien, On 09/02/2016 12:12 PM, Julien Grall wrote: > > > On 02/09/16 10:26, Sergej Proskurin wrote: >> Hi Julien, > > Hello Sergej, > >> On 09/01/2016 06:09 PM, Julien Grall wrote: >>> Hello Sergej, >>> >>> On 16/08/16 23:16, Sergej Proskurin wrote: This commit moves the

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

>>> On 02.09.16 at 12:02, wrote: On 02.09.16 at 10:51, wrote: >> @@ -320,6 +321,23 @@ int compat_memory_op(unsigned int cmd, >> XEN_GUEST_HANDLE_PARAM(void) compat) >> break; >> } >> >> +case XENMEM_access_op: >>

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

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

Re: [Xen-devel] [PATCH v3 4/6] Pause/Unpause the domain before/after assigning PI hooks

>>> On 02.09.16 at 12:30, wrote: > >> -Original Message- >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: Friday, September 2, 2016 5:26 PM >> To: Wu, Feng >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com; >>

Re: [Xen-devel] [PATCH v3] xen: credit1: fix a race when picking initial pCPU for a vCPU

On 19/08/16 17:26, Dario Faggioli wrote: > In the Credit1 hunk of 9f358ddd69463 ("xen: Have > schedulers revise initial placement") csched_cpu_pick() > is called without taking the runqueue lock of the > (temporary) pCPU that the vCPU has been assigned to > (e.g., in XEN_DOMCTL_max_vcpus). > >

Re: [Xen-devel] [PATCH] tools/migrate: Prevent PTE truncation from being fatal duing the live phase

Wei Liu writes ("Re: [PATCH] tools/migrate: Prevent PTE truncation from being fatal duing the live phase"): > Ian, please backport this to Xen 4.6 and 4.7. Queued, thanks. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org

Re: [Xen-devel] [PATCH] libxl: fix libxl_device_usbdev_list()

Wei Liu writes ("Re: [PATCH] libxl: fix libxl_device_usbdev_list()"): > Pushed. Backport to 4.7 is required. Queued, thanks. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

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

flight 100720 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/100720/ 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

[Xen-devel] [PATCH v6 1/4] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

A new HVMOP - HVMOP_map_mem_type_to_ioreq_server, is added to let one ioreq server claim/disclaim its responsibility for the handling of guest pages with p2m type p2m_ioreq_server. Users of this HVMOP can specify which kind of operation is supposed to be emulated in a parameter named flags.

Re: [Xen-devel] [PATCH] tools: delete gtraceview and gtracestat

On 30/08/16 13:50, Ian Jackson wrote: > Wei Liu writes ("[PATCH] tools: delete gtraceview and gtracestat"): >> There has not been any substantial update to them since 2011. My quick >> check shows that they don't work. >> >> Just delete them. It would be easy to resurrect them from git log should

Re: [Xen-devel] [PATCH v5 4/4] x86/ioreq server: Reset outstanding p2m_ioreq_server entries when an ioreq server unmaps.

On 8/30/2016 8:17 PM, Yu Zhang wrote: On 8/16/2016 9:35 PM, George Dunlap wrote: On 12/07/16 10:02, Yu Zhang wrote: This patch resets p2m_ioreq_server entries back to p2m_ram_rw, after an ioreq server has unmapped. The resync is done both asynchronously with the current

[Xen-devel] xen arm64 dom0 question

Hi Julien, Stefano On My ARM64 platform, there is 6GB memory. 0x8000 - 0xfff: 2GB 0x88000 - 0x9: 4GB xen will alloc 1:1 mapping for Dom0 memory, so if I assign dom0_mem with a bigger value, saying 2048MB or bigger. xen will alloc continus memory from higher address space

Re: [Xen-devel] [PATCH] xen/pciback: support driver_override

nce) to record what (public, well-known) commit your patch series was built on] [Check https://git-scm.com/docs/git-format-patch for more information] url: https://github.com/0day-ci/linux/commits/Juergen-Gross/xen-pciback-support-driver_override/20160902-195956 base: https://git.kernel.org/

Re: [Xen-devel] [PATCH 19/24] xen: credit2: soft-affinity awareness in load balancing

On 17/08/16 18:19, Dario Faggioli wrote: We want is soft-affinity to play a role in load balancing, i.e., when deciding whether or not to something like that at some point. (Oh, and while there, just a couple of style fixes are also done.) Signed-off-by: Dario Faggioli

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

>>> On 02.09.16 at 13:18, wrote: > On 09/02/2016 01:02 PM, Jan Beulich wrote: > On 02.09.16 at 10:51, wrote: >>> Changes since V1 / RFC: >>> - Renamed xc_set_mem_access_sparse() to xc_set_mem_access_multi(), >>>and

[Xen-devel] [PATCH 1/5] xen: add tainted state and show warning is gcov is enabled

Signed-off-by: Wei Liu --- The location of warning_add() is a bit arbitrary because gcov doesn't have an initialisation routine. Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan

[Xen-devel] [PATCH 0/5] gcov: more cleanup

This series further cleans up existing gcov code. It should be now clear that Xen's gcov is using gcc 3.4 format. I have tried to integrate gcc 4.7 format. The amount of work is moderate in terms of coding effort, but I now believe it is a mistake to have invented xen specific format which is in

[Xen-devel] [PATCH 5/5] gcov: split out gcc version specific stuff

Gcov record format is tied to specific gcc versions. The current code in tree conforms to gcc 3.4 format. Move structure definitions to a specific file and factor out some version specific functions. No functional change. Signed-off-by: Wei Liu --- Cc: Andrew Cooper

[Xen-devel] [PATCH 3/5] xen: replace TEST_COVERAGE with CONFIG_GCOV

The sole purpose of TEST_COVERAGE macro is to guard the availability of gcov sysctl. Now we have a proper CONFIG_GCOV, use it. Signed-off-by: Wei Liu --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson

[Xen-devel] [PATCH 4/5] gcov: add option to determine gcov format

Currently only gcc 3.4 format is supported. Signed-off-by: Wei Liu --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk

[Xen-devel] [PATCH] xen/pciback: support driver_override

Support the driver_override scheme introduced with commit 782a985d7af2 ("PCI: Introduce new device binding path using pci_dev.driver_override") As pcistub_probe() is called for all devices (it has to check for a match based on the slot address rather than device type) it has to check for

Re: [Xen-devel] [PATCH 1/5] xen: add tainted state and show warning is gcov is enabled

>>> On 02.09.16 at 13:47, wrote: Since this is a config option - why bother issuing a warning and tainting the hypervisor? > --- a/xen/common/gcov/gcov.c > +++ b/xen/common/gcov/gcov.c > @@ -23,6 +23,11 @@ > #include > #include > > +const char __initconst

Re: [Xen-devel] [PATCH 2/5] gcov: collect more sections to constructor list

>>> On 02.09.16 at 13:47, wrote: > --- a/xen/arch/x86/xen.lds.S > +++ b/xen/arch/x86/xen.lds.S > @@ -205,6 +205,8 @@ SECTIONS > . = ALIGN(8); > __ctors_start = .; > *(.ctors) > + *(SORT(.init_array.*)) > + *(.init_array) >

Re: [Xen-devel] [PATCH 3/5] xen: replace TEST_COVERAGE with CONFIG_GCOV

>>> On 02.09.16 at 13:47, wrote: > The sole purpose of TEST_COVERAGE macro is to guard the availability of > gcov sysctl. Now we have a proper CONFIG_GCOV, use it. > > Signed-off-by: Wei Liu Acked-by: Jan Beulich

Re: [Xen-devel] [PATCH 1/5] xen: add tainted state and show warning is gcov is enabled

On Fri, Sep 02, 2016 at 05:56:49AM -0600, Jan Beulich wrote: > >>> On 02.09.16 at 13:47, wrote: > > Since this is a config option - why bother issuing a warning and > tainting the hypervisor? > Because there isn't a clear indicator if gcov is enabled. I think it would be

Re: [Xen-devel] [PATCH 4/5] gcov: add option to determine gcov format

>>> On 02.09.16 at 13:47, wrote: > Currently only gcc 3.4 format is supported. Doesn't this patch contradict your coverage letter? Here you provide means to add support for further formats, but there you said there's no obvious route to that goal. Jan

Re: [Xen-devel] [PATCH 0/5] gcov: more cleanup

On 02/09/16 12:47, Wei Liu wrote: > This series further cleans up existing gcov code. It should be now clear that > Xen's gcov is using gcc 3.4 format. > > I have tried to integrate gcc 4.7 format. The amount of work is moderate in > terms of coding effort, but I now believe it is a mistake to

Re: [Xen-devel] [PATCH 0/5] gcov: more cleanup

On Fri, Sep 02, 2016 at 01:04:45PM +0100, Andrew Cooper wrote: > On 02/09/16 12:47, Wei Liu wrote: > > This series further cleans up existing gcov code. It should be now clear > > that > > Xen's gcov is using gcc 3.4 format. > > > > I have tried to integrate gcc 4.7 format. The amount of work is

Re: [Xen-devel] [PATCH 1/5] xen: add tainted state and show warning is gcov is enabled

>>> On 02.09.16 at 14:01, wrote: > On Fri, Sep 02, 2016 at 05:56:49AM -0600, Jan Beulich wrote: >> >>> On 02.09.16 at 13:47, wrote: >> >> Since this is a config option - why bother issuing a warning and >> tainting the hypervisor? >> > > Because there

Re: [Xen-devel] [PATCH 4/5] gcov: add option to determine gcov format

On Fri, Sep 02, 2016 at 06:01:22AM -0600, Jan Beulich wrote: > >>> On 02.09.16 at 13:47, wrote: > > Currently only gcc 3.4 format is supported. > > Doesn't this patch contradict your coverage letter? Here you provide > means to add support for further formats, but there you

Re: [Xen-devel] [PATCH 2/5] gcov: collect more sections to constructor list

On Fri, Sep 02, 2016 at 05:58:43AM -0600, Jan Beulich wrote: > >>> On 02.09.16 at 13:47, wrote: > > --- a/xen/arch/x86/xen.lds.S > > +++ b/xen/arch/x86/xen.lds.S > > @@ -205,6 +205,8 @@ SECTIONS > > . = ALIGN(8); > > __ctors_start = .; > > *(.ctors) >

Re: [Xen-devel] [PATCH 1/5] xen: add tainted state and show warning is gcov is enabled

On 02/09/16 13:06, Jan Beulich wrote: On 02.09.16 at 14:01, wrote: >> On Fri, Sep 02, 2016 at 05:56:49AM -0600, Jan Beulich wrote: >> On 02.09.16 at 13:47, wrote: >>> Since this is a config option - why bother issuing a warning and >>> tainting

Re: [Xen-devel] [PATCH 0/5] gcov: more cleanup

On 02/09/16 13:06, Wei Liu wrote: > On Fri, Sep 02, 2016 at 01:04:45PM +0100, Andrew Cooper wrote: >> On 02/09/16 12:47, Wei Liu wrote: >>> This series further cleans up existing gcov code. It should be now clear >>> that >>> Xen's gcov is using gcc 3.4 format. >>> >>> I have tried to integrate

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

On 09/02/2016 01:02 PM, Jan Beulich wrote: >> +/* >> > + * Corresponding list of access settings for pfn_list >> > + * Used only with XENMEM_access_op_set_access_multi >> > + */ >> > +XEN_GUEST_HANDLE(uint8) access_list; > And for both of them - I don't think the arrays are

Re: [Xen-devel] [PATCH v3 03/38] arm/p2m: Introduce p2m_(switch|restore)_vttbr_and_(g|s)et_flags

On 02/09/16 09:40, Sergej Proskurin wrote: > Hi Julien, Hello Sergej, > On 09/01/2016 05:51 PM, Julien Grall wrote: >> Hello Sergej, >> >> On 16/08/16 23:16, Sergej Proskurin wrote: >>> This commit introduces macros for switching and restoring the vttbr >>> considering the currently set irq

Re: [Xen-devel] [PATCH v3 04/38] arm/p2m: Add first altp2m HVMOP stubs

On 02/09/16 10:26, Sergej Proskurin wrote: Hi Julien, Hello Sergej, On 09/01/2016 06:09 PM, Julien Grall wrote: Hello Sergej, On 16/08/16 23:16, Sergej Proskurin wrote: This commit moves the altp2m-related code from x86 to ARM. Functions s/moves/copies/ However, this is not really

[Xen-devel] [PATCH 0/2] x86/HVM: feature checking improvements

1: VMX: correct feature checks for MPX and XSAVES 2: x86/HVM: adjust feature checking in MSR intercept handling Signed-off-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 02/38] arm/p2m: Expose p2m_*lock helpers

On 02/09/16 11:12, Sergej Proskurin wrote: > Hi Julien, Hello Sergej, > On 09/01/2016 05:48 PM, Julien Grall wrote: >> Hello Sergej, >> >> On 16/08/16 23:16, Sergej Proskurin wrote: >>> This commit exposes the "p2m_*lock" helpers, as they will be used within >>> the file ./xen/arch/arm/altp2m.c,

[Xen-devel] [PATCH 1/2] VMX: correct feature checks for MPX and XSAVES

Their VMCS fields aren't tied to the respective base CPU feature flags but instead to VMX specific ones. Note that while the VMCS GUEST_BNDCFGS field exists if either of the two respective features is available, MPX continues to get exposed to guests only with both features present. Also add the

Re: [Xen-devel] [PATCH v3 02/38] arm/p2m: Expose p2m_*lock helpers

Hi Julien, On 09/02/2016 12:15 PM, Julien Grall wrote: > On 02/09/16 11:12, Sergej Proskurin wrote: >> Hi Julien, > > Hello Sergej, > >> On 09/01/2016 05:48 PM, Julien Grall wrote: >>> Hello Sergej, >>> >>> On 16/08/16 23:16, Sergej Proskurin wrote: This commit exposes the "p2m_*lock"

Re: [Xen-devel] [PATCH v3 4/6] Pause/Unpause the domain before/after assigning PI hooks

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Friday, September 2, 2016 5:26 PM > To: Wu, Feng > Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com; > george.dun...@eu.citrix.com; Tian, Kevin ; xen- >

Re: [Xen-devel] [PATCH] x86: correct PT_NOTE file position

On 24/08/16 21:45, Konrad Rzeszutek Wilk wrote: > On Wed, Aug 24, 2016 at 09:24:38AM -0600, Jan Beulich wrote: >> Program and section headers disagreed about the file offset at which >> the build ID note lives. > Gosh. That was an oversight. >> Reported-by: Sylvain Munaut

Re: [Xen-devel] [PATCH v3 10/38] arm/p2m: Move hostp2m init/teardown to individual functions

On 02/09/16 10:09, Sergej Proskurin wrote: Hi Julien, On 09/01/2016 07:36 PM, Julien Grall wrote: Hello Sergej, On 16/08/16 23:16, Sergej Proskurin wrote: --- xen/arch/arm/p2m.c| 71 +-- xen/include/asm-arm/p2m.h | 11 2 files

Re: [Xen-devel] [PATCH] x86/mm: drop pointless use of __FUNCTION__

On Wed, Aug 24, 2016 at 9:01 AM, Jan Beulich wrote: > Non-debugging message text should be (and is here) distinguishable > without also logging function names. > > Signed-off-by: Jan Beulich Acked-by: George Dunlap > > ---

Re: [Xen-devel] [PATCH] libxl: fix libxl_device_usbdev_list()

Juergen Gross writes ("[PATCH] libxl: fix libxl_device_usbdev_list()"): > Commit 03814de1d2ecdabedabceb8e728d934a632a43b9 ("libxl: Do not trust > frontend for vusb") introduced an error in libxl_device_usbdev_list(). > Fix it. > > Signed-off-by: Juergen Gross Oops, sorry!

[Xen-devel] [PATCH v6 3/4] x86/ioreq server: Handle read-modify-write cases for p2m_ioreq_server pages.

In ept_handle_violation(), write violations are also treated as read violations. And when a VM is accessing a write-protected address with read-modify-write instructions, the read emulation process is triggered first. For p2m_ioreq_server pages, current ioreq server only forwards the write

[Xen-devel] [PATCH v6 4/4] x86/ioreq server: Reset outstanding p2m_ioreq_server entries when an ioreq server unmaps.

This patch resets p2m_ioreq_server entries back to p2m_ram_rw, after an ioreq server has unmapped. The resync is done both asynchronously with the current p2m_change_entry_type_global() interface, and synchronously by iterating the p2m table. The synchronous resetting is necessary because we need

[Xen-devel] [PATCH v6 0/4] x86/ioreq server: Introduce HVMMEM_ioreq_server mem type.

XenGT leverages ioreq server to track and forward the accesses to GPU I/O resources, e.g. the PPGTT(per-process graphic translation tables). Currently, ioreq server uses rangeset to track the BDF/ PIO/MMIO ranges to be emulated. To select an ioreq server, the rangeset is searched to see if the

[Xen-devel] [PATCH v6 2/4] x86/ioreq server: Release the p2m lock after mmio is handled.

Routine hvmemul_do_io() may need to peek the p2m type of a gfn to select the ioreq server. For example, operations on gfns with p2m_ioreq_server type will be delivered to a corresponding ioreq server, and this requires that the p2m type not be switched back to p2m_ram_rw during the emulation

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

On 09/02/2016 01:02 PM, Jan Beulich wrote: On 02.09.16 at 10:51, wrote: >> Changes since V1 / RFC: >> - Renamed xc_set_mem_access_sparse() to xc_set_mem_access_multi(), >>and XENMEM_access_op_set_access_sparse to >>XENMEM_access_op_set_access_multi. >> -

Re: [Xen-devel] [PATCH] tools: delete gtraceview and gtracestat

On Fri, Sep 02, 2016 at 12:13:04PM +0100, George Dunlap wrote: > On 02/09/16 12:07, Wei Liu wrote: > > On Fri, Sep 02, 2016 at 12:05:49PM +0100, George Dunlap wrote: > >> On 30/08/16 13:50, Ian Jackson wrote: > >>> Wei Liu writes ("[PATCH] tools: delete gtraceview and gtracestat"): > There

Re: [Xen-devel] [PATCH] memory: fix compat handling of XENMEM_access_op

On 30/08/16 10:15, Jan Beulich wrote: > Within compat_memory_op() this needs to be placed in the first switch() > statement, or it ends up being dead code (as that first switch() has a > default case chaining to compat_arch_memory_op()). > > Signed-off-by: Jan Beulich

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

>>> On 02.09.16 at 10:51, wrote: > Changes since V1 / RFC: > - Renamed xc_set_mem_access_sparse() to xc_set_mem_access_multi(), >and XENMEM_access_op_set_access_sparse to >XENMEM_access_op_set_access_multi. > - Renamed the 'nr' parameter to 'size'. Why? > -

Re: [Xen-devel] qemu-2.7 regression, IPXE boot in HVM fails

On Wed, Aug 31, Olaf Hering wrote: > The following HVM domU.cfg crashes during boot from emulated network > with qemu 2.7, but it works fine with qemu stable-2.6 branch: > > name='hvm' > memory=1024 > vcpus=2 > boot="n" > disk=[ 'file:/disk0.raw,hda,w', ] > vif=[

[Xen-devel] [PATCH 2/2] x86/HVM: adjust feature checking in MSR intercept handling

Consistently consult hvm_cpuid(). With that, BNDCFGS gets better handled outside of VMX specific code, just like XSS. Don't needlessly check for MTRR support when the MSR being accessed clearly is not an MTRR one. Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/hvm.c +++

Re: [Xen-devel] [PATCH] tools: delete gtraceview and gtracestat

On Fri, Sep 02, 2016 at 12:05:49PM +0100, George Dunlap wrote: > On 30/08/16 13:50, Ian Jackson wrote: > > Wei Liu writes ("[PATCH] tools: delete gtraceview and gtracestat"): > >> There has not been any substantial update to them since 2011. My quick > >> check shows that they don't work. > >> >

Re: [Xen-devel] [PATCH] tools: delete gtraceview and gtracestat

On 02/09/16 12:07, Wei Liu wrote: > On Fri, Sep 02, 2016 at 12:05:49PM +0100, George Dunlap wrote: >> On 30/08/16 13:50, Ian Jackson wrote: >>> Wei Liu writes ("[PATCH] tools: delete gtraceview and gtracestat"): There has not been any substantial update to them since 2011. My quick check

Re: [Xen-devel] [PATCH] x86/PV: make PMU MSR handling consistent

On 29/08/16 17:07, Boris Ostrovsky wrote: > On 08/29/2016 11:37 AM, Jan Beulich wrote: >> So far accesses to Intel MSRs on an AMD system fall through to the >> default case, while accesses to AMD MSRs on an Intel system bail (in >> the RDMSR case without updating EAX and EDX). Make the "AMD MSRs

Re: [Xen-devel] [PATCH] x86emul: check alignment of SSE and AVX memory operands

On 02/09/16 08:49, Jan Beulich wrote: > It only now occurred to me that there's no new hook needed to do so. > Eliminate the two work item comments. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper

Re: [Xen-devel] [PATCH] tools: delete gtraceview and gtracestat

Wei Liu writes ("Re: [PATCH] tools: delete gtraceview and gtracestat"): > On Fri, Sep 02, 2016 at 12:13:04PM +0100, George Dunlap wrote: > > If so, it's probably just the case that the trace record format has > > changed somewhat and these weren't updated. It would probably be fairly > >

<    1   2