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
---
CC: Jun Nakajima
CC: Kevin Tian
CC: George Dunlap
CC: Jan
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
>>> gfn, mfn_t mfn,
>>> ept_e
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
---
Changes in v2:
* changed mistakenly used mfn_valid() to mfn_eq
de
it into ROMBIOS instead of the old one.
Signed-off-by: Igor Druzhinin
---
CC: Jan Beulich
CC: Andrew Cooper
CC: Ian Jackson
CC: Wei Liu
---
tools/firmware/hvmloader/Makefile | 2 +-
tools/firmware/vgabios/Makefile | 29 +++--
tools/firmware/vgabios/vbe.c | 9 ++
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 w
fted later when the rest of ROMBIOS compatibility fixes
are in place.
Signed-off-by: Igor Druzhinin
Reviewed-by: Paul Durrant
---
Changes in v3:
* move ACPI table externs into util.h
Changes in v2:
* fix insufficient allocation size of localent
---
tools/firmware/hvmloader/hvmloader.c | 2
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é
>>> ---
>>> Cc: Igor Druzhinin
>>> Cc: Jan Beulich
>>> Cc: Andrew Cooper
>>> Cc:
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:
>>>
uild_tables, so the values can be properly set in the FADT
>>> table provided to the guest.
>>>
>>> Signed-off-by: Roger Pau Monné
>>> ---
>>> Cc: Igor Druzhinin
>>> Cc: Jan Beulich
>>> Cc: Andrew Cooper
>>> Cc: Ian Jackson
of ROMBIOS compatibility fixes
are in place.
Signed-off-by: Igor Druzhinin
Reviewed-by: Paul Durrant
---
Changes in v4:
* Use V1 port location unconditionally as modern versions of
Qemu-trad use it anyway
* Change confusing comments in ioreq.h
Changes in v3:
* move ACPI table externs into util.
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
of ROMBIOS compatibility fixes
are in place.
Signed-off-by: Igor Druzhinin
Reviewed-by: Paul Durrant
---
Changes in v5:
* various refinements
Changes in v4:
* Use V1 port location unconditionally as modern versions of
Qemu-trad use it anyway
* Change confusing comments in ioreq.h
Changes in
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
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
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 original environment may hardly b
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)
>>>
>>> void vcpu_destroy(struct vcpu
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
>>> * we should disable
On 21/11/17 13:22, Jan Beulich wrote:
>>>> On 09.11.17 at 15:49, wrote:
>> See the code comment being added for why we need this.
>>
>> Reported-by: Igor Druzhinin
>> Signed-off-by: Jan Beulich
>
> I realize we aren't settled yet on where to put
On 21/11/17 15:29, Jan Beulich wrote:
>>>> On 21.11.17 at 15:07, wrote:
>> On 21/11/17 13:22, Jan Beulich wrote:
>>>>>> On 09.11.17 at 15:49, wrote:
>>>> See the code comment being added for why we need this.
>>>>
>>>>
On 09/11/17 14:49, Jan Beulich wrote:
> See the code comment being added for why we need this.
>
> Reported-by: Igor Druzhinin
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -479,7 +479,13 @@ static void vmx_
cific
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
---
tools/firmware/hvmloader/hvmloader.c | 2 --
tool
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
...
+static uint8_t *xen_replace_cache_entry_unlocked(hwaddr old_phys_addr,
+ hwaddr new_phys_addr
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 continues reboot.
Steps
On 24/07/17 17:42, Alexey G wrote:
> Hi,
>
> On Mon, 24 Jul 2017 10:53:16 +0100
> Igor Druzhinin wrote:
>>> [Zhang, Xiong Y] Thanks for your suggestion.
>>> Indeed, if I set mmi_hole >= 4G - RMRR_Base, this could fix my issue.
>>> For this I still hav
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 wrote:
>>>>> [Zhang, Xiong Y] Thanks for your suggestion.
>>>>> Indeed, if I
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
On 25/07/17 17:40, Alexey G wrote:
> On Mon, 24 Jul 2017 21:39:08 +0100
> Igor Druzhinin 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 devices will
>>> be emu
cific
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
Reviewed-by: Paul Durrant
---
Changes in v2:
* fix in
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
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
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é wrote:
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.
>
>
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
---
Cc: Ian Jackson
Cc: Wei Liu
Cc: Andrew Cooper
---
tools/libs
n 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 physm
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
---
configure | 18
hw/i386/xen/xen-mapcache.c
Non-functional change.
Signed-off-by: Igor Druzhinin
---
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 cffa7e2..d259cf7 100644
--- a/hw/i386/xen
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
t
for compatibility reasons.
Signed-off-by: Igor Druzhinin
---
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/hw/i386/xen/xen-hvm.c
index d2
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 e.g
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 give
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
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
Non-functional change.
Signed-off-by: Igor Druzhinin
---
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 cffa7e2..d259cf7 100644
--- a/hw/i386/xen
t
for compatibility reasons.
Signed-off-by: Igor Druzhinin
---
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/hw/i386/xen/xen-hvm.c
index d2
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
---
configure | 18 ++
hw/i386/xen/xen-mapcache.c
e 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 cr
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 ; sstabell...@kernel.org;
>> Anthony Perard ; Paul Durrant
On 04/07/17 17:42, Paul Durrant wrote:
>> -Original Message-
>> From: Igor Druzhinin
>> Sent: 04 July 2017 17:34
>> To: Paul Durrant ; xen-de...@lists.xenproject.org;
>> qemu-de...@nongnu.org
>> Cc: sstabell...@kernel.org; Anthony Perard ;
>> pbonz
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
Non-functional change.
Signed-off-by: Igor Druzhinin
Reviewed-by: Stefano Stabellini
Reviewed-by: Paul Durrant
---
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
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 mappings
xen/mapcache: introduce xen_replace_cache_entry()
xen:
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
---
configure | 18 +
hw/i386/xen/xen-mapcache.c
t
for compatibility reasons.
Signed-off-by: Igor Druzhinin
---
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(-)
diff --git a/hw/i386/xen/xen-
vif->lock is used to protect statistics gathering agents from using the
queue structure during cleaning.
Signed-off-by: Igor Druzhinin
---
drivers/net/xen-netback/interface.c | 6 --
drivers/net/xen-netback/xenbus.c| 2 ++
2 files changed, 6 insertions(+), 2 deletions(-)
diff --gi
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 lea
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
---
drivers/net/xen-netback/xenbus.c | 11 +++
1 file changed, 11
ing.
Signed-off-by: Igor Druzhinin
---
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/xen-netback/interface.c
index e30f
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
On 13/01/17 10:38, Wei Liu wrote:
> On Thu, Jan 12, 2017 at 05:51:56PM +0000, 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 pa
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 the trace
buffer correctly from userspace for some corner cases.
Signed-off-by: Igor
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
Checked that.
Tested-by: Igor Druzhinin
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 uint32_t offsets we
need to
multiply it
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
>> Cc: Igor Druzhinin ; xen-devel > de...@lists.xenproject.org>; Linux Kernel Mailing
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
---
drivers/net/xen-netback/interface.c | 13 -
drivers/net
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 ; jgr...@suse.com; Wei Liu
&
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 ; jgr...@suse.com; Wei Liu
&
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
---
v2:
* Add protection for xenvif_get_ethtool_stats
* Additional
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 ; jgr...@suse.com; Wei Liu
&
ddress and update the VRAM region metadata (including
previously registered pointer) accordingly.
Signed-off-by: Igor Druzhinin
---
exec.c | 3 ++
hw/display/vga.c | 2 +-
include/hw/xen/xen.h | 2 +-
xen-hvm.c| 114
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
---
v3:
* Fix unintended semantic change in xenvif_get_ethtool_stats
ddress and update the VRAM region metadata (including
previously registered pointer) accordingly.
Signed-off-by: Igor Druzhinin
---
v2:
* Fix some building and coding style issues
---
exec.c | 3 ++
hw/display/vga.c | 2 +-
include/hw/xen/xen.h | 2 +-
xen-hvm-stub.c
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
---
v4:
* Use READ_ONCE instead of rcu_dereference to stop sparse
ddress and update the VRAM region metadata (including
previously registered pointer) accordingly.
Signed-off-by: Igor Druzhinin
---
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 change for Xen
* Dr
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 implies that
this time successfully, and update the VRAM region
metadata accordingly.
Signed-off-by: Igor Druzhinin
---
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_ram_ptr and qemu_ram_ptr_length
this time successfully, and update the VRAM region
metadata accordingly.
Signed-off-by: Igor Druzhinin
---
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 comment explaining qemu_m
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
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 the VRAM re
78 matches
Mail list logo
