Re: [Xen-devel] [PATCH] VMX: sync CPU state upon vCPU destruction

On 09/11/17 14:49, Jan Beulich wrote: > See the code comment being added for why we need this. > > Reported-by: Igor Druzhinin <igor.druzhi...@citrix.com> > Signed-off-by: Jan Beulich <jbeul...@suse.com> > > --- a/xen/arch/x86/hvm/vmx/vmx.c > +++ b/xen/arch/x86/

Re: [Xen-devel] Ping: [PATCH] VMX: sync CPU state upon vCPU destruction

On 21/11/17 15:29, Jan Beulich wrote: >>>> On 21.11.17 at 15:07, <igor.druzhi...@citrix.com> wrote: >> On 21/11/17 13:22, Jan Beulich wrote: >>>>>> On 09.11.17 at 15:49, <jbeul...@suse.com> wrote: >>>> See the code comment being added

Re: [Xen-devel] Ping: [PATCH] VMX: sync CPU state upon vCPU destruction

On 21/11/17 13:22, Jan Beulich wrote: >>>> On 09.11.17 at 15:49, <jbeul...@suse.com> wrote: >> See the code comment being added for why we need this. >> >> Reported-by: Igor Druzhinin <igor.druzhi...@citrix.com> >> Signed-off-by: Jan Beulich <jbeu

Re: [Xen-devel] [PATCH] VMX: sync CPU state upon vCPU destruction

On 10/11/17 10:30, Jan Beulich wrote: On 10.11.17 at 09:41, wrote: >> On Thu, 2017-11-09 at 07:49 -0700, Jan Beulich wrote: >>> --- a/xen/arch/x86/hvm/vmx/vmx.c >>> +++ b/xen/arch/x86/hvm/vmx/vmx.c >>> @@ -479,7 +479,13 @@ static void vmx_vcpu_destroy(struct vcpu

Re: [Xen-devel] [PATCH v2 1/2] VMX: fix VMCS race on context-switch paths

On 07/11/17 14:55, Jan Beulich wrote: On 07.11.17 at 15:24, wrote: >> On 07/11/17 08:07, Jan Beulich wrote: >>> --- unstable.orig/xen/arch/x86/domain.c >>> +++ unstable/xen/arch/x86/domain.c >>> @@ -379,6 +379,14 @@ int vcpu_initialise(struct vcpu *v) >>> >>>

Re: [Xen-devel] [PATCH v2 1/2] VMX: fix VMCS race on context-switch paths

On 07/11/17 08:07, Jan Beulich wrote: On 02.11.17 at 20:46, wrote: >>> Any ideas about the root cause of the fault and suggestions how to >>> reproduce it >>> would be welcome. Does this crash really has something to do with PML? I >>> doubt >>> because the

Re: [Xen-devel] [PATCH v2 1/2] VMX: fix VMCS race on context-switch paths

On 27/10/17 18:42, Igor Druzhinin wrote: > On 16/02/17 11:15, Jan Beulich wrote: >> When __context_switch() is being bypassed during original context >> switch handling, the vCPU "owning" the VMCS partially loses control of >> it: It will appear non-running to remot

Re: [Xen-devel] [PATCH v2 1/2] VMX: fix VMCS race on context-switch paths

On 16/02/17 11:15, Jan Beulich wrote: > When __context_switch() is being bypassed during original context > switch handling, the vCPU "owning" the VMCS partially loses control of > it: It will appear non-running to remote CPUs, and hence their attempt > to pause the owning vCPU will have no effect

[Xen-devel] [PATCH v5] hvmloader, libxl: use the correct ACPI settings depending on device model

compatibility fixes are in place. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> Reviewed-by: Paul Durrant <paul.durr...@citrix.com> --- Changes in v5: * various refinements Changes in v4: * Use V1 port location unconditionally as modern versions of Qemu-trad use it any

Re: [Xen-devel] [PATCH v4] hvmloader, libxl: use the correct ACPI settings depending on device model

On 30/08/17 08:21, Roger Pau Monné wrote: > On Tue, Aug 29, 2017 at 05:29:53PM +0100, Igor Druzhinin wrote: >> We need to choose ACPI tables properly depending on the device >> model version we are running. Previously, this decision was >> made by BIOS type specific code in h

[Xen-devel] [PATCH v4] hvmloader, libxl: use the correct ACPI settings depending on device model

compatibility fixes are in place. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> Reviewed-by: Paul Durrant <paul.durr...@citrix.com> --- Changes in v4: * Use V1 port location unconditionally as modern versions of Qemu-trad use it anyway * Change confusing comments in iore

Re: [Xen-devel] [PATCH] acpi: set correct address of the control/event blocks in the FADT

ol/event blocks to >>> acpi_build_tables, so the values can be properly set in the FADT >>> table provided to the guest. >>> >>> Signed-off-by: Roger Pau Monné <roger@citrix.com> >>> --- >>> Cc: Igor Druzhinin <igor.druzhi...@citrix.com&

Re: [Xen-devel] [PATCH] acpi: set correct address of the control/event blocks in the FADT

On 29/08/17 14:51, Wei Liu wrote: > On Tue, Aug 29, 2017 at 02:37:50PM +0100, Igor Druzhinin wrote: >> On 29/08/17 14:33, Wei Liu wrote: >>> On Tue, Aug 29, 2017 at 02:24:49PM +0100, Andrew Cooper wrote: >>>> On 29/08/17 09:50, Roger Pau Monne wrote: >>>

Re: [Xen-devel] [PATCH] acpi: set correct address of the control/event blocks in the FADT

t;> acpi_build_tables, so the values can be properly set in the FADT >>> table provided to the guest. >>> >>> Signed-off-by: Roger Pau Monné <roger@citrix.com> >>> --- >>> Cc: Igor Druzhinin <igor.druzhi...@citrix.com> >>> Cc

[Xen-devel] [PATCH v3] hvmloader, libxl: use the correct ACPI settings depending on device model

when the rest of ROMBIOS compatibility fixes are in place. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> Reviewed-by: Paul Durrant <paul.durr...@citrix.com> --- Changes in v3: * move ACPI table externs into util.h Changes in v2: * fix insufficient allocation size of localen

Re: [Xen-devel] [PATCH v2] hvmloader, libxl: use the correct ACPI settings depending on device model

On 26/07/17 14:30, Roger Pau Monné wrote: > On Wed, Jul 26, 2017 at 02:21:49PM +0100, Igor Druzhinin wrote: >> On 26/07/17 14:06, Roger Pau Monné wrote: >>> On Wed, Jul 26, 2017 at 11:56:55AM +0100, Igor Druzhinin wrote: >>>> On 26/07/17 08:31, Roger Pau Monné wro

Re: [Xen-devel] [PATCH v2] hvmloader, libxl: use the correct ACPI settings depending on device model

On 26/07/17 14:06, Roger Pau Monné wrote: > On Wed, Jul 26, 2017 at 11:56:55AM +0100, Igor Druzhinin wrote: >> On 26/07/17 08:31, Roger Pau Monné wrote: >>> On Tue, Jul 25, 2017 at 08:55:30PM +0100, Igor Druzhinin wrote: >>>> We need to choose ACPI tables and ACPI

Re: [Xen-devel] [PATCH v2] hvmloader, libxl: use the correct ACPI settings depending on device model

On 26/07/17 08:31, Roger Pau Monné wrote: > On Tue, Jul 25, 2017 at 08:55:30PM +0100, Igor Druzhinin wrote: >> We need to choose ACPI tables and ACPI IO port location >> properly depending on the device model version we are running. >> Previously, this decision was made

[Xen-devel] [PATCH v2] hvmloader, libxl: use the correct ACPI settings depending on device model

tables if it's SeaBIOS. This change saves this behavior but adds an additional way (xenstore key) to specify the correct device model if we happen to run a non-default one. Toolstack bit makes use of it. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> Reviewed-by: Paul Durrant <

Re: [Xen-devel] [Bug] Intel RMRR support with upstream Qemu

On 25/07/17 17:40, Alexey G wrote: > On Mon, 24 Jul 2017 21:39:08 +0100 > Igor Druzhinin <igor.druzhi...@citrix.com> wrote: >>> But, the problem is that overall MMIO hole(s) requirements are not known >>> exactly at the time the HVM domain being created. Some PCI devi

Re: [Xen-devel] [PATCH] hvmloader, libxl: use the correct ACPI settings depending on device model

On 25/07/17 15:33, Wei Liu wrote: > On Wed, Jul 19, 2017 at 10:19:35PM +0100, Igor Druzhinin wrote: >> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c >> index 1158303..8dc8186 100644 >> --- a/tools/libxl/libxl_create.c >> +++ b/tools/libxl/libxl_c

Re: [Xen-devel] [Bug] Intel RMRR support with upstream Qemu

On 25/07/17 08:03, Zhang, Xiong Y wrote: >> On 24/07/17 17:42, Alexey G wrote: >>> Hi, >>> >>> On Mon, 24 Jul 2017 10:53:16 +0100 >>> Igor Druzhinin <igor.druzhi...@citrix.com> wrote: >>>>> [Zhang, Xiong Y] Thanks for your suggestion

Re: [Xen-devel] [Bug] Intel RMRR support with upstream Qemu

On 24/07/17 17:42, Alexey G wrote: > Hi, > > On Mon, 24 Jul 2017 10:53:16 +0100 > Igor Druzhinin <igor.druzhi...@citrix.com> wrote: >>> [Zhang, Xiong Y] Thanks for your suggestion. >>> Indeed, if I set mmi_hole >= 4G - RMRR_Base, this could fix my issue.

Re: [Xen-devel] [Bug] Intel RMRR support with upstream Qemu

On 24/07/17 09:07, Zhang, Xiong Y wrote: >>> On Fri, 21 Jul 2017 10:57:55 + >>> "Zhang, Xiong Y" wrote: >>> On an intel skylake machine with upstream qemu, if I add "rdm=strategy=host, policy=strict" to hvm.cfg, win 8.1 DomU couldn't boot up and

Re: [Xen-devel] [PULL for-2.10 6/7] xen/mapcache: introduce xen_replace_cache_entry()

On 21/07/17 14:50, Anthony PERARD wrote: On Tue, Jul 18, 2017 at 03:22:41PM -0700, Stefano Stabellini wrote: From: Igor Druzhinin <igor.druzhi...@citrix.com> ... +static uint8_t *xen_replace_cache_entry_unlocked(hwaddr old_phys_addr, +

[Xen-devel] [PATCH] hvmloader, libxl: use the correct ACPI settings depending on device model

tables if it's SeaBIOS. This change saves this behavior but adds an additional way (xenstore key) to specify the correct device model if we happen to run a non-default one. Toolstack bit makes use of it. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> --- tools/firmware/hvm

[Xen-devel] [PATCH v3 0/4] xen: don't save/restore the physmap on VM save/restore

instead of allocating a new one * Patch 4: don't use xen_phys_offset_to_gaddr in non-compat mode --- Igor Druzhinin (4): xen: move physmap saving into a separate function xen/mapcache: add an ability to create dummy mappings xen/mapcache: introduce xen_replace_cache_entry() xen: don't use

[Xen-devel] [PATCH v3 3/4] xen/mapcache: introduce xen_replace_cache_entry()

xenforeignmemory_map2() call with an extended interface that was recently introduced in libxenforeignmemory [1]. [1] https://www.mail-archive.com/xen-devel@lists.xen.org/msg113007.html Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> --- configure | 18 +++

[Xen-devel] [PATCH v3 4/4] xen: don't use xenstore to save/restore physmap anymore

for compatibility reasons. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> --- hw/i386/xen/xen-hvm.c | 48 ++--- hw/i386/xen/xen-mapcache.c | 4 include/hw/xen/xen_common.h | 1 + 3 files changed, 42 insertions(+), 11 deletions(-)

[Xen-devel] [PATCH v3 1/4] xen: move physmap saving into a separate function

Non-functional change. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> Reviewed-by: Stefano Stabellini <sstabell...@kernel.org> Reviewed-by: Paul Durrant <paul.durr...@citrix.com> --- hw/i386/xen/xen-hvm.c | 57 ---

[Xen-devel] [PATCH v3 2/4] xen/mapcache: add an ability to create dummy mappings

Dummys are simple anonymous mappings that are placed instead of regular foreign mappings in certain situations when we need to postpone the actual mapping but still have to give a memory region to QEMU to play with. This is planned to be used for restore on Xen. Signed-off-by: Igor Druzhinin

Re: [Xen-devel] [PATCH v2 3/4] xen/mapcache: introduce xen_replace_cache_entry()

On 04/07/17 17:42, Paul Durrant wrote: >> -Original Message- >> From: Igor Druzhinin >> Sent: 04 July 2017 17:34 >> To: Paul Durrant <paul.durr...@citrix.com>; xen-de...@lists.xenproject.org; >> qemu-de...@nongnu.org >> Cc: sstabell...@kernel.org;

Re: [Xen-devel] [PATCH v2 3/4] xen/mapcache: introduce xen_replace_cache_entry()

On 04/07/17 17:27, Paul Durrant wrote: >> -Original Message- >> From: Igor Druzhinin >> Sent: 04 July 2017 16:48 >> To: xen-de...@lists.xenproject.org; qemu-de...@nongnu.org >> Cc: Igor Druzhinin <igor.druzhi...@citrix.com>; sstabell...@kernel

[Xen-devel] [PATCH v2 3/4] xen/mapcache: introduce xen_replace_cache_entry()

xenforeignmemory_map2() call with an extended interface that was recently introduced in libxenforeignmemory [1]. [1] https://www.mail-archive.com/xen-devel@lists.xen.org/msg113007.html Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> --- configure | 18

[Xen-devel] [PATCH v2 0/4] xen: don't save/restore the physmap on VM save/restore

the logic of xen_replace_cache_entry_unlocked to reuse the existing entry instead of allocating a new one * Patch 4: don't use xen_phys_offset_to_gaddr in non-compat mode --- Igor Druzhinin (4): xen: move physmap saving into a separate function xen/mapcache: add an ability to create dummy

[Xen-devel] [PATCH v2 4/4] xen: don't use xenstore to save/restore physmap anymore

for compatibility reasons. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> --- hw/i386/xen/xen-hvm.c | 48 ++--- include/hw/xen/xen_common.h | 1 + 2 files changed, 38 insertions(+), 11 deletions(-) diff --git a/hw/i386/xen/xen-hvm.c b/h

[Xen-devel] [PATCH v2 1/4] xen: move physmap saving into a separate function

Non-functional change. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> --- hw/i386/xen/xen-hvm.c | 57 --- 1 file changed, 31 insertions(+), 26 deletions(-) diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c index c

[Xen-devel] [PATCH v2 2/4] xen/mapcache: add an ability to create dummy mappings

Dummys are simple anonymous mappings that are placed instead of regular foreign mappings in certain situations when we need to postpone the actual mapping but still have to give a memory region to QEMU to play with. This is planned to be used for restore on Xen. Signed-off-by: Igor Druzhinin

Re: [Xen-devel] [PATCH 3/4] xen/mapcache: introduce xen_remap_cache_entry()

On 01/07/17 01:08, Stefano Stabellini wrote: > On Fri, 30 Jun 2017, Igor Druzhinin wrote: >> This new call is trying to update a requested map cache entry >> according to the changes in the physmap. The call is searching >> for the entry, unmaps it, tries to translate the addr

Re: [Xen-devel] [PATCH 2/4] xen/mapcache: add an ability to create dummy mappings

On 01/07/17 01:06, Stefano Stabellini wrote: > On Fri, 30 Jun 2017, Igor Druzhinin wrote: >> Dummys are simple anonymous mappings that are placed instead >> of regular foreign mappings in certain situations when we need >> to postpone the actual mapping but still have to gi

Re: [Xen-devel] [PATCH] xen/balloon: don't online new memory initially

On 03/07/17 16:40, Juergen Gross wrote: > When setting up the Xenstore watch for the memory target size the new > watch will fire at once. Don't try to reach the configured target size > by onlining new memory in this case, as the current memory size will > be smaller in almost all cases due to

[Xen-devel] [PATCH 2/4] xen/mapcache: add an ability to create dummy mappings

Dummys are simple anonymous mappings that are placed instead of regular foreign mappings in certain situations when we need to postpone the actual mapping but still have to give a memory region to QEMU to play with. This is planned to be used for restore on Xen. Signed-off-by: Igor Druzhinin

[Xen-devel] [PATCH 4/4] xen: don't use xenstore to save/restore physmap anymore

for compatibility reasons. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> --- hw/i386/xen/xen-hvm.c | 45 ++--- include/hw/xen/xen_common.h | 1 + 2 files changed, 35 insertions(+), 11 deletions(-) diff --git a/hw/i386/xen/xen-hvm.c b/h

[Xen-devel] [PATCH 3/4] xen/mapcache: introduce xen_remap_cache_entry()

of a new xenforeignmemory_map2() call with extended interface that was recently introduced in libxenforeignmemory [1]. [1] https://www.mail-archive.com/xen-devel@lists.xen.org/msg113007.html Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> --- configure | 18 ++

[Xen-devel] [PATCH 1/4] xen: move physmap saving into a separate function

Non-functional change. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> --- hw/i386/xen/xen-hvm.c | 57 --- 1 file changed, 31 insertions(+), 26 deletions(-) diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c index c

[Xen-devel] [PATCH 0/4] xen: don't save/restore the physmap on VM save/restore

and change it to a real one later during machine state restore. Igor Druzhinin (4): xen: move physmap saving into a separate function xen/mapcache: add an ability to create dummy mappings xen/mapcache: introduce xen_remap_cache_entry() xen: don't use xenstore to save/restore physmap anymore

[Xen-devel] [PATCH] tools/libxenforeignmemory: add xenforeignmemory_map2 function

The new function repeats the behavior of the first version except it has an extended list of arguments which are subsequently passed to mmap() call. This is needed for QEMU depriviledging. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> --- Cc: Ian Jackson <ian.jack...@eu.c

Re: [Xen-devel] Fwd: VM Live Migration with Local Storage

On 12/06/17 04:16, Bruno Alvisio wrote: > Hello, > > I think it would be beneficial to add local disk migration feature for > ‘blkback' backend since it is one of the mostly used backends. I would > like to start a discussion about the design of the machinery needed to > achieve this feature. >

Re: [Xen-devel] [PATCH] firmware/vgabios: Port PCI based VBE LFB discovery method from QEMU fork

On 13/06/17 15:04, Andrew Cooper wrote: > On 10/05/17 15:31, Igor Druzhinin wrote: >> QEMU-traditional implements non-standard VBE registers for getting LFB >> physical address from inside of VGA BIOS code. QEMU doesn't have >> those registers implemented and returns 0 when a

[Xen-devel] [PATCH] firmware/vgabios: Port PCI based VBE LFB discovery method from QEMU fork

it into ROMBIOS instead of the old one. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> --- CC: Jan Beulich <jbeul...@suse.com> CC: Andrew Cooper <andrew.coop...@citrix.com> CC: Ian Jackson <ian.jack...@eu.citrix.com> CC: Wei Liu <wei.l...@citrix.com> --- too

[Xen-devel] [PATCH v2 for-4.9] x86/mm: Fix incorrect unmapping of 2MB and 1GB pages

target order being set each time even for 2MB and 1GB mappings. This eventually breaks down an EPT structure irreversibly into 4K mappings which prevents consecutive high order mappings to this area. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> --- Changes in v2: * changed mist

Re: [Xen-devel] [PATCH for-4.9] x86/mm: Fix incorrect unmapping of 2MB and 1GB pages

On 10/05/17 11:51, George Dunlap wrote: > On 10/05/17 11:26, Jan Beulich wrote: > On 10.05.17 at 11:43, wrote: >>> --- a/xen/arch/x86/mm/p2m-ept.c >>> +++ b/xen/arch/x86/mm/p2m-ept.c >>> @@ -681,6 +681,7 @@ ept_set_entry(struct p2m_domain *p2m, unsigned long >>>

[Xen-devel] [PATCH for-4.9] x86/mm: Fix incorrect unmapping of 2MB and 1GB pages

target order being set each time even for 2MB and 1GB mappings. This eventually breaks down an EPT structure irreversibly into 4K mappings which prevents consecutive high order mappings to this area. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> --- CC: Jun Nakajima <

Re: [Xen-devel] [PATCH v5] xen: don't save/restore the physmap on VM save/restore

On 16/03/17 12:54, Igor Druzhinin wrote: > On 16/03/17 12:26, Anthony PERARD wrote: >> On Wed, Mar 15, 2017 at 04:01:19PM +0000, Igor Druzhinin wrote: >>> Saving/restoring the physmap to/from xenstore was introduced to >>> QEMU majorly in order to cover up th

Re: [Xen-devel] [PATCH v5] xen: don't save/restore the physmap on VM save/restore

On 16/03/17 12:26, Anthony PERARD wrote: > On Wed, Mar 15, 2017 at 04:01:19PM +0000, Igor Druzhinin wrote: >> Saving/restoring the physmap to/from xenstore was introduced to >> QEMU majorly in order to cover up the VRAM region restore issue. >> The sequence of restore opera

[Xen-devel] [PATCH v5] xen: don't save/restore the physmap on VM save/restore

successfully, and update the VRAM region metadata accordingly. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> --- v5: * Add an assertion and debug printf v4: * Use VGA post_load handler for vram_ptr update v3: * Modify qemu_ram_ptr_length similarly with qemu_map_ram_ptr * Add a c

[Xen-devel] [PATCH v4] xen: don't save/restore the physmap on VM save/restore

successfully, and update the VRAM region metadata accordingly. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> --- v4: * Use VGA post_load handler for vram_ptr update v3: * Modify qemu_ram_ptr_length similarly with qemu_map_ram_ptr * Add a comment explaining qemu_map_r

Re: [Xen-devel] [PATCH v3] xen: don't save/restore the physmap on VM save/restore

On 13/03/17 21:15, Stefano Stabellini wrote: > On Mon, 13 Mar 2017, Igor Druzhinin wrote: >> Saving/restoring the physmap to/from xenstore was introduced to >> QEMU majorly in order to cover up the VRAM region restore issue. >> The sequence of restore operations implie

[Xen-devel] [PATCH v3] xen: don't save/restore the physmap on VM save/restore

and update the VRAM region metadata (including previously registered pointer) accordingly. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> --- v3: * Modify qemu_ram_ptr_length similarly with qemu_map_ram_ptr * Add a comment explaining qemu_map_ram_ptr and qemu_ram_ptr_length semantic

[Xen-devel] [PATCH net v4] xen-netback: fix race condition on XenBus disconnect

In some cases during XenBus disconnect event handling and subsequent queue resource release there may be some TX handlers active on other processors. Use RCU in order to synchronize with them. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> --- v4: * Use READ_ONCE i

[Xen-devel] [PATCH v2] xen: don't save/restore the physmap on VM save/restore

and update the VRAM region metadata (including previously registered pointer) accordingly. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> --- v2: * Fix some building and coding style issues --- exec.c | 3 ++ hw/display/vga.c | 2 +- include/hw/xen/xen.h | 2 +

[Xen-devel] [PATCH net v3] xen-netback: fix race condition on XenBus disconnect

In some cases during XenBus disconnect event handling and subsequent queue resource release there may be some TX handlers active on other processors. Use RCU in order to synchronize with them. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> --- v3: * Fix unintended semantic

[Xen-devel] [PATCH] xen: don't save/restore the physmap on VM save/restore

and update the VRAM region metadata (including previously registered pointer) accordingly. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> --- exec.c | 3 ++ hw/display/vga.c | 2 +- include/hw/xen/xen.h | 2 +- xen-hvm.c

Re: [Xen-devel] [PATCH net v2] xen-netback: fix race condition on XenBus disconnect

On 06/03/17 08:58, Paul Durrant wrote: >> -Original Message- >> From: Igor Druzhinin [mailto:igor.druzhi...@citrix.com] >> Sent: 03 March 2017 20:23 >> To: net...@vger.kernel.org; xen-de...@lists.xenproject.org >> Cc: Paul Durrant <paul.durr...@citr

[Xen-devel] [PATCH net v2] xen-netback: fix race condition on XenBus disconnect

In some cases during XenBus disconnect event handling and subsequent queue resource release there may be some TX handlers active on other processors. Use RCU in order to synchronize with them. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> --- v2: * Add prot

Re: [Xen-devel] [PATCH] xen-netback: fix race condition on XenBus disconnect

On 03/03/17 09:18, Paul Durrant wrote: >> -Original Message- >> From: Igor Druzhinin [mailto:igor.druzhi...@citrix.com] >> Sent: 02 March 2017 22:57 >> To: net...@vger.kernel.org; xen-de...@lists.xenproject.org >> Cc: Paul Durrant <paul.durr...@citr

Re: [Xen-devel] [PATCH] xen-netback: fix race condition on XenBus disconnect

On 03/03/17 09:18, Paul Durrant wrote: >> -Original Message- >> From: Igor Druzhinin [mailto:igor.druzhi...@citrix.com] >> Sent: 02 March 2017 22:57 >> To: net...@vger.kernel.org; xen-de...@lists.xenproject.org >> Cc: Paul Durrant <paul.durr...@citr

[Xen-devel] [PATCH] xen-netback: fix race condition on XenBus disconnect

In some cases during XenBus disconnect event handling and subsequent queue resource release there may be some TX handlers active on other processors. Use RCU in order to synchronize with them. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> --- drivers/net/xen-netback/interface.

Re: [Xen-devel] BUG due to "xen-netback: protect resource cleaning on XenBus disconnect"

On 02/03/17 12:19, Paul Durrant wrote: >> -Original Message- >> From: Juergen Gross [mailto:jgr...@suse.com] >> Sent: 02 March 2017 12:13 >> To: Wei Liu <wei.l...@citrix.com> >> Cc: Igor Druzhinin <igor.druzhi...@citrix.com>; xen-devel > de..

[Xen-devel] [PATCH v2 0/2] xen-netback: fix memory leaks on XenBus disconnect

Just split the initial patch in two as proposed by Wei. Since the approach for locking netdev statistics is inconsistent (tends not to have any locking at all) accross the kernel we'd better to rely on our internal lock for this purpose. Igor Druzhinin (2): xen-netback: fix memory leaks

[Xen-devel] [PATCH v2 1/2] xen-netback: fix memory leaks on XenBus disconnect

Eliminate memory leaks introduced several years ago by cleaning the queue resources which are allocated on XenBus connection event. Namely, queue structure array and pages used for IO rings. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> --- drivers/net/xen-netback/xenbus.

[Xen-devel] [PATCH v2 2/2] xen-netback: protect resource cleaning on XenBus disconnect

vif->lock is used to protect statistics gathering agents from using the queue structure during cleaning. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> --- drivers/net/xen-netback/interface.c | 6 -- drivers/net/xen-netback/xenbus.c| 2 ++ 2 files changed, 6 inserti

Re: [Xen-devel] [PATCH] xen-netback: fix memory leaks on XenBus disconnect

On 12/01/17 17:51, Igor Druzhinin wrote: > Eliminate memory leaks introduced several years ago by cleaning the queue > resources which are allocated on XenBus connection event. Namely, queue > structure array and pages used for IO rings. > vif->lock is used to protect statistics g

[Xen-devel] [PATCH] xen-netback: fix memory leaks on XenBus disconnect

ing. Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com> --- drivers/net/xen-netback/interface.c | 6 -- drivers/net/xen-netback/xenbus.c| 13 + 2 files changed, 17 insertions(+), 2 deletions(-) diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xe

Re: [Xen-devel] [PATCH] trace: Fix incorrect number of pages used for trace metadata

Checked that. Tested-by: Igor Druzhinin <igor.druzhi...@citrix.com> On 30/09/16 17:12, George Dunlap wrote: On 30/09/16 17:04, Igor Druzhinin wrote: On 30/09/16 15:46, George Dunlap wrote: On 29/09/16 14:53, Igor Druzhinin wrote: As long as t_info_first_offset is calculated in ui

Re: [Xen-devel] [PATCH] trace: Fix incorrect number of pages used for trace metadata

On 30/09/16 15:46, George Dunlap wrote: On 29/09/16 14:53, Igor Druzhinin wrote: As long as t_info_first_offset is calculated in uint32_t offsets we need to multiply it by sizeof(uint32_t) in order to get the right number of pages for trace metadata. Not doing that makes it impossible to read